Messages in this thread | | | Date | Sun, 20 Aug 2000 14:48:12 +0100 | From | Philipp Rumpf <> | Subject | Re: Updated Linux 2.4 issues page |
| |
On Sun, Aug 20, 2000 at 11:24:45AM +0100, Russell King wrote: > Theodore Ts'o writes: > > 10. To Do But Non Showstopper > > > > According to Philip Rumpf: > > * IO-mapping.txt is out of date
Just to elaborate on this a bit:
1. Many of the examples rely on ISA MMIO memory not requiring ioremap() - readb(0xC0000)-style accesses are invalid now, either use isa_readb or ioremap.
2. The statements about bus addresses are mostly outdated. Since most drivers care about PCI DMA only and we have a new API for that, those sections should just be removed.
> Can the address taken by ioremap() be clarified please? Is it supposed to > be a PCI address, or a so-called "physical" address (corresponding to the > address on the bus between the CPU and the host bridge, which may have > other devices hung on it)? > > On some ARM architectures, physical address != pci addresses. Therefore, > this is a contention point when people talk about passing "physical" > addresses into ioremap.
As far as I understand, the architecture in question has the following setup:
both MMIO and memory are accessed using the same bus. The PCI bridge translates memory bus addresses 0x80000000 ... to PCI bus addresses starting with 0; other I/O on the memory bus (flash) has its MMIO range starting at 0x40000000.
The current setup is that the addresses in struct pci_dev (which are passed to ioremap() by PCI drivers) start at 0 (and ioremap() fixes them up so they actually end up as memory bus addresses starting at 0x80000000), and there is no easy way to remap the other I/O at memory bus addresses 0x40000000 (Russell, wouldn't passing 0xC0000000 to ioremap() work ?)).
I proposed to Russell to change ioremap()'s address argument to be the memory bus address (so starting at 0x80000000 for PCI devices) and handle the offset in architecture-specific pcibios_* functions.
As I understand the current API, both setups would be correct (i.e. should work with portable PCI device drivers). The only real difference is how it handles devices not behind the PCI bridge, and there don't seem to be that many of those.
Philipp Rumpf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |