PCI I/O space -- reg or ranges?
scottwood at freescale.com
Fri Sep 7 00:15:01 EST 2007
On Thu, Sep 06, 2007 at 03:56:38PM +0200, Segher Boessenkool wrote:
> > 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.
Why does it not make sense? I'm not sure what you mean by using it as
"normal memory space", but if the PCI bridge does a straightforward
linear mapping of I/O into memory space (like most non-x86 bridges do),
it seems to make sense to me to reuse the existing ranges mechanism
rather than require each driver to have extra glue code.
And given the substantial impact of such a change on many existing device
trees and the kernel, it should probably be brought up in a thread with a
subject that will clue people in to what is being discussed, rather than
buried in "AmigaOne device tree source v2".
BTW, memory space could be non-linear as well, so should we stop using
ranges for that? For an example, see the old Alphas which lacked
byte/word I/O, and thus used a weird sparse mapping to control the size
of the access that went out over the bus.
> 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.
All it currently needs to do is a), provided it's a normal linear mapping
and the I/O space is in ranges.
More information about the Linuxppc-dev