lkml.org 
[lkml]   [2013]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 6/6] OF: Introduce DT overlay support.
    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@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.

    --
    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
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2013-01-23 07:01    [W:2.535 / U:0.948 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site