Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CGME20211022063928epcas1p28a32be208929f9905c80e655736b7a7d@epcas1p2.samsung.com>
 <20211022063920.2145-1-huijin.park@samsung.com>
In-Reply-To: <20211022063920.2145-1-huijin.park@samsung.com>
From:   Ulf Hansson <ulf.hansson@linaro.org>
Date:   Tue, 26 Oct 2021 18:55:01 +0200
Message-ID: <CAPDyKFo0FZ04dO-sJwL+Nvs-7JY22+y03VYRCmi80TpwdizxGQ@mail.gmail.com>
Subject: Re: [PATCH 1/2] mmc: core: adjust polling interval for CMD1
To:     Huijin Park <huijin.park@samsung.com>
Cc:     linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
        Huijin Park <bbanghj.park@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 22 Oct 2021 at 08:39, Huijin Park <huijin.park@samsung.com> wrote:
>
> In mmc_send_op_cond(), loops are continuously performed at the same
> interval of 10 ms.  However the behaviour is not good for some eMMC
> which can be out from a busy state earlier than 10 ms if normal.
>
> Therefore, this patch adjusts the waiting interval time. The interval
> time starts at 1 ms, but doubles until the range reaches 10 ms for
> each loop.
>
> The reason for adjusting the interval time is that it is important
> to reduce the eMMC initialization time, especially in devices that
> use eMMC as rootfs.
>
> Test log(eMMC:KLM8G1GETF-B041):
>
> before: 12 ms (0.439407 - 0.427186)
> [0.419407] mmc0: starting CMD0 arg 00000000 flags 000000c0
> [0.422652] mmc0: starting CMD1 arg 00000000 flags 000000e1
> [0.424270] mmc0: starting CMD0 arg 00000000 flags 000000c0
> [0.427186] mmc0: starting CMD1 arg 40000080 flags 000000e1<-start
> [0.439407] mmc0: starting CMD1 arg 40000080 flags 000000e1<-finish
> [0.439721] mmc0: starting CMD2 arg 00000000 flags 00000007
>
> after: 4 ms (0.431725 - 0.427352)
> [0.419575] mmc0: starting CMD0 arg 00000000 flags 000000c0
> [0.422819] mmc0: starting CMD1 arg 00000000 flags 000000e1
> [0.424435] mmc0: starting CMD0 arg 00000000 flags 000000c0
> [0.427352] mmc0: starting CMD1 arg 40000080 flags 000000e1<-start
> [0.428913] mmc0: starting CMD1 arg 40000080 flags 000000e1
> [0.431725] mmc0: starting CMD1 arg 40000080 flags 000000e1<-finish
> [0.432038] mmc0: starting CMD2 arg 00000000 flags 00000007
>
> Signed-off-by: Huijin Park <huijin.park@samsung.com>
>
> diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
> index 0c54858e89c0..61b4ffdc89ce 100644
> --- a/drivers/mmc/core/mmc_ops.c
> +++ b/drivers/mmc/core/mmc_ops.c
> @@ -177,6 +177,7 @@ int mmc_send_op_cond(struct mmc_host *host, u32 ocr, u32 *rocr)
>  {
>         struct mmc_command cmd = {};
>         int i, err = 0;
> +       int interval = 1, interval_max = 10;
>
>         cmd.opcode = MMC_SEND_OP_COND;
>         cmd.arg = mmc_host_is_spi(host) ? 0 : ocr;
> @@ -198,7 +199,9 @@ int mmc_send_op_cond(struct mmc_host *host, u32 ocr, u32 *rocr)
>
>                 err = -ETIMEDOUT;
>
> -               mmc_delay(10);
> +               mmc_delay(interval);
> +               if (interval < interval_max)
> +                       interval = min(interval * 2, interval_max);

It looks like we should be able to replace the above polling loop with
__mmc_poll_for_busy(). We would need a callback function and a
callback data, specific for CMD1, but that looks far better to me, if
we can get that to work.

Would you mind having a look?

>
>                 /*
>                  * According to eMMC specification v5.1 section 6.4.3, we

Kind regards
Uffe