- trimmed cc-list On Thu, 4 Feb 2021 at 13:08, <yann.gautier@xxxxxxxxxxx> wrote: > > From: Yann Gautier <yann.gautier@xxxxxxxxxxx> > > To properly manage commands awaiting R1B responses, the capability > MMC_CAP_NEED_RSP_BUSY is enabled in mmci driver, for variants that > manage busy detection. > This R1B management needs both the flags MMC_CAP_NEED_RSP_BUSY and > MMC_CAP_WAIT_WHILE_BUSY to be enabled together. Would it be possible for you to share a little bit more about the problem? Like under what circumstances does things screw up? Is the issue only occurring when the cmd->busy_timeout becomes larger than host->max_busy_timeout. Or even in other cases? > > Signed-off-by: Yann Gautier <yann.gautier@xxxxxxxxxxx> > --- > drivers/mmc/host/mmci.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c > index 1bc674577ff9..bf6971fdd1a6 100644 > --- a/drivers/mmc/host/mmci.c > +++ b/drivers/mmc/host/mmci.c > @@ -2148,7 +2148,7 @@ static int mmci_probe(struct amba_device *dev, > if (variant->busy_dpsm_flag) > mmci_write_datactrlreg(host, > host->variant->busy_dpsm_flag); > - mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY; > + mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_NEED_RSP_BUSY; This isn't correct as the ux500 (and likely also other legacy variants) don't need this. I have tried it in the past and it works fine for ux500 without MMC_CAP_NEED_RSP_BUSY. The difference is rather that the busy detection for stm32 variants needs a corresponding HW busy timeout to be set (its variant->busy_timeout flag is set). Perhaps we can use that information instead? Note that, MMC_CAP_NEED_RSP_BUSY, means that cmd->busy_timeout will not be set by the core for erase commands, CMD5 and CMD6. By looking at the code in mmci_start_command(), it looks like we will default to a timeout of 10s, when cmd->busy_timeout isn't set. At least for some erase requests, that won't be sufficient. Would it be possible to disable the HW busy timeout in some way - and maybe use a software timeout instead? Maybe I already asked Ludovic about this? :-) BTW, did you check that the MMCIDATATIMER does get the correct value set for the timer in mmci_start_command() and if host->max_busy_timeout gets correctly set in mmci_set_max_busy_timeout()? [...] Kind regards Uffe
