On Wed, Jun 30, 2021 at 1:50 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> > We wait forever in mmc_wait_for_req_done() since the completion
> > never arrives.
>
> Thanks for sharing these details. It looks like the mmci driver is
> waiting for the busy completion IRQ, forever.
Yep
> Either the HW busy detection isn't working properly in mmci or the
> eMMC card is behaving a bit odd (continues to deassert the DAT0 line
> forever).
Yep. I think the card is odd because I have this working fine on
3 other ux500 phones, this is the odd one out. I will try to check
what eMMC is in the others as well.
> What certainly is missing in the mmci driver, is a software based
> timeout for cases like these. The mmci driver should better complete
> the request with -ETIMEDOUT error for the cmd, rather than hanging
> forever and waiting for the busy completion IRQ.
That is true, it would make the driver more robust.
> > I think you also mentioned the timeout in EXT_CSD maybe not being
> > long enough? How do I play around with this?
> > MMC_QUIRK_LONG_READ_TIME?
>
> As mmci doesn't care about busy timeouts, but waits forever, this is
> likely not the problem.
>
> However, I would like to try to narrow down the problem even further.
> Would you mind try the below debug patch?
With this patch mmc2 comes up and I can mount and browse
the eMMC.
I think it is because these lines in mmci_cmd_irq() will not
be executed:
/* Handle busy detection on DAT0 if the variant supports it. */
if (busy_resp && host->variant->busy_detect)
if (!host->ops->busy_complete(host, status, err_msk))
return;
These seemed to be especially problematic to me.
However the core can still use ->card_busy() at times?
Yours,
Linus Walleij
