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

[李晓洁 (Xiaojie Li/13233)]

>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
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@xxxxxxxxxxxxxxxx> 
发送时间: 2026年9月11日 23:47
收件人: 李晓洁 (Xiaojie Li/13233) <xiaojie.li2@xxxxxxxxxx>
抄送: Ulf Hansson <ulfh@xxxxxxxxxx>; linux-mmc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; 陈文超 (Wenchao Chen) <Wenchao.Chen@xxxxxxxxxx>; 张如泉 (Rain Zhang) <Rain.Zhang@xxxxxxxxxx>; 唐月林 (Yuelin Tang) <yuelin.tang@xxxxxxxxxx>; cixi.geng@xxxxxxxxx
主题: 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@xxxxxxxxxx> 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

Attachment: Optimize latency logging in __mmc_poll_for_busy.xlsx
Description: Optimize latency logging in __mmc_poll_for_busy.xlsx