[lkml]   [1996]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: test version of 2.1.0 available
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

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 Karrer

xgras -- The Great RHEED-Analysys System for Linux


 \ /
  Last update: 2005-03-22 13:37    [W:0.053 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site