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

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

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

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

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?

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson