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. Regards Ernst ------------------------------------------------------------------------------ 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
