Lines Matching +full:locality +full:- +full:specific
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
45 platform is allowed to do into a specific model, while still providing
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 --------------------
100 definition ends up requiring a specific version of the ACPI specification
101 -- it's baseline. ACPI firmware must continue to work, even though it may
110 -----------------------------
123 -------------------------
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)
199 and SLIT (System Locality distance Information Table), sections
206 tables from section 18) to support specific functionality.
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
271 how specific data structures are defined by specific UUIDs. Linux should
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
356 Such code in _PSx methods will of course be very platform specific. But,
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,
384 to a very specific SoC, or tie an SoC to a very specific version of the
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
403 /* DT specific functionality */
409 /* ACPI specific functionality */
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 ----------
473 Individual items specific to Linux on ARM, contained in the Linux
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
515 Specific Data) Implementation Guide"
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