Re: [RFC] DT affinity bindings/representing bus masters with DT

On Tue, Mar 19, 2013 at 07:07:34AM +0000, David Gibson wrote:

On Mon, Mar 18, 2013 at 09:48:16AM +0000, Lorenzo Pieralisi wrote:

quoted

On Mon, Mar 18, 2013 at 03:09:28AM +0000, David Gibson wrote:

quoted

On Mon, Mar 11, 2013 at 05:06:57PM +0000, Lorenzo Pieralisi wrote:

quoted

Hi David,

thanks for your feedback.

On Wed, Mar 06, 2013 at 09:57:14PM +0000, David Gibson wrote:

quoted

On Fri, Feb 15, 2013 at 05:21:02PM +0000, Lorenzo Pieralisi wrote:

[snip]

quoted

quoted

quoted

Each foo@2000000 reg property maps to a device that represents a bus master
(to make it clearer, a foo@2000000 reg property defines an address space that
belongs to a bus master, ie the address space represents a programming
interface specific to that master; in the bindings above address 0x2000000 is
the address at which acme1 device can programme its "foo" interface, address
0x2001000 is the address at which acme2 device can programme its "foo"
interface).

Ok.  I think annotating the existing reg property like this is a very
bad idea.  I haven't seen all the previous discussion, so I'm not
totally clean on what this affinity concept is about.  But as I
understand it, these "slave" resources cannot be treated like an
ordinary resource in in the reg property.  That means an older client
will potentially misinterpret "reg" because it doesn't know about
"affinity".

Not really, "reg" still complies with the current DT bindings. Affinity
is there to associate a reg property to a "master" but the reg property
definition does not change. I do not think backward compatibility is a
problem per-se here.

Ok, I did not understand the problem properly.

quoted

quoted

Worse, again, if I've understood correctly, resources with different
"masters" are essentially in different logical address spaces.  "reg"
properties should always sit in the logical address space representing
the parent node's bus.  Different address spaces could also have
different address sizes, which would really complicate parsing "reg".

I think we need to post what we have, it is really complex to explain
the issue without a concrete example. To cut a long story short I
would not say that the resources sit in different address spaces, it is
that we need to associate those address ranges with specific bus masters.

We have to have a way to say:

"Address range 0x80001000 - 0x80001fff is used to programme the control
registers associated with the port connected to master X".

When a CPU wants to programme a control port for a specific master, it
needs to know what address range should be programmed.

I mentioned "resources" instead of addresses since the problem we are
having is the same when it comes to map IRQs to set of CPUS. We need
to associate a resource (IRQ or address) to a set of cpus (or more in
general, masters).

Hrm.  See, I think I may be misunderstanding the problem again,
because with this description I can see no problem.  It's already up
to the device binding to describe the purpose of each entry in the reg
property.  So what's the problem with it just being part of the
binding to say which reg entry is associated with which master port?

That's exactly what we are trying to do. But to associate the reg
property to a master port we need a phandle, how can we pull that off
otherwise ?

Ah, right.  I was meaning that the binding specifies the abstract port
number that each reg entry is associated with.  I'm fine with adding a
property to map the port numbers to master devices on the other end.
I think treating it in two steps like that is better than thinking of
the master phandles being  directly associated with reg entries,
because it also handles cases like having a bank of common/global
registers not associated with any port/master, or cases where the
ports aren't all identical and some need more resources than others.

That's fine by me. Can you provide me with an example of how the bindings
should tie a specific reg property to an abstract port number ? reg properties
ordering (ie index) ? Or port number encoded in the reg property itself ?

Thanks,
Lorenzo