123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134 |
- 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.
|