Lines Matching refs:DT

38    while DT explicitly does not support this.  For hardware vendors, being
47    as for RAS) which are currently used in production systems.  DT does not.
48    Such bindings could be defined in DT at some point, but doing so means ARM
54    both DT and ACPI if they want to support multiple operating systems.  And,
78 in place.  DT does exactly what Linux needs it to when working with vertically
80 server vendors need.  Linux could potentially get there with DT, but doing so
82 the hardware vendors need, Microsoft won’t collaborate on DT, and hardware
110 exclusive with DT support at compile time.
115 Regardless of whether DT or ACPI is used, the kernel must always be capable
126 When an ARMv8 system boots, it can either have DT information, ACPI tables,
128 the kernel will try to use DT for device enumeration; if there is no DT
132 fall back to DT if there are no ACPI tables present.  The basic idea is that
141 is used, the kernel will disable ACPI and try to use DT to boot instead; the
215 Clocks provide an excellent example.  In DT, clocks need to be specified
224 In DT, the parameters needed by the driver to set up clocks as in the example
235 names ("KEY0") to four characters unlike DT; (2) there is no industry
269 as DT bindings, or the UEFI Forum as device properties.  While we do not want
270 to simply move all DT bindings into ACPI device properties, we can learn from
275 both DT bindings and ACPI device properties for device drivers have review
293 whether DT or ACPI is being used.  This API should be used [6]; it can
295 discourage divergence between DT bindings and ACPI device properties.
374 DO NOT remove any DT handling when adding ACPI support for a driver.  The
381 allow most divergence between ACPI and DT functionality to be kept local to
387        /* DT specific functionality */
415 clear the different names the driver is probed for, both from DT and from