Re: Accessing MMIO PCI space - crossplatform

Jamie Lokier (jamie@imbolc.ucc.ie)
Sun, 15 Nov 1998 09:05:10 +0000


On Sat, Nov 14, 1998 at 09:12:10PM +0100, ralf@uni-koblenz.de wrote:
> On Fri, Nov 13, 1998 at 03:55:04PM +0000, Jamie Lokier wrote:
> > This mess will be cleaned up sometime in version 2.3. So if you want it
> > cleaned up, perhaps the best way is to help ensure 2.2 is ready for
> > release. Hint :-)
>
> Can you elaborate a bit about your cleanup plans? The current scheme of
> dealing with I/O addresses, caches and other things doesn't deal with some
> hardware features of certain MIPS or other systems which do an ``virtual
> busaddr'' to ``physical busaddr'' translation. I'm myself working a bit
> on extending the current scheme to support more powerful I/O hardware.

I wasn't necessarily thinking of doing it myself! :-) Mainly because
it's a *huge* job, because of all the old drivers which need to be
changed with any new scheme even to keep working on their original
platforms. Or lots of compatibility macros need writing.

Can you tell me what you mean by "virtual busaddr" to "physical
busaddr"? If it is a translation of addresses from the CPU subsystem to
those on the ISA/PCI bus, it's not a problem because it can be
encapsulated in ioremap().

If it's a way to access 64-bit PCI space from a 32-bit micro, everything
gets dubious because you sometimes want to pass the bus address around,
which needs the full 64 bits. To make matters worse, in this case some
devices won't be able to write to the memory of others because you can't
program them with 64-bit target addresses.

If it's a translation between different devices on the ISA/PCI bus
that's a much bigger problem because a few things do device-to-device
DMA, and they would have to know about this one way or another.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/