Re: Spinlock vs mutexes for spi network driver

[Amit Uttamchandani <amit.uttam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Wed, Mar 17, 2010 at 05:28:16PM -0400, Ned Forrester wrote:

[...]

> If I recall correctly, the work queue does NOT run in interrupt context
> (are allowed to sleep), and therefore mutexs are permitted (for locking
> with other non-interrupt activity).  The interrupt handler definitely
> runs in interrupt context.  If the locking protects data that is shared
> between interrupt context and non-interrupt context, then it will have
> to be done with a spinlock.  pxa2xx_spi.c (the driver I am familiar
> with) does not use any mutexes, because the protected data structure is
> used in the interrupt handlers.
> 

Thanks for the explanation. It fixed a few issues I was having.

Regarding mutexes and spi reads and transfers. Is it possible for
multiple SPI reads to be 'overwriting' each other thus resulting in
wrong reads? Which is why mutexes should be used to lock SPI bus? I
understand there is a patch waiting to be included to the mainline that
has functions to lock the bus before doing a transfer.

e.g. You issue a read and while that read is happening, a second spi
read call from another function uses the bus and thus results in wrong
data being returned to the first read.

> It has been a while since I have dealt with this stuff, so I have said
> something wrong, above, I'm sure I will be quickly corrected.
> 

Thanks again.



------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev