Message-ID: <CAPDyKFrGCrC6fc+VDJGhCiM8nSiu8M-NeM+UGMUPERt2aeLTbg@mail.gmail.com>
Date:   Fri, 13 May 2022 22:06:05 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Jean Rene Dawin <jdawin@...h.uni-bielefeld.de>
Cc:     "H . Nikolaus Schaller" <hns@...delico.com>,
        Huijin Park <huijin.park@...sung.com>,
        linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org
Subject: Re: [PATCH] mmc: core: Restore (almost) the busy polling for MMC_SEND_OP_COND

On Wed, 11 May 2022 at 08:46, Jean Rene Dawin
<jdawin@...h.uni-bielefeld.de> wrote:
>
> Ulf Hansson wrote on Wed  4/05/22 11:08:
> > On Wed, 4 May 2022 at 07:46, Jean Rene Dawin
> > <jdawin@...h.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@...aro.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@...h.uni-bielefeld.de>
> > > > > Reported-by: H. Nikolaus Schaller <hns@...delico.com>
> > > > > Cc: Huijin Park <huijin.park@...sung.com>
> > > > > Fixes: 76bfc7ccc2fa ("mmc: core: adjust polling interval for CMD1")
> > > > > Signed-off-by: Ulf Hansson <ulf.hansson@...aro.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.
> >
> > Kind regards
> > Uffe
>
> Hi,
>
> I tested 2 beaglebones now - one with Micron eMMC and the other with Kingston.
> With the Kingston chip I don't get the errors. So it seems to be card specific.
>
> Grepping for mmc in dmesg gives the following.
>
> Beaglebone with Micron eMMC:
>
>   sdhci-omap 481d8000.mmc: supply pbias not found, using dummy regulator
>   sdhci-omap 481d8000.mmc: supply vqmmc not found, using dummy regulator
>   mmc1: SDHCI controller on 481d8000.mmc [481d8000.mmc] using External DMA
>   mmc1: new high speed MMC card at address 0001
>   mmcblk1: mmc1:0001 MMC04G 3.66 GiB
>    mmcblk1: p1
>   mmcblk1boot0: mmc1:0001 MMC04G 1.00 MiB
>   mmcblk1boot1: mmc1:0001 MMC04G 1.00 MiB
>   mmcblk1rpmb: mmc1:0001 MMC04G 128 KiB, chardev (247:0)
>   sdhci-omap 48060000.mmc: Got CD GPIO
>   sdhci-omap 48060000.mmc: supply pbias not found, using dummy regulator
>   sdhci-omap 48060000.mmc: supply vqmmc not found, using dummy regulator
>   mmc0: SDHCI controller on 48060000.mmc [48060000.mmc] using External DMA
>
>
> Beaglebone with Kingston eMMC:
>
>   sdhci-omap 481d8000.mmc: supply pbias not found, using dummy regulator
>   sdhci-omap 481d8000.mmc: supply vqmmc not found, using dummy regulator
>   mmc1: SDHCI controller on 481d8000.mmc [481d8000.mmc] using External DMA
>   mmc1: new high speed MMC card at address 0001
>   mmcblk1: mmc1:0001 M62704 3.56 GiB
>    mmcblk1: p1
>   mmcblk1boot0: mmc1:0001 M62704 2.00 MiB
>   mmcblk1boot1: mmc1:0001 M62704 2.00 MiB
>   mmcblk1rpmb: mmc1:0001 M62704 512 KiB, chardev (247:0)
>   sdhci-omap 48060000.mmc: Got CD GPIO
>   sdhci-omap 48060000.mmc: supply pbias not found, using dummy regulator
>   sdhci-omap 48060000.mmc: supply vqmmc not found, using dummy regulator
>   mmc0: SDHCI controller on 48060000.mmc [48060000.mmc] using External DMA
>
> Is this enough information to identify the mmc card?

Thanks for running the tests and sharing this information.

One thing that I realized, again, is that you seem to be encountering
the problem only during re-initialization (at runtime resume of the
eMMC card), but I guess, at least theoretically, you could meet the
same problem during the first initialization (boot). At this point we
can't use a card quirk, simply because we don't know anything about
the card yet.

That said, I think we should change the MMC_OP_COND_PERIOD_US to 4ms,
to make sure it works for all cases. Do you want to send a patch for
this - or just tell me if you prefer me to do it!?

Additionally, for those eMMC cards that can cope with a smaller
polling period, we could add a new generic DT property for the eMMC
card (Documentation/devicetree/bindings/mmc/mmc-card.yaml). In this
way we can avoid regressing eMMC initializations in general, but at
the same time allow those cards/platforms that can cope with a smaller
timeout, to specify and use this to decrease the initialization time.

Kind regards
Uffe

Powered by blists - more mailing lists