Lines Matching +full:pull +full:- +full:ups
23 industry-standard Arm systems, they also apply to more than one operating
25 ACPI and Linux only, on an Arm system -- that is, what Linux expects of
30 ----------------
33 exist in Linux for describing non-enumerable hardware, after all. In this
40 - ACPI’s byte code (AML) allows the platform to encode hardware behavior,
45 - ACPI’s OSPM defines a power management model that constrains what the
49 - In the enterprise server environment, ACPI has established bindings (such
55 - Choosing a single interface to describe the abstraction between a platform
61 - The new ACPI governance process works well and Linux is now at the same
87 interfaces -- one for Linux and one for Windows.
91 --------------------
102 -- its baseline. ACPI firmware must continue to work, even though it may
111 -----------------------------
124 -------------------------
159 for 32-bit addresses.
161 Further, the ACPI core will only use the 64-bit address fields in the FADT
162 (Fixed ACPI Description Table). Any 32-bit address fields in the FADT will
175 - RSDP (Root System Description Pointer), section 5.2.5
177 - XSDT (eXtended System Description Table), section 5.2.8
179 - FADT (Fixed ACPI Description Table), section 5.2.9
181 - DSDT (Differentiated System Description Table), section
184 - MADT (Multiple APIC Description Table), section 5.2.12
186 - GTDT (Generic Timer Description Table), section 5.2.24
188 - PPTT (Processor Properties Topology Table), section 5.2.30
190 - DBG2 (DeBuG port table 2), section 5.2.6, specifically Table 5-6.
192 - APMT (Arm Performance Monitoring unit Table), section 5.2.6, specifically Table 5-6.
194 …- AGDI (Arm Generic diagnostic Dump and Reset Device Interface Table), section 5.2.6, specificall…
196 - If PCI is supported, the MCFG (Memory mapped ConFiGuration
197 Table), section 5.2.6, specifically Table 5-6.
199 - If booting without a console=<device> kernel parameter is
201 section 5.2.6, specifically Table 5-6.
203 - If necessary to describe the I/O topology, SMMUs and GIC ITSs,
205 Table 5-6).
207 - If NUMA is supported, the following tables are required:
209 - SRAT (System Resource Affinity Table), section 5.2.16
211 - SLIT (System Locality distance Information Table), section 5.2.17
213 - If NUMA is supported, and the system contains heterogeneous memory,
216 - If the ACPI Platform Error Interfaces are required, the following
219 - BERT (Boot Error Record Table, section 18.3.1)
221 - EINJ (Error INJection table, section 18.6.1)
223 - ERST (Error Record Serialization Table, section 18.5)
225 - HEST (Hardware Error Source Table, section 18.3.2)
227 - SDEI (Software Delegated Exception Interface table, section 5.2.6,
228 specifically Table 5-6)
230 - AEST (Arm Error Source Table, section 5.2.6,
231 specifically Table 5-6)
233 - RAS2 (ACPI RAS2 feature table, section 5.2.21)
235 - If the system contains controllers using PCC channel, the
238 - If the system contains a controller to capture board-level system state,
242 - If NVDIMM is supported, the NFIT (NVDIMM Firmware Interface Table), section 5.2.26
244 - If video framebuffer is present, the BGRT (Boot Graphics Resource Table), section 5.2.23
246 - If IPMI is implemented, the SPMI (Server Platform Management Interface),
247 section 5.2.6, specifically Table 5-6.
249 - If the system contains a CXL Host Bridge, the CEDT (CXL Early Discovery
250 Table), section 5.2.6, specifically Table 5-6.
252 …- If the system supports MPAM, the MPAM (Memory Partitioning And Monitoring table), section 5.2.6,
253 specifically Table 5-6.
255 - If the system lacks persistent storage, the IBFT (ISCSI Boot Firmware
256 Table), section 5.2.6, specifically Table 5-6.
267 --------------
273 In non-driver code, if the presence of ACPI needs to be detected at
279 ------------------
283 ACPI can be useful -- the driver takes into account that it may have less
303 are always multiple ways to describe the same thing -- including device
309 wide registry that maintains a list of names, minimizing re-use; (3)
311 again making re-use difficult; and (4) how does one maintain backward
331 - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
333 Common device properties can be registered by creating a pull request to [4] so
336 but not as "uefi-" common properties.
370 ------------------------------------
380 get that to work, ACPI assumes each device has defined D-states and that these
387 - be managed in a _PSx method which gets called on entry to power
390 - be declared separately as power resources with their own _ON and _OFF
391 methods. They are then tied back to D-states for a particular device
399 - If either _PS0 or _PS3 is implemented, then the other method must also
402 - If a device requires usage or setup of a power resource when on, the ASL
405 - Resources allocated or enabled in the _PS0 method should be disabled
406 or de-allocated in the _PS3 method.
408 - Firmware will leave the resources in a reasonable state before handing
413 and avoid having to read special non-standard values from ACPI tables. Further,
419 ------
420 ACPI makes the assumption that clocks are initialized by the firmware --
421 UEFI, in this case -- to some working value before control is handed over
422 to the kernel. This has implications for devices such as UARTs, or SoC-driven
426 working values. If for some reason the frequency needs to change -- e.g.,
427 throttling for power management -- the device driver should expect that
434 If an SoC vendor wants to provide fine-grained control of the system clocks,
444 ----------------------
448 DO try to structure the driver so that it is data-driven. That is, set up
449 a struct containing internal per-device state based on defaults and whatever
471 struct device_node node = pdev->dev.of_node;
476 else if (ACPI_HANDLE(&pdev->dev))
503 ----
506 the changes being driven by Arm-specific requirements. Proposed changes are
518 If this is because of errors, quirks and fix-ups may be necessary, but will
527 ----------
541 ------------
547 ----------
549 document Arm-DEN-0094: "Arm Base System Architecture", version 1.0C, dated 6 Oct 2022
552 Document Arm-DEN-0044: "Arm Base Boot Requirements", version 2.0G, dated 15 Apr 2022
555 Document Arm-DEN-0029: "Arm Server Base System Architecture", version 7.1, dated 06 Oct 2022
562 https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf
570 -------
571 - Al Stone <al.stone@linaro.org>
572 - Graeme Gregory <graeme.gregory@linaro.org>
573 - Hanjun Guo <hanjun.guo@linaro.org>
575 - Grant Likely <grant.likely@linaro.org>, for the "Why ACPI on ARM?" section