Date:	Fri, 9 Nov 2012 21:42:37 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	David Gibson <david@...son.dropbear.id.au>
Cc:	Pantelis Antoniou <panto@...oniou-consulting.com>,
	Rob Herring <robherring2@...il.com>,
	Deepak Saxena <dsaxena@...aro.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Scott Wood <scottwood@...escale.com>,
	Tony Lindgren <tony@...mide.com>,
	Kevin Hilman <khilman@...com>, Matt Porter <mporter@...com>,
	Koen Kooi <koen@...inion.thruhere.net>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Felipe Balbi <balbi@...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 Fri, Nov 9, 2012 at 2:26 AM, David Gibson
<david@...son.dropbear.id.au> wrote:
> (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 */ >;
>         };
>
> The subtree for the expansion module gets attached as a subnode of
> this one.  It doesn't use explicit interrupt-parents but instead just
> uses the expansion local irq specifiers, letting the parent be the
> default which will bubble up to this socket node where the
> interrupt-map will send them to the right places.
>
> I don't recall the gpio bindings off hand, but as I recall we based
> them off the irq tree bindings so we ought to be able to do the same
> thing for them.
>
> Likewise, if there are several interchangeable expansion sockets that
> have some address bits hard wired to distinguish them, we can just use
> socket local mmio addresses within the subtree and the ranges property
> here will sort that out.

If I'm reading correctly, the suggestion is that everything be grafted
below a single node and all connections route through that node using
mapping. Correct?

For interrupts that works today
For gpios, it isn't currently supported, but we could do it.
For SPI it would mean that the new spi devices would not appear below
the actual spi bus they are attached to
For I2C, MDIO, and one wire, same problem.
For memory mapped devices, the expansion node would need to a ranges
for all the windows that map through it, and it assumes only one
memory mapped bus (or at least it prefers only one memory mapped bus.
If there were more than one then the expansion node placement wouldn't
have a natural place to sit)

The problem is that this is not like a PCI bus where there is only one
kind of interface. It is a whole bunch of interfaces that happen to be
grouped together loosely (as an expansion connector in the beaglebone
case, but expansion isn't the only problem that I'm hearing about).

So, with a group of i2c, spi, memory mapped and other devices than are
all plugged in together, how does that look? They really should not
sit on the same level. An spi device cannot be a peer of an i2c device
for instance, the address mapping is entirely different. The kernel
really wants i2c devices to be a child of the actual i2c bus which may
already have an i2c device or too on the main board. Does the
expansion node need to have some kind of redirect node for each of the
busses where the children of it need to create devices as children of
the master bus?

To me that seems to get really complex in a hurry. More complex than
the overlay approach.

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