On Wed, Mar 11, 2020 at 5:03 AM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
>
> On Tue, 10 Mar 2020 at 16:33, Ulf Hansson <ulf.hansson@xxxxxxxxxx> 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@xxxxxxxxx>
