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

[David Gibson]

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

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.

> Of course, relying on .dts compatibility rather than .dtb compatibility
> might negatively impact the complexity of an initrd environment if we
> end up loading overlays from there...

Well, it does mean we'd need dtc in the initrd.  But dtc has no
library dependencies except libc, so that really shouldn't be too
bad.  In return we entirely avoid inventing a new phandle resolution
protocol.

-- 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/