On Tue, 18 Dec 2001, Jim Paris wrote:
> The ports are dealt with by /proc/ioports. What about /proc/iomem?
> The ISA ports and ISA memory are seperate, and the ports work fine and
> just as I would expect them to. But for memory, where should the
> PCMCIA driver be reserving space? Should I
> 1) make /proc/iomem contain addresses relative to the start of I/O memory,
> just as /proc/ioports contains addresses relative to the start of
> I/O port space? This will only work if I stop letting the kernel
> reserve the iomem resource for system memory.
There should probably be an ISA memory space reserved somewhere in the
CPU memory space (/proc/iomem reflects memory addresses as seen by the
CPU). You should reserve resources within it.
There should be an ISA I/O space reserved somewhere in /proc/iomem, too,
as the I/O space is real only for CPUs defining special bus cycles for I/O
accesses (MIPS is not one of them, hence it must be done by the chipset).
The /proc/ioports reports addresses relative to that space.
> 2) make the i82365 driver use absolute addresses in /proc/iomem, by
> adding (isa_slot_offset - KSEG1) to all *_mem_resource calls?
> (breaks i82365 for other arches)
Mapping between physical addresses and MIPS virtual addresses (KSEG1 is a
virtual address) should be done by bus access functions (or macros), such
as inb/outb/readl/readw/isa_readb/isa_readw, etc. See the Alpha port for
how it should be done. It appears to have done it particularly cleanly.
> 3) Invent a new resource "isamem", reserve the correct absolute
> addresses in "iomem", and the modify the i82365 driver to use
> "isamem" instead? (again breaks i82365 for other arches)
Don't do it.
> Given the current way the I/O memory is handled on MIPS, the only way
> I can get the i82365 driver working breaks it for every other arch.
Then the MIPS I/O memory handling is broken.
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail: email@example.com, PGP key available +