Hi Florian,
On Tuesday 03 Jan 2017 16:47:03 Florian Fainelli wrote:
> On 01/03/2017 04:31 PM, David Gibson wrote:
> > On Tue, Jan 03, 2017 at 03:44:28PM -0800, Florian Fainelli wrote:
[snip]
> >> Digression: I was actually wondering if we may not have a need to do the
> >> same thing for "reg" properties, where a given device may have memory
> >> mapped I/O registers in one place, and another address in another bus,
> >> with a different address space, this is actually pretty common for e.g:
> >> PHY (Ethernet, PCIe, SATA or USB).
> >
> > I've wondered about something like that for some time (my working name
> > was 'bus-reg'). The use cases I encountered were on PPC4xx machines
> > which had lots of things controlled (at least partially) by the
> > sideband "DCR" (Device Control Register) bus. We did invent a
> > 'dcr-reg' property to cover that specific case, and I think something
> > similar has been done for some other sideband busses. Something like
> > 'bus-reg' would be a more general solution to the problem.
>
> Seems to me like syscon is pretty much what was invented in Linux to
> support that use case.
>
> > I believe the "classic" IEEE1275 way of solving this is to have
> > separate nodes on each of the relevant busses, with phandle pointers
> > linking them together. The relevant driver would claim all the
> > related nodes. Again, it gets pretty messy, though.
>
> Yes still pretty ugly.
>
> Device Tree tends to list resources as properties of the node that
> consumes them, which is fine, although it can lead to duplicate values
> in a given DTB, but one could also imagine, say listing all register
> resources as properties of the bus that decodes these addresses, and
> then having child nodes of that bus node reference via phandle their
> relevant "reg" cells. Something like this for instance:
>
> bus@deadbeef {
> reg = <0x10000000 0x100>, //UART 0
> <0x10000100 0x100> //UART 1
>
> uart@100 {
> compatible = "acme,uart";
> reg = <&bus 0>;
> };
> };
>
> You get the idea ;)
/me shivers :-)
The problem you've raised comes down in my opinion to the fact that a tree
simply can't represent a topology that isn't tree-like. The device tree more
or less lays down nodes from the point of view of control buses. As soon as
your device sits on multiple buses the device tree can't represent it
accurately. So far this hasn't really been an issue (probably thank to the
occasional hack), but with devices becoming more and more complex I wouldn't
be surprised if we had to really tackle this problem in the not too distant
future. A nasty example that comes to my mind is an SoC with two clusters of
CPU of different architectures (namely ARM and SH) where some peripheral are
accessible to both the ARM and SH side, but mapped at different addresses. So
far we've only described the ARM view of the system, but wouldn't it be lovely
to have a single DT that can cover both ? :-)
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
