[RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

[Stephen Warren]

On 11/13/2012 12:25 AM, David Gibson wrote:
> On Mon, Nov 12, 2012 at 09:52:32AM -0700, Stephen Warren wrote:
>> On 11/12/2012 05:10 AM, Pantelis Antoniou wrote:
> [snip]
>>> Oh yes. In fact if one was to use a single kernel image for beagleboard
>>> and beaglebone, for the cape to work for both, it is required for it's
>>> dtb to be compatible. 
>>
>> Well, as Grant pointed out, it's not actually strictly necessary for the
>> .dtb to be compatible; only the .dts /need/ be compatible, and the .dtb
>> can be generated at run-time using dtc for example.
> 
> So, actually, I think a whole bunch of problems with phandle
> resolution disappear if we don't try to define an overlay .dtb format,
> or at least treat it only as a very shortlived object.  A more precise
> proposal below.  Note that this works more or less equally well with
> either the original overlay approach or the graft/graft-bundle
> proposal I made elsewhere.
> 
> 1) We annotate the base tree with some extra label information for
> nodes which overlays are likely to want to reference by phandle.  e.g.
> 
> 	beaglebone_pic: interrupt-controller at XXXXX {
> 		...
> 		phandle,symbolic-name = "beaglebone_pic";
> 	};
> 
> We could extend dtc to (optionally?) auto-generate those properties
> from its existing label syntax.  Not sure if that's a good idea or
> not yet.  In any case, we compile this augmented base tree to .dtb as
> normal and boot our kernel with it.

Yes, I think a name-based approach is preferable over using
opaque/arbitrary phandle IDs/ranges/...

> 2) The information for the capes/modules/whatever is
> distributed/packaged as .dts, never .dtb.  When userspace detects the
> new module (or the user explicitly tells it, if it's not probeable) it
> picks up the correct dts and runs it through dtc in a special mode.
> In this mode dtc takes the existing base tree (from /proc/device-tree,
> say) as well as the new dts.  In this mode, dtc allocates phandles for
> the new tree fragment so as not to collide with anything from the
> supplied base tree (as well as avoiding internal conflicts,
> obviously).  It also allows node references to the base tree by using
> those label annotations from (1) to match symbolic names to the
> phandle values in the base tree.
> 
> 3) The resulting partial .dtb for the module is highly specific to the
> base tree (which if the base tree was generated at runtime by firmware
> could even be specific to a particular boot).  But that's ok, because
> we just spit it into the kernel, absolute phandle values and all, then
> throw it away.  Next time we need the module info, we recompile it
> again.

Once you've booted with a base tree, and loaded a partial .dtb for one
child board, and are then loading a .dtb for another child board (or you
unloaded the original child board and are loading a replacement), then
presumably the current in-kernel device tree also depends on all the
runtime history too.

So then going back to your point (2), that means we need to have
user-space serialize the dtc execution so that we don't compile two new
partial .dtbs in parallel, and end up with each not conflicting with the
current in-kernel device tree, but still conflicting with each-other. I
imagine that's easily solvable though.