Lines Matching refs:of
7 This article describes how Linux uses the device tree. An overview of
15 is a description of hardware that is readable by an operating system
16 so that the operating system doesn't need to hard code details of the
20 nodes may have an arbitrary number of named properties encapsulating
22 links from one node to another outside of the natural tree structure.
24 Conceptually, a common set of usage conventions, called 'bindings',
30 maximize use of existing support code, but since property and node
33 however, of creating a new binding without first doing some homework
41 The DT was originally created by Open Firmware as part of the
44 Device Tree to discover the topology of the hardware at runtime, and
45 thereby support a majority of available hardware without hard coded
54 powerpc platforms, regardless of whether or not they used Open
65 all architectures. At the time of this writing, 6 mainlined
67 out of mainline (nios) have some level of DT support.
83 setup decisions based on data passed into the kernel instead of on
87 duplication and make it easier to support a wide range of hardware
105 In the majority of cases, the machine identity is irrelevant, and the
116 The 'compatible' property contains a sorted list of strings starting
117 with the exact name of the machine, followed by an optional list of
127 of SoCs in general. You'll notice that the list is sorted from most
133 high level of change from one board to another, even within the same
136 better to err on the side of caution and not claim one board is
146 any of the dt_compat list entries appear in the compatible property.
148 machine. After searching the entire table of machine_descs,
154 of cases, a single machine_desc can support a large number of boards
155 if they all use the same SoC, or same family of SoCs. However,
160 becomes ugly and/or unmaintainable if it is more than just a couple of
164 support for a wide common set of boards by specifying "less
174 However, this approach does not take into account the priority of the
180 In most cases, a DT will be the sole method of communicating data from
183 of an initrd image.
185 Most of this data is contained in the /chosen node, and when booting
195 properties define the address and size of an initrd blob. Note that
197 match the usual semantic of struct resource. The chosen node may also
198 optionally contain an arbitrary number of additional properties for
209 location of usable RAM.
212 scanning of the device tree after selecting the correct machine_desc
223 on ARM. The remainder of this section uses examples from the ARM
230 doesn't materially change the behaviour of either of these functions.
232 to call any of the DT query functions (of_* in include/linux/of*.h) to
238 embedded platforms by defining a set of static clock structures,
241 instead of hard coding static devices for each platform, the list of
246 registering a block of platform_devices. A platform_device is a concept
250 platform devices roughly correspond to device nodes at the root of the
251 tree and children of simple memory mapped bus nodes.
253 About now is a good time to lay out an example. Here is part of the
321 of device each node represents, or even if a node represents a device
324 considered a device). The children of the /soc node are memory mapped
331 The trick is that the kernel starts at the root of the tree and looks
334 of some kind, and second, it can be assumed that any node at the root
335 of the tree is either directly attached to the processor bus, or is a
337 For each of these nodes, Linux allocates and registers a
342 assume that its devices are children of a bus controller. For
343 example, each i2c_client is a child of an i2c_master. Each spi_device
344 is a child of an SPI bus. Similarly for USB, PCI, MDIO, etc. The
346 ever appear as children of an I2C bus node. Ditto for SPI, MDIO, USB,
347 etc. The only devices which do not require a specific type of parent
349 later), which will happily live at the base of the Linux /sys/devices
350 tree. Therefore, if a DT node is at the root of the tree, then it
354 to kick off discovery of devices at the root of the tree. The
355 parameters are all NULL because when starting from the root of the
363 what about the children of the SoC node? Shouldn't they be registered
370 SoC node and simply registers platform_devices for each of its
376 Actually, it turns out that registering children of some
396 [Need to add discussion of adding i2c/spi/etc child devices]
401 ARM Primecells are a certain kind of device attached to the ARM AMBA
407 siblings of the same bus segment.
414 of_platform_populate() will register it as an amba_device instead of a