On 11/12/2012 06:05 PM, David Gibson wrote:
> On Fri, Nov 09, 2012 at 09:42:37PM +0000, Grant Likely wrote:
...
> 2) graft bundle
>
> The base tree has something like this:
>
> ...
> i2c@XXX {
> ...
> cape-socket {
> compatible = "vendor,cape-socket";
> id = "Socket-A";
> piece-id = "i2c";
> ranges = < ... >;
> };
> };
> ...
> spi@YYY {
> ...
> cape-socket {
> compatible = "vendor,cape-socket";
> id = "Socket-A";
> piece-id = "spi";
> ranges = < ... >;
> };
> };
> ...
> cape-socket {
> compatible = "vendor,cape-socket";
> id = "Socket-A";
> piece-id = "misc";
> interrupt-map = < ... >;
> interrupt-map-mask = < ... >;
> gpio-map = < ... >;
> gpio-map-mask = < ... >;
> };
>
> Then instead of grafting a single subtree for the socket, we install a
> "bundle" of subtrees, one each for each of the pieces within the
> socket. That bundle could either be an actual set of multiple fdts,
> or they could be placed into one fdt with a dummy root node, something like:
>
> / {
> plugin-bundle;
> compatible = "vendor,cape-plugin";
> version = ...;
> i2c-piece = {
> piece-id = "i2c";
> ...
> };
> misc-piece = {
> piece-id = "misc";
> ...
> };
> };
I do like this approach; it's the kind of thing I proposed at:
> http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg20414.html
One question though: Perhaps the base board has two instances of the
same type of connector vendor,cape-socket, allowing 2 independent capes
to be plugged in. When overlaying/grafting the child board's .dts, we'd
need some way to specify the socket ID that was being plugged into. Is
that the intent of the "id" property in your base board example above?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
