Messages in this thread |  | | From | Jochen Karrer <> | Subject | Re: test version of 2.1.0 available | Date | 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
--
|  |