From: David Gibson <dwg-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org>
To: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: Yoder Stuart-B08248
<B08248-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
devicetree-discuss
<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
parch-QRwYI7m9GJLYtjvyW6yDsg@public.gmane.org
Subject: Re: [Power.org:parch] ePAPR 1.1 to do list
Date: Tue, 31 Aug 2010 11:00:10 +1000 [thread overview]
Message-ID: <20100831010010.GE5210@yookeroo> (raw)
In-Reply-To: <20100830173314.446aae02-1MYqz8GpK7RekFaExTCHk1jVikpgYyvb5NbjCUgZEJk@public.gmane.org>
On Mon, Aug 30, 2010 at 05:33:14PM -0500, Scott Wood wrote:
> On Mon, 30 Aug 2010 14:34:44 -0700
> Yoder Stuart-B08248 <B08248-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
>
> > I've consolidated what I am aware of with respect to errors found in
> > 1.0,
> > clarifications needed, and new mechanisms to go into ePAPR 1.1 into
> > a single list.
> >
> > Let me know if you are aware of anything else.
>
> 2.2.1.1 should perhaps have a stronger connection between unit addresses
> and reg -- if you don't have the latter, you can't have the former.
> This is required for bindings to work on real Open Firmware. David
> Gibson just posted a patch to dtc yesterday that verifies this.
Unsurprisingly, I also think this would be a good idea.
> Disambiguation without reg can still be achieved by appending numbers
> to the node names, without @.
And since this is already a standard practice in a bunch of 4xx device
trees, we should at least include mention of it as a programmer's note
in ePAPR.
> One use case to consider is nodes that have no reg, but do have
> ranges, such as the somewhat misnamed "soc" nodes. The unit address
> mechanism has similar advantages here as with reg (a standardized way
> to disambiguate based on child-bus address, and ability to omit the unit
> address to get the first one). We could make the rule be "first reg
> address, if no reg then first ranges child-bus address, if no reg or
> ranges then no unit address".
>
> Such unit addresses may not work on true OF as is, but bindings should
> not require the use of unit addresses -- and if people using real OF
> find them useful, it doesn't seem like it would be unreasonable to
> modify OF to support ranges-based unit addresses in the absence of reg.
Yeah, the ranges-based unit address convention is already used in some
fsl trees. Some IBM firmware people (with something that has both
real OF and ePAPR aspects) came up with an interesting approach to
this one. On a bus bridge with no-MMIO they created a dummy 'reg'
property with zero length (at the same address as the first 'ranges'
entry, IIRC). This had the advantage of Just Working with the
existing internal OF code, and doesn't appear to confuse anything, so
far.
Not sure which way is the better option for estabishing a firm
convention.
--
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 prev parent reply other threads:[~2010-08-31 1:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-30 21:34 ePAPR 1.1 to do list Yoder Stuart-B08248
[not found] ` <9696D7A991D0824DBA8DFAC74A9C5FA306688C2F-ofAVchDyotYzzZk0BCvKg5jmvxFtTJ+o0e7PPNI6Mm0@public.gmane.org>
2010-08-30 22:33 ` [Power.org:parch] " Scott Wood
[not found] ` <20100830173314.446aae02-1MYqz8GpK7RekFaExTCHk1jVikpgYyvb5NbjCUgZEJk@public.gmane.org>
2010-08-31 1:00 ` David Gibson [this message]
2010-09-13 18:17 ` Scott Wood
[not found] ` <20100913131752.54981fb1-1MYqz8GpK7RekFaExTCHk1jVikpgYyvb5NbjCUgZEJk@public.gmane.org>
2010-09-20 2:44 ` David Gibson
2011-01-11 22:14 ` Yoder Stuart-B08248
[not found] ` <9F6FE96B71CF29479FF1CDC8046E150301D94E-TcFNo7jSaXM0vywKSws3iq4g8xLGJsHaLnY5E4hWTkheoWH0uzbU5w@public.gmane.org>
2011-01-11 22:26 ` Scott Wood
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=20100831010010.GE5210@yookeroo \
--to=dwg-8fk3idey6ehbdgjk7y7tuq@public.gmane.org \
--cc=B08248-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=parch-QRwYI7m9GJLYtjvyW6yDsg@public.gmane.org \
--cc=scottwood-KZfg59tc24xl57MIdRCFDg@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).