Messages in this thread | | | From | Mike Frysinger <> | Date | Thu, 17 Sep 2009 18:53:58 -0400 | Subject | Re: [spi-devel-general] [PATCH 1/2] spi: new SPI bus lock/unlockfunctions |
| |
On Thu, Sep 17, 2009 at 18:45, H Hartley Sweeten wrote: > On Thursday, September 17, 2009 3:03 PM, Mike Frysinger wrote: >> From: Yi Li <yi.li@analog.com> >> >> 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. >> >> /** >> + * spi_lock_bus - lock SPI bus for exclusive access >> + * @spi: device which want to lock the bus >> + * Context: any >> + * >> + * Once the caller owns exclusive access to the SPI bus, >> + * only messages for this device will be transferred. >> + * Messages for other devices are queued but not transferred until >> + * the bus owner unlock the bus. >> + * >> + * The caller may call spi_lock_bus() before spi_sync() or spi_async(). >> + * So this call may be used in irq and other contexts which can't sleep, >> + * as well as from task contexts which can sleep. >> + * >> + * It returns zero on success, else a negative error code. >> + */ >> +int spi_lock_bus(struct spi_device *spi) >> +{ >> + if (spi->master->lock_bus) >> + return spi->master->lock_bus(spi); >> + else >> + return 0; >> +} >> +EXPORT_SYMBOL_GPL(spi_lock_bus); >> + >> +/** >> + * spi_unlock_bus - unlock SPI bus >> + * @spi: device which want to unlock the bus >> + * Context: any >> + * >> + * The caller has called spi_lock_bus() to lock the bus. It calls >> + * spi_unlock_bus() to release the bus so messages for other devices >> + * can be transferred. >> + * >> + * If the caller did not call spi_lock_bus() before, spi_unlock_bus() >> + * should have no effect. >> + * >> + * It returns zero on success, else a negative error code. >> + */ >> +int spi_unlock_bus(struct spi_device *spi) >> +{ >> + if (spi->master->unlock_bus) >> + return spi->master->unlock_bus(spi); >> + else >> + return 0; >> +} >> +EXPORT_SYMBOL_GPL(spi_unlock_bus); >> + >> +/** > > I assume the spi master driver must supply the {lock/unlock}_bus methods > to properly support the locking.
currently, yes. a common solution would be nice. ideas/patches welcome ;).
> But, by returning 0 when the methods > are not supplied you are basically saying all the current master drivers > in mainline support bus locking. I think this is really only "true" if > spi->master->num_chipselect == 1.
right, but that is no different from what we have today. there is no way for a client to guarantee exclusive access, so you cant write code assuming it in the first place. the only consumer thus far (mmc_spi) actually errors out if such conditions exist.
in other words, we arent breaking anything.
> Also, do you have a master driver that does have the {lock/unlock}_bus > methods? I would like to see how you handled it.
http://git.kernel.org/?p=linux/kernel/git/vapier/blackfin.git;a=commitdiff;h=cc54fa8ed63e11a000031bc650d41d57b441803d -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |