linux-mmc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: linux-mmc@vger.kernel.org, Chris Ball <chris@printf.net>
Cc: Dong Aisheng <b29396@freescale.com>,
	Stephen Warren <swarren@nvidia.com>,
	Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Ulf Hansson <ulf.hansson@linaro.org>
Subject: [PATCH 05/13] mmc: core: Fixup busy detection for mmc switch operations
Date: Wed, 29 Jan 2014 23:37:57 +0100	[thread overview]
Message-ID: <1391035085-2747-6-git-send-email-ulf.hansson@linaro.org> (raw)
In-Reply-To: <1391035085-2747-1-git-send-email-ulf.hansson@linaro.org>

If the host controller supports busy detection in HW, we expect the
MMC_CAP_WAIT_WHILE_BUSY to be set. Likewise the corresponding
host->max_busy_timeout should reflect the maximum busy detection
timeout supported by the host.

Previously we expected a host that supported MMC_CAP_WAIT_WHILE_BUSY to
cope with any timeout, which just isn't feasible due to HW limitations.

For most switch operations, R1B responses are expected and thus we need
to check for busy detection completion. To cope with cases where the
requested busy detection timeout is greater than what the host are able
to support, we fallback to use a R1 response instead. This will prevent
the host from doing HW busy detection.

In those cases, busy detection completion is handled by polling the for
the card's status using CMD13. This is the same mechanism used when the
host doesn't support MMC_CAP_WAIT_WHILE_BUSY.

Do note, a host->max_busy_timeout set to zero, is interpreted by the
mmc core as it don't know what the host supports. It will then provide
the host with whatever timeout the mmc core finds suitable.

For some cases the mmc core has unfurtunate no clue of what timeout to
use. In these cases we provide the host with a timeout value of zero,
which the host may interpret as use whatever timeout it finds suitable.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/mmc/core/mmc_ops.c |   33 ++++++++++++++++++++++++++-------
 1 file changed, 26 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 04ecdb9..f51b5ba 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -418,6 +418,17 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value,
 	struct mmc_command cmd = {0};
 	unsigned long timeout;
 	u32 status = 0;
+	bool use_r1b_resp = use_busy_signal;
+
+	/*
+	 * If the cmd timeout and the max_busy_timeout of the host are both
+	 * specified, let's validate them. A failure means we need to prevent
+	 * the host from doing hw busy detection, which is done by converting
+	 * to a R1 response instead of a R1B.
+	 */
+	if (timeout_ms && host->max_busy_timeout &&
+		(timeout_ms > host->max_busy_timeout))
+		use_r1b_resp = false;
 
 	cmd.opcode = MMC_SWITCH;
 	cmd.arg = (MMC_SWITCH_MODE_WRITE_BYTE << 24) |
@@ -425,13 +436,17 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value,
 		  (value << 8) |
 		  set;
 	cmd.flags = MMC_CMD_AC;
-	if (use_busy_signal)
+	if (use_r1b_resp) {
 		cmd.flags |= MMC_RSP_SPI_R1B | MMC_RSP_R1B;
-	else
+		/*
+		 * A busy_timeout of zero means the host can decide to use
+		 * whatever value it finds suitable.
+		 */
+		cmd.busy_timeout = timeout_ms;
+	} else {
 		cmd.flags |= MMC_RSP_SPI_R1 | MMC_RSP_R1;
+	}
 
-
-	cmd.busy_timeout = timeout_ms;
 	if (index == EXT_CSD_SANITIZE_START)
 		cmd.sanitize_busy = true;
 
@@ -447,18 +462,22 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value,
 	 * CRC errors shall only be ignored in cases were CMD13 is used to poll
 	 * to detect busy completion.
 	 */
-	if (host->caps & MMC_CAP_WAIT_WHILE_BUSY)
+	if ((host->caps & MMC_CAP_WAIT_WHILE_BUSY) && use_r1b_resp)
 		ignore_crc = false;
 
+	/* We have an unspecified cmd timeout, use the fallback value. */
+	if (!timeout_ms)
+		timeout_ms = MMC_OPS_TIMEOUT_MS;
+
 	/* Must check status to be sure of no errors. */
-	timeout = jiffies + msecs_to_jiffies(MMC_OPS_TIMEOUT_MS);
+	timeout = jiffies + msecs_to_jiffies(timeout_ms);
 	do {
 		if (send_status) {
 			err = __mmc_send_status(card, &status, ignore_crc);
 			if (err)
 				return err;
 		}
-		if (host->caps & MMC_CAP_WAIT_WHILE_BUSY)
+		if ((host->caps & MMC_CAP_WAIT_WHILE_BUSY) && use_r1b_resp)
 			break;
 		if (mmc_host_is_spi(host))
 			break;
-- 
1.7.9.5


  parent reply	other threads:[~2014-01-29 22:38 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-29 22:37 [PATCH 00/13] mmc: Improve busy detection for MMC_CAP_WAIT_WHILE_BUSY Ulf Hansson
2014-01-29 22:37 ` [PATCH 01/13] mmc: core: Rename max_discard_to to max_busy_timeout Ulf Hansson
2014-01-29 22:37 ` [PATCH 02/13] mmc: core: Rename cmd_timeout_ms to busy_timeout Ulf Hansson
2014-01-29 22:37 ` [PATCH 03/13] mmc: core: Add ignore_crc flag to __mmc_switch Ulf Hansson
2014-01-29 22:37 ` [PATCH 04/13] mmc: core: Minor simplifications " Ulf Hansson
2014-01-29 22:37 ` Ulf Hansson [this message]
2014-01-29 22:37 ` [PATCH 06/13] mmc: core: Use generic CMD6 time while switching to eMMC HS200 mode Ulf Hansson
2014-01-29 22:37 ` [PATCH 07/13] mmc: core: Respect host's max_busy_timeout when sending sleep cmd Ulf Hansson
2014-01-29 22:38 ` [PATCH 08/13] mmc: block: Use R1 responses for stop cmds for read requests Ulf Hansson
2014-01-29 22:38 ` [PATCH 09/13] mmc: block: Implement card_busy_detect() for busy detection Ulf Hansson
2014-01-29 22:38 ` [PATCH 10/13] mmc: block: Respect hw busy detection in card_busy_detect() Ulf Hansson
2014-01-29 22:38 ` [PATCH 11/13] mmc: block: Fixup busy detection while invoking stop cmd at recovery Ulf Hansson
2014-01-29 22:38 ` [PATCH 12/13] mmc: mmci: Handle CMD irq before DATA irq Ulf Hansson
2014-02-12 13:17   ` Ulf Hansson
2014-01-29 22:38 ` [PATCH 13/13] mmc: mmci: Enable support for busy detection for ux500 variant Ulf Hansson
2014-02-12 13:20   ` Ulf Hansson
2014-09-03  6:51 ` [PATCH 00/13] mmc: Improve busy detection for MMC_CAP_WAIT_WHILE_BUSY Dong Aisheng
2014-09-03  7:32   ` Ulf Hansson
2014-09-03  7:24     ` Dong Aisheng
2014-09-05  9:29     ` Jaehoon Chung
2014-09-05 11:02       ` Ulf Hansson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1391035085-2747-6-git-send-email-ulf.hansson@linaro.org \
    --to=ulf.hansson@linaro.org \
    --cc=adrian.hunter@intel.com \
    --cc=b29396@freescale.com \
    --cc=chris@printf.net \
    --cc=linux-mmc@vger.kernel.org \
    --cc=swarren@nvidia.com \
    --cc=vladimir_zapolskiy@mentor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).