ACPI spec is x86 oriented thus it use NMI for error reporting as low latency
error signalling way. Fast response to error occurrance is what ARM trying to
satisfy using interrupt prioritization since there is no NMI direct equivalent
for ARM architecture.
Patch set are divided into three step:
1. Create generic code responsible for setting interrupt priority.
2. Use it in interrupt setup.
3. Example of interrupt controller priority mapping for GIC platform dependent
code.
Patch set tries to meet requirements like:
- not breaking existing code
- easy to expand to new priority levels
- easy to map generic priority levels to platform dependent priority values
See commit logs for more detailed explanation.
From: Al Stone <ahs3(a)redhat.com>
This is the first in a series to eventually convert all of the Arndale
GPIO controllers to ACPI. This is the proposed ACPI description meant
to match what is done in DT, but is very specific to the Samsung driver.
Signed-off-by: Al Stone <al.stone(a)linaro.org>
---
platforms/exynos5250-arndale.acpi/ssdt0.asl | 64 ++++++++++++++++++++++++++++-
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/platforms/exynos5250-arndale.acpi/ssdt0.asl b/platforms/exynos5250-arndale.acpi/ssdt0.asl
index 69dce10..8b8efc7 100644
--- a/platforms/exynos5250-arndale.acpi/ssdt0.asl
+++ b/platforms/exynos5250-arndale.acpi/ssdt0.asl
@@ -12,6 +12,68 @@ DefinitionBlock (
2, // SSDT compliance revision
"LINARO", // OEM ID
"ARNDALE ", // table ID
- 0x00000001) // OEM revision
+ 0x00000003) // OEM revision
{
+ Scope (\_SB)
+ {
+ // Base Address: 0x03860000
+ Device (SPC3) // Samsung pin controller
+ {
+ Name (_HID, "LINA0002")
+ Name (_UID, 0x3)
+
+ Name (BNKS, 0x1) // number of pin banks
+ Name (NGRP, 0x1) // number of pin groups
+ Name (NFUN, 0x1) // number of pinmux functions
+
+ Method (_CRS, 0x0, Serialized)
+ {
+ // Base address for the pin controller
+ Name (RBUF, ResourceTemplate ()
+ {
+ Memory32Fixed (ReadWrite,
+ 0x03860000,
+ 0x20)
+ })
+ Return (RBUF)
+ }
+
+ Device (GPZ) // GPIO chip GPZ -- first bank
+ {
+ Name (TAG, "gpz") // human-readable name
+ Name (BASE, 0x0) // base pin number
+ Name (NPIN, 0x7) // number of pins
+
+ // We need _CRS here in order to provide
+ // the actual registers for this part of
+ // the controller
+ Method (_CRS, 0x0, Serialized)
+ {
+ Name (RBUF, ResourceTemplate ()
+ {
+ Memory32Fixed (ReadWrite,
+ 0x03860000,
+ 0x20)
+ })
+ Return (RBUF)
+ }
+ }
+
+ Device (I2S0) // First Pin Group
+ {
+ Name (NPIN, 0x7) // number of pins
+ Name (FUNC, 0x2) // function number
+ Name (PUD, 0x0) // direction
+ Name (DRV, 0x0) // drive
+ Method (PINS, 0x0, NotSerialized)
+ {
+ Return (Package () {
+ "gpz-0", "gpz-1", "gpz-2",
+ "gpz-3", "gpz-4", "gpz-5",
+ "gpz-6"
+ })
+ }
+ }
+ }
+ }
}
--
1.8.3.1
From: Al Stone <ahs3(a)redhat.com>
While trying to figure out some problems I was having with my ACPI
blobs, I ran into several things that needed fixing in mab. Some of
these are innocuous, but some -- like using both 32- and 64-bit addresses
in the FACS, and the RSDP checksums -- are actually in violation of the
spec.
While I was there, I added a little more info in the verbose output,
and corrected what was being printed out.
The new feature is that one can now use -H to produce a blob that does
not have the header we've been using so far.
Changes from v1:
-- This time, I actually _remembered_ to run checkpatch, so cleaned
up the extra whitespace in patch 7/7.
Al Stone (7):
mab: Makefile needs to rebuild if .h changes and use CFLAGS properly
mab: use 32- or 64-bit FACS addresses in the FADT, not both
mab: set both checksums in the RSDP, not just one
mab: print out the correct offset in the blob
mab: add option to NOT use a blob header, if needed
mab: print out physical address when being verbose
mab: update Changelog and version number for this patch series
tools/mab/Changelog | 19 +++++++++
tools/mab/Makefile | 6 +--
tools/mab/mab.c | 109 +++++++++++++++++++++++++++++++---------------------
tools/mab/mab.h | 5 ++-
4 files changed, 91 insertions(+), 48 deletions(-)
--
1.8.3.1
Hi,
Lots of people from different companies are concerned about ACPI vs FDT, not only Linaro,
This is a good news for us.
They will discuss it in person in New Orleans at Linux Plumber (September, 2013)
Al, Graeme, will you attend Linux Plumber next month?
Thanks
Hanjun
-------- Original Message --------
Subject: ACPI vs Device Tree - moving forward
Date: Tue, 20 Aug 2013 20:26:50 +0100
From: Matthew Garrett <mjg59(a)srcf.ucam.org>
To: <linux-kernel(a)vger.kernel.org>, <linux-acpi(a)vger.kernel.org>
CC: <linux(a)roeck-us.net>, <dvhart(a)linux.intel.com>, <hpa(a)zytor.com>, <linus.walleij(a)linaro.org>, <rjw(a)sisk.pl>
This conversation seems to have pretty much entirely ended up happening
on ksummit-discuss, which doesn't seem that useful. So let's have
another go with a wider audience (and where I don't have to sign up for
yet another mailing list...)
ACPI and DT overlap in that they both provide a mechanism for
enumerating non-enumerable devices, and both also provide a mechanism
for attaching additional configuration data to devices (which may or may
not be otherwise enumerable). There's a sufficient overlap in
functionality that at least one platform that's traditionally been
Device Tree (arm) is also adding support for ACPI - there's even
ACPI-based arm hardware on the market already.
Right now that's a problem for us. The same hardware may end up shipped
with either ACPI or DT-based firmware, and at the moment we'd need to
either write two drivers or one driver with two glue layers. This is
somewhat suboptimal.
The biggest difference between DT and ACPI is that DT is effectively a
somewhat structured mechanism for passing arbitrary data, while ACPI
tends (with exceptions) to provide standardised data. For instance, in
DT we might have:
sdhci@c8000000 {
status = "okay";
power-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_HIGH>;
bus-width = <4>;
keep-power-in-suspend;
};
In ACPI the normal way to handle this would be to have a GPIO operation
region that listed the GPIOs:
OperationRegion(GPO1, GeneralPurposeIO, 0, 1)
Field(GP01, ByteAcc, NoLock, Preserve)
{
Connection (GpioIo(Exclusive, PullUp,,,,,)
TG06, 1
}
And then an ACPI device:
Device (\_SB.SDHC)
{
Method (_PS0, 0, NotSerialized)
{
Store (1, TG06)
}
Method (_PS3, 0, NotSerialized)
{
Store (0, TG06)
}
}
with the ACPI core then executing these methods whenever a device is
powered up or down.
How can we unify these two different representations? The only terribly
plausible way of doing so seems to be to push that out to a helper
function and then have it handled as part of device runtime power
management, and just have the driver make pm_runtime_get() and _put()
calls.
So we can theoretically handle cases like power lines without /too/ much
trouble, while representing the same thing in either ACPI or DT. But we
have plenty of other data - in the case of SDHCI alone, there's the bus
width and potentially card detect and write protect gpio lines. These
can easily be represented in ACPI, but not in a terribly generic way. We
could easily add new functions to retrieve this information, but doing
this through the standards body is likely to prove tedious, especially
when new hardware types appear and we want to be able to ship support
pretty much immediately.
The other choice is to ignore most of the existing ACPI functionality
and just use it as a mechanism for providing additional metadata. Apple
already do this using the _DSM methods:
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x07)
{
"refnum",
0x00,
"address",
0x39,
"device-id",
0x0cc8,
Buffer (0x01)
{
0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
where the DTGP() method verifies that the caller passed in an
appropriate UUID and then hands back this buffer.
Putting all our existing DT metadata in there would be straightforward,
but we would then effectively just be using ACPI to repackage DT -
drivers would continue to make DT-specific calls in order to obtain the
information they need.
This seems like the least-effort approach, but it doesn't really solve
much. Any other OS on the same hardware is unlikely to use the DT data,
and if someone wants to run Linux on hardware that was intended for
another OS they're unlikely to have any DT data to use.
So while unifying this seems hugely desirable, right now it's not
incredibly obvious how we can actually achieve that. In some cases it's
easy to take DT information and rewrite it the ACPI way, but in others
we just don't seem to have the primitives we need for that. One approach
would be to work through the existing DT bindings documentation and see
what's missing from ACPI and work on adding it, but we'll still then
need helper functions that are able to obtain the same information from
either source.
In any case, it seems like this is something that should be discussed. A
bunch of people in the earlier discussion mentioned that they were going
to be in New Orleans, so I'd suggest that we arrange a time for
in-person discussion there. That should give us a solid basis for
further mailing list discussion, and then there'll be another
opportunity for discussion in Edinburgh.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
From: Naresh Bhat <naresh.bhat(a)linaro.org>
Signed-off-by: Naresh Bhat <naresh.bhat(a)linaro.org>
Fix comments ARMv8 foundation acpi platform
---
platforms/foundation-v8.acpi/dsdt.asl | 2 +-
platforms/foundation-v8.acpi/ssdt0.asl | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/platforms/foundation-v8.acpi/dsdt.asl b/platforms/foundation-v8.acpi/dsdt.asl
index d1a9716..69f5884 100644
--- a/platforms/foundation-v8.acpi/dsdt.asl
+++ b/platforms/foundation-v8.acpi/dsdt.asl
@@ -1,7 +1,7 @@
/*
* Copyright (c) 2013, Al Stone <al.stone(a)linaro.org>
*
- * [DSDT] Description of the Arndale board (exynos5250)
+ * [DSDT] Description of the ARMv8 foundation model
*
* This source is released under the terms of the GPLv2.
*/
diff --git a/platforms/foundation-v8.acpi/ssdt0.asl b/platforms/foundation-v8.acpi/ssdt0.asl
index 165c1ae..9796ebd 100644
--- a/platforms/foundation-v8.acpi/ssdt0.asl
+++ b/platforms/foundation-v8.acpi/ssdt0.asl
@@ -1,7 +1,7 @@
/*
* Copyright (c) 2013, Al Stone <al.stone(a)linaro.org>
*
- * [SSDT] Description of the Arndale board (exynos5250) GPIO structure
+ * [SSDT] Description of the ARMv8 foundation model GPIO structure
*
* This source is released under the terms of the GPLv2.
*/
--
1.7.9.5
From: Naresh Bhat <naresh.bhat(a)linaro.org>
Signed-off-by: Naresh Bhat <naresh.bhat(a)linaro.org>
Fix all the comments under foundation-v8.acpi platforms
---
platforms/foundation-v8.acpi/dsdt.asl | 2 +-
platforms/foundation-v8.acpi/ssdt0.asl | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/platforms/foundation-v8.acpi/dsdt.asl b/platforms/foundation-v8.acpi/dsdt.asl
index 6a5d1be..c5c692b 100644
--- a/platforms/foundation-v8.acpi/dsdt.asl
+++ b/platforms/foundation-v8.acpi/dsdt.asl
@@ -1,7 +1,7 @@
/*
* Copyright (c) 2013, Al Stone <al.stone(a)linaro.org>
*
- * [DSDT] Description of the Arndale board (exynos5250)
+ * [DSDT] Description of the foundation-v8
*
* This source is released under the terms of the GPLv2.
*/
diff --git a/platforms/foundation-v8.acpi/ssdt0.asl b/platforms/foundation-v8.acpi/ssdt0.asl
index 165c1ae..11328f9 100644
--- a/platforms/foundation-v8.acpi/ssdt0.asl
+++ b/platforms/foundation-v8.acpi/ssdt0.asl
@@ -1,7 +1,7 @@
/*
* Copyright (c) 2013, Al Stone <al.stone(a)linaro.org>
*
- * [SSDT] Description of the Arndale board (exynos5250) GPIO structure
+ * [SSDT] Description of the foundation-v8 GPIO structure
*
* This source is released under the terms of the GPLv2.
*/
--
1.7.9.5
This is only required if we are doing initrd table overiding. This is
currently disabled for arm/arm64. Remove this as allowing initrd
overiding needs fuller re-work on these platforms anyway.
Signed-off-by: Graeme Gregory <graeme.gregory(a)linaro.org>
---
arch/arm/kernel/setup.c | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 168f7c5..da3d8df 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -62,19 +62,6 @@
#include "atags.h"
-/* BOZO: clears up the missing symbol during compile, but is this
- * the right way to handle it?
- */
-/*
- * end_pfn only includes RAM, while max_pfn_mapped includes all e820 entries.
- * The direct mapping extends to max_pfn_mapped, so that we can directly access
- * apertures, ACPI and other tables without having to play with fixmaps.
- */
-unsigned long max_low_pfn_mapped;
-unsigned long max_pfn_mapped;
-
-/* END BOZO */
-
#if defined(CONFIG_FPE_NWFPE) || defined(CONFIG_FPE_FASTFPE)
char fpe_type[8];
--
1.7.10.4