[14/19] mmc: sdricoh_cs: Respect the cmd->busy_timeout from the mmc core

Message ID 20200414161413.3036-15-ulf.hansson@linaro.org
State New
Headers show
  • mmc: Improve host driver's support for R1B responses
Related show

Commit Message

Ulf Hansson April 14, 2020, 4:14 p.m.
Using a fixed 1s polling timeout for all commands is a bit problematic.

For some commands it means waiting longer than needed for the polling to be
aborted, which may not a big issue, but still. For other commands, like for
an erase (CMD38) that uses a R1B response, may require longer timeouts than
1s. In these cases, we may end up treating the command as it failed, while
it just needed some more time to complete successfully.

Fix the problem by respecting the cmd->busy_timeout, which is provided by
the mmc core.

Note that, even if the sdricoh_cs driver may currently not support HW busy
detection on DAT0, some comments in the code refer to that the HW may
support it. Therefore, it seems better to be proactive in this case.

Cc: Sascha Sommer <saschasommer@freenet.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

 drivers/mmc/host/sdricoh_cs.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)



diff --git a/drivers/mmc/host/sdricoh_cs.c b/drivers/mmc/host/sdricoh_cs.c
index d7a191f14337..dfd395ff7c3e 100644
--- a/drivers/mmc/host/sdricoh_cs.c
+++ b/drivers/mmc/host/sdricoh_cs.c
@@ -156,7 +156,7 @@  static int sdricoh_query_status(struct sdricoh_host *host, unsigned int wanted)
 static int sdricoh_mmc_cmd(struct sdricoh_host *host, struct mmc_command *cmd)
-	unsigned int status;
+	unsigned int status, timeout_us;
 	int ret;
 	unsigned char opcode = cmd->opcode;
@@ -178,9 +178,12 @@  static int sdricoh_mmc_cmd(struct sdricoh_host *host, struct mmc_command *cmd)
 	if (!opcode)
 		return 0;
+	timeout_us = cmd->busy_timeout ? cmd->busy_timeout * 1000 :
 	ret = readl_poll_timeout(host->iobase + R21C_STATUS, status,
 			sdricoh_status_ok(host, status, STATUS_CMD_FINISHED),
+			32, timeout_us);
 	 * Don't check for timeout status in the loop, as it's not always reset