Lines Matching +full:firmware +full:- +full:clocks
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
51 and x86 would end up using completely different code paths in both firmware
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
85 vendors would still end up providing two completely separate firmware
86 interfaces -- one for Linux and one for Windows.
90 --------------------
94 kernel and firmware to agree on a consistent abstraction that can be
101 -- it's baseline. ACPI firmware must continue to work, even though it may
105 older kernel versions. Further, ACPI firmware must also work with the most
110 -----------------------------
123 -------------------------
153 ACPI tables provided by the system firmware; the ACPI core will then traverse
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
231 Clocks provide an excellent example. In DT, clocks need to be specified
240 In DT, the parameters needed by the driver to set up clocks as in the example
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
266 of quite a few firmware problems and is not recommended.
274 - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
276 - https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
290 synthesize the definition of a binding so it can be used in any firmware,
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,
363 Clocks chapter
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
370 When the kernel boots, the clocks are assumed to be set to reasonable
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
375 methods to be expected). The only exceptions to this are CPU clocks where
376 CPPC provides a much richer interface than ACPI methods. If the clocks
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 ----------
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