[PATCH V5 0/4] Add level shifter support for qualcomm SOC's

[PATCH V5 0/4] Add level shifter support for qualcomm SOC's

[Sarthak Garg]

Add level shifter support for qualcomm SOC's.

- Changed from v4
    - As suggested by Krzysztof Kozlowski Renamed the property from
    `max-sd-hs-frequency` to `max-sd-hs-hz` for clarity.
    - As suggested by Krzysztof Kozlowski remove min/max constraints
    and add default: 50000000 in dt-bindings.
    - As suggested by Konrad Dybcio moved max-sd-hs-hz property in the
    SoC dtsi.
    - Retained sdhci-caps-mask in sm8550.dtsi for now and will revisit
    its removal for future targets after thorough validation and testing
    from the beginning.

- Changed from v3
    - As suggested by Krzysztof Kozlowski moved the property from the
    SoC-level DTS to the board-level DTS.
    - Revised the commit messages to clearly explain its board-specific.

- Changed from v2
    - As suggested by Konrad Dybcio and Ulf Hansson redesigned logic
      to introduce a new DT property max-sd-hs-frequency and override
      the hs_max_dtr accordingly in sd.c file.

- Changed from v1
    - As suggested by Krzysztof Kozlowski redesigned logic to use
    compatible property for adding this level shifter support.
    - Addressed Adrian Hunter comments on V1 with resepect to
      checkpatch.
    - Cleared the bits first and then set bits in
      sdhci_msm_execute_tuning as suggested by Adrian Hunter.
    - Upated the if condition logic in msm_set_clock_rate_for_bus_mode
      as suggested by Adrian Hunter.

Sarthak Garg (4):
  mmc: sdhci-msm: Enable tuning for SDR50 mode for SD card
  dt-bindings: mmc: controller: Add max-sd-hs-frequency property
  mmc: core: Introduce a new flag max-sd-hs-hz
  arm64: dts: qcom: sm8550: Add max-sd-hs-hz property

 .../bindings/mmc/mmc-controller-common.yaml       |  8 ++++++++
 arch/arm64/boot/dts/qcom/sm8550.dtsi              |  1 +
 drivers/mmc/core/host.c                           |  2 ++
 drivers/mmc/core/sd.c                             |  2 +-
 drivers/mmc/host/sdhci-msm.c                      | 15 +++++++++++++++
 include/linux/mmc/host.h                          |  1 +
 6 files changed, 28 insertions(+), 1 deletion(-)

-- 
2.34.1

[PATCH V5 1/4] mmc: sdhci-msm: Enable tuning for SDR50 mode for SD card

[Sarthak Garg]

For Qualcomm SoCs which needs level shifter for SD card, extra delay is
seen on receiver data path.

To compensate this delay enable tuning for SDR50 mode for targets which
has level shifter. SDHCI_SDR50_NEEDS_TUNING caps will be set for targets
with level shifter on Qualcomm SOC's.

Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
---
 drivers/mmc/host/sdhci-msm.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 66c0d1ba2a33..bf91cb96a0ea 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -81,6 +81,7 @@
 #define CORE_IO_PAD_PWR_SWITCH_EN	BIT(15)
 #define CORE_IO_PAD_PWR_SWITCH	BIT(16)
 #define CORE_HC_SELECT_IN_EN	BIT(18)
+#define CORE_HC_SELECT_IN_SDR50	(4 << 19)
 #define CORE_HC_SELECT_IN_HS400	(6 << 19)
 #define CORE_HC_SELECT_IN_MASK	(7 << 19)
 
@@ -1133,6 +1134,10 @@ static bool sdhci_msm_is_tuning_needed(struct sdhci_host *host)
 {
 	struct mmc_ios *ios = &host->mmc->ios;
 
+	if (ios->timing == MMC_TIMING_UHS_SDR50 &&
+	    host->flags & SDHCI_SDR50_NEEDS_TUNING)
+		return true;
+
 	/*
 	 * Tuning is required for SDR104, HS200 and HS400 cards and
 	 * if clock frequency is greater than 100MHz in these modes.
@@ -1201,6 +1206,8 @@ static int sdhci_msm_execute_tuning(struct mmc_host *mmc, u32 opcode)
 	struct mmc_ios ios = host->mmc->ios;
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
 	struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
+	const struct sdhci_msm_offset *msm_offset = msm_host->offset;
+	u32 config;
 
 	if (!sdhci_msm_is_tuning_needed(host)) {
 		msm_host->use_cdr = false;
@@ -1217,6 +1224,14 @@ static int sdhci_msm_execute_tuning(struct mmc_host *mmc, u32 opcode)
 	 */
 	msm_host->tuning_done = 0;
 
+	if (ios.timing == MMC_TIMING_UHS_SDR50 &&
+	    host->flags & SDHCI_SDR50_NEEDS_TUNING) {
+		config = readl_relaxed(host->ioaddr + msm_offset->core_vendor_spec);
+		config &= ~CORE_HC_SELECT_IN_MASK;
+		config |= CORE_HC_SELECT_IN_EN | CORE_HC_SELECT_IN_SDR50;
+		writel_relaxed(config, host->ioaddr + msm_offset->core_vendor_spec);
+	}
+
 	/*
 	 * For HS400 tuning in HS200 timing requires:
 	 * - select MCLK/2 in VENDOR_SPEC
-- 
2.34.1

[PATCH V5 2/4] dt-bindings: mmc: controller: Add max-sd-hs-frequency property

[Sarthak Garg]

Some platforms may require limiting the maximum frequency used in SD
High-Speed (HS) mode due to board-level hardware constraints. For
example, certain boards may include level shifters or other components
that cannot reliably operate at the default 50 MHz HS frequency.

Introduce a new optional device tree property max-sd-hs-frequency to
limit the maximum frequency (in Hz) used for SD cards operating in
High-Speed (HS) mode.

Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com>
---
 .../devicetree/bindings/mmc/mmc-controller-common.yaml    | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
index 9a7235439759..d6b785cb2bd9 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
@@ -93,6 +93,14 @@ properties:
     minimum: 400000
     maximum: 384000000
 
+  max-sd-hs-hz:
+    description: |
+      Maximum frequency (in Hz) to be used for SD cards operating in
+      High-Speed (HS) mode. This is useful for board-specific limitations,
+      such as level shifters or others where the card cannot reliably
+      operate at the default 50 MHz HS frequency.
+    default: 50000000
+
   disable-wp:
     $ref: /schemas/types.yaml#/definitions/flag
     description:
-- 
2.34.1

[PATCH V5 3/4] mmc: core: Introduce a new flag max-sd-hs-hz

[Sarthak Garg]

Introduce a new device tree flag to cap the maximum High-Speed (HS)
mode frequency for SD cards, accommodating board-specific
constraints such as the inclusion of a level shifter which cannot
support the default 50Mhz HS frequency and others.

Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com>
---
 drivers/mmc/core/host.c  | 2 ++
 drivers/mmc/core/sd.c    | 2 +-
 include/linux/mmc/host.h | 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index dacb5bd9bb71..3fe6ae56a6ae 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -302,6 +302,8 @@ int mmc_of_parse(struct mmc_host *host)
 	/* f_max is obtained from the optional "max-frequency" property */
 	device_property_read_u32(dev, "max-frequency", &host->f_max);
 
+	device_property_read_u32(dev, "max-sd-hs-hz", &host->max_sd_hs_hz);
+
 	/*
 	 * Configure CD and WP pins. They are both by default active low to
 	 * match the SDHCI spec. If GPIOs are provided for CD and / or WP, the
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index ec02067f03c5..67cd63004829 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -359,7 +359,7 @@ static int mmc_read_switch(struct mmc_card *card)
 	}
 
 	if (status[13] & SD_MODE_HIGH_SPEED)
-		card->sw_caps.hs_max_dtr = HIGH_SPEED_MAX_DTR;
+		card->sw_caps.hs_max_dtr = card->host->max_sd_hs_hz ?: HIGH_SPEED_MAX_DTR;
 
 	if (card->scr.sda_spec3) {
 		card->sw_caps.sd3_bus_mode = status[13];
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 68f09a955a90..a698b4b02d95 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -565,6 +565,7 @@ struct mmc_host {
 	int			hsq_depth;
 
 	u32			err_stats[MMC_ERR_MAX];
+	unsigned int		max_sd_hs_hz;
 	unsigned long		private[] ____cacheline_aligned;
 };
 
-- 
2.34.1

[PATCH V5 4/4] arm64: dts: qcom: sm8550: Add max-sd-hs-hz property

[Sarthak Garg]

Due to board-specific hardware constraints particularly related
to level shifter in this case the maximum frequency for SD High-Speed
(HS) mode must be limited to 37.5 MHz to ensure reliable operation of SD
card in HS mode.

This is achieved by introducing the `max-sd-hs-hz` property in the
device tree, allowing the controller to operate within safe frequency
limits for HS mode.

Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com>
---
 arch/arm64/boot/dts/qcom/sm8550.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 82cabf777cd2..3692a3a49634 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -3189,6 +3189,7 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
 					 &config_noc SLAVE_SDCC_2 QCOM_ICC_TAG_ACTIVE_ONLY>;
 			interconnect-names = "sdhc-ddr", "cpu-sdhc";
 			bus-width = <4>;
+			max-sd-hs-hz = <37500000>;
 			dma-coherent;
 
 			/* Forbid SDR104/SDR50 - broken hw! */
-- 
2.34.1

Re: [PATCH V5 4/4] arm64: dts: qcom: sm8550: Add max-sd-hs-hz property

[Krzysztof Kozlowski]

On 03/09/2025 10:04, Sarthak Garg wrote:
> Due to board-specific hardware constraints particularly related
> to level shifter in this case the maximum frequency for SD High-Speed
> (HS) mode must be limited to 37.5 MHz to ensure reliable operation of SD
> card in HS mode.
> 
> This is achieved by introducing the `max-sd-hs-hz` property in the
> device tree, allowing the controller to operate within safe frequency
> limits for HS mode.
> 

Probably we will now replicate the same discussion... And it will be
happening every time you send the same and not reflect it in commit msg.

Bindings say board setup, this commit msg says board config, but the
patch says SoC. This is not correct.

Best regards,
Krzysztof

Re: [PATCH V5 2/4] dt-bindings: mmc: controller: Add max-sd-hs-frequency property

[Krzysztof Kozlowski]

On 03/09/2025 10:04, Sarthak Garg wrote:
> Some platforms may require limiting the maximum frequency used in SD
> High-Speed (HS) mode due to board-level hardware constraints. For
> example, certain boards may include level shifters or other components
> that cannot reliably operate at the default 50 MHz HS frequency.
> 
> Introduce a new optional device tree property max-sd-hs-frequency to
> limit the maximum frequency (in Hz) used for SD cards operating in
> High-Speed (HS) mode.
> 
> Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com>
> ---
>  .../devicetree/bindings/mmc/mmc-controller-common.yaml    | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> index 9a7235439759..d6b785cb2bd9 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> +++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> @@ -93,6 +93,14 @@ properties:
>      minimum: 400000
>      maximum: 384000000
>  
> +  max-sd-hs-hz:
> +    description: |
> +      Maximum frequency (in Hz) to be used for SD cards operating in
> +      High-Speed (HS) mode. This is useful for board-specific limitations,
> +      such as level shifters or others where the card cannot reliably
> +      operate at the default 50 MHz HS frequency.
> +    default: 50000000

no minimum/maximum? If 50 MHz is default, isn't it also an actual max?

Best regards,
Krzysztof

Re: [PATCH V5 0/4] Add level shifter support for qualcomm SOC's

[Dragan Simic]

Hello Sarthak and Krzysztof,

On 2025-09-03 10:04, Sarthak Garg wrote:
> Add level shifter support for qualcomm SOC's.
> 
> - Changed from v4
>     - As suggested by Krzysztof Kozlowski Renamed the property from
>     `max-sd-hs-frequency` to `max-sd-hs-hz` for clarity.

I just spotted this series, so I'm sorry for jumping in late.  To me,
"max-sd-hs-frequency" was actually a better choice, because it goes
together with the already existing "max-frequency" property.

Yes, "max-sd-hs-hz" is obviously more clear, but to me, consistency
is more important.  Just my $.02.

>     - As suggested by Krzysztof Kozlowski remove min/max constraints
>     and add default: 50000000 in dt-bindings.
>     - As suggested by Konrad Dybcio moved max-sd-hs-hz property in the
>     SoC dtsi.
>     - Retained sdhci-caps-mask in sm8550.dtsi for now and will revisit
>     its removal for future targets after thorough validation and 
> testing
>     from the beginning.
> 
> - Changed from v3
>     - As suggested by Krzysztof Kozlowski moved the property from the
>     SoC-level DTS to the board-level DTS.
>     - Revised the commit messages to clearly explain its 
> board-specific.
> 
> - Changed from v2
>     - As suggested by Konrad Dybcio and Ulf Hansson redesigned logic
>       to introduce a new DT property max-sd-hs-frequency and override
>       the hs_max_dtr accordingly in sd.c file.
> 
> - Changed from v1
>     - As suggested by Krzysztof Kozlowski redesigned logic to use
>     compatible property for adding this level shifter support.
>     - Addressed Adrian Hunter comments on V1 with resepect to
>       checkpatch.
>     - Cleared the bits first and then set bits in
>       sdhci_msm_execute_tuning as suggested by Adrian Hunter.
>     - Upated the if condition logic in msm_set_clock_rate_for_bus_mode
>       as suggested by Adrian Hunter.
> 
> Sarthak Garg (4):
>   mmc: sdhci-msm: Enable tuning for SDR50 mode for SD card
>   dt-bindings: mmc: controller: Add max-sd-hs-frequency property
>   mmc: core: Introduce a new flag max-sd-hs-hz
>   arm64: dts: qcom: sm8550: Add max-sd-hs-hz property
> 
>  .../bindings/mmc/mmc-controller-common.yaml       |  8 ++++++++
>  arch/arm64/boot/dts/qcom/sm8550.dtsi              |  1 +
>  drivers/mmc/core/host.c                           |  2 ++
>  drivers/mmc/core/sd.c                             |  2 +-
>  drivers/mmc/host/sdhci-msm.c                      | 15 +++++++++++++++
>  include/linux/mmc/host.h                          |  1 +
>  6 files changed, 28 insertions(+), 1 deletion(-)

Re: [PATCH V5 2/4] dt-bindings: mmc: controller: Add max-sd-hs-frequency property

[Rob Herring]

On Wed, Sep 03, 2025 at 01:34:02PM +0530, Sarthak Garg wrote:
> Some platforms may require limiting the maximum frequency used in SD
> High-Speed (HS) mode due to board-level hardware constraints. For
> example, certain boards may include level shifters or other components
> that cannot reliably operate at the default 50 MHz HS frequency.
> 
> Introduce a new optional device tree property max-sd-hs-frequency to
> limit the maximum frequency (in Hz) used for SD cards operating in
> High-Speed (HS) mode.
> 
> Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com>
> ---
>  .../devicetree/bindings/mmc/mmc-controller-common.yaml    | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> index 9a7235439759..d6b785cb2bd9 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> +++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> @@ -93,6 +93,14 @@ properties:
>      minimum: 400000
>      maximum: 384000000
>  
> +  max-sd-hs-hz:
> +    description: |
> +      Maximum frequency (in Hz) to be used for SD cards operating in
> +      High-Speed (HS) mode. This is useful for board-specific limitations,
> +      such as level shifters or others where the card cannot reliably
> +      operate at the default 50 MHz HS frequency.
> +    default: 50000000

Why doesn't max-frequency work for you? I would think frequency limits 
wouldn't really depend on the mode.

> +
>    disable-wp:
>      $ref: /schemas/types.yaml#/definitions/flag
>      description:
> -- 
> 2.34.1
> 

Re: [PATCH V5 0/4] Add level shifter support for qualcomm SOC's

[Rob Herring]

On Wed, Sep 03, 2025 at 10:24:55AM +0200, Dragan Simic wrote:
> Hello Sarthak and Krzysztof,
> 
> On 2025-09-03 10:04, Sarthak Garg wrote:
> > Add level shifter support for qualcomm SOC's.
> > 
> > - Changed from v4
> >     - As suggested by Krzysztof Kozlowski Renamed the property from
> >     `max-sd-hs-frequency` to `max-sd-hs-hz` for clarity.
> 
> I just spotted this series, so I'm sorry for jumping in late.  To me,
> "max-sd-hs-frequency" was actually a better choice, because it goes
> together with the already existing "max-frequency" property.
> 
> Yes, "max-sd-hs-hz" is obviously more clear, but to me, consistency
> is more important.  Just my $.02.

It's about defining the property units as 'frequency' could be kHz, MHz, 
etc. Unfortunately 'max-frequency' existed before standardizing with 
units.

Rob

Re: [PATCH V5 0/4] Add level shifter support for qualcomm SOC's

[Dragan Simic]

Hello Rob,

On 2025-09-03 22:42, Rob Herring wrote:
> On Wed, Sep 03, 2025 at 10:24:55AM +0200, Dragan Simic wrote:
>> On 2025-09-03 10:04, Sarthak Garg wrote:
>> > Add level shifter support for qualcomm SOC's.
>> >
>> > - Changed from v4
>> >     - As suggested by Krzysztof Kozlowski Renamed the property from
>> >     `max-sd-hs-frequency` to `max-sd-hs-hz` for clarity.
>> 
>> I just spotted this series, so I'm sorry for jumping in late.  To me,
>> "max-sd-hs-frequency" was actually a better choice, because it goes
>> together with the already existing "max-frequency" property.
>> 
>> Yes, "max-sd-hs-hz" is obviously more clear, but to me, consistency
>> is more important.  Just my $.02.
> 
> It's about defining the property units as 'frequency' could be kHz, 
> MHz,
> etc. Unfortunately 'max-frequency' existed before standardizing with
> units.

I see, thanks for the clarification.  In that case, we should perhaps
declare the "max-frequency" property obsolete and substitute it with new
"max-hz" property.  I'll see to whip up an RFC patch for that.

Hmm, there's also the "spi-max-frequency" property, for example, which
would also benefit from becoming replaced with "spi-max-hz".  That 
should
be another RFC patch. :)

Re: [PATCH V5 2/4] dt-bindings: mmc: controller: Add max-sd-hs-frequency property

[Sarthak Garg]

On 9/3/2025 1:52 PM, Krzysztof Kozlowski wrote:
> On 03/09/2025 10:04, Sarthak Garg wrote:
>> Some platforms may require limiting the maximum frequency used in SD
>> High-Speed (HS) mode due to board-level hardware constraints. For
>> example, certain boards may include level shifters or other components
>> that cannot reliably operate at the default 50 MHz HS frequency.
>>
>> Introduce a new optional device tree property max-sd-hs-frequency to
>> limit the maximum frequency (in Hz) used for SD cards operating in
>> High-Speed (HS) mode.
>>
>> Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com>
>> ---
>>   .../devicetree/bindings/mmc/mmc-controller-common.yaml    | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
>> index 9a7235439759..d6b785cb2bd9 100644
>> --- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
>> +++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
>> @@ -93,6 +93,14 @@ properties:
>>       minimum: 400000
>>       maximum: 384000000
>>   
>> +  max-sd-hs-hz:
>> +    description: |
>> +      Maximum frequency (in Hz) to be used for SD cards operating in
>> +      High-Speed (HS) mode. This is useful for board-specific limitations,
>> +      such as level shifters or others where the card cannot reliably
>> +      operate at the default 50 MHz HS frequency.
>> +    default: 50000000
> 
> no minimum/maximum? If 50 MHz is default, isn't it also an actual max?
> 
> Best regards,
> Krzysztof

I realized I had misinterpreted your earlier comment, which led to the
removal of min/max. I’ll reintroduce them with the following values:

+    minimum: 400000
+    maximum: 50000000
+    default: 50000000

Regarding your comment on V4 — "Don't repeat constraints in free form
text" — just to clarify: are you suggesting that I remove the sentence:

"This is useful for board-specific limitations, such as level shifters
or others where the card cannot reliably operate at the default 50 MHz
HS frequency."

If so, I’ll go ahead and remove it from the bindings.

Best regards,
Sarthak

Re: [PATCH V5 2/4] dt-bindings: mmc: controller: Add max-sd-hs-frequency property

[Sarthak Garg]

On 9/4/2025 2:09 AM, Rob Herring wrote:
> On Wed, Sep 03, 2025 at 01:34:02PM +0530, Sarthak Garg wrote:
>> Some platforms may require limiting the maximum frequency used in SD
>> High-Speed (HS) mode due to board-level hardware constraints. For
>> example, certain boards may include level shifters or other components
>> that cannot reliably operate at the default 50 MHz HS frequency.
>>
>> Introduce a new optional device tree property max-sd-hs-frequency to
>> limit the maximum frequency (in Hz) used for SD cards operating in
>> High-Speed (HS) mode.
>>
>> Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com>
>> ---
>>   .../devicetree/bindings/mmc/mmc-controller-common.yaml    | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
>> index 9a7235439759..d6b785cb2bd9 100644
>> --- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
>> +++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
>> @@ -93,6 +93,14 @@ properties:
>>       minimum: 400000
>>       maximum: 384000000
>>   
>> +  max-sd-hs-hz:
>> +    description: |
>> +      Maximum frequency (in Hz) to be used for SD cards operating in
>> +      High-Speed (HS) mode. This is useful for board-specific limitations,
>> +      such as level shifters or others where the card cannot reliably
>> +      operate at the default 50 MHz HS frequency.
>> +    default: 50000000
> 
> Why doesn't max-frequency work for you? I would think frequency limits
> wouldn't really depend on the mode.
> 

The reason max-frequency isn't sufficient in this case is that it 
applies globally across all operating modes of the SD card interface. 
However, the constraint we're trying to address is specific to 
High-Speed (HS) mode where the default frequency is 50 MHz.By 
introducing a mode-specific property like max-sd-hs-frequency, we can 
target only HS mode without affecting the capabilities of other modes. 
This provides more granular control and avoids performance degradation 
for other modes.

>> +
>>     disable-wp:
>>       $ref: /schemas/types.yaml#/definitions/flag
>>       description:
>> -- 
>> 2.34.1
>>

Re: [PATCH V5 4/4] arm64: dts: qcom: sm8550: Add max-sd-hs-hz property

[Konrad Dybcio]

On 9/3/25 10:21 AM, 'Krzysztof Kozlowski' via kernel wrote:
> On 03/09/2025 10:04, Sarthak Garg wrote:
>> Due to board-specific hardware constraints particularly related
>> to level shifter in this case the maximum frequency for SD High-Speed
>> (HS) mode must be limited to 37.5 MHz to ensure reliable operation of SD
>> card in HS mode.
>>
>> This is achieved by introducing the `max-sd-hs-hz` property in the
>> device tree, allowing the controller to operate within safe frequency
>> limits for HS mode.
>>
> 
> Probably we will now replicate the same discussion... And it will be
> happening every time you send the same and not reflect it in commit msg.
> 
> Bindings say board setup, this commit msg says board config, but the
> patch says SoC. This is not correct.

Both are correct, looking at the problem from two perspectives.

The bindings description mentions board-specific limitations (e.g. because
"the board's electrical design does not allow one to achieve the full rated
frequency that the SoC can otherwise do, in a stable way")

Here the author tries to argue that almost all SM8550 boards are broken
in this sense, because the reference design did not feature the required
passive components, making most (derivative) designs sort of "broken by
default" - and only some (if any?) vendors decided to go with the
additional components required to lift this limitation.

This in turn makes it fair to assume the developer experience would benefit
from having the SD card high speed modes always work (with the slight speed
cap which may not be required for the 1 or 2 designs that took the extra
step) without each board DT creator having to track down this property
separately.

Konrad

Re: [PATCH V5 4/4] arm64: dts: qcom: sm8550: Add max-sd-hs-hz property

[Krzysztof Kozlowski]

On 04/09/2025 10:36, Konrad Dybcio wrote:
> On 9/3/25 10:21 AM, 'Krzysztof Kozlowski' via kernel wrote:
>> On 03/09/2025 10:04, Sarthak Garg wrote:
>>> Due to board-specific hardware constraints particularly related
>>> to level shifter in this case the maximum frequency for SD High-Speed
>>> (HS) mode must be limited to 37.5 MHz to ensure reliable operation of SD
>>> card in HS mode.
>>>
>>> This is achieved by introducing the `max-sd-hs-hz` property in the
>>> device tree, allowing the controller to operate within safe frequency
>>> limits for HS mode.
>>>
>>
>> Probably we will now replicate the same discussion... And it will be
>> happening every time you send the same and not reflect it in commit msg.
>>
>> Bindings say board setup, this commit msg says board config, but the
>> patch says SoC. This is not correct.
> 
> Both are correct, looking at the problem from two perspectives.
> 
> The bindings description mentions board-specific limitations (e.g. because
> "the board's electrical design does not allow one to achieve the full rated
> frequency that the SoC can otherwise do, in a stable way")
> 
> Here the author tries to argue that almost all SM8550 boards are broken
> in this sense, because the reference design did not feature the required
> passive components, making most (derivative) designs sort of "broken by
> default" - and only some (if any?) vendors decided to go with the
> additional components required to lift this limitation.
> 
> This in turn makes it fair to assume the developer experience would benefit
> from having the SD card high speed modes always work (with the slight speed
> cap which may not be required for the 1 or 2 designs that took the extra
> step) without each board DT creator having to track down this property
> separately.

And then if you send same v3, I will ask the same. Can the author
finally write commit msgs reflecting discussions and previous disagreements?

Reviewers questions happen for a reason, so sending the same means
person ignored that reason.

Best regards,
Krzysztof

Re: [PATCH V5 4/4] arm64: dts: qcom: sm8550: Add max-sd-hs-hz property

[Krzysztof Kozlowski]

On 04/09/2025 12:51, Krzysztof Kozlowski wrote:
> On 04/09/2025 10:36, Konrad Dybcio wrote:
>> On 9/3/25 10:21 AM, 'Krzysztof Kozlowski' via kernel wrote:
>>> On 03/09/2025 10:04, Sarthak Garg wrote:
>>>> Due to board-specific hardware constraints particularly related
>>>> to level shifter in this case the maximum frequency for SD High-Speed
>>>> (HS) mode must be limited to 37.5 MHz to ensure reliable operation of SD
>>>> card in HS mode.
>>>>
>>>> This is achieved by introducing the `max-sd-hs-hz` property in the
>>>> device tree, allowing the controller to operate within safe frequency
>>>> limits for HS mode.
>>>>
>>>
>>> Probably we will now replicate the same discussion... And it will be
>>> happening every time you send the same and not reflect it in commit msg.

Just to emphasize this - it will happen EVERY time.

>>>
>>> Bindings say board setup, this commit msg says board config, but the
>>> patch says SoC. This is not correct.
>>
>> Both are correct, looking at the problem from two perspectives.
>>
>> The bindings description mentions board-specific limitations (e.g. because
>> "the board's electrical design does not allow one to achieve the full rated
>> frequency that the SoC can otherwise do, in a stable way")
>>
>> Here the author tries to argue that almost all SM8550 boards are broken
>> in this sense, because the reference design did not feature the required
>> passive components, making most (derivative) designs sort of "broken by
>> default" - and only some (if any?) vendors decided to go with the
>> additional components required to lift this limitation.
>>
>> This in turn makes it fair to assume the developer experience would benefit
>> from having the SD card high speed modes always work (with the slight speed
>> cap which may not be required for the 1 or 2 designs that took the extra
>> step) without each board DT creator having to track down this property
>> separately.
> 
> And then if you send same v3, I will ask the same. Can the author

v3 -> v6

> finally write commit msgs reflecting discussions and previous disagreements?

Best regards,
Krzysztof

Re: [PATCH V5 4/4] arm64: dts: qcom: sm8550: Add max-sd-hs-hz property

[Konrad Dybcio]

On 9/4/25 12:52 PM, Krzysztof Kozlowski wrote:
> On 04/09/2025 12:51, Krzysztof Kozlowski wrote:
>> On 04/09/2025 10:36, Konrad Dybcio wrote:
>>> On 9/3/25 10:21 AM, 'Krzysztof Kozlowski' via kernel wrote:
>>>> On 03/09/2025 10:04, Sarthak Garg wrote:
>>>>> Due to board-specific hardware constraints particularly related
>>>>> to level shifter in this case the maximum frequency for SD High-Speed
>>>>> (HS) mode must be limited to 37.5 MHz to ensure reliable operation of SD
>>>>> card in HS mode.
>>>>>
>>>>> This is achieved by introducing the `max-sd-hs-hz` property in the
>>>>> device tree, allowing the controller to operate within safe frequency
>>>>> limits for HS mode.
>>>>>
>>>>
>>>> Probably we will now replicate the same discussion... And it will be
>>>> happening every time you send the same and not reflect it in commit msg.
> 
> Just to emphasize this - it will happen EVERY time.
> 
>>>>
>>>> Bindings say board setup, this commit msg says board config, but the
>>>> patch says SoC. This is not correct.
>>>
>>> Both are correct, looking at the problem from two perspectives.
>>>
>>> The bindings description mentions board-specific limitations (e.g. because
>>> "the board's electrical design does not allow one to achieve the full rated
>>> frequency that the SoC can otherwise do, in a stable way")
>>>
>>> Here the author tries to argue that almost all SM8550 boards are broken
>>> in this sense, because the reference design did not feature the required
>>> passive components, making most (derivative) designs sort of "broken by
>>> default" - and only some (if any?) vendors decided to go with the
>>> additional components required to lift this limitation.
>>>
>>> This in turn makes it fair to assume the developer experience would benefit
>>> from having the SD card high speed modes always work (with the slight speed
>>> cap which may not be required for the 1 or 2 designs that took the extra
>>> step) without each board DT creator having to track down this property
>>> separately.
>>
>> And then if you send same v3, I will ask the same. Can the author
> 
> v3 -> v6

So, would you be accepting of this patch if the commit message was:

arm64: dts: qcom: sm8550: Limit max SD HS mode frequency by default

Due to an implementation detail in this SoC, additional passive
electrical components are required to achieve the maximum rated speed
of the SD controller when paired with a High-Speed SD Card. Without them,
the clock frequency must be limited to 37.5 MHz for link stability.

Because the reference design does not contain these components, most
(derivative) boards do not have them either. To accommodate for that,
apply the frequency limit by default and delegate lifting it to the
odd boards that do contain the necessary onboard hardware.

Konrad

Re: [PATCH V5 4/4] arm64: dts: qcom: sm8550: Add max-sd-hs-hz property

[Krzysztof Kozlowski]

On 04/09/2025 14:27, Konrad Dybcio wrote:
> On 9/4/25 12:52 PM, Krzysztof Kozlowski wrote:
>> On 04/09/2025 12:51, Krzysztof Kozlowski wrote:
>>> On 04/09/2025 10:36, Konrad Dybcio wrote:
>>>> On 9/3/25 10:21 AM, 'Krzysztof Kozlowski' via kernel wrote:
>>>>> On 03/09/2025 10:04, Sarthak Garg wrote:
>>>>>> Due to board-specific hardware constraints particularly related
>>>>>> to level shifter in this case the maximum frequency for SD High-Speed
>>>>>> (HS) mode must be limited to 37.5 MHz to ensure reliable operation of SD
>>>>>> card in HS mode.
>>>>>>
>>>>>> This is achieved by introducing the `max-sd-hs-hz` property in the
>>>>>> device tree, allowing the controller to operate within safe frequency
>>>>>> limits for HS mode.
>>>>>>
>>>>>
>>>>> Probably we will now replicate the same discussion... And it will be
>>>>> happening every time you send the same and not reflect it in commit msg.
>>
>> Just to emphasize this - it will happen EVERY time.
>>
>>>>>
>>>>> Bindings say board setup, this commit msg says board config, but the
>>>>> patch says SoC. This is not correct.
>>>>
>>>> Both are correct, looking at the problem from two perspectives.
>>>>
>>>> The bindings description mentions board-specific limitations (e.g. because
>>>> "the board's electrical design does not allow one to achieve the full rated
>>>> frequency that the SoC can otherwise do, in a stable way")
>>>>
>>>> Here the author tries to argue that almost all SM8550 boards are broken
>>>> in this sense, because the reference design did not feature the required
>>>> passive components, making most (derivative) designs sort of "broken by
>>>> default" - and only some (if any?) vendors decided to go with the
>>>> additional components required to lift this limitation.
>>>>
>>>> This in turn makes it fair to assume the developer experience would benefit
>>>> from having the SD card high speed modes always work (with the slight speed
>>>> cap which may not be required for the 1 or 2 designs that took the extra
>>>> step) without each board DT creator having to track down this property
>>>> separately.
>>>
>>> And then if you send same v3, I will ask the same. Can the author
>>
>> v3 -> v6
> 
> So, would you be accepting of this patch if the commit message was:
> 
> arm64: dts: qcom: sm8550: Limit max SD HS mode frequency by default
> 
> Due to an implementation detail in this SoC, additional passive
> electrical components are required to achieve the maximum rated speed
> of the SD controller when paired with a High-Speed SD Card. Without them,
> the clock frequency must be limited to 37.5 MHz for link stability.
> 
> Because the reference design does not contain these components, most
> (derivative) boards do not have them either. To accommodate for that,
> apply the frequency limit by default and delegate lifting it to the
> odd boards that do contain the necessary onboard hardware.
Yes, it is an excellent explanation.

Best regards,
Krzysztof

Re: [PATCH V5 4/4] arm64: dts: qcom: sm8550: Add max-sd-hs-hz property

[Konrad Dybcio]

On 9/4/25 3:07 PM, Krzysztof Kozlowski wrote:
> On 04/09/2025 14:27, Konrad Dybcio wrote:
>> On 9/4/25 12:52 PM, Krzysztof Kozlowski wrote:
>>> On 04/09/2025 12:51, Krzysztof Kozlowski wrote:
>>>> On 04/09/2025 10:36, Konrad Dybcio wrote:
>>>>> On 9/3/25 10:21 AM, 'Krzysztof Kozlowski' via kernel wrote:
>>>>>> On 03/09/2025 10:04, Sarthak Garg wrote:
>>>>>>> Due to board-specific hardware constraints particularly related
>>>>>>> to level shifter in this case the maximum frequency for SD High-Speed
>>>>>>> (HS) mode must be limited to 37.5 MHz to ensure reliable operation of SD
>>>>>>> card in HS mode.
>>>>>>>
>>>>>>> This is achieved by introducing the `max-sd-hs-hz` property in the
>>>>>>> device tree, allowing the controller to operate within safe frequency
>>>>>>> limits for HS mode.
>>>>>>>
>>>>>>
>>>>>> Probably we will now replicate the same discussion... And it will be
>>>>>> happening every time you send the same and not reflect it in commit msg.
>>>
>>> Just to emphasize this - it will happen EVERY time.
>>>
>>>>>>
>>>>>> Bindings say board setup, this commit msg says board config, but the
>>>>>> patch says SoC. This is not correct.
>>>>>
>>>>> Both are correct, looking at the problem from two perspectives.
>>>>>
>>>>> The bindings description mentions board-specific limitations (e.g. because
>>>>> "the board's electrical design does not allow one to achieve the full rated
>>>>> frequency that the SoC can otherwise do, in a stable way")
>>>>>
>>>>> Here the author tries to argue that almost all SM8550 boards are broken
>>>>> in this sense, because the reference design did not feature the required
>>>>> passive components, making most (derivative) designs sort of "broken by
>>>>> default" - and only some (if any?) vendors decided to go with the
>>>>> additional components required to lift this limitation.
>>>>>
>>>>> This in turn makes it fair to assume the developer experience would benefit
>>>>> from having the SD card high speed modes always work (with the slight speed
>>>>> cap which may not be required for the 1 or 2 designs that took the extra
>>>>> step) without each board DT creator having to track down this property
>>>>> separately.
>>>>
>>>> And then if you send same v3, I will ask the same. Can the author
>>>
>>> v3 -> v6
>>
>> So, would you be accepting of this patch if the commit message was:
>>
>> arm64: dts: qcom: sm8550: Limit max SD HS mode frequency by default
>>
>> Due to an implementation detail in this SoC, additional passive
>> electrical components are required to achieve the maximum rated speed
>> of the SD controller when paired with a High-Speed SD Card. Without them,
>> the clock frequency must be limited to 37.5 MHz for link stability.
>>
>> Because the reference design does not contain these components, most
>> (derivative) boards do not have them either. To accommodate for that,
>> apply the frequency limit by default and delegate lifting it to the
>> odd boards that do contain the necessary onboard hardware.
> Yes, it is an excellent explanation.

Sarthak, if you believe what I said is accurate, feel free to copy-paste
as is

Konrad