[PATCH 6/6] OF: Introduce DT overlay support.

[Pantelis Antoniou]

On Jan 23, 2013, at 7:12 AM, David Gibson wrote:

> On Tue, Jan 22, 2013 at 01:08:04PM +0200, Pantelis Antoniou wrote:
>> Hi
>> 
>> On Jan 22, 2013, at 5:50 AM, David Gibson wrote:
>> 
>>> On Fri, Jan 04, 2013 at 09:31:10PM +0200, Pantelis Antoniou wrote:
>>>> Introduce DT overlay support.
>>>> Using this functionality it is possible to dynamically overlay a part of
>>>> the kernel's tree with another tree that's been dynamically loaded.
>>>> It is also possible to remove node and properties.
>>>> 
>>>> Signed-off-by: Pantelis Antoniou <panto at antoniou-consulting.com>
>>>> ---
>>>> Documentation/devicetree/overlay-notes.txt | 179 +++++++
>>>> drivers/of/Kconfig                         |  10 +
>>>> drivers/of/Makefile                        |   1 +
>>>> drivers/of/overlay.c                       | 831 +++++++++++++++++++++++++++++
>>>> include/linux/of.h                         | 107 ++++
>>>> 5 files changed, 1128 insertions(+)
>>>> create mode 100644 Documentation/devicetree/overlay-notes.txt
>>>> create mode 100644 drivers/of/overlay.c
>>>> 
>>>> diff --git a/Documentation/devicetree/overlay-notes.txt b/Documentation/devicetree/overlay-notes.txt
>>>> new file mode 100644
>>>> index 0000000..5289cbb
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/overlay-notes.txt
>>>> @@ -0,0 +1,179 @@
>>>> +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 the kernel in a way that
>>>> +is reflecting the changes.
>>> 
>>> Um.. I'm having a great deal of trouble parsing that sentence.
>>> 
>>>> +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 at 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 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.
>>> 
>>> Hrm.  This all seems rather complicated.  Maybe it needs to be, but
>>> I'm not entirely convinced yet.
>>> 
>>> One other point - both of these patches are assuming that the overlay
>>> is in the "live tree" format, but it still needs a bunch of extra
>>> mangling.  Would it simplify things to just go straight from the
>>> overlay in flat tree form to modifications to the system-wide live
>>> tree.
>> 
>> Sorry, I can't parse this. You mean apply the overlay without converting
>> to live tree format?
> 
> Yes.
> 

The gymnastics required when operating on the flat tree will make grown, tough as nails
s/w developers cry.

In essence you will have to replicate the unflattening functionality again, create a
similar tree structure as the live tree, do your work, and then discard it.

A bit excessive don't you think?

 
> -- 
> David Gibson			| I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
> 				| _way_ _around_!
> http://www.ozlabs.org/~dgibson