[RFC] AmigaOne device tree source v2

[Segher Boessenkool]

> That looks totally bogus.  Unlike Segher, I think there are a few
> cases where overlapping reg and ranges can make sense

That's not unlike me -- I may have lower tolerance for it though :-)

> (PCI bridges
> where config space is accessed indirectly via MMIO registers which lie
> in the legacy ISA IO space is an example).

That's a good example yes.

> But this doesn't look like
> such a case - it just looks like whoever did the device tree
> misunderstood the distinction between reg and ranges.

Indeed.

>>> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
>>> PowerPC system bus.  So, it can not be mentioned in the "ranges"
>>> property, but the PHB registers used to access it should be shown
>>> in the "reg" property.  It could be a simple linear window (it
>>> sounds like it is here?), but it could for example also be 
>>> implemented
>>> via an address/data register pair.
>
> Err... huh?  The legacy IO space is assigned a block of addresses in
> 3-word "OF-PCI-space by the PCI binding.  When that is translated into
> an MMIO range by the bridge, there's no reason that can't be encoded
> into the ranges property.

Sure, it can be encoded like that.  But does it make sense?
You cannot use legacy I/O space as normal memory space.

On an arch like x86, where "I/O addresses" exist on the system
bus as well, it would make sense, since you can translate I/O
addresses to I/O addresses that way (except on x86 even it cannot
be done either, since I/O addresses cannot be encoded on the root
bus -- at least not in existing device trees.  There is no official
x86 binding yet though).

Also, from a driver standpoint, a PHB driver needs to find out
two main things about the bridge: a) how and where to generate
config cycles; b) how and where to generate legacy I/O cycles.
It is told "how" by the "compatible" property, and "where" by
the "reg" property, normally.

But yes, you _can_ use "ranges" for this purpose on PHBs where
legacy I/O is linearly mapped.  It just doesn't make much sense.
The binding for your specific PHB should tell you what to do.

>> Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it 
>> should
>> be enough to check for the board type, but a compatible property 
>> doesn't
>> hurt.
>
> The whole damn point of the device tree is to avoid using this kind of
> non-local information "I know what the board type is over there, so it
> must be this PCI bridge over here".  The node should have a compatible
> property which is sufficient to select the right bridge driver.

Yeah.  _Even if_ the kernel decides to cheat by hardcoding certain
board information, that doesn't mean the device tree shouldn't
encode that info, too.

> I think this is typically badly done at the moment, simply because PCI
> has historically been set up by the platform code, rather than by a
> "host bridge driver" in the mould of other drivers.  I don't see that
> changing real soon, but that doesn't mean we shouldn't at least put
> enough information in the device tree to make it possible.

Exactly.


Segher