Lines Matching refs:and

1 Linux and the Device Tree
14 structure and language for describing hardware.  More specifically, it
19 Structurally, the DT is a tree, or acyclic graph with named nodes, and
27 connections, and peripheral devices.
30 maximize use of existing support code, but since property and node
32 or create new ones by defining new nodes and properties.  Be wary,
44 Device Tree to discover the topology of the hardware at runtime, and
48 Since Open Firmware is commonly used on PowerPC and SPARC platforms,
52 In 2005, when PowerPC Linux began a major cleanup and to merge 32-bit
53 and 64-bit support, the decision was made to require DT support on all
58 kexec, and other bootloaders were modified to support both passing a
59 Device Tree Binary (dtb) and to modify a dtb at boot time.  DT was
66 architectures (arm, microblaze, mips, powerpc, sparc, and x86) and 1
78 it, and it doesn't magically make all hardware configuration problems
80 hardware configuration from the board and device driver support in the
82 it allows board and device support to become data driven; to make
87 duplication and make it easier to support a wide range of hardware
92 2) runtime configuration, and
97 First and foremost, the kernel will use data in the DT to identify the
100 perfectly by the device tree in a consistent and reliable manner.
101 Hardware is not perfect though, and so the kernel must identify the
105 In the majority of cases, the machine identity is irrelevant, and the
110 table and selects the machine_desc which best matches the device tree
112 property in the root device tree node, and comparing it with the
119 example, the root compatible properties for the TI BeagleBoard and its
126 claims that it compatible with the OMAP 3450 SoC, and the omap3 family
134 product line, and it is hard to nail down exactly what is meant when one
136 better to err on the side of caution and not claim one board is
160 becomes ugly and/or unmaintainable if it is more than just a couple of
169 machine_desc could be added which implements the workarounds and only
173 hook from each machine_desc, and the first one returning TRUE is used.
175 compatible list, and probably should be avoided for new architecture
181 firmware to the kernel, so also gets used to pass in runtime and
182 configuration data like the kernel parameters string and the location
185 Most of this data is contained in the /chosen node, and when booting
194 The bootargs property contains the kernel arguments, and the initrd-*
195 properties define the address and size of an initrd blob.  Note that
204 the device tree and uses the helpers to extract information required
208 and early_init_dt_scan_memory() to determine the size and
217 After the board has been identified, and after the early configuration data
222 the machine_desc .init_early(), .init_irq() and .init_machine() hooks
229 and .init_irq() is used to set up interrupt handling.  Using a DT
231 If a DT is provided, then both .init_early() and .init_irq() are able
239 platform_devices, and other data in the board support .c file, and
242 devices can be obtained by parsing the DT, and allocating device
248 by hardware, and for 'composite' or 'virtual' devices (more on those
251 tree and children of simple memory mapped bus nodes.
319 this DT and decide which nodes to create platform_devices for.
322 at all.  The /chosen, /aliases, and /memory nodes are informational
325 devices, but the codec@1a is an i2c device, and the sound node
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
337 For each of these nodes, Linux allocates and registers a
348 device are platform_devices (and amba_devices, but more on that
357 parent struct device (the last NULL), and we're not using a match
362 In the Tegra example, this accounts for the /soc and /sound nodes, but
368 its spi_device children, and similarly for other bus_types.
370 SoC node and simply registers platform_devices for each of its
371 children.  The board support code would allocate and register an SoC
373 and register platform_devices for /soc/interrupt-controller, /soc/serial,
374 /soc/i2s, and /soc/i2c in its .probe() hook.  Easy, right?
377 platform_devices as more platform_devices is a common pattern, and the
378 device tree support code reflects that and makes the above example
380 of_device_id table, and any node that matches an entry in that table
402 bus which include some support for hardware detection and power
403 management.  In Linux, struct amba_device and the amba_bus_type is
405 not all devices on an AMBA bus are Primecells, and for Linux it is
406 typical for both amba_device and platform_device instances to be