From: Segher Boessenkool <segher@kernel•crashing.org>
To: "Grant Likely" <grant.likely@secretlab•ca>
Cc: linuxppc-dev Development <linuxppc-dev@ozlabs•org>,
Sven Luther <sven@genesi-usa•com>
Subject: Re: Discussion on SOC device tree bindings
Date: Mon, 15 Jan 2007 19:31:50 +0100 [thread overview]
Message-ID: <0c74c52b3ba6dd16f47fb393da58d53a@kernel.crashing.org> (raw)
In-Reply-To: <528646bc0701150906o253c898dobe3b55ffb91add70@mail.gmail.com>
>> Can someone summarise why we are talking about exposing clock
>> controllers
>> for anything more than informational purposes?
>
> Isn't the whole device tree all about "informational purposes?" :-)
It is.
> 1. We all agree that the device tree is about how best to describe the
> hardware; not how Linux or anyone else intends to use it. (ie.
> provide as much relevant information as possible without building an
> insanely large tree and regardless of whether or not Linux uses the
> info.)
It seems *not* everyone has got this firmly into his/her
head yet. It is not something people have the "agree"
with at all though; it is just the way it is.
> 4. I think that the general consensus is that the device tree should
> have a node for shared SoC registers and a node for each on chip
> device. One will point to the other (phandle?) to indicate which node
> device drivers should look to for twiddling the shared bits.
Erm, the way you state this, you're violating (1.) already ;-)
Implicit from the type of SoC control thing, we know what
registers control what devices; the only thing the device
tree needs to express what those devices (from the viewpoint
of the control device) are in the device tree. i.e., like
you said, there need to be some links set up between the
controlled devices' nodes and the control node.
> 5. The contentious issue is which direction those links should be
> constructed. Does the device node describe where to find it's SoC
> parent node and what the device index is? Or does the SoC node
> describe which device nodes it provides shared register service for?
> 6. Paramount in this discussion is making sure that the device tree is
> detailed enough that if any of the above information is missing
> (because firmware is never going to have everything we want), the
> information can still be determined and filled in. For example, as
> long as we know the processor is a mpc5200b; then the shared register
> bindings can be filled in at fixup time.
Much more importantly, a big consideration is making the
binding so simple and so close to the actual hardware
relations, that it becomes as future-proof as possible.
Requiring properties in many different device nodes that
cannot have those properties required by their own binding,
is not the way to go; having the same information wholly
self-contained in the device node that the binding is all
about, in only one property even, is so obviously a much
cleaner much simpler way to go about it that I don't know,
why the heck are we still talking about this?
We should never violate (1.), period.
Segher
next prev parent reply other threads:[~2007-01-15 18:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <528646bc0701131555n3249b503i3b6e8c37db41dd52@mail.gmail.com>
2007-01-14 22:29 ` Discussion on SOC device tree bindings Grant Likely
2007-01-15 11:05 ` Sascha Hauer
2007-01-15 13:48 ` Grant Likely
2007-01-15 15:42 ` Segher Boessenkool
2007-01-16 8:25 ` Sascha Hauer
[not found] ` <45AA098C.70101@246tNt.com>
[not found] ` <6189b01379f62aa4516484872f4ef86f@kernel.crashing.org>
[not found] ` <1168810790.4803.11.camel@localhost.localdomain>
[not found] ` <ccc8fbc935d8f8d3e30870d43959f6c7@kernel.crashing.org>
[not found] ` <1168817449.4803.28.camel@localhost.localdomain>
[not found] ` <ef64a4198a02929a00c28abb5f0934b5@kernel.crashing.org>
[not found] ` <1168818533.4803.37.camel@localhost.localdomain>
[not found] ` <a1af25147ea7308c394d243511b96f69@kernel.crashing.org>
[not found] ` <45ABA20E.30008@genesi-usa.com>
2007-01-15 17:06 ` Grant Likely
2007-01-15 18:31 ` Segher Boessenkool [this message]
2007-01-16 6:25 ` Benjamin Herrenschmidt
2007-01-16 9:07 ` Segher Boessenkool
[not found] ` <1168928567.4803.55.camel@localhost.localdomain>
2007-01-17 8:40 ` Grant Likely
2007-01-19 10:58 ` Segher Boessenkool
2007-01-19 16:11 ` Yoder Stuart-B08248
2007-01-19 16:38 ` Grant Likely
2007-01-19 16:50 ` Segher Boessenkool
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=0c74c52b3ba6dd16f47fb393da58d53a@kernel.crashing.org \
--to=segher@kernel$(echo .)crashing.org \
--cc=grant.likely@secretlab$(echo .)ca \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=sven@genesi-usa$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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