On Wed, Jan 23, 2013 at 01:01:58PM +0200, Pantelis Antoniou wrote:
> 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 <pa...@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@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.

It's really not that bad.  In particular it's only tricky if you want
to make alterations to the flat tree, which you shouldn't need to
here.

> 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?

It would be, if you actually needed to do that.  But what you can
actually do is:
        1. parse the information you need out of the base tree
        2. use the flat tree functions to retrieve the
__local_fixups__ and __fixups__ information from the overlay, parsing
just those into a temporary data structure
        3. Perform a single pass over the flat tree overlay, inserting
each node and and property into the live tree, applying fixups as you
go.

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

Attachment: signature.asc
Description: Digital signature

Reply via email to