On Wed, 30 Jun 2021 at 16:26, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > 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. Yes, exactly. The IRQ based busy detection code gets disabled with my debug patch. It looks like there are some race conditions in the HW busy detection path for mmci, which gets triggered by this eMMC card. > > However the core can still use ->card_busy() at times? It can and will. Although, it's more optimal to receive an IRQ when busy on DAT0 is de-asserted, rather than polling with ->card_busy(). Hence we also have MMC_CAP_WAIT_WHILE_BUSY. I will have another look at the code in mmci, to see if there is something we can try to improve. Kind regards Uffe
