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

[Pantelis Antoniou]

Hi Stephen,

On Nov 10, 2012, at 12:57 AM, Stephen Warren wrote:

> On 11/08/2012 07:26 PM, David Gibson wrote:
> ...
>> I also think graft will handle most of your use cases, although as I
>> said I don't fully understand the implications of some of them, so I
>> could be wrong.  So, the actual insertion of the subtree is pretty
>> trivial to implement.  phandles are the obvious other matter to be
>> dealt with.  I haven't found the right thread where what you've
>> envisaged so far is discussed, so here are things I can see:
>> 
>> 1) Avoiding phandle collisions between main tree and subtree (or
>>   between subtrees).
>> 
>> I'm hopeful that this can be resolved just by establishing some
>> conventions about the ranges of phandles to be used for various
>> components.  I'd certainly be happy to add a directive to dtc which
>> enforces allocation of phandles within a specified range.
> 
> One case I wonder about is:
> 
> Base board A that's split into two .dts files e.g. due to there being
> two versions of the base board which are 90% identical, yet there being
> a few differences between them.
> 
> Base board B that's just a single .dts file.
> 
> We might allocate phandle range 0..999 for the base board.
> 
> Child board X plugs into either, so the two base boards need to "export"
> the same set of phandle IDs to the child board to allow it to reference
> them.
> 
> If base board A version 2 comes along after the phandle IDs that the
> child board uses are defined, then how do we handle assigning a specific
> phandle ID range to each of base board A's two version-specific
> overlays, when the version-specific changes might affect arbitrary
> phandle IDs within the range, and require some to be moved into the base
> board version-specific overlays and some to stay in the common base
> board .dts?
> 

Static phandle allocation, could work, but not without considerable trouble.

Maybe we're over-engineering things. Perhaps having the kernel use the
phandle values generated by dtc is not required.

What about the following simple scheme:

1) Have dtc create local phandle values the same way, as it is today.
   Generate the flat tree normally, but keep in a table the locations
   of all phandle references. Keep track of non resolvable phandle references
   in a different table. One could use the fixup mechanism I described in
   a previous email, if you don't care about keeping a big table.
2) Upon loading the base DT or the overlay, the kernel makes sure the phandles
   don't overlap; simply add a per DT fragment constant offset.
3) Resolve phandle references that were unresolved at compile time.
 

>> 2) Resolving phandle references within a subtree
>> 
>> If we can handle (1) by convention, we don't need anything here, the
>> references are fine as is.
>> 
>> (3) Resolving phandle references from the subtree to the main tree.
>> 
>> So, I think this can actually be avoided, at least in cases where what
>> physical connections are available to the expansion module is well
>> defined.  The main causes to have external references are interrupts
>> and gpios.  Interrupts we handle by defining an interrupt specifier
>> space for the interrupts available on the expansion
>> socket/connector/bus/whatever.  In the master tree we then have
>> something like:
>> 
>> ...
>> 	expansion-socket at XXXX {
>> 		expansion-id = "SlotA";
>> 		interrupt-map = < /* map expansion irq specs to
>> 				     board interrupt controllers */ >;
>> 		interrupt-map-mask = < ... >;
>> 		ranges = < /* map expansion local addresses to global
>> 		              mmio */ >;
>> 	};
> 
> We would end up needing an interrupt-map or ranges type of property for
> basically any resource type.
> 
> For example, what about an I2C bus that's routed to the daughter board,
> and the daughter board contains an I2C bus mux, whose control path isn't
> through I2C but rather GPIOs? In this case, the I2C bus mux isn't a
> child of the I2C bus, but a separate entity that indicates its parent
> I2C bus using a phandle. I presume a similar argument applies to almost
> any kind of resource. This is probably do-able, but certainly something
> to consider with the socket approach. I do like the socket approach though.

Capebus has taken this approach.

You see, perhaps from the standpoint of the standard platform devices that
a cape provides, a bus is not a very fitting construct.

But from a hardware engineer/user perspective, a cape is an expansion board,
and virtual slots are used. This is similar to what you're saying
with socket approach, right? 

Regards

-- Pantelis