Lines Matching +full:regulator +full:- +full:allow +full:- +full:set +full:- +full:load
21 While the documents mentioned above set out the requirements for building
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
71 order to allow for orderly change over time. ACPI frees the OS from needing
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 -----------------------------
123 -------------------------
140 In order for the kernel to load and use ACPI tables, the UEFI implementation
141 MUST set the ACPI_20_TABLE_GUID to point to the RSDP table (the table with
157 RSDTs have been deprecated and are ignored on arm64 since they only allow
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
168 hardware reduced mode must be set to zero.
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
218 set, acpi_disabled will always be 1.
222 ------------------
226 ACPI can be useful -- the driver takes into account that it may have less
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
274 - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
276 - https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
315 ------------------------------------
319 With ACPI, the kernel clock and regulator framework is not expected to be used
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
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
377 are not set, there is no direct way for Linux to control them.
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
397 allow most divergence between ACPI and DT functionality to be kept local to
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 ----------
481 can be used to set it to some other value. The
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