On Tue, Dec 18, 2001 at 01:57:12PM -0500, Jim Paris wrote:
> > > > -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?
It's a general memory map. Basically you have an memory address space
and an I/O space. The latter should be treated as an entirely independant
thing just like on x86 where special instructions (in / out) are necessary
to access it. On MIPS the difference is more blurry as this I/O port
addres space is accessible through normal load / store instructions.
> > 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.
Well, calling ioremap anyway is ok. The whole isa_* thing was invented to
make keeping the large number of antique ISA drivers that don't have any
maintainers alive.
Ralf
