[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f960aa98-5508-36fd-166d-7f41c7d85154@nvidia.com>
Date: Tue, 25 Feb 2020 11:41:31 +0000
From: Jon Hunter <jonathanh@...dia.com>
To: Ulf Hansson <ulf.hansson@...aro.org>,
Bitan Biswas <bbiswas@...dia.com>,
Adrian Hunter <adrian.hunter@...el.com>
CC: Naresh Kamboju <naresh.kamboju@...aro.org>,
Jens Axboe <axboe@...nel.dk>,
Alexei Starovoitov <ast@...nel.org>,
linux-block <linux-block@...r.kernel.org>,
<lkft-triage@...ts.linaro.org>,
open list <linux-kernel@...r.kernel.org>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>,
John Stultz <john.stultz@...aro.org>,
Thierry Reding <treding@...dia.com>
Subject: Re: LKFT: arm x15: mmc1: cache flush error -110
On 25/02/2020 10:04, Jon Hunter wrote:
...
>>> I find that from the commit the changes in mmc_flush_cache below is
>>> the cause.
>>>
>>> ##
>>> @@ -961,7 +963,8 @@ int mmc_flush_cache(struct mmc_card *card)
>>> (card->ext_csd.cache_size > 0) &&
>>> (card->ext_csd.cache_ctrl & 1)) {
>>> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>>> - EXT_CSD_FLUSH_CACHE, 1, 0);
>>> + EXT_CSD_FLUSH_CACHE, 1,
>>> + MMC_CACHE_FLUSH_TIMEOUT_MS);
>
>
> I no longer see the issue on reverting the above hunk as Bitan suggested
> but now I see the following (which is expected) ...
>
> WARNING KERN mmc1: unspecified timeout for CMD6 - use generic
For Tegra, the default timeout used when no timeout is specified for CMD6
is 100mS. So hard-coding the following also appears to workaround the
problem on Tegra ...
diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 868653bc1555..5155e0240fca 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -992,7 +992,7 @@ int mmc_flush_cache(struct mmc_card *card)
(card->ext_csd.cache_size > 0) &&
(card->ext_csd.cache_ctrl & 1)) {
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
- EXT_CSD_FLUSH_CACHE, 1, 0);
+ EXT_CSD_FLUSH_CACHE, 1, 100);
if (err)
pr_err("%s: cache flush error %d\n",
mmc_hostname(card->host), err);
So the problem appears to be causing by the timeout being too long rather
than not long enough.
Looking more at the code, I think now that we are hitting the condition
...
diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 868653bc1555..feae82b1ff35 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -579,8 +579,10 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value,
* the host to avoid HW busy detection, by converting to a R1 response
* instead of a R1B.
*/
- if (host->max_busy_timeout && (timeout_ms > host->max_busy_timeout))
+ if (host->max_busy_timeout && (timeout_ms > host->max_busy_timeout)) {
+ pr_warn("%s: timeout (%d) > max busy timeout (%d)", mmc_hostname(host), timeout_ms, host->max_busy_timeout);
use_r1b_resp = false;
+ }
With the above I see ...
WARNING KERN mmc1: timeout (1600) > max busy timeout (672)
So with the longer timeout we are not using/requesting the response.
Cheers
Jon
--
nvpublic
Powered by blists - more mailing lists