On Wed, Feb 17, 2010 at 12:35 AM, Ernst Schwab <[email protected]> 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 _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
