MTD Mapping driver - out of vmalloc space

Chris Elston chris.elston at
Sat Apr 9 00:42:46 EST 2005

Dear all,

I'm writing an MTD mapping driver for a board with (up to) 512M SDRAM, and
(up to) 256M Flash and I've hit a bit of a problem.  The standard way to write
a mapping driver seems to be to map the whole of the Flash into kernel virtual
memory space.  While this is not a problem for small Flash devices, I'm hitting
the limit of the vmalloc space.  

So I decided to modify my mapping driver to work through a smaller virtual 
addressing window.

Basically, all reads/writes are redirected through my custom functions which
first ensure that the correct physical address range is mapped into virtual
space and then drop through to the standard read/write functions.  The mapping
is achieved using ioremap/iounmap calls.  (code attached)

David Woodhouse pointed out that this approach is not viable because the reads
and writes must be atomic - and ioremap can potentially sleep.  So I'm stuck as
to how to proceed.

Ideally what I'd like is to be able to allocate a block of virtual addresses at 
init time and then dynamically modify the physical address range that it refers to.
Since I wouldn't be requesting any more vmalloc space - just changing the mapping 
for the space I have got - I'd hopefully be able to make this a non-blocking
operation.  Unfortunately I have no idea how to go about this - or even if it's
possible :)

Thanks in advance,


This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rsppc7d-flash.c
Type: application/octet-stream
Size: 8944 bytes
Desc: rsppc7d-flash.c
Url : 

More information about the Linuxppc-embedded mailing list