Re: [PATCH 1/5] spi: spi_lock_bus and spi_unlock_bus

[Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

On Wed, Feb 17, 2010 at 12:35 AM, Ernst Schwab <mail-3FdAPXqljGQisWB6T/0fQA@public.gmane.org> wrote:
> Grant Likely wrote:
>
>> It sounds like you're very worried about making changes to the core
>> code,
>
> Maybe...
>
>> In fact, now that I've had an evening to think about it, the solution
>> is even simpler than what I said earlier.  It requires 3 things to be
>> added to struct spi_master.
>> - 1 Mutex
>> - 1 spin lock
>> - 1 flag.
>
>> The mutex protects spi_async, and provides sleeping "for free"
>> The spinlock protects the atomic spi_sync call.
>
> Sound viable and good, but, in Documentation/spi/spi-summary we have:
>
> "
> The basic I/O primitive is spi_async().  Async requests may be
> issued in any context (irq handler, task, etc) and completion
> is reported using a callback provided with the message.
> After any detected error, the chip is deselected and processing
> of that spi_message is aborted.
> "
>
> Is this compatible with a Mutex protecting spi_async?
> It seems to me, that spi_async must queue the SPI message
> immediately and return. The queue is implemented in the SPI master driver. I
> suppose that's why the blackfin bus locking pioneers chose to make the
> change in the SPI master driver.

No, sorry, I made a mistake and got the functions backwards when I was
writing up my description.  What I meant to say is:

spi_sync() is protected by a mutex because it can sleep
spi_async() needs to be protected with a flag and a spinlock because
it can be called atomically and must not sleep

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev