Lines Matching +full:in +full:- +full:tree
1 .. SPDX-License-Identifier: GPL-2.0
7 The Linux usage model for device tree data
11 This article describes how Linux uses the device tree. An overview of
12 the device tree data format can be found on the device tree usage page
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
26 links from one node to another outside of the natural tree structure.
29 is defined for how data should appear in the tree to describe typical
41 already being enumerated in existing systems.
44 ----------
48 Device Tree to discover the topology of the hardware at runtime, and
54 Device Tree.
56 In 2005, when PowerPC Linux began a major cleanup and to merge 32-bit
57 and 64-bit support, the decision was made to require DT support on all
60 Tree (FDT) was created which could be passed to the kernel as a binary
61 blob without requiring a real Open Firmware implementation. U-Boot,
63 Device Tree Binary (dtb) and to modify a dtb at boot time. DT was
66 existing non-DT aware firmware.
74 -------------
75 If you haven't already read the Device Tree Usage\ [1]_ page,
79 -------------------
84 hardware configuration from the board and device driver support in the
88 per-machine hard coded selections.
90 Ideally, data driven platform setup should result in less code
101 ---------------------------
102 First and foremost, the kernel will use data in the DT to identify the
103 specific machine. In a perfect world, the specific platform shouldn't
105 perfectly by the device tree in a consistent and reliable manner.
108 machine-specific fixups.
110 In the majority of cases, the machine identity is irrelevant, and the
112 CPU or SoC. On ARM for example, setup_arch() in
113 arch/arm/kernel/setup.c will call setup_machine_fdt() in
115 table and selects the machine_desc which best matches the device tree
117 property in the root device tree node, and comparing it with the
118 dt_compat list in struct machine_desc (which is defined in
127 compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3";
128 compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3";
130 Where "ti,omap3-beagleboard-xm" specifies the exact model, it also
132 of SoCs in general. You'll notice that the list is sorted from most
146 One more note on compatible values. Any string used in a compatible
148 documentation for compatible strings in Documentation/devicetree/bindings.
151 any of the dt_compat list entries appear in the compatible property.
155 on which entry in the compatible property each machine_desc matches
158 The reasoning behind this scheme is the observation that in the majority
162 require special setup code that is not useful in the generic case.
164 troublesome board(s) in generic setup code, but doing so very quickly
170 compatible" values in the dt_compat list. In the example above,
175 matches on "ti,omap3-beagleboard".
184 -------------------------
185 In most cases, a DT will be the sole method of communicating data from
186 firmware to the kernel, so also gets used to pass in runtime and
190 Most of this data is contained in the /chosen node, and when booting
195 initrd-start = <0xc8000000>;
196 initrd-end = <0xc8200000>;
199 The bootargs property contains the kernel arguments, and the initrd-*
201 initrd-end is the first address after the initrd image, so this doesn't
204 platform-specific configuration data.
207 several times with different helper callbacks to parse device tree
209 the device tree and uses the helpers to extract information required
217 scanning of the device tree after selecting the correct machine_desc
221 ---------------------
223 has been parsed, then kernel initialization can proceed in the normal
224 way. At some point in this process, unflatten_device_tree() is called
226 This is also when machine-specific setup hooks will get called, like
232 As can be guessed by the names, .init_early() is used for any machine-
233 specific setup that needs to be executed early in the boot process,
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
244 platform_devices, and other data in the board support .c file, and
245 registering it en-masse in .init_machine(). When DT is used, then
256 tree and children of simple memory mapped bus nodes.
259 device tree for the NVIDIA Tegra board::
263 #address-cells = <1>;
264 #size-cells = <1>;
265 interrupt-parent = <&intc>;
276 compatible = "nvidia,tegra20-soc", "simple-bus";
277 #address-cells = <1>;
278 #size-cells = <1>;
281 intc: interrupt-controller@50041000 {
282 compatible = "nvidia,tegra20-gic";
283 interrupt-controller;
284 #interrupt-cells = <1>;
289 compatible = "nvidia,tegra20-uart";
295 compatible = "nvidia,tegra20-i2s";
302 compatible = "nvidia,tegra20-i2c";
303 #address-cells = <1>;
304 #size-cells = <0>;
317 compatible = "nvidia,harmony-sound";
318 i2s-controller = <&i2s1>;
319 i2s-codec = <&wm8903>;
325 However, looking at the tree, it is not immediately obvious what kind
336 The trick is that the kernel starts at the root of the tree and looks
340 of the tree is either directly attached to the processor bus, or is a
343 platform_device, which in turn may get bound to a platform_driver.
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
359 to kick off discovery of devices at the root of the tree. The
361 tree, there is no need to provide a starting node (the first NULL), a
367 In the Tegra example, this accounts for the /soc and /sound nodes, but
378 and register platform_devices for /soc/interrupt-controller, /soc/serial,
379 /soc/i2s, and /soc/i2c in its .probe() hook. Easy, right?
383 device tree support code reflects that and makes the above example
385 of_device_id table, and any node that matches an entry in that table
386 will also get its child nodes registered. In the Tegra case, the code
395 "simple-bus" is defined in the Devicetree Specification as a property
397 could be written to just assume simple-bus compatible nodes will
398 always be traversed. However, we pass it in as an argument so that
404 ------------------------
408 management. In Linux, struct amba_device and the amba_bus_type is