Discussion on SOC device tree bindings

[Segher Boessenkool]

> I don't think the argument that the data should not be scattered about
> in various device nodes holds a whole lot of water.

It's one of the main design principles behind the device
tree at all, how can it _not_ make sense.  If you just put
random pieces of data wherever you feel like putting them
you end up with ACPI instead.

> There is already
> precedence for this with the interrupt binding.

With interrupts it is unavoidable, since you often have cascaded
controllers.

> Putting the linkage in the device nodes does not bloat the tree, and
> it does not duplicate information.  The device tree is just as
> expressive either way around,

Except you have to parse the whole tree to determine the function
of the one controller node.

> so typical usage becomes the tie
> breaker.  Typical usage is for the device driver to "call" the system
> node; therefore put the linkage information in the device node where
> it's most easily retrieved when needed.

You don't normally use the device tree at runtime; typical usage
is to parse it at startup and initialise some internal kernel
data structures from that.  The device tree needs to express the
system in a clear, extensible way; it is not its purpose to "make
things easy" for the Linux kernel (although that can happen as a
side effect).

> Looking at the larger scope; we're talking about an SoC here.  While
> most of the SoC device drivers don't need to know anything about the
> SoC as a whole, the platform code should really know what SoC part it
> is on.  SoC designers love to toss in special cases which don't really
> slide nicely into our pretty device tree, and the OS almost always
> needs chip specific support code to handle it.

Yep.  Which is why IMHO the OF binding shouldn't even try to
model the functionality of such a SoC controller node.  It has
to show what it is that is controlled though.

> I'm inclined to say
> that the bindings from device node to shared soc registers may be
> *recommended*, but not *required*.

If they aren't required, you obviously have some other way to
get that information, so it shouldn't be recommended either.

>   As long as there is some form of
> linkage between the soc and device nodes, and as long as the SoC node
> describes exactly which SoC it is, then the OS has all the information
> it needs to figure out which devices are connected to which bits of
> which shared registers (based on register address).

Yes exactly.  And if we can express all this in a simple
self-contained way, like for example put this all in one
device node, why do something terribly complex and kludgy
instead?

> Now, this might
> be a bad precedence, but I'm hesitant to go down the path of trying to
> describe something in the device tree which is inherent to the SoC
> design.

You shouldn't try to.  Since the "controlled" devices are in
the device tree however, you have to list them in the "controller"
node so you can figure out what is what.


Segher