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
