Note: I had forgot to start this thread on the mailing list; but I'm
moving it there now.
On 1/15/07, Matt Sealey [off-list ref] wrote:
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?" :-)
I seem to have missed some mails, had some spam filtered and deleted by
automation this weekend, and I am not following the general discussion
so well (from a "I don't understand" standpoint) as it is.
I am not sure from my point of view that it is relevant to expose such
details in the tree since the information is not useful or changable by
Linux. What clock controls what device, the cascading down the tree and
so on doesn't seem to give me any more information than no information
at all when the clocks are relatively fixed at boot time (Linux should
not be reconfiguring internal SoC bus clocks)
No, we're not talking about SoC bus clocks. In fact, we're not
talking about clocks at all. :-) Shared clock registers just happen
to be a convenient example for the topic we're really talking about.
The thread started with discussion about the 5200 device tree binding
conventions, but has moved to a specific issue. Now we are talking
about how to deal with shared registers. ie. There are 2 I2C
controllers on the 5200, but they share one register. How is that
best represented in the device tree?
Here's the quick summary of the points so far:
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.)
2. It is not reasonable to try to describe every chip register in the
device tree
3. It is reasonable to assume that the OS has SoC specific code to
deal with variations in implementation.
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.
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.
It may come in useful and this may be a bad example, for ATA drivers
where I always see the message "assuming 33MHz bus lock for PIO" - rather
than assume, it would be reported, but is this all that we are discussing
here or is there something a lot more complicated coming off it that just
went right over my head?
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
quoted
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
The thread started with discussion about the 5200 device tree binding
conventions, but has moved to a specific issue. Now we are talking
about how to deal with shared registers. ie. There are 2 I2C
controllers on the 5200, but they share one register. How is that
best represented in the device tree?
.../i2c-core/i2c-bus@0
/i2c-bus@1
Or something like that. Make one device that encloses them all. Well,
that's of the top of my head, somebod might have a better idea.
Ben.
quoted
The thread started with discussion about the 5200 device tree binding
conventions, but has moved to a specific issue. Now we are talking
about how to deal with shared registers. ie. There are 2 I2C
controllers on the 5200, but they share one register. How is that
best represented in the device tree?
.../i2c-core/i2c-bus@0
/i2c-bus@1
This describes two i2c buses under one i2c controller;
that's not the same thing. OTOH, I suspect that's
closer to the real situation. Grant?
Or something like that. Make one device that encloses them all.
It's the only way to do it, the shared register can be
in the "reg" property for one device node only.
Segher