Date:	Fri, 09 Nov 2012 15:57:38 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	David Gibson <david@...son.dropbear.id.au>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	Kevin Hilman <khilman@...com>, Matt Porter <mporter@...com>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Pantelis Antoniou <panto@...oniou-consulting.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Felipe Balbi <balbi@...com>,
	Deepak Saxena <dsaxena@...aro.org>,
	Scott Wood <scottwood@...escale.com>,
	Russ Dill <Russ.Dill@...com>, linux-omap@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org
Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices
 to mach-omap2)

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?

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

Powered by blists - more mailing lists