Re: [PATCH RFC 0/7] "NAND on UPM" and related patches

[Anton Vorontsov <avorontsov@ru.mvista.com>]

On Wed, Dec 12, 2007 at 10:54:29AM -0600, Scott Wood wrote:
> Anton Vorontsov wrote:
> >On Wed, Dec 12, 2007 at 10:40:35AM -0600, Scott Wood wrote:
> >>Not enough to be worth the complexity compared to the overhead of NAND
> >>access -- especially in the likely case of a non-SMP build.
> >
> >I'm allowing UPM access from the IRQ handlers (because nothing prevents
> >this, so why deny?). Thus locks are needed even on non-SMP build,
> 
> No, it just needs to disable interrupts.
> Which is what locks do on non-SMP.
> The overhead of this is not worth 30 lines of code to avoid.

Well, speaking of overhead. There could be a lot of fsl_upm_run_pattern
calls between _start and _end. In NAND case it's maximum 3, plus
they're indirect (i.e. NAND layer calls them via pointers to cmdfunc,
and cmdfunc calls run_patterns). Each out_X is another sync, and all
that time we're holding a lock with local IRQs disabled.

fsl upm infrastructure isn't only for NAND though, so I might imagine
use cases when there might be more run_patterns between start and end.

As the compromise I might suggest this: forbid pattern_start/pattern_end
from the ISRs (by marking them as might_sleep()), and replace _irqsave
spinlock with simple spinlock.

That way on UP we don't lose anything, but on SMP we still have an
overhead in case of single used UPM. :-/

Given that, personally I'd want to lockless variant to stay.

So, you still want to get rid of it?


Much thanks,

-- 
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2