diff options
author | Robert P. J. Day <rpjday@crashcourse.ca> | 2013-05-30 07:49:59 -0400 |
---|---|---|
committer | Jiri Kosina <jkosina@suse.cz> | 2013-06-18 07:46:27 -0400 |
commit | b6f4287c493d666c6d97f2c1dff82cf63b143153 (patch) | |
tree | 4e62a0e71557f13df4e5a2d856004aa41d071b95 /Documentation | |
parent | 4c7d6361fa0dc9817ef878a7fbb6e50dd33c2f6d (diff) |
doc: device tree: clarify stuff in usage-model.txt.
Fix one filename typo, and tweak a bit of documentation for clarity --
no functional changes.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/devicetree/usage-model.txt | 11 |
1 files changed, 6 insertions, 5 deletions
diff --git a/Documentation/devicetree/usage-model.txt b/Documentation/devicetree/usage-model.txt index 0efedaad5165..2b6b3d3f0388 100644 --- a/Documentation/devicetree/usage-model.txt +++ b/Documentation/devicetree/usage-model.txt | |||
@@ -106,17 +106,18 @@ In the majority of cases, the machine identity is irrelevant, and the | |||
106 | kernel will instead select setup code based on the machine's core | 106 | kernel will instead select setup code based on the machine's core |
107 | CPU or SoC. On ARM for example, setup_arch() in | 107 | CPU or SoC. On ARM for example, setup_arch() in |
108 | arch/arm/kernel/setup.c will call setup_machine_fdt() in | 108 | arch/arm/kernel/setup.c will call setup_machine_fdt() in |
109 | arch/arm/kernel/devicetree.c which searches through the machine_desc | 109 | arch/arm/kernel/devtree.c which searches through the machine_desc |
110 | table and selects the machine_desc which best matches the device tree | 110 | table and selects the machine_desc which best matches the device tree |
111 | data. It determines the best match by looking at the 'compatible' | 111 | data. It determines the best match by looking at the 'compatible' |
112 | property in the root device tree node, and comparing it with the | 112 | property in the root device tree node, and comparing it with the |
113 | dt_compat list in struct machine_desc. | 113 | dt_compat list in struct machine_desc (which is defined in |
114 | arch/arm/include/asm/mach/arch.h if you're curious). | ||
114 | 115 | ||
115 | The 'compatible' property contains a sorted list of strings starting | 116 | The 'compatible' property contains a sorted list of strings starting |
116 | with the exact name of the machine, followed by an optional list of | 117 | with the exact name of the machine, followed by an optional list of |
117 | boards it is compatible with sorted from most compatible to least. For | 118 | boards it is compatible with sorted from most compatible to least. For |
118 | example, the root compatible properties for the TI BeagleBoard and its | 119 | example, the root compatible properties for the TI BeagleBoard and its |
119 | successor, the BeagleBoard xM board might look like: | 120 | successor, the BeagleBoard xM board might look like, respectively: |
120 | 121 | ||
121 | compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3"; | 122 | compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3"; |
122 | compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3"; | 123 | compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3"; |
@@ -161,7 +162,7 @@ cases. | |||
161 | 162 | ||
162 | Instead, the compatible list allows a generic machine_desc to provide | 163 | Instead, the compatible list allows a generic machine_desc to provide |
163 | support for a wide common set of boards by specifying "less | 164 | support for a wide common set of boards by specifying "less |
164 | compatible" value in the dt_compat list. In the example above, | 165 | compatible" values in the dt_compat list. In the example above, |
165 | generic board support can claim compatibility with "ti,omap3" or | 166 | generic board support can claim compatibility with "ti,omap3" or |
166 | "ti,omap3450". If a bug was discovered on the original beagleboard | 167 | "ti,omap3450". If a bug was discovered on the original beagleboard |
167 | that required special workaround code during early boot, then a new | 168 | that required special workaround code during early boot, then a new |
@@ -377,7 +378,7 @@ platform_devices as more platform_devices is a common pattern, and the | |||
377 | device tree support code reflects that and makes the above example | 378 | device tree support code reflects that and makes the above example |
378 | simpler. The second argument to of_platform_populate() is an | 379 | simpler. The second argument to of_platform_populate() is an |
379 | of_device_id table, and any node that matches an entry in that table | 380 | of_device_id table, and any node that matches an entry in that table |
380 | will also get its child nodes registered. In the tegra case, the code | 381 | will also get its child nodes registered. In the Tegra case, the code |
381 | can look something like this: | 382 | can look something like this: |
382 | 383 | ||
383 | static void __init harmony_init_machine(void) | 384 | static void __init harmony_init_machine(void) |