Discussion on SOC device tree bindings

[Segher Boessenkool]

>> 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