Re: [PATCH v2] mmc: core: Optimize polling delay in __mmc_poll_for_busy()

[Shawn Lin <shawn.lin@linux.dev>]

On 2026/09/20 Sun 13:40, 李晓洁 (Xiaojie Li/13233) wrote:
>> No, that's the whole point. We don't want open coded polling loops, it's just a nightmare to maintain. Please try to extend the existing
>> __mmc_poll_for_busy() instead.
> 
> Hi Uffe,
> 
> Following your suggestion to extend __mmc_poll_for_busy() instead of using open-coded polling loops, here is the proposed optimization.
> 
> In our actual testing, we found that setting udelay_max = 8000 (8ms) is more time-efficient than udelay_max = 10000 (10ms).
> For CMD1 (SEND_OP_COND), the polling intervals are 4ms, 6ms, and 8ms, capped at a maximum of 8ms.
> Attached are the recorded per-boot phase latencies for udelay_max=8000 (8ms) and udelay_max=10000 (10ms), with timestamps in seconds.
> Please let me know if you cannot open the attachment, and I will resend it.
> 
> diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c

I think the CMD1-specific branch can be avoided altogether. The reason
CMD1's tail latency is high is that __mmc_poll_for_busy() limits udelay
to a maximum of 32768 and, more importantly, the sleep upper bound is
udelay * 2.

Would it be possible to parameterize the maximum delay instead? E.g.

   int __mmc_poll_for_busy(host, period_us, udelay_max_us, timeout_ms, 
cb, cb_data)

and limit both the backoff step and the sleep upper bound to
udelay_max_us:

   unsigned int sleep_max = min(udelay * 2, udelay_max_us);
   usleep_range(min(udelay, udelay_max_us), sleep_max);

Then mmc_send_op_cond() passes its own maximum delay (8ms), while all
other callers keep passing 32768 so their behaviour is unchanged. That
is two lines of code, no busy_cb pointer comparison, and the tail bound
(8ms) is actually tighter than the linear +2ms schedule (10ms).

Could you try to see if the linear step is still needed once the sleep
upper bound is limited to the maximum delay?


> index a952cc8..9c4762c 100644
> --- a/drivers/mmc/core/mmc_ops.c
> +++ b/drivers/mmc/core/mmc_ops.c
> @@ -539,9 +539,23 @@
>   
>   		/* Throttle the polling rate to avoid hogging the CPU. */
>   		if (busy) {
> -			usleep_range(udelay, udelay * 2);
> -			if (udelay < udelay_max)
> -				udelay *= 2;
> +			/*
> +			 * Special delay handling is required for mmc_send_op_cond;
> +			 * otherwise, for slower memory particles, the time required to
> +			 * wait for the status change will increase.
> +			 */
> +			if (busy_cb == __mmc_send_op_cond_cb) {
> +				udelay_max = 8000;
> +				usleep_range(udelay, udelay + 2000);
> +				if (udelay < udelay_max)
> +					udelay += 2000;
> +				else
> +					udelay = udelay_max;
> +			} else {
> +				usleep_range(udelay, udelay * 2);
> +				if (udelay < udelay_max)
> +					udelay *= 2;
> +			}
>   		}
>   	} while (busy);
> 
> 
> Best regards,
> Xiaojie.Li
> 
> -----邮件原件-----
> 发件人: Ulf Hansson <ulf.hansson@oss.qualcomm.com>
> 发送时间: 2026年9月11日 23:47
> 收件人: 李晓洁 (Xiaojie Li/13233) <xiaojie.li2@unisoc.com>
> 抄送: Ulf Hansson <ulfh@kernel.org>; linux-mmc@vger.kernel.org; linux-kernel@vger.kernel.org; 陈文超 (Wenchao Chen) <Wenchao.Chen@unisoc.com>; 张如泉 (Rain Zhang) <Rain.Zhang@unisoc.com>; 唐月林 (Yuelin Tang) <yuelin.tang@unisoc.com>; cixi.geng@linux.dev
> 主题: Re: [PATCH] mmc: core: Modify the CMD1 transmission interval
> 
> 
> 注意: 这封邮件来自于外部。除非你确定邮件内容安全，否则不要点击任何链接和附件。
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> 
> On Fri, Sep 11, 2026 at 4:45 AM 李晓洁 (Xiaojie Li/13233) <xiaojie.li2@unisoc.com> wrote:
>>
>> Hi Uffe:
>>          Thank you for your reply.
>>          However, I noticed that __mmc_poll_for_busy() and mmc_poll_for_busy() are invoked either directly or indirectly by many other functions within the MMC driver.
>> Modifying them directly could potentially introduce unintended side effects.
>>
>>          Would it be acceptable to implement a dedicated function specifically for CMD1? We could create a CMD1-specific variant based on the existing __mmc_poll_for_busy().
>> This approach would significantly minimize the potential impact on the rest of the codebase.
> 
> No, that's the whole point. We don't want open coded polling loops, it's just a nightmare to maintain. Please try to extend the existing
> __mmc_poll_for_busy() instead.
> 
> And next time, please don't top post.
> 
> [...]
> 
> Kind regards
> Uffe