From: Adrian Hunter <adrian.hunter@intel.com>
To: <ziniu.wang_1@nxp.com>, <ulf.hansson@linaro.org>, <haibo.chen@nxp.com>
Cc: <shawnguo@kernel.org>, <s.hauer@pengutronix.de>,
<kernel@pengutronix.de>, <festevam@gmail.com>,
<imx@lists.linux.dev>, <linux-mmc@vger.kernel.org>, <s32@nxp.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 6/6] mmc: sdhci-esdhc-imx: switch standard tuning to manual tuning
Date: Tue, 22 Apr 2025 13:53:15 +0300 [thread overview]
Message-ID: <465c3e5a-8b6a-47e0-9777-a6ed15669964@intel.com> (raw)
In-Reply-To: <20250409075550.3413032-7-ziniu.wang_1@nxp.com>
On 9/04/25 10:55, ziniu.wang_1@nxp.com wrote:
> From: Luke Wang <ziniu.wang_1@nxp.com>
>
> Current standard tuning has some limitations:
>
> 1. Standard tuning only try 40 times to find first pass window, but this
> pass window maybe not the best pass window.
>
> 2. Sometimes there are two tuning pass windows and the gap between
> those two windows may only have one cell. If tuning step > 1, the gap may
> just be skipped and host assumes those two windows as a continuous
> windows. This will cause a bad delay cell near the gap to be selected.
>
> 3. Standard tuning logic need to detect at least one success and failure
> to pass the tuning. If all cells in the tuning window pass, the hardware
> will not set the SDHCI_CTRL_TUNED_CLK bit, causing tuning failed.
>
> 4. Standard tuning logic only check the CRC, do not really compare the data
> pattern. If data pins are connected incorrectly, standard will not detect
> this kind of issue.
>
> Switch to manual tuning to avoid those limitations
Is it necessary to have standard tuning at all then?
>
> Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
> ---
> drivers/mmc/host/sdhci-esdhc-imx.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
> index fd0ad0ad1519..9b66e07ed8e7 100644
> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> @@ -275,35 +275,35 @@ static const struct esdhc_soc_data usdhc_imx6q_data = {
> };
>
> static const struct esdhc_soc_data usdhc_imx6sl_data = {
> - .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
> + .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_MAN_TUNING
> | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_ERR004536
> | ESDHC_FLAG_HS200
> | ESDHC_FLAG_BROKEN_AUTO_CMD23,
> };
>
> static const struct esdhc_soc_data usdhc_imx6sll_data = {
> - .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
> + .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_MAN_TUNING
> | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
> | ESDHC_FLAG_HS400
> | ESDHC_FLAG_STATE_LOST_IN_LPMODE,
> };
>
> static const struct esdhc_soc_data usdhc_imx6sx_data = {
> - .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
> + .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_MAN_TUNING
> | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
> | ESDHC_FLAG_STATE_LOST_IN_LPMODE
> | ESDHC_FLAG_BROKEN_AUTO_CMD23,
> };
>
> static const struct esdhc_soc_data usdhc_imx6ull_data = {
> - .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
> + .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_MAN_TUNING
> | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
> | ESDHC_FLAG_ERR010450
> | ESDHC_FLAG_STATE_LOST_IN_LPMODE,
> };
>
> static const struct esdhc_soc_data usdhc_imx7d_data = {
> - .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
> + .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_MAN_TUNING
> | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
> | ESDHC_FLAG_HS400
> | ESDHC_FLAG_STATE_LOST_IN_LPMODE
> @@ -319,7 +319,7 @@ static struct esdhc_soc_data usdhc_s32g2_data = {
> };
>
> static struct esdhc_soc_data usdhc_imx7ulp_data = {
> - .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
> + .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_MAN_TUNING
> | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
> | ESDHC_FLAG_PMQOS | ESDHC_FLAG_HS400
> | ESDHC_FLAG_STATE_LOST_IN_LPMODE,
> @@ -332,7 +332,7 @@ static struct esdhc_soc_data usdhc_imxrt1050_data = {
> };
>
> static struct esdhc_soc_data usdhc_imx8qxp_data = {
> - .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
> + .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_MAN_TUNING
> | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
> | ESDHC_FLAG_HS400 | ESDHC_FLAG_HS400_ES
> | ESDHC_FLAG_STATE_LOST_IN_LPMODE
> @@ -341,7 +341,7 @@ static struct esdhc_soc_data usdhc_imx8qxp_data = {
> };
>
> static struct esdhc_soc_data usdhc_imx8mm_data = {
> - .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
> + .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_MAN_TUNING
> | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
> | ESDHC_FLAG_HS400 | ESDHC_FLAG_HS400_ES
> | ESDHC_FLAG_STATE_LOST_IN_LPMODE,
next prev parent reply other threads:[~2025-04-22 10:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-09 7:55 [PATCH 0/6] enhance the tuning process reliability for i.MX uSDHC controller ziniu.wang_1
2025-04-09 7:55 ` [PATCH 1/6] mmc: sdhci-esdhc-imx: explicitly reset tuning circuit via RSTT bit ziniu.wang_1
2025-04-09 7:55 ` [PATCH 2/6] mmc: sdhci-esdhc-imx: reset async FIFO before sending manual tuning command ziniu.wang_1
2025-04-09 7:55 ` [PATCH 3/6] mmc: sdhci-esdhc-imx: widen auto-tuning window for standard tuning ziniu.wang_1
2025-04-09 7:55 ` [PATCH 4/6] mmc: sdhci-esdhc-imx: widen auto-tuning window for manual tuning ziniu.wang_1
2025-04-09 7:55 ` [PATCH 5/6] mmc: sdhci-esdhc-imx: verify tuning control status after configuration ziniu.wang_1
2025-04-09 7:55 ` [PATCH 6/6] mmc: sdhci-esdhc-imx: switch standard tuning to manual tuning ziniu.wang_1
2025-04-22 10:53 ` Adrian Hunter [this message]
2025-04-22 11:09 ` [EXT] " Luke Wang
2025-04-22 10:54 ` [PATCH 0/6] enhance the tuning process reliability for i.MX uSDHC controller Adrian Hunter
2025-04-22 15:44 ` Ulf Hansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=465c3e5a-8b6a-47e0-9777-a6ed15669964@intel.com \
--to=adrian.hunter@intel.com \
--cc=festevam@gmail.com \
--cc=haibo.chen@nxp.com \
--cc=imx@lists.linux.dev \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=s32@nxp.com \
--cc=shawnguo@kernel.org \
--cc=ulf.hansson@linaro.org \
--cc=ziniu.wang_1@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox