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. -Scott _______________________________________________ Linuxppc-dev mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-dev
