From: Yi Li <[email protected]> The MMC/SPI spec does not play well with typical SPI design -- it often needs to send out a command in one message, read a response, then do some other arbitrary step. Since we can't let another SPI client use the bus during this time, use the new SPI lock/unlock functions to provide the required exclusivity.
Signed-off-by: Yi Li <[email protected]> Signed-off-by: Mike Frysinger <[email protected]> --- v2 - drop now unused maybe_count_child as pointed out by H Hartley Sweeten drivers/mmc/host/mmc_spi.c | 41 ++--------------------------------------- 1 files changed, 2 insertions(+), 39 deletions(-) diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c index a461017..c3563a7 100644 --- a/drivers/mmc/host/mmc_spi.c +++ b/drivers/mmc/host/mmc_spi.c @@ -1084,6 +1084,7 @@ static void mmc_spi_request(struct mmc_host *mmc, struct mmc_request *mrq) #endif /* issue command; then optionally data and stop */ + spi_lock_bus(host->spi); status = mmc_spi_command_send(host, mrq, mrq->cmd, mrq->data != NULL); if (status == 0 && mrq->data) { mmc_spi_data_do(host, mrq->cmd, mrq->data, mrq->data->blksz); @@ -1092,7 +1093,7 @@ static void mmc_spi_request(struct mmc_host *mmc, struct mmc_request *mrq) else mmc_cs_off(host); } - + spi_unlock_bus(host->spi); mmc_request_done(host->mmc, mrq); } @@ -1294,18 +1295,6 @@ struct count_children { struct bus_type *bus; }; -static int maybe_count_child(struct device *dev, void *c) -{ - struct count_children *ccp = c; - - if (dev->bus == ccp->bus) { - if (ccp->n) - return -EBUSY; - ccp->n++; - } - return 0; -} - static int mmc_spi_probe(struct spi_device *spi) { void *ones; @@ -1337,32 +1326,6 @@ static int mmc_spi_probe(struct spi_device *spi) return status; } - /* We can use the bus safely iff nobody else will interfere with us. - * Most commands consist of one SPI message to issue a command, then - * several more to collect its response, then possibly more for data - * transfer. Clocking access to other devices during that period will - * corrupt the command execution. - * - * Until we have software primitives which guarantee non-interference, - * we'll aim for a hardware-level guarantee. - * - * REVISIT we can't guarantee another device won't be added later... - */ - if (spi->master->num_chipselect > 1) { - struct count_children cc; - - cc.n = 0; - cc.bus = spi->dev.bus; - status = device_for_each_child(spi->dev.parent, &cc, - maybe_count_child); - if (status < 0) { - dev_err(&spi->dev, "can't share SPI bus\n"); - return status; - } - - dev_warn(&spi->dev, "ASSUMING SPI bus stays unshared!\n"); - } - /* We need a supply of ones to transmit. This is the only time * the CPU touches these, so cache coherency isn't a concern. * -- 1.6.5.rc1 ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
