[PATCH 0/4] mmc: Fix busy detection timeouts for some SDHCI variant

[PATCH 0/4] mmc: Fix busy detection timeouts for some SDHCI variant

[Ulf Hansson]

The mmc core may decide (for CMD6 and erase/trim/discard operations) to convert
from using an R1B response into using an R1 response, in cases when the needed
busy timeout exceeds the host's maximum supported HW max_busy_timeout. The core
does this to prevent the host from doing HW busy detection and instead rely on
polling, as to cope with the needed busy timeout.

However, it has turned out that some SDHCI variants (tegra, omap), really
requires R1B for all commands that have this response associated with them. This
became especially obvious when commit 24ed3bd01d6a ("mmc: core: Specify timeouts
for BKOPS and CACHE_FLUSH for eMMC") (and a few other commits on top) got
introduced in v5.6-rc1, as several people reported errors (thanks!). More
precisely, the mentioned commit triggered the existing problems described above
in the SDHCI variant drivers, when an eMMC cache flush command (CMD6) was
issued.

This series fixes these problems, but the changes are also targeted for stable
releases as the problems have existed since a long time back.

Please help out in testing this!

Kind regards
Ulf Hansson


Ulf Hansson (4):
  mmc: core: Allow host controllers to require R1B for CMD6
  mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for erase/trim/discard
  mmc: sdhci-omap: Fix busy detection by enabling MMC_CAP_NEED_RSP_BUSY
  mmc: sdhci-tegra: Fix busy detection by enabling MMC_CAP_NEED_RSP_BUSY

 drivers/mmc/core/core.c        | 5 ++++-
 drivers/mmc/core/mmc_ops.c     | 6 ++++--
 drivers/mmc/host/sdhci-omap.c  | 3 +++
 drivers/mmc/host/sdhci-tegra.c | 3 +++
 include/linux/mmc/host.h       | 1 +
 5 files changed, 15 insertions(+), 3 deletions(-)

-- 
2.20.1

[PATCH 1/4] mmc: core: Allow host controllers to require R1B for CMD6

[Ulf Hansson]

It has turned out that some host controllers can't use R1B for CMD6 and
other commands that have R1B associated with them. Therefore invent a new
host cap, MMC_CAP_NEED_RSP_BUSY to let them specify this.

In __mmc_switch(), let's check the flag and use it to prevent R1B responses
from being converted into R1. Note that, this also means that the host are
on its own, when it comes to manage the busy timeout.

Suggested-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/mmc/core/mmc_ops.c | 6 ++++--
 include/linux/mmc/host.h   | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index da425ee2d9bf..e025604e17d4 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -542,9 +542,11 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value,
 	 * If the max_busy_timeout of the host is specified, make sure it's
 	 * enough to fit the used timeout_ms. In case it's not, let's instruct
 	 * the host to avoid HW busy detection, by converting to a R1 response
-	 * instead of a R1B.
+	 * instead of a R1B. Note, some hosts requires R1B, which also means
+	 * they are on their own when it comes to deal with the busy timeout.
 	 */
-	if (host->max_busy_timeout && (timeout_ms > host->max_busy_timeout))
+	if (!(host->caps & MMC_CAP_NEED_RSP_BUSY) && host->max_busy_timeout &&
+	    (timeout_ms > host->max_busy_timeout))
 		use_r1b_resp = false;
 
 	cmd.opcode = MMC_SWITCH;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index ba703384bea0..4c5eb3aa8e72 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -333,6 +333,7 @@ struct mmc_host {
 				 MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR104 | \
 				 MMC_CAP_UHS_DDR50)
 #define MMC_CAP_SYNC_RUNTIME_PM	(1 << 21)	/* Synced runtime PM suspends. */
+#define MMC_CAP_NEED_RSP_BUSY	(1 << 22)	/* Commands with R1B can't use R1. */
 #define MMC_CAP_DRIVER_TYPE_A	(1 << 23)	/* Host supports Driver Type A */
 #define MMC_CAP_DRIVER_TYPE_C	(1 << 24)	/* Host supports Driver Type C */
 #define MMC_CAP_DRIVER_TYPE_D	(1 << 25)	/* Host supports Driver Type D */
-- 
2.20.1

[PATCH 2/4] mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for erase/trim/discard

[Ulf Hansson]

The busy timeout that is computed for each erase/trim/discard operation,
can become quite long and may thus exceed the host->max_busy_timeout. If
that becomes the case, mmc_do_erase() converts from using an R1B response
to an R1 response, as to prevent the host from doing HW busy detection.

However, it has turned out that some hosts requires an R1B response no
matter what, so let's respect that via checking MMC_CAP_NEED_RSP_BUSY. Note
that, if the R1B gets enforced, the host becomes fully responsible of
managing the needed busy timeout, in one way or the other.

Suggested-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/mmc/core/core.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index aa54d359dab7..a971c4bcc442 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1732,8 +1732,11 @@ static int mmc_do_erase(struct mmc_card *card, unsigned int from,
 	 * the erase operation does not exceed the max_busy_timeout, we should
 	 * use R1B response. Or we need to prevent the host from doing hw busy
 	 * detection, which is done by converting to a R1 response instead.
+	 * Note, some hosts requires R1B, which also means they are on their own
+	 * when it comes to deal with the busy timeout.
 	 */
-	if (card->host->max_busy_timeout &&
+	if (!(card->host->caps & MMC_CAP_NEED_RSP_BUSY) &&
+	    card->host->max_busy_timeout &&
 	    busy_timeout > card->host->max_busy_timeout) {
 		cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_AC;
 	} else {
-- 
2.20.1

[PATCH 3/4] mmc: sdhci-omap: Fix busy detection by enabling MMC_CAP_NEED_RSP_BUSY

[Ulf Hansson]

It has turned out that the sdhci-omap controller requires the R1B response,
for commands that has this response associated with them. So, converting
from an R1B to an R1 response for a CMD6 for example, leads to problems
with the HW busy detection support.

Fix this by informing the mmc core about the requirement, via setting the
host cap, MMC_CAP_NEED_RSP_BUSY.

Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Reported-by: Anders Roxell <anders.roxell@linaro.org>
Reported-by: Faiz Abbas <faiz_abbas@ti.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/mmc/host/sdhci-omap.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
index 882053151a47..c4978177ef88 100644
--- a/drivers/mmc/host/sdhci-omap.c
+++ b/drivers/mmc/host/sdhci-omap.c
@@ -1192,6 +1192,9 @@ static int sdhci_omap_probe(struct platform_device *pdev)
 	if (of_find_property(dev->of_node, "dmas", NULL))
 		sdhci_switch_external_dma(host, true);
 
+	/* R1B responses is required to properly manage HW busy detection. */
+	mmc->caps |= MMC_CAP_NEED_RSP_BUSY;
+
 	ret = sdhci_setup_host(host);
 	if (ret)
 		goto err_put_sync;
-- 
2.20.1

[PATCH 4/4] mmc: sdhci-tegra: Fix busy detection by enabling MMC_CAP_NEED_RSP_BUSY

[Ulf Hansson]

It has turned out that the sdhci-tegra controller requires the R1B response,
for commands that has this response associated with them. So, converting
from an R1B to an R1 response for a CMD6 for example, leads to problems
with the HW busy detection support.

Fix this by informing the mmc core about the requirement, via setting the
host cap, MMC_CAP_NEED_RSP_BUSY.

Reported-by: Bitan Biswas <bbiswas@nvidia.com>
Reported-by: Peter Geis <pgwipeout@gmail.com>
Suggested-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/mmc/host/sdhci-tegra.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 403ac44a7378..a25c3a4d3f6c 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -1552,6 +1552,9 @@ static int sdhci_tegra_probe(struct platform_device *pdev)
 	if (tegra_host->soc_data->nvquirks & NVQUIRK_ENABLE_DDR50)
 		host->mmc->caps |= MMC_CAP_1_8V_DDR;
 
+	/* R1B responses is required to properly manage HW busy detection. */
+	host->mmc->caps |= MMC_CAP_NEED_RSP_BUSY;
+
 	tegra_sdhci_parse_dt(host);
 
 	tegra_host->power_gpio = devm_gpiod_get_optional(&pdev->dev, "power",
-- 
2.20.1

Re: [PATCH 0/4] mmc: Fix busy detection timeouts for some SDHCI variant

[Anders Roxell]

On Tue, 10 Mar 2020 at 16:33, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> The mmc core may decide (for CMD6 and erase/trim/discard operations) to convert
> from using an R1B response into using an R1 response, in cases when the needed
> busy timeout exceeds the host's maximum supported HW max_busy_timeout. The core
> does this to prevent the host from doing HW busy detection and instead rely on
> polling, as to cope with the needed busy timeout.
>
> However, it has turned out that some SDHCI variants (tegra, omap), really
> requires R1B for all commands that have this response associated with them. This
> became especially obvious when commit 24ed3bd01d6a ("mmc: core: Specify timeouts
> for BKOPS and CACHE_FLUSH for eMMC") (and a few other commits on top) got
> introduced in v5.6-rc1, as several people reported errors (thanks!). More
> precisely, the mentioned commit triggered the existing problems described above
> in the SDHCI variant drivers, when an eMMC cache flush command (CMD6) was
> issued.
>
> This series fixes these problems, but the changes are also targeted for stable
> releases as the problems have existed since a long time back.
>
> Please help out in testing this!

Tested-by: Anders Roxell <anders.roxell@linaro.org>

I tested it on a beagleboard x15.

Cheers,
Anders

>
> Kind regards
> Ulf Hansson
>
>
> Ulf Hansson (4):
>   mmc: core: Allow host controllers to require R1B for CMD6
>   mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for erase/trim/discard
>   mmc: sdhci-omap: Fix busy detection by enabling MMC_CAP_NEED_RSP_BUSY
>   mmc: sdhci-tegra: Fix busy detection by enabling MMC_CAP_NEED_RSP_BUSY
>
>  drivers/mmc/core/core.c        | 5 ++++-
>  drivers/mmc/core/mmc_ops.c     | 6 ++++--
>  drivers/mmc/host/sdhci-omap.c  | 3 +++
>  drivers/mmc/host/sdhci-tegra.c | 3 +++
>  include/linux/mmc/host.h       | 1 +
>  5 files changed, 15 insertions(+), 3 deletions(-)
>
> --
> 2.20.1
>

Re: [PATCH 0/4] mmc: Fix busy detection timeouts for some SDHCI variant

[Ulf Hansson]

On Tue, 10 Mar 2020 at 16:33, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> The mmc core may decide (for CMD6 and erase/trim/discard operations) to convert
> from using an R1B response into using an R1 response, in cases when the needed
> busy timeout exceeds the host's maximum supported HW max_busy_timeout. The core
> does this to prevent the host from doing HW busy detection and instead rely on
> polling, as to cope with the needed busy timeout.
>
> However, it has turned out that some SDHCI variants (tegra, omap), really
> requires R1B for all commands that have this response associated with them. This
> became especially obvious when commit 24ed3bd01d6a ("mmc: core: Specify timeouts
> for BKOPS and CACHE_FLUSH for eMMC") (and a few other commits on top) got
> introduced in v5.6-rc1, as several people reported errors (thanks!). More
> precisely, the mentioned commit triggered the existing problems described above
> in the SDHCI variant drivers, when an eMMC cache flush command (CMD6) was
> issued.
>
> This series fixes these problems, but the changes are also targeted for stable
> releases as the problems have existed since a long time back.
>
> Please help out in testing this!

FYI, this is now applied on my fixes branch.

[...]

Kind regards
Uffe

Re: [PATCH 3/4] mmc: sdhci-omap: Fix busy detection by enabling MMC_CAP_NEED_RSP_BUSY

[Faiz Abbas]

Hi Uffe,

On 10/03/20 9:03 pm, Ulf Hansson wrote:
> It has turned out that the sdhci-omap controller requires the R1B response,
> for commands that has this response associated with them. So, converting
> from an R1B to an R1 response for a CMD6 for example, leads to problems
> with the HW busy detection support.
> 
> Fix this by informing the mmc core about the requirement, via setting the
> host cap, MMC_CAP_NEED_RSP_BUSY.
> 
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Reported-by: Anders Roxell <anders.roxell@linaro.org>
> Reported-by: Faiz Abbas <faiz_abbas@ti.com>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

Thanks for sending this fix. I will more look into the underlying
behaviour once I'm back in office next week.

Tested-by: Faiz Abbas <faiz_abbas@ti.com>

Regards,
Faiz

Re: [PATCH 0/4] mmc: Fix busy detection timeouts for some SDHCI variant

[Peter Geis]

On Wed, Mar 11, 2020 at 5:03 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Tue, 10 Mar 2020 at 16:33, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > The mmc core may decide (for CMD6 and erase/trim/discard operations) to convert
> > from using an R1B response into using an R1 response, in cases when the needed
> > busy timeout exceeds the host's maximum supported HW max_busy_timeout. The core
> > does this to prevent the host from doing HW busy detection and instead rely on
> > polling, as to cope with the needed busy timeout.
> >
> > However, it has turned out that some SDHCI variants (tegra, omap), really
> > requires R1B for all commands that have this response associated with them. This
> > became especially obvious when commit 24ed3bd01d6a ("mmc: core: Specify timeouts
> > for BKOPS and CACHE_FLUSH for eMMC") (and a few other commits on top) got
> > introduced in v5.6-rc1, as several people reported errors (thanks!). More
> > precisely, the mentioned commit triggered the existing problems described above
> > in the SDHCI variant drivers, when an eMMC cache flush command (CMD6) was
> > issued.
> >
> > This series fixes these problems, but the changes are also targeted for stable
> > releases as the problems have existed since a long time back.
> >
> > Please help out in testing this!
>
> FYI, this is now applied on my fixes branch.
>
> [...]
>
> Kind regards
> Uffe

Short term this appears to resolve the issue on Ouya (Tegra30).
I'll let you know if anything comes up long term, but for the reported issue:

Tested-By: Peter Geis <pgwipeout@gmail.com>