Re: Discussion on SOC device tree bindings

["Grant Likely" <grant.likely@secretlab.ca>]

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 <matt@genesi-usa.com> 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