Re: test version of 2.1.0 available

Jochen Karrer (karrer@wpfd25.physik.uni-wuerzburg.de)
Wed, 25 Sep 1996 10:23:04 +0200 (MET DST)

Hi
Linus wrote:
>
> - memory re-mapping may be broken right now, so anything that needs
> "vremap()" probably doesn't work. If you have a driver that breaks due
> to this, please test changing the line (line 187 in mm/vmalloc.c)
>
> set_pte(pte, mk_pte(offset, PAGE_KERNEL));
>
> to do a
>
> set_pte(pte, mk_pte(offset+PAGE_OFFSET, PAGE_KERNEL));

I am using vremap for remaping memory and memory-mapped IO-Space
from a PCI-Framegrabber. The address PCI-Bus-Adress is 0xf8000000,
so I don't think
set_pte(pte, mk_pte(offset+PAGE_OFFSET, PAGE_KERNEL));
will work, because 0xf8000000+0xc0000000 => wrap around)

I'm also confused about the usage of readl().
readl() adds PAGE_OFFSET to the Address I wan't to write to,
but my driver reads from vremaped PCI-memory, and with
the new scheme vremap will return a virtual address like
0xc???????. If another 3Giga is added there will be a
wraparound. I think we have to discriminate between
a readl to real (Bus) addresses and a readl to vremaped
memory.

As the ncr53c8xx.c uses the same memory-mapping scheme, my
Framegrabber uses, I would like to hear if the NCR-driver works
in memory-mapped mode in pre-2.1. If I'm right it should
try to access memory at
0xc0000000+0xc00000000+something_small = 0x80000000+something_small

Jochen

--


Jochen Karrer
http://cip.physik.uni-wuerzburg.de/~cip307


xgras -- The Great RHEED-Analysys System for Linux



--