| Message ID | 20200414161413.3036-4-ulf.hansson@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | mmc: Improve host driver's support for R1B responses | expand |
On Tue, Apr 14, 2020 at 06:13:57PM +0200, Ulf Hansson wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Using a fixed 2s timeout for all commands is a bit problematic. > > For some commands it means waiting longer than needed for the timer to > expire, 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 > 2s. 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. > > Cc: Ludovic Desroches <ludovic.desroches@microchip.com> > Cc: Nicolas Ferre <nicolas.ferre@microchip.com> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Far better than a fixed timeout. This driver covers many versions of the IP. I could test it with only one version. As I didn't any regression and these three patches make sense Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com> Thanks > --- > drivers/mmc/host/atmel-mci.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c > index 7292970065b6..5cb692687698 100644 > --- a/drivers/mmc/host/atmel-mci.c > +++ b/drivers/mmc/host/atmel-mci.c > @@ -809,6 +809,9 @@ static u32 atmci_prepare_command(struct mmc_host *mmc, > static void atmci_send_command(struct atmel_mci *host, > struct mmc_command *cmd, u32 cmd_flags) > { > + unsigned int timeout_ms = cmd->busy_timeout ? cmd->busy_timeout : > + ATMCI_CMD_TIMEOUT_MS; > + > WARN_ON(host->cmd); > host->cmd = cmd; > > @@ -819,8 +822,7 @@ static void atmci_send_command(struct atmel_mci *host, > atmci_writel(host, ATMCI_ARGR, cmd->arg); > atmci_writel(host, ATMCI_CMDR, cmd_flags); > > - mod_timer(&host->timer, > - jiffies + msecs_to_jiffies(ATMCI_CMD_TIMEOUT_MS)); > + mod_timer(&host->timer, jiffies + msecs_to_jiffies(timeout_ms)); > } > > static void atmci_send_stop_cmd(struct atmel_mci *host, struct mmc_data *data) > -- > 2.20.1 >
diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c index 7292970065b6..5cb692687698 100644 --- a/drivers/mmc/host/atmel-mci.c +++ b/drivers/mmc/host/atmel-mci.c @@ -809,6 +809,9 @@ static u32 atmci_prepare_command(struct mmc_host *mmc, static void atmci_send_command(struct atmel_mci *host, struct mmc_command *cmd, u32 cmd_flags) { + unsigned int timeout_ms = cmd->busy_timeout ? cmd->busy_timeout : + ATMCI_CMD_TIMEOUT_MS; + WARN_ON(host->cmd); host->cmd = cmd; @@ -819,8 +822,7 @@ static void atmci_send_command(struct atmel_mci *host, atmci_writel(host, ATMCI_ARGR, cmd->arg); atmci_writel(host, ATMCI_CMDR, cmd_flags); - mod_timer(&host->timer, - jiffies + msecs_to_jiffies(ATMCI_CMD_TIMEOUT_MS)); + mod_timer(&host->timer, jiffies + msecs_to_jiffies(timeout_ms)); } static void atmci_send_stop_cmd(struct atmel_mci *host, struct mmc_data *data)
Using a fixed 2s timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the timer to expire, 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 2s. 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. Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> --- drivers/mmc/host/atmel-mci.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.20.1