Lines Matching +full:dt +full:- +full:property
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
45 - ACPI’s OSPM defines a power management model that constrains what the
49 - In the enterprise server environment, ACPI has established bindings (such
50 as for RAS) which are currently used in production systems. DT does not.
51 Such bindings could be defined in DT at some point, but doing so means Arm
55 - Choosing a single interface to describe the abstraction between a platform
57 both DT and ACPI if they want to support multiple operating systems. And,
61 - The new ACPI governance process works well and Linux is now at the same
81 in place. DT does exactly what Linux needs it to when working with vertically
83 server vendors need. Linux could potentially get there with DT, but doing so
85 the hardware vendors need, Microsoft won’t collaborate on DT, and hardware
87 interfaces -- one for Linux and one for Windows.
91 --------------------
102 -- its baseline. ACPI firmware must continue to work, even though it may
111 -----------------------------
113 exclusive with DT support at compile time.
118 Regardless of whether DT or ACPI is used, the kernel must always be capable
124 -------------------------
129 When an Arm system boots, it can either have DT information, ACPI tables,
131 the kernel will try to use DT for device enumeration; if there is no DT
135 fall back to DT if there are no ACPI tables present. The basic idea is that
144 is used, the kernel will disable ACPI and try to use DT to boot instead; the
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
288 Clocks provide an excellent example. In DT, clocks need to be specified
297 In DT, the parameters needed by the driver to set up clocks as in the example
303 are always multiple ways to describe the same thing -- including device
306 then retrieve the value of the property by evaluating the KEY0 object.
308 names ("KEY0") to four characters unlike DT; (2) there is no industry
309 wide registry that maintains a list of names, minimizing re-use; (3)
310 there is also no registry for the definition of property values ("value0"),
311 again making re-use difficult; and (4) how does one maintain backward
331 - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
336 but not as "uefi-" common properties.
340 as DT bindings, or the UEFI Forum as device properties. While we do not want
341 to simply move all DT bindings into ACPI device properties, we can learn from
344 If it is necessary to define a new device property, or if it makes sense to
346 both DT bindings and ACPI device properties for device drivers have review
348 to the Linux mailing lists, the device property definitions needed must be
351 the device property has been accepted by the Linux community, it must be
354 will always be the canonical site for device property definitions.
357 intent to register a previously unused device property name as a means of
364 whether DT or ACPI is being used. This API should be used [5]; it can
366 discourage divergence between DT bindings and ACPI device 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 ----------------------
445 DO NOT remove any DT handling when adding ACPI support for a driver. The
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
452 allow most divergence between ACPI and DT functionality to be kept local to
458 /* DT specific functionality */
471 struct device_node node = pdev->dev.of_node;
476 else if (ACPI_HANDLE(&pdev->dev))
486 clear the different names the driver is probed for, both from DT and from
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
565 property interface can be found in
566 include/linux/property.h and drivers/base/property.c.
570 -------
571 - Al Stone <[email protected]>
572 - Graeme Gregory <[email protected]>
573 - Hanjun Guo <[email protected]>
575 - Grant Likely <[email protected]>, for the "Why ACPI on ARM?" section