MTD Mapping driver - out of vmalloc space
chris.elston at radstone.co.uk
Sat Apr 9 00:42:46 EST 2005
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
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
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...
Size: 8944 bytes
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050408/d417043f/attachment.obj
More information about the Linuxppc-embedded