Documentation/devicetree/usage-model.rst

17 The "Open Firmware Device Tree", or simply Devicetree (DT), is a data
23 Structurally, the DT is a tree, or acyclic graph with named nodes, and
45 The DT was originally created by Open Firmware as part of the
57 and 64-bit support, the decision was made to require DT support on all
59 Firmware.  To do this, a DT representation called the Flattened Device
63 Device Tree Binary (dtb) and to modify a dtb at boot time.  DT was
66 existing non-DT aware firmware.
71 out of mainline (nios) have some level of DT support.
80 The most important thing to understand is that the DT is simply a data
94 Linux uses DT data for three major purposes:
102 First and foremost, the kernel will use data in the DT to identify the
185 In most cases, a DT will be the sole method of communicating data from
212 early_init_dt_scan_root() to initialize the DT address space model,
230 thing when using a DT.
234 and .init_irq() is used to set up interrupt handling.  Using a DT
236 If a DT is provided, then both .init_early() and .init_irq() are able
237 to call any of the DT query functions (of_* in include/linux/of*.h) to
240 The most interesting hook in the DT context is .init_machine() which
245 registering it en-masse in .init_machine().  When DT is used, then
247 devices can be obtained by parsing the DT, and allocating device
254 later).  While there is no 'platform device' terminology for the DT,
324 this DT and decide which nodes to create platform_devices for.
350 same hierarchy is also found in the DT, where I2C device nodes only
355 tree.  Therefore, if a DT node is at the root of the tree, then it
369 as platform devices too?  For Linux DT support, the generic behaviour
414 When using the DT, this creates problems for of_platform_populate()