Date: Sat, 30 Sep 1995 02:36:51 -0700 (PDT) From: Julian Elischer <julian@ref.tfs.com> To: hackers@freebsd.org Subject: correctness of isa.c Message-ID: <199509300936.CAA18581@ref.tfs.com>
next in thread | raw e-mail | index | archive | help
in isa_device.h,
in struct isa_device{}
one field , is defined as:
caddr_t id_maddr; /* physical i/o memory address on bus (if any)*/
ok so this is the Physical address of ram on the device..
so why does isa.c pass it into the device as:
if (!reconfig && isdp->id_maddr) {
isdp->id_maddr -= 0xa0000; /* XXX should be a define */
isdp->id_maddr += atdevbase;
which is the kvm mapped address of it..
BUT ONLY IF THE DEVICE IS in the 640K-1MB hole!
I have a device at 2GB
needless to say, I need to 'undo' this mess when
I'm probed, to find my original address..
sure it's a nice idea to do it in one place, but
it doesn't cover all bases..
then to add insult to injury:
further down..
we see.
if (isdp->id_maddr)
printf(" maddr 0x%lx", kvtop(isdp->id_maddr));
where the field is Assumed to hold a kernel virtual address..
naturally, 2GB+addevbase-0xa0000 gives a rather strange answer..
and what if I didn't want to map that memory all at once,
but use it page by page?
I'd have to zero this field, but then I wouldn't get a message
about it..
grrrrr
If I were to 'fix' this for all our drivers,
does anyone here see a really important reason for this field
to hold physical and virtual addresses at different times?
I have a pass over all drivers coming up to add devfs stuff..
I could add this to the list of things to fix..
not that many drivers have shared memory, and with frame buffers mapped
into high memory becoing more common, this kludge should go..
(also while we're about it, why is id_irq a bitfield?
it's almost believable, but is there a really good reason?)
julian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509300936.CAA18581>