[PATCH][MTD] mtdpart.c: allow other drivers to get physical address of partition

[David Woodhouse]

On Thu, 2007-08-02 at 14:55 -0700, Jared Hulbert wrote:
> > That does'nt work on smp machines, does it?
> 
> Probably not.  That code is machine specific, and only implemented for
> a couple of ARM targets.
> 
> > Sounds like a hack to me.
> 
> :)  Yes but it works where it needs to.  It's done a lot in the cellular world.
> 
> > How do you know a user app that has a valid pte to your flash media
> > accesses it? Userspace may do so at any time it wants, and as far as I
> > understand Joerns and Davids explanations on flash it will just see
> > invalid data rather than raising a page fault.
> 
> Maybe I wasn't so clear.  Assuming the MTD is going to do an erase you would:
> 
> (a) zap all page affected by block erase
> (b) identify all pte's mapped to the affected region
> (c) modify these pte's so they now trigger a fault
> (d) wait for completion of erase
> (c) reestablish valid pte mappings

No need to reestablish them -- they'll fault when they need to, which
means less work next time you erase. And it'll be a minor page fault,
which is quite cheap -- it only needs to set up the pte and return.

> If you get a fault it gets routed to the filesystem .fault or
> something like that.  The .fault routine can:
> (a) suspend the erase
> (b) copy the page to RAM
> (c) update the pte to point to RAM
> (d) resume the erase

This could lead to all your data pages ending up in RAM, which kind of
defeats the object of XIP.

> -or-
> (a) suspend the erase
> (b) reenable the pte
> (c) wait a short time
> (d) disable pte again
> (e) resume the erase

Alternatively, just wait for the chip to become available. Or increment
a count of 'waiters' and only interrupt the erase when there are a
certain number of people waiting.

Perhaps we want to set it up so that _if_ there is a process which can
continue, it'll do so. Only when there's nothing runnable in userspace
do we suspend an erase? In that case, perhaps we'd want some kind of
hook in the idle loop?

-- 
dwmw2