Lines Matching +full:armv8 +full:- +full:based
2 ACPI on ARMv8 Servers
5 ACPI can be used for ARMv8 general purpose servers designed to follow
11 The ARMv8 kernel implements the reduced hardware model of ACPI version
17 If an ARMv8 system does not meet the requirements of the SBSA and 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
34 reasoning behind ACPI on ARMv8 servers. Actually, we snitch a good portion
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 -----------------------------
111 ACPI support in drivers and subsystems for ARMv8 should never be mutually
123 -------------------------
124 The only defined method for passing ACPI tables to the kernel on ARMv8
128 When an ARMv8 system boots, it can either have DT information, ACPI tables,
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)
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
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
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
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
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
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
459 It is the intent of the ARMv8 ACPI kernel code to follow the ACPI specification
463 If this is because of errors, quirks and fix-ups may be necessary, but will
472 ----------
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