Documentation/arm64/arm-acpi.rst

7 Base Boot Requirements) [1] specifications.  Please note that the SBBR
22 industry-standard ARMv8 servers, they also apply to more than one operating
24 ACPI and Linux only, on an ARMv8 system -- that is, what Linux expects of
29 ----------------
32 exist in Linux for describing non-enumerable hardware, after all.  In this
39 -  ACPI’s byte code (AML) allows the platform to encode hardware behavior,
44 -  ACPI’s OSPM defines a power management model that constrains what the
48 -  In the enterprise server environment, ACPI has established bindings (such
54 -  Choosing a single interface to describe the abstraction between a platform
60 -  The new ACPI governance process works well and Linux is now at the same
86 interfaces -- one for Linux and one for Windows.
90 --------------------
101 -- it's baseline.  ACPI firmware must continue to work, even though it may
110 -----------------------------
114 At boot time the kernel will only use one description method depending on
115 parameters passed from the boot loader (including kernel bootargs).
123 -------------------------
124 The only defined method for passing ACPI tables to the kernel on ARMv8
126 means that ACPI is only supported on platforms that boot via UEFI.
132 In neither is available, the kernel will not boot.  If acpi=force is used
135 the kernel will not fail to boot unless it absolutely has no other choice.
143 is used, the kernel will disable ACPI and try to use DT to boot instead; the
158 for 32-bit addresses.
160 Further, the ACPI core will only use the 64-bit address fields in the FADT
161 (Fixed ACPI Description Table).  Any 32-bit address fields in the FADT will
174     -  RSDP (Root System Description Pointer), section 5.2.5
176     -  XSDT (eXtended System Description Table), section 5.2.8
178     -  FADT (Fixed ACPI Description Table), section 5.2.9
180     -  DSDT (Differentiated System Description Table), section
183     -  MADT (Multiple APIC Description Table), section 5.2.12
185     -  GTDT (Generic Timer Description Table), section 5.2.24
187     -  If PCI is supported, the MCFG (Memory mapped ConFiGuration
188        Table), section 5.2.6, specifically Table 5-31.
190     -  If booting without a console=<device> kernel parameter is
192        section 5.2.6, specifically Table 5-31.
194     -  If necessary to describe the I/O topology, SMMUs and GIC ITSs,
196        Table 5-31).
198     -  If NUMA is supported, the SRAT (System Resource Affinity Table)
203 able to boot properly since it may not be able to configure all of the
210 --------------
216 In non-driver code, if the presence of ACPI needs to be detected at
222 ------------------
226 ACPI can be useful -- the driver takes into account that it may have less
235 value, this can be done in an ACPI method; all the driver needs to do is
236 invoke the method and not concern itself with what the method needs to do
238 by changing what the ACPI method does, and not the driver.
246 are always multiple ways to describe the same thing -- including device
252 wide registry that maintains a list of names, minimizing re-use; (3)
254 again making re-use difficult; and (4) how does one maintain backward
255 compatibility as new hardware comes out?  The _DSD method was created
257 use the _DSD method for device properties and nothing else.
274    - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
276    - https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
315 ------------------------------------
325 get that to work, ACPI assumes each device has defined D-states and that these
327 in ACPI, _PS0 is the method to invoke to turn a device full on, and _PS3 is for
332    -  be managed in a _PSx method which gets called on entry to power
335    -  be declared separately as power resources with their own _ON and _OFF
336       methods.  They are then tied back to D-states for a particular device
344    -  If either _PS0 or _PS3 is implemented, then the other method must also
347    -  If a device requires usage or setup of a power resource when on, the ASL
348       should organize that it is allocated/enabled using the _PS0 method.
350    -  Resources allocated or enabled in the _PS0 method should be disabled
351       or de-allocated in the _PS3 method.
353    -  Firmware will leave the resources in a reasonable state before handing
358 and avoid having to read special non-standard values from ACPI tables. Further,
364 ------
365 ACPI makes the assumption that clocks are initialized by the firmware --
366 UEFI, in this case -- to some working value before control is handed over
367 to the kernel.  This has implications for devices such as UARTs, or SoC-driven
371 working values.  If for some reason the frequency needs to change -- e.g.,
372 throttling for power management -- the device driver should expect that
373 process to be abstracted out into some ACPI method that can be invoked
379 If an SoC vendor wants to provide fine-grained control of the system clocks,
389 ----------------------
393 DO try to structure the driver so that it is data-driven.  That is, set up
394 a struct containing internal per-device state based on defaults and whatever
416          struct device_node node = pdev->dev.of_node;
421          else if (ACPI_HANDLE(&pdev->dev))
448 ----
451 the changes being driven by ARM-specific requirements.  Proposed changes are
463 If this is because of errors, quirks and fix-ups may be necessary, but will
472 ----------
478                        an ACPI method invokes the _OS method.  On ARM64
486 ------------
492 ----------
494     document ARM-DEN-0029, or newer:
498     Document ARM-DEN-0044A, or newer: "Server Base Boot Requirements, System
506     http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Seattle_ACPI_Guide.pdf
523 -------
524 - Al Stone <al.stone@linaro.org>
525 - Graeme Gregory <graeme.gregory@linaro.org>
526 - Hanjun Guo <hanjun.guo@linaro.org>
528 - Grant Likely <grant.likely@linaro.org>, for the "Why ACPI on ARM?" section