From: David Gibson <david@gibson.dropbear.id.au>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: "David VomLehn (dvomlehn)" <dvomlehn@cisco.com>,
prasun.kapoor@caviumnetworks.com, linux-mips@linux-mips.org,
devicetree-discuss@lists.ozlabs.org,
David Daney <ddaney@caviumnetworks.com>
Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs.
Date: Sat, 16 Oct 2010 17:24:41 +1100 [thread overview]
Message-ID: <20101016062441.GB5036@yookeroo> (raw)
In-Reply-To: <20101016034548.GB21170@angua.secretlab.ca>
On Fri, Oct 15, 2010 at 09:45:48PM -0600, Grant Likely wrote:
> [reorganized quoting]
> On Fri, Oct 15, 2010 at 12:48:55PM -0500, David VomLehn (dvomlehn) wrote:
> >
> > David Daney wrote:
> > > On 10/15/2010 10:30 AM, David VomLehn (dvomlehn) wrote:
> > >
> > > > If this is really a question of needing to dynamically generate the
> > > > device tree, then you have no choice. It's worth mentioning, though,
> > > > that the device tree compiler (dtc) does have the ability to include
> > > > files, making it easier to create and maintain device trees that are
> > > > static but which share devices.
> > >
> > > Some experimentation will be necessary. We will have to patch in some
> > > properties like the Ethernet MAC address as that is stored in a
> > > separate eeprom. Also some boards have pluggable I/O modules, so we
> > > may not know at dtb generation time what is there.
>
> If it touches firmware, then you'll need to be careful about getting
> painted into a corner with an over-complex boot firmware design, but
> yet this sounds like an appropriate approach.
>
> > We're in much the same situation. Almost all of the device tree is
> > static, but we add on/overwrite little bits. I'm not the device tree
> > expert, but if I understand correctly, you can even have dtc emit labels
> > that you can reference to make the fix-up simpler.
>
> The labels are not available at runtime, but properties in the
> 'aliases' node can (and should) be used to avoid having to depend on
> the full path to a device node. It has been on my to-do list for a
> while to add automatic parsing of aliases when finding a node by full
> path.
Well.. the labels can be available at runtime, but only if you use
dtc's "asm" output mode and link the resulting asm code into your
kernel. There are situations where this is a good approach, but I
suspect yours is not one of them.
libfdt already automatically expands aliases when locating a node by
full path.
--
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-10-16 6:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-15 0:17 Device Tree questions WRT MIPS/Octeon SOCs David Daney
2010-10-15 0:32 ` Grant Likely
2010-10-15 1:13 ` Warner Losh
2010-10-15 1:29 ` Grant Likely
2010-10-15 17:30 ` David VomLehn (dvomlehn)
2010-10-15 17:30 ` David VomLehn (dvomlehn)
2010-10-15 17:42 ` David Daney
2010-10-15 17:48 ` David VomLehn (dvomlehn)
2010-10-15 17:48 ` David VomLehn (dvomlehn)
2010-10-16 3:45 ` Grant Likely
2010-10-16 6:24 ` David Gibson [this message]
2010-10-16 6:20 ` David Gibson
2010-10-16 3:48 ` Grant Likely
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=20101016062441.GB5036@yookeroo \
--to=david@gibson.dropbear.id.au \
--cc=ddaney@caviumnetworks.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=dvomlehn@cisco.com \
--cc=grant.likely@secretlab.ca \
--cc=linux-mips@linux-mips.org \
--cc=prasun.kapoor@caviumnetworks.com \
/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