Re: isa memory address
From: Antonino Sergi
Date: Wed Nov 10 2004 - 04:40:37 EST
On Tue, 2004-11-09 at 17:56, Maciej W. Rozycki wrote:
> On Tue, 9 Nov 2004, Antonino Sergi wrote:
> > I looked for iomem with a kernel-2.4.2:
> > /proc/iomem reports
> > 00000000-0009fbff : System RAM
> > 0009fc00-0009ffff : reserved
> > 000a0000-000bffff : Video RAM area
> > 000c0000-000c7fff : Video ROM
> > 000f0000-000fffff : System ROM
> > 00100000-1fffbfff : System RAM
> > Nothing in the region 000d0000-000d0006 (used by my driver),
> > so why is it BUSY?
> Because you are trying to use the region in the I/O port space. That's
> probably not what you want to do and an 8-bit ISA board cannot decode it
> at all anyway. Actually for some platforms using the I/O space outside
> the low 16-bit range may be quite difficult even for buses and devices
> that support it and Linux does not support it then, either. So Linux
> correctly informs you you cannot use that range.
This is actually not clear for me.
> > > > I'm working with an old data acquisition system that uses an 8-bit card
> > > > in an ISA slot (address 0xd0000), by a simple driver I ported from
> > > > kernel 1.1.x to 2.2.24.
> > > >
> > > > It works fine, but I'd like to have features by newer kernels (2.4 or
> > > > even 2.6), like new filesystems support.
> > > >
> > > > On kernels >=2.4.0 check_region returns -EBUSY for that address,
> > > > but it is not actually used; I tried to understand if something has been
> > > > changed/removed, because of obsolescence of devices, in IO management,
> > > > but I couldn't.
> Try check_mem_region() instead, ...
> > > You might have to dummy up a call to release_resource() first,
> > > then use request_resource() to acquire it.
> ... or better yet request_mem_region()/release_resource(), as the former
> is deprecated and will be removed.
I tried but (on 2.4.2):
- request_region fails but, ignoring it and remapping physical address
to virtual, everything works fine, except for release_region, of course.
- request_mem_region works but what I get from communication with the
actual device are numbers that sometimes are surely wrong.
I couldn't understand what is the actual difference between
ioport_resource and iomem_resource to track the problem.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/