On 02/16/2010 03:43 PM, Grant Likely wrote: > On Tue, Feb 16, 2010 at 12:57 PM, Ernst Schwab <[email protected]> wrote: >> From: Yi Li <[email protected]> >> >> For some MMC cards over SPI bus, it needs to lock the SPI bus for its own >> use. The SPI transfer must not be interrupted by other SPI devices that >> share the SPI bus with SPI MMC card. >> >> This patch introduces 2 APIs for SPI bus locking operation. > > This series seems to try and solve the problem the hard way, and by > creating a new locking scheme (and as history shows, new locking > schemes are *alwasy* broken). > > Why is the locking getting pushed down to the bus driver level? It > seems to me that the whole thing could be handled with common code and > a mutex in the spi_master structure. spi_sync would be easy to handle > by putting a mutex around the spi_message submission. spi_async would > be a little harder since it needs to be atomic, but that could also be > handled with a flag protected by a spinlock. > > Basically, the idea is that existing drivers continue to use the API as-is > > Drivers that want to lock the bus for exclusive access must call > spi_lock_bus() which should take the mutex and then sleep until all > in-flight spi_messages are processed. After that, anyone calling > spi_async() will simply sleep until the locker unlocks the bus again. > > To handle spi_sync() would probably require a flag protected by a > spinlock. If the flag is set, then spi_sync() would simply fail. > > Finally, the locking driver would need locked versions of spi_sync() > and spi_async() that sidestep the lock checks. It would only be valid > to call these versions when holding the SPI bus lock. > > There is no need to specify the spi_device in the lock request. Since > the lock is exclusive, it is known that the only driver calling the > locked API version must already hold the lock. > > Have I got this wrong?
Not sure. Does your proposal account for the case of a system with more than one SPI bus? In such a case, there should be a lock per bus. -- Ned Forrester [email protected] Oceanographic Systems Lab 508-289-2226 Applied Ocean Physics and Engineering Dept. Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA http://www.whoi.edu/ http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212 http://www.whoi.edu/hpb/Site.do?id=1532 http://www.whoi.edu/page.do?pid=10079 ------------------------------------------------------------------------------ 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
