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