public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: Luke Wang <ziniu.wang_1@nxp.com>,
	"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
	Bough Chen <haibo.chen@nxp.com>
Cc: Frank Li <frank.li@nxp.com>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"festevam@gmail.com" <festevam@gmail.com>,
	"imx@lists.linux.dev" <imx@lists.linux.dev>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	dl-S32 <S32@nxp.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [EXT] Re: [PATCH 0/4] mmc: sdhci-esdhc-imx: add 1-bit bus width support
Date: Tue, 3 Mar 2026 11:29:08 +0200	[thread overview]
Message-ID: <eb7f3122-7792-4cd1-929d-d181fc23359d@intel.com> (raw)
In-Reply-To: <DU2PR04MB8567C32F1ECAA3AF45D4DA79ED7FA@DU2PR04MB8567.eurprd04.prod.outlook.com>

On 03/03/2026 05:39, Luke Wang wrote:
> 
> 
>> -----Original Message-----
>> From: Adrian Hunter <adrian.hunter@intel.com>
>> Sent: Monday, March 2, 2026 9:45 PM
>> To: Luke Wang <ziniu.wang_1@nxp.com>; ulf.hansson@linaro.org; Bough
>> Chen <haibo.chen@nxp.com>
>> Cc: Frank Li <frank.li@nxp.com>; s.hauer@pengutronix.de;
>> kernel@pengutronix.de; festevam@gmail.com; imx@lists.linux.dev; linux-
>> mmc@vger.kernel.org; dl-S32 <S32@nxp.com>; linux-arm-
>> kernel@lists.infradead.org; linux-kernel@vger.kernel.org
>> Subject: [EXT] Re: [PATCH 0/4] mmc: sdhci-esdhc-imx: add 1-bit bus width
>> support
>>
>> Caution: This is an external email. Please take care when clicking links or
>> opening attachments. When in doubt, report the message using the 'Report
>> this email' button
>>
>>
>> On 02/03/2026 10:00, ziniu.wang_1@nxp.com wrote:
>>> From: Luke Wang <ziniu.wang_1@nxp.com>
>>>
>>> This series adds 1-bit bus width support for sdhci-esdhc-imx driver.
>>>
>>> Currently sdhci-esdhc-imx doesn't support 1-bit width because it
>>> doesn't call sdhci_get_property() to parse "bus-width = <1>" and
>>> set SDHCI_QUIRK_FORCE_1_BIT_DATA quirk.
>>>
>>> After adding sdhci_get_property(), another issue is exposed:
>>> mmc_select_hs200() returns 0 without switching when 1-bit bus is
>>> used, causing mmc_select_timing() to skip mmc_select_hs(). This
>>> leaves eMMC in legacy mode (26MHz) instead of High Speed (52MHz).
>>
>> How do you end up with incompatible caps?  If sdhci is adding
>> them, then maybe stop that instead of removing them later?
> 
> The incompatible caps come from sdhci_setup_host() in sdhci.c, where
> UHS/DDR/HS200/HS400 caps are added based on hardware capability registers
> without checking bus width.
> 
> I can add bus width check directly in the condition, like:
> 
>     /* Any UHS-I mode in caps implies SDR12 and SDR25 support. */
> +   /* UHS modes require at least 4-bit bus width */
> -   if (host->caps1 & (SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
> -                      SDHCI_SUPPORT_DDR50))
> +   if ((mmc->caps & MMC_CAP_4_BIT_DATA) &&
> +       (host->caps1 & (SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
> +                       SDHCI_SUPPORT_DDR50)))
>         mmc->caps |= MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25;
> 
> Similar changes for SDR104/HS200/DDR50/HS400 settings.
> 
> Is this the right approach?

I think SDHCI_QUIRK_FORCE_1_BIT_DATA should override the hardware
capabilities, similar to SDHCI_QUIRK2_NO_1_8_V.  So something like:

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index b1a3cd574c84..605be55f8d2d 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -4539,8 +4539,15 @@ int sdhci_setup_host(struct sdhci_host *host)
 	 * their platform code before calling sdhci_add_host(), and we
 	 * won't assume 8-bit width for hosts without that CAP.
 	 */
-	if (!(host->quirks & SDHCI_QUIRK_FORCE_1_BIT_DATA))
+	if (host->quirks & SDHCI_QUIRK_FORCE_1_BIT_DATA) {
+		host->caps1 &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50);
+		if (host->quirks2 & SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400)
+			host->caps1 &= ~SDHCI_SUPPORT_HS400;
+		mmc->caps2 &= ~(MMC_CAP2_HS200 | MMC_CAP2_HS400 | MMC_CAP2_HS400_ES);
+		mmc->caps &= ~(MMC_CAP_DDR | MMC_CAP_UHS);
+	} else {
 		mmc->caps |= MMC_CAP_4_BIT_DATA;
+	}
 
 	if (host->quirks2 & SDHCI_QUIRK2_HOST_NO_CMD23)
 		mmc->caps &= ~MMC_CAP_CMD23;


> 
> Thanks,
> Luke
> 
>>
>>>
>>> Fix by dropping incompatible UHS/DDR/HS200/HS400 caps in
>>> mmc_validate_host_caps() for 1-bit width, and clean up duplicate
>>> code now handled by common framework.
>>>
>>> Luke Wang (4):
>>>   mmc: core: fix timing selection for 1-bit bus width
>>>   mmc: sdhci-esdhc-imx: add 1-bit bus width support
>>>   mmc: sdhci-esdhc-imx: remove duplicate HS400 bus width validation
>>>   mmc: sdhci-pltfm: remove duplicate DTS property parsing
>>>
>>>  drivers/mmc/core/host.c            | 19 ++++++++++++++-----
>>>  drivers/mmc/host/sdhci-esdhc-imx.c |  6 +-----
>>>  drivers/mmc/host/sdhci-pltfm.c     |  7 -------
>>>  3 files changed, 15 insertions(+), 17 deletions(-)
>>>
> 



      reply	other threads:[~2026-03-03  9:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-02  8:00 [PATCH 0/4] mmc: sdhci-esdhc-imx: add 1-bit bus width support ziniu.wang_1
2026-03-02  8:00 ` [PATCH 1/4] mmc: core: fix timing selection for 1-bit bus width ziniu.wang_1
2026-03-02  8:54   ` Shawn Lin
2026-03-02  8:00 ` [PATCH 2/4] mmc: sdhci-esdhc-imx: add 1-bit bus width support ziniu.wang_1
2026-03-02  8:00 ` [PATCH 3/4] mmc: sdhci-esdhc-imx: remove duplicate HS400 bus width validation ziniu.wang_1
2026-03-02  8:00 ` [PATCH 4/4] mmc: sdhci-pltfm: remove duplicate DTS property parsing ziniu.wang_1
2026-03-02 13:44 ` [PATCH 0/4] mmc: sdhci-esdhc-imx: add 1-bit bus width support Adrian Hunter
2026-03-03  3:39   ` [EXT] " Luke Wang
2026-03-03  9:29     ` Adrian Hunter [this message]

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=eb7f3122-7792-4cd1-929d-d181fc23359d@intel.com \
    --to=adrian.hunter@intel.com \
    --cc=S32@nxp.com \
    --cc=festevam@gmail.com \
    --cc=frank.li@nxp.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=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