134 lines
3.8 KiB
Plaintext
134 lines
3.8 KiB
Plaintext
Device Tree Overlay Notes
|
|
-------------------------
|
|
|
|
This document describes the implementation of the in-kernel
|
|
device tree overlay functionality residing in drivers/of/overlay.c and is a
|
|
companion document to Documentation/devicetree/dt-object-internal.txt[1] &
|
|
Documentation/devicetree/dynamic-resolution-notes.txt[2]
|
|
|
|
How overlays work
|
|
-----------------
|
|
|
|
A Device Tree's overlay purpose is to modify the kernel's live tree, and
|
|
have the modification affecting the state of the kernel in a way that
|
|
is reflecting the changes.
|
|
Since the kernel mainly deals with devices, any new device node that result
|
|
in an active device should have it created while if the device node is either
|
|
disabled or removed all together, the affected device should be deregistered.
|
|
|
|
Lets take an example where we have a foo board with the following base tree
|
|
which is taken from [1].
|
|
|
|
---- foo.dts -----------------------------------------------------------------
|
|
/* FOO platform */
|
|
/ {
|
|
compatible = "corp,foo";
|
|
|
|
/* shared resources */
|
|
res: res {
|
|
};
|
|
|
|
/* On chip peripherals */
|
|
ocp: ocp {
|
|
/* peripherals that are always instantiated */
|
|
peripheral1 { ... };
|
|
}
|
|
};
|
|
---- foo.dts -----------------------------------------------------------------
|
|
|
|
The overlay bar.dts, when loaded (and resolved as described in [2]) should
|
|
|
|
---- bar.dts -----------------------------------------------------------------
|
|
/plugin/; /* allow undefined label references and record them */
|
|
/ {
|
|
.... /* various properties for loader use; i.e. part id etc. */
|
|
fragment@0 {
|
|
target = <&ocp>;
|
|
__overlay__ {
|
|
/* bar peripheral */
|
|
bar {
|
|
compatible = "corp,bar";
|
|
... /* various properties and child nodes */
|
|
}
|
|
};
|
|
};
|
|
};
|
|
---- bar.dts -----------------------------------------------------------------
|
|
|
|
result in foo+bar.dts
|
|
|
|
---- foo+bar.dts -------------------------------------------------------------
|
|
/* FOO platform + bar peripheral */
|
|
/ {
|
|
compatible = "corp,foo";
|
|
|
|
/* shared resources */
|
|
res: res {
|
|
};
|
|
|
|
/* On chip peripherals */
|
|
ocp: ocp {
|
|
/* peripherals that are always instantiated */
|
|
peripheral1 { ... };
|
|
|
|
/* bar peripheral */
|
|
bar {
|
|
compatible = "corp,bar";
|
|
... /* various properties and child nodes */
|
|
}
|
|
}
|
|
};
|
|
---- foo+bar.dts -------------------------------------------------------------
|
|
|
|
As a result of the overlay, a new device node (bar) has been created
|
|
so a bar platform device will be registered and if a matching device driver
|
|
is loaded the device will be created as expected.
|
|
|
|
Overlay in-kernel API
|
|
--------------------------------
|
|
|
|
The API is quite easy to use.
|
|
|
|
1. Call of_overlay_create() to create and apply an overlay. The return value
|
|
is a cookie identifying this overlay.
|
|
|
|
2. Call of_overlay_destroy() to remove and cleanup the overlay previously
|
|
created via the call to of_overlay_create(). Removal of an overlay that
|
|
is stacked by another will not be permitted.
|
|
|
|
Finally, if you need to remove all overlays in one-go, just call
|
|
of_overlay_destroy_all() which will remove every single one in the correct
|
|
order.
|
|
|
|
Overlay DTS Format
|
|
------------------
|
|
|
|
The DTS of an overlay should have the following format:
|
|
|
|
{
|
|
/* ignored properties by the overlay */
|
|
|
|
fragment@0 { /* first child node */
|
|
|
|
target=<phandle>; /* phandle target of the overlay */
|
|
or
|
|
target-path="/path"; /* target path of the overlay */
|
|
|
|
__overlay__ {
|
|
property-a; /* add property-a to the target */
|
|
node-a { /* add to an existing, or create a node-a */
|
|
...
|
|
};
|
|
};
|
|
}
|
|
fragment@1 { /* second child node */
|
|
...
|
|
};
|
|
/* more fragments follow */
|
|
}
|
|
|
|
Using the non-phandle based target method allows one to use a base DT which does
|
|
not contain a __symbols__ node, i.e. it was not compiled with the -@ option.
|
|
The __symbols__ node is only required for the target=<phandle> method, since it
|
|
contains the information required to map from a phandle to a tree location.
|