Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220304105656.149281-1-ulf.hansson@linaro.org>
 <CAPDyKFr1PzSaiKqB4ZoqTS_8bGsEH=aB3ARhxyGu+cYeRqeBew@mail.gmail.com> <20220504054652.GA7851@math.uni-bielefeld.de>
In-Reply-To: <20220504054652.GA7851@math.uni-bielefeld.de>
From:   Ulf Hansson <ulf.hansson@linaro.org>
Date:   Wed, 4 May 2022 11:08:19 +0200
Message-ID: <CAPDyKFrBVyYx+BybGR2P8paS6qA=V2EHAXH+vPUc9JzxoXn6+g@mail.gmail.com>
Subject: Re: [PATCH] mmc: core: Restore (almost) the busy polling for MMC_SEND_OP_COND
To:     Jean Rene Dawin <jdawin@math.uni-bielefeld.de>
Cc:     "H . Nikolaus Schaller" <hns@goldelico.com>,
        Huijin Park <huijin.park@samsung.com>,
        linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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.

Kind regards
Uffe


>
>
> ---
>  drivers/mmc/core/mmc_ops.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
> index 180d7e9d3400..1fd57f342842 100644
> --- a/drivers/mmc/core/mmc_ops.c
> +++ b/drivers/mmc/core/mmc_ops.c
> @@ -21,7 +21,7 @@
>
>  #define MMC_BKOPS_TIMEOUT_MS           (120 * 1000) /* 120s */
>  #define MMC_SANITIZE_TIMEOUT_MS                (240 * 1000) /* 240s */
> -#define MMC_OP_COND_PERIOD_US          (1 * 1000) /* 1ms */
> +#define MMC_OP_COND_PERIOD_US          (4 * 1000) /* 1ms */
>  #define MMC_OP_COND_TIMEOUT_MS         1000 /* 1s */
>
>  static const u8 tuning_blk_pattern_4bit[] = {
> --
> 2.35.1
>
>
> Regards,
> Jean Rene