[PATCH 15/16] Add device tree for Ebony

[Segher Boessenkool]

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

Yes, and they can use "dcr-reg" properties just fine; compare
to how "interrupt-parent" works: nodes that can use the normal
tree rules don't need it, everything else does.

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

It's not about MMIO; it's about addressability.  On many systems
almost none of the I/O subsystems primary address (config space
for PCI!) is on MMIO.

Quoting from OF1275:

> The device tree’s structure mimics the organization of the system 
> hardware, viewed as a hierarchy of interconnected buses and their 
> attached devices.

The interrupt cascade is not a bus.

> I picked the interrupt tree, because
> it seemed to make as much or more logical sense as the other,

Yeah I know.

> and as a
> bonus it makes the probing logic easier.

How so?  There already is completely generic probing
code for interrupt controllers AFAIK.


Segher