Re: [PATCH] mmc: core: Restore (almost) the busy polling for MMC_SEND_OP_COND

[Jean Rene Dawin <jdawin@math.uni-bielefeld.de>]

Ulf Hansson wrote on Wed  4/05/22 11:08:
> On Wed, 4 May 2022 at 07:46, Jean Rene Dawin
> <jdawin@math.uni-bielefeld.de> wrote:
> >
> > Ulf Hansson wrote on Mon  7/03/22 13:17:
> > > On Fri, 4 Mar 2022 at 11:57, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > >
> > > > Commit 76bfc7ccc2fa ("mmc: core: adjust polling interval for CMD1"),
> > > > significantly decreased the polling period from ~10-12ms into just a couple
> > > > of us. The purpose was to decrease the total time spent in the busy polling
> > > > loop, but unfortunate it has lead to problems, that causes eMMC cards to
> > > > never gets out busy and thus fails to be initialized.
> > > >
> > > > To fix the problem, but also to try to keep some of the new improved
> > > > behaviour, let's start by using a polling period of 1-2ms, which then
> > > > increases for each loop, according to common polling loop in
> > > > __mmc_poll_for_busy().
> > > >
> > > > Reported-by: Jean Rene Dawin <jdawin@math.uni-bielefeld.de>
> > > > Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
> > > > Cc: Huijin Park <huijin.park@samsung.com>
> > > > Fixes: 76bfc7ccc2fa ("mmc: core: adjust polling interval for CMD1")
> > > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > > > ---
> > > >
> > > > Jean Rene and H. Nikolaus, if this doesn't work, please try extending the
> > > > the MMC_OP_COND_PERIOD_US a bit, to so see if we can find a value that always
> > > > works.
> > > >
> > > > Kind regards
> > > > Uffe
> >
> > >
> > > Applied for fixes and by adding two tested-by tags from you, thanks!
> > >
> > > Kind regards
> > > Uffe
> >
> > Hi,
> >
> > with the current value of MMC_OP_COND_PERIOD_US = 1ms I still see
> >
> > mmc1: Card stuck being busy! __mmc_poll_for_busy
> > mmc1: error -110 doing runtime resume
> >
> > regularly. The same with 2ms. Setting it to 4ms makes the messages go
> > away. Would it be ok to increase MMC_OP_COND_PERIOD_US to 4ms?
> 
> It doesn't look like we have a very good alternative - unless the
> problem is tied to a particular type of eMMC card, is it? (If so, we
> can add a card-quirk).
> 
> The only other option I see, would then be to add a generic DT
> property for eMMCs, that allows us to specify the OP_COND polling
> period for it. See
> Documentation/devicetree/bindings/mmc/mmc-card.yaml.

Hi,

ok, I will test with another beaglebone which has a different emmc chip.

Regards,
Jean Rene