[RFC] AmigaOne device tree source v2
segher at kernel.crashing.org
Thu Sep 6 23:56:38 EST 2007
> 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.
>>> 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
>>> 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
>> be enough to check for the board type, but a compatible property
> 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.
More information about the Linuxppc-dev