asgardius/android_kernel_motorola_sm6225
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

doc: device tree: clarify stuff in usage-model.txt.

Browse source 
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>
This commit is contained in:
Robert P. J. Day 2013-05-30 07:49:59 -04:00 committed by Jiri Kosina
parent 4c7d6361fa
commit b6f4287c49
1 changed files with 6 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
Documentation/devicetree/usage-model.txt
View file

@ -106,17 +106,18 @@ In the majority of cases, the machine identity is irrelevant, and the
kernel will instead select setup code based on the machine's core
CPU or SoC. On ARM for example, setup_arch() in
arch/arm/kernel/setup.c will call setup_machine_fdt() in
arch/arm/kernel/devicetree.c which searches through the machine_desc
arch/arm/kernel/devtree.c which searches through the machine_desc
table and selects the machine_desc which best matches the device tree
data. It determines the best match by looking at the 'compatible'
property in the root device tree node, and comparing it with the
dt_compat list in struct machine_desc.
dt_compat list in struct machine_desc (which is defined in
arch/arm/include/asm/mach/arch.h if you're curious).
The 'compatible' property contains a sorted list of strings starting
with the exact name of the machine, followed by an optional list of
boards it is compatible with sorted from most compatible to least. For
example, the root compatible properties for the TI BeagleBoard and its
successor, the BeagleBoard xM board might look like:
successor, the BeagleBoard xM board might look like, respectively:
compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3";
compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3";
@ -161,7 +162,7 @@ cases.
Instead, the compatible list allows a generic machine_desc to provide
support for a wide common set of boards by specifying "less
compatible" value in the dt_compat list. In the example above,
compatible" values in the dt_compat list. In the example above,
generic board support can claim compatibility with "ti,omap3" or
"ti,omap3450". If a bug was discovered on the original beagleboard
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
device tree support code reflects that and makes the above example
simpler. The second argument to of_platform_populate() is an
of_device_id table, and any node that matches an entry in that table
will also get its child nodes registered. In the tegra case, the code
will also get its child nodes registered. In the Tegra case, the code
can look something like this:
static void __init harmony_init_machine(void)