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

[David Gibson]

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:
> > On Fri, Feb 15, 2013 at 05:21:02PM +0000, Lorenzo Pieralisi wrote:
[snip]
> > > Each foo at 2000000 reg property maps to a device that represents a bus master
> > > (to make it clearer, a foo at 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.

> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20130318/8f8da8df/attachment.sig>