[PATCH 15/16] Add device tree for Ebony

[David Gibson]

On Thu, Feb 15, 2007 at 04:09:15AM +0100, Segher Boessenkool wrote:
> >> Yes.  UIC1 is not addressed via UIC0, and as such should
> >> not be a child of it; it should be a direct child of its DCR
> >> controller, just like UIC0.
> >
> > No, the DCR tree, like the interrupt tree in most cases, is
> > independent of the main tree structure.
> 
> Yes true; you can hang the UICs from somewhere under the
> "soc" node or whatever you want.  You need some way to
> distinguish separate identical devices though; you can't
> do it by device unit since your devices don't have any
> (they don't have a "reg" but only a "dcr-reg").  If you
> would hang them in a DCR tree, you could use the plain
> "reg" property instead of the "dcr-reg" property and
> all would be fine (if the DCR binding allows this -- and
> it better should, it is the standard OF addressing algorithm).

No, doesn't work.  The trouble is there are other devices that *do*
sit on the normal MMIO bus, but also have DCRs (MAL, POB, SDRAM
controller).  The DCR tree has to cut across the normal bus tree, like
the interrupt tree.

> However, my main point remains: the two interrupt controllers
> should be siblings in the device tree, since they are that on
> the hardware.

In what way are they "that on the hardware".  They're siblings on the
DCR tree, they're parent/child on the interrupt tree.  Given that
they're not on the MMIO tree at all, I see no strong reason to pick
one representation over another.  I picked the interrupt tree, because
it seemed to make as much or more logical sense as the other, and as a
bonus it makes the probing logic easier.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson