devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Mon, 18 Mar 2013 14:09:28 +1100	[thread overview]
Message-ID: <20130318030928.GG9402@truffula.fritz.box> (raw)
In-Reply-To: <20130311170657.GD25250-7AyDDHkRsp3ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 3299 bytes --]

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?

-- 
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

  parent reply	other threads:[~2013-03-18  3:09 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 [this message]
     [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
     [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=20130318030928.GG9402@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).