Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753604AbZIRAwS (ORCPT ); Thu, 17 Sep 2009 20:52:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752710AbZIRAwO (ORCPT ); Thu, 17 Sep 2009 20:52:14 -0400 Received: from smtp.gentoo.org ([140.211.166.183]:56409 "EHLO smtp.gentoo.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752220AbZIRAwN (ORCPT ); Thu, 17 Sep 2009 20:52:13 -0400 From: Mike Frysinger To: spi-devel-general@lists.sourceforge.net, David Brownell Cc: Andrew Morton , linux-kernel@vger.kernel.org, Yi Li Subject: [PATCH 2/2 v2] mmc_spi: lock the SPI bus when accessing the card Date: Thu, 17 Sep 2009 20:52:14 -0400 Message-Id: <1253235134-25571-1-git-send-email-vapier@gentoo.org> X-Mailer: git-send-email 1.6.5.rc1 In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3090 Lines: 98 From: Yi Li 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 Signed-off-by: Mike Frysinger --- 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 -- 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/