> Therefore:
>
> set_io_port_base(0xb4000000);
> isa_slot_offset = 0xb0000000;
Yep, that's what I have.
> > > -more /proc/iomem
> > 00000000-00ffffff : System Ram
> > 00002000-001bc6af : Kernel code
> > 001cf300-00299fff : Kernel data
> > (this seems very wrong to me, since the kernel is most definately
> > not in the I/O memory space; real memory, of course, but I/O memory??)
>
> No, this makes perfect sense on a 16mb system.
How so? See the memory map I just sent in my other mail. Should I be
adding isa_slot_offset to calls to check/request/release_mem_region?
Or should I make a isa_{check,request,release}_mem_region that adds
this in? In which case, doesn't that turn /proc/iomem into a general
memory map rather than an I/O memory map?
> > 4) it can use ioremap, and then read[bwl] and write[bwl] with the result
> > - this fails with the current ioremap; neither ioremap nor read/write[bwl]
> > take isa_slot_offset into account
>
> And that's right because isa_slot_offset is used by the isa_{read,write}[bwl]
> functions which do not require ioremap having been called before. You're
> (fortunately ...) using PCI and PCI drivers are required to use ioremap.
No, I'm not using PCI, but it's calling ioremap anyway. So, yes, I
suppose I could change the driver to not call ioremap and use
isa_{read,write}[bwl] (since doing both adds KSEG1 twice).
But why shouldn't ioremap + {read,write}[bwl] also work?
If it did, I wouldn't have to touch the driver.
-jim
