devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Pantelis Antoniou <panto@antoniou-consulting.com>
Cc: Grant Likely <grant.likely@secretlab.ca>,
	Rob Herring <rob.herring@calxeda.com>,
	Rob Landley <rob@landley.net>, Jon Loeliger <jdl@jdl.com>,
	Tony Lindgren <tony@atomide.com>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Benoit Cousson <b-cousson@ti.com>,
	Mitch Bradley <wmb@firmworks.com>, Alan Tull <atull@altera.com>,
	linux-omap@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	Matt Porter <mporter@ti.com>, Russ Dill <Russ.Dill@ti.com>,
	Koen Kooi <koen@dominion.thruhere.net>,
	Joel A Fernandes <agnel.joel@gmail.com>,
	Rob Clark <robdclark@gmail.com>,
	Jason Kridner <jkridner@beagleboard.org>,
	Matt Ranostay <mranostay@gmail.com>
Subject: Re: [PATCH 6/6] OF: Introduce DT overlay support.
Date: Fri, 25 Jan 2013 13:34:30 +1100	[thread overview]
Message-ID: <20130125023430.GB25924@truffula.fritz.box> (raw)
In-Reply-To: <EAB57031-78DC-4150-B1A9-F6A19A60293F@antoniou-consulting.com>

[-- Attachment #1: Type: text/plain, Size: 6543 bytes --]

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 <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.
> > 
> 
> 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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2013-01-25  2:34 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-04 19:31 [PATCH 0/6] Introducing Device Tree Overlays Pantelis Antoniou
2013-01-04 19:31 ` [PATCH 1/6] OF: Introduce device tree node flag helpers Pantelis Antoniou
2013-01-04 19:31 ` [PATCH 2/6] OF: export of_property_notify Pantelis Antoniou
2013-01-04 19:31 ` [PATCH 3/6] OF: Export all DT proc update functions Pantelis Antoniou
2013-03-16  9:45   ` Grant Likely
2013-03-19 11:42     ` Pantelis Antoniou
2013-03-19 17:08       ` Grant Likely
2013-03-16  9:53   ` Grant Likely
2013-01-04 19:31 ` [PATCH 4/6] OF: Introduce utility helper functions Pantelis Antoniou
2013-01-04 19:31 ` [PATCH 5/6] OF: Introduce Device Tree resolve support Pantelis Antoniou
     [not found]   ` <1357327870-13615-6-git-send-email-panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>
2013-01-21  4:48     ` David Gibson
2013-01-21 10:59       ` Pantelis Antoniou
2013-01-22  4:05         ` David Gibson
     [not found]           ` <20130122040524.GG23500-W9XWwYn+TF0XU02nzanrWNbf9cGiqdzd@public.gmane.org>
2013-01-22 11:06             ` Pantelis Antoniou
2013-01-23  4:40               ` David Gibson
2013-01-23 10:58                 ` Pantelis Antoniou
2013-03-16  9:24                   ` Grant Likely
2013-03-19 11:51                     ` Pantelis Antoniou
2013-03-19 17:18                       ` Grant Likely
2013-03-21  9:12                         ` Pantelis Antoniou
     [not found] ` <1357327870-13615-1-git-send-email-panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>
2013-01-04 19:31   ` [PATCH 6/6] OF: Introduce DT overlay support Pantelis Antoniou
     [not found]     ` <1357327870-13615-7-git-send-email-panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>
2013-01-06  2:24       ` Rob Landley
2013-01-07 10:45         ` Pantelis Antoniou
2013-01-22  3:50     ` David Gibson
2013-01-22 11:08       ` Pantelis Antoniou
2013-01-23  5:12         ` David Gibson
2013-01-23 11:01           ` Pantelis Antoniou
2013-01-25  2:34             ` David Gibson [this message]
2013-01-05  3:35   ` [PATCH 0/6] Introducing Device Tree Overlays Richard Cochran
     [not found]     ` <20130105033541.GA2501-TJb37gCd1q6chkuNt9O67llkmcu1nq/N@public.gmane.org>
2013-01-05  6:16       ` Joel A Fernandes
2013-01-05  9:35         ` Richard Cochran
     [not found]           ` <20130105093558.GA31408-TJb37gCd1q6chkuNt9O67llkmcu1nq/N@public.gmane.org>
2013-01-05 10:13             ` Pantelis Antoniou
2013-01-06  4:37             ` Rob Landley
2013-02-21 21:25 ` delicious quinoa
     [not found]   ` <CANk1AXQ7ajnwTaHwwbyrri2YkX_60uC9xrQYWuR8u4eT2EQsew-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-02-21 21:53     ` Pantelis Antoniou
2013-02-22 15:57       ` delicious quinoa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130125023430.GB25924@truffula.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=Russ.Dill@ti.com \
    --cc=agnel.joel@gmail.com \
    --cc=atull@altera.com \
    --cc=b-cousson@ti.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=jdl@jdl.com \
    --cc=jkridner@beagleboard.org \
    --cc=koen@dominion.thruhere.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mporter@ti.com \
    --cc=mranostay@gmail.com \
    --cc=panto@antoniou-consulting.com \
    --cc=rob.herring@calxeda.com \
    --cc=rob@landley.net \
    --cc=robdclark@gmail.com \
    --cc=swarren@wwwdotorg.org \
    --cc=tony@atomide.com \
    --cc=wmb@firmworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).