From nobody Fri Sep 25 16:51:05 2026 Received: from SHSQR01.spreadtrum.com (unknown [222.66.158.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A7A6C36196C; Thu, 10 Sep 2026 07:11:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=222.66.158.135 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789024294; cv=none; b=ed0R51u5iV3yGoGMavkAr4Wo4IVKTaKhAcQ6pdTkdZcacMmYNtUo3cjbVykt7zF/8bJMJn7eizBPnnCrk4XvpdhqBnXv5ijm4QGp45mBxOngiloRMps7Vd+EraFXwhQ04KH6hb11fvlaReGCFjFfa8gk1tkEzwdAK6lcXelwDbQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789024294; c=relaxed/simple; bh=OOred7fU+56RxD82Zb46MrrNEw+p+8Xn2R/7L276OXE=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=dAgdkv0k6Z3disjK0Ao1z2BCwaWWrDmy3e1L9rT4SaJXRKXdNXVI2poGJNp+nWexPd1+AWHsuylVsGAG1rfaky5I1+/VzRJ0I7RbVPDGnu44oOonOFApf2wh8UkiAzG7wK4Q32fXWMU9Twx0oQIwtafFup1fphAGnPERs0OJuO0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=unisoc.com; spf=pass smtp.mailfrom=unisoc.com; dkim=pass (2048-bit key) header.d=unisoc.com header.i=@unisoc.com header.b=zcqi/bby; arc=none smtp.client-ip=222.66.158.135 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=unisoc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=unisoc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=unisoc.com header.i=@unisoc.com header.b="zcqi/bby" Received: from dlp.unisoc.com ([10.29.3.86]) by SHSQR01.spreadtrum.com with ESMTPS id 68A7Afq1050902 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 10 Sep 2026 15:10:41 +0800 (+08) (envelope-from xiaojie.li2@unisoc.com) Received: from SHDLP.spreadtrum.com (unknown [10.29.3.67]) by dlp.unisoc.com (SkyGuard) with ESMTPS id 4hgTKj2jjLz2MBNdN; Thu, 10 Sep 2026 15:08:25 +0800 (CST) Received: from zeshmbx09.spreadtrum.com (10.29.3.107) by zeshmbx14.spreadtrum.com (10.29.3.67) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Thu, 10 Sep 2026 15:10:40 +0800 Received: from zeshmbx09.spreadtrum.com ([fe80::7981:d4bc:3eee:c0be]) by zeshmbx09.spreadtrum.com ([fe80::7981:d4bc:3eee:c0be%17]) with mapi id 15.00.1497.048; Thu, 10 Sep 2026 15:10:40 +0800 From: =?gb2312?B?wO7P/r3gIChYaWFvamllIExpLzEzMjMzKQ==?= To: Ulf Hansson CC: "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , =?gb2312?B?s8LOxLOsIChXZW5jaGFvIENoZW4p?= , =?gb2312?B?1cXI58iqIChSYWluIFpoYW5nKQ==?= , =?gb2312?B?zMbUwsHWIChZdWVsaW4gVGFuZyk=?= , "cixi.geng@linux.dev" Subject: [PATCH] mmc: core: Modify the CMD1 transmission interval Thread-Topic: [PATCH] mmc: core: Modify the CMD1 transmission interval Thread-Index: AQHdNgR8DmoNOL7mLUCpmwUb62wN6bbHdPag Date: Thu, 10 Sep 2026 07:10:39 +0000 Message-ID: References: <20260827091436.1339716-1-xiaojie.li2@unisoc.com> In-Reply-To: <20260827091436.1339716-1-xiaojie.li2@unisoc.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MAIL: SHSQR01.spreadtrum.com 68A7Afq1050902 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unisoc.com; s=default; t=1789024263; bh=OOred7fU+56RxD82Zb46MrrNEw+p+8Xn2R/7L276OXE=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=zcqi/bbyEgSrJ97bh1sojvJe3GAVaJfcJo06P7pydpR3d9AJg2InnWVXgZMCbfE6b pHb3ZPyZPD9jjkoUAA4TC6Bm/BsLRsMr8WQlgIQcQlk0e2Fz6D8XIUfGzv6xt9TA3K 9s/yWVtV/AS+2vV6YkdhixFVbjkwXHcIRYOBrScD2ENgl5K9j29KA/jqR7CnuDcGC2 +6WtEtcxROL+VoXmT561jH0/WGLMpG5CVV+tMBlxxdsIbSh2h1Namo9D724KFc//O4 mWy5ssehgR1kg6adxt2CnhlZ5k0RB8hWyuo4falzAphoswgE+OA4fhNwYmbEuCMA0U DkK5YxdobLrJA== Content-Type: text/plain; charset="utf-8" Hi Ulf, Just following up on the patch below. Could you please let me know if there are any concerns or if further chang= es are needed? Best regards, Xiaojie.Li -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: =E6=9D=8E=E6=99=93=E6=B4=81 (Xiaojie Li/13233)= =20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2026=E5=B9=B48=E6=9C=8827=E6=97=A5 17= :15 =E6=94=B6=E4=BB=B6=E4=BA=BA: Ulf Hansson =E6=8A=84=E9=80=81: linux-mmc@vger.kernel.org; linux-kernel@vger.kernel.org= ; =E6=9D=8E=E6=99=93=E6=B4=81 (Xiaojie Li/13233) ; = =E9=99=88=E6=96=87=E8=B6=85 (Wenchao Chen) ; =E5= =BC=A0=E5=A6=82=E6=B3=89 (Rain Zhang) ; =E5=94=90=E6= =9C=88=E6=9E=97 (Yuelin Tang) ; cixi.geng@linux.dev =E4=B8=BB=E9=A2=98: [PATCH] mmc: core: Modify the CMD1 transmission interval The current code's maximum udelay value is set to 64ms. Since it uses uslee= p_range(udelay, udelay*2), this results in a maximum wait time of 128ms bet= ween two consecutive CMD1 commands. For lower-performance eMMC chips, local= testing shows that compared to the old code which used mmc_delay(10), the = total time required to wait for the busy bit in the CMD1 response to change= has increased by approximately 300ms, negatively impacting the overall eMM= C initialization time. Although the current code sends the CMD1 command fewer times than the old v= ersion, the total waiting time is significantly longer. To address this, it's proposed to modify the CMD1 sending interval to follo= w a pattern like 4ms, 6ms, 8ms, 10ms, 10ms, etc., effectively capping the l= ongest single wait at 10ms. Local testing confirms that this approach can b= ring the total time waiting for the busy state change very close to the per= formance level of the old code. The eMMC chip used for testing: manfid=3D 0x00009b, name=3D Y0S128, mdt=3D = 2022-10 The eMMC part number is: YMEC8B0TE2A2C3 Signed-off-by: Xiaojie Li --- drivers/mmc/core/mmc_ops.c | 85 ++++++++++++++++---------------------- 1 file changed, 36 insertions(+), 49 deletions(-) diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c index = a952cc8265af..3076666cf2ca 100644 --- a/drivers/mmc/core/mmc_ops.c +++ b/drivers/mmc/core/mmc_ops.c @@ -189,64 +189,51 @@ int mmc_go_idle(struct mmc_host *host) return err; } =20 -static int __mmc_send_op_cond_cb(void *cb_data, bool *busy) -{ - struct mmc_op_cond_busy_data *data =3D cb_data; - struct mmc_host *host =3D data->host; - struct mmc_command *cmd =3D data->cmd; - u32 ocr =3D data->ocr; - int err =3D 0; - - err =3D mmc_wait_for_cmd(host, cmd, 0); - if (err) - return err; - - if (mmc_host_is_spi(host)) { - if (!(cmd->resp[0] & R1_SPI_IDLE)) { - *busy =3D false; - return 0; - } - } else { - if (cmd->resp[0] & MMC_CARD_BUSY) { - *busy =3D false; - return 0; - } - } - - *busy =3D true; - - /* - * According to eMMC specification v5.1 section 6.4.3, we - * should issue CMD1 repeatedly in the idle state until - * the eMMC is ready. Otherwise some eMMC devices seem to enter - * the inactive mode after mmc_init_card() issued CMD0 when - * the eMMC device is busy. - */ - if (!ocr && !mmc_host_is_spi(host)) - cmd->arg =3D cmd->resp[0] | BIT(30); - - return 0; -} - int mmc_send_op_cond(struct mmc_host *host, u32 ocr, u32 *rocr) { struct mmc_command cmd =3D {}; + unsigned int udelay =3D MMC_OP_COND_PERIOD_US; + unsigned int udelay_max =3D 10000; + unsigned long timeout =3D jiffies +=20 +msecs_to_jiffies(MMC_OP_COND_TIMEOUT_MS) + 1; int err =3D 0; - struct mmc_op_cond_busy_data cb_data =3D { - .host =3D host, - .ocr =3D ocr, - .cmd =3D &cmd - }; =20 cmd.opcode =3D MMC_SEND_OP_COND; cmd.arg =3D mmc_host_is_spi(host) ? 0 : ocr; cmd.flags =3D MMC_RSP_SPI_R1 | MMC_RSP_R3 | MMC_CMD_BCR; =20 - err =3D __mmc_poll_for_busy(host, MMC_OP_COND_PERIOD_US, - MMC_OP_COND_TIMEOUT_MS, - &__mmc_send_op_cond_cb, &cb_data); - if (err) - return err; + while (!time_after(jiffies, timeout)) { + err =3D mmc_wait_for_cmd(host, &cmd, 0); + if (err) + break; + + if (mmc_host_is_spi(host)) { + if (!(cmd.resp[0] & R1_SPI_IDLE)) + break; + } else { + if (cmd.resp[0] & MMC_CARD_BUSY) + break; + } + + /* + * According to eMMC specification v5.1 section 6.4.3, we + * should issue CMD1 repeatedly in the idle state until + * the eMMC is ready. Otherwise some eMMC devices seem to enter + * the inactive mode after mmc_init_card() issued CMD0 when + * the eMMC device is busy. + */ + if (!ocr && !mmc_host_is_spi(host)) + cmd.arg =3D cmd.resp[0] | BIT(30); + + usleep_range(udelay, udelay + 1000); + + if (udelay < udelay_max) + udelay +=3D 2000; + else + udelay =3D udelay_max; + } + + if (time_after(jiffies, timeout)) + err =3D -ETIMEDOUT; =20 if (rocr && !mmc_host_is_spi(host)) *rocr =3D cmd.resp[0]; -- 2.34.1