Lines Matching +full:hardware +full:- +full:driven
12 The Arm kernel implements the reduced hardware model of ACPI version
20 specifications, then ACPI may not be a good fit for the hardware.
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,
41 while DT explicitly does not support this. For hardware vendors, being
43 system releases on new hardware.
45 - ACPI’s OSPM defines a power management model that constrains what the
47 flexibility in hardware design.
49 - In the enterprise server environment, ACPI has established bindings (such
55 - Choosing a single interface to describe the abstraction between a platform
56 and an OS is important. Hardware vendors would not be required to implement
61 - The new ACPI governance process works well and Linux is now at the same
62 table as hardware vendors and other OS vendors. In fact, there is no
67 changes being made to ACPI are being driven by Linux.
70 responsibility for hardware behaviour cannot solely be the domain of the
73 to understand all the minute details of the hardware so that the OS doesn’t
75 hardware vendors to take responsibility for power management behaviour without
78 ACPI is also important because hardware and OS vendors have already worked
85 the hardware vendors need, Microsoft won’t collaborate on DT, and hardware
87 interfaces -- one for Linux and one for Windows.
91 --------------------
94 software and hardware are often used for long periods. ACPI allows the
96 maintained over time, even as hardware or software change. As long as the
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
165 Hardware reduced mode (see Section 4.1 of the ACPI 6.1 specification) will
168 hardware from other architectures. Any fields that are not to be used for
169 hardware reduced mode must be set to zero.
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
285 If done properly in the driver, the hardware can change and improve over
294 to change the clock. Changing the hardware can then take place over time
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
312 compatibility as new hardware comes out? The _DSD method was created
331 - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
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,
414 abstracting the use of these resources allows the hardware to change over time
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