From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
Cc: "nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
"rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org"
<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [RFC] DT affinity bindings/representing bus masters with DT
Date: Tue, 19 Mar 2013 18:07:34 +1100 [thread overview]
Message-ID: <20130319070734.GX9402@truffula.fritz.box> (raw)
In-Reply-To: <20130318094815.GA30116-7AyDDHkRsp3ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 4390 bytes --]
On Mon, Mar 18, 2013 at 09:48:16AM +0000, Lorenzo Pieralisi wrote:
> On Mon, Mar 18, 2013 at 03:09:28AM +0000, David Gibson wrote:
> > 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@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.
> >
> > > > 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.
--
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
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 192 bytes --]
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
next prev parent reply other threads:[~2013-03-19 7:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-15 17:21 [RFC] DT affinity bindings/representing bus masters with DT Lorenzo Pieralisi
[not found] ` <20130215172102.GF3014-7AyDDHkRsp3ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2013-02-15 17:52 ` Dave Martin
[not found] ` <20130215175206.GA11931-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2013-02-18 18:39 ` Dave Martin
2013-03-06 21:57 ` David Gibson
[not found] ` <20130306215714.GC6740-W9XWwYn+TF0XU02nzanrWNbf9cGiqdzd@public.gmane.org>
2013-03-11 17:06 ` Lorenzo Pieralisi
[not found] ` <20130311170657.GD25250-7AyDDHkRsp3ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2013-03-18 3:09 ` David Gibson
[not found] ` <20130318030928.GG9402-W9XWwYn+TF0XU02nzanrWNbf9cGiqdzd@public.gmane.org>
2013-03-18 9:48 ` Lorenzo Pieralisi
[not found] ` <20130318094815.GA30116-7AyDDHkRsp3ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2013-03-19 7:07 ` David Gibson [this message]
[not found] ` <20130319070734.GX9402-W9XWwYn+TF0XU02nzanrWNbf9cGiqdzd@public.gmane.org>
2013-03-25 15:20 ` Lorenzo Pieralisi
[not found] ` <20130325152038.GC27959-7AyDDHkRsp3ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2013-04-13 22:24 ` Grant Likely
2013-04-15 13:43 ` Lorenzo Pieralisi
[not found] ` <20130415134302.GA4568-7AyDDHkRsp3ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2013-04-16 15:55 ` Dave Martin
[not found] ` <20130416155518.GA2234-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2013-04-17 10:49 ` Lorenzo Pieralisi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130319070734.GX9402@truffula.fritz.box \
--to=david-xt8fgy+axnrb3ne2bgzf6laj5h9x9tb+@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org \
--cc=nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).