[PATCH 0/2] RB1 fixes

[PATCH 0/2] RB1 fixes

[Sumit Garg]

From: Sumit Garg <sumit.garg@oss.qualcomm.com>

The eMMC on RB1 boards supports HS200 mode but currently the msm_shdci
driver in U-Boot is missing DLL configuration required for HS200 mode to
work. Hence disable HS200 for now until proper support is in place.

Apart from that, add DT override for USB to work in host mode as otg
mode isn't supported. Along with that disable sdhci_2 which doesn't work
as of now.

There is another patch related to clk_stub posted here [1] which allows
the MMC clocks to be probed properly.

[1] https://patchwork.ozlabs.org/project/uboot/patch/20250407120536.236003-4-jorge.ramirez@oss.qualcomm.com/

Sumit Garg (2):
  arm: dts: Add override for RB1
  qcom_defconfig: Disable MMC HS200 mode support

 arch/arm/dts/qrb2210-rb1-u-boot.dtsi | 11 +++++++++++
 configs/qcom_defconfig               |  1 -
 2 files changed, 11 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/qrb2210-rb1-u-boot.dtsi

-- 
2.43.0

[PATCH 1/2] arm: dts: Add override for RB1

[Sumit Garg]

From: Sumit Garg <sumit.garg@oss.qualcomm.com>

Add U-Boot override for RB1 to for USB in host mode as OTG mode isn't
supported. Also, disable sdhc_2 as it's currently not supported, sdhc_1
works fine though.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
---
 arch/arm/dts/qrb2210-rb1-u-boot.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100644 arch/arm/dts/qrb2210-rb1-u-boot.dtsi

diff --git a/arch/arm/dts/qrb2210-rb1-u-boot.dtsi b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
new file mode 100644
index 00000000000..1e136ee405a
--- /dev/null
+++ b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/* This is usually OTG but U-Boot doesn't support that properly */
+&usb_dwc3 {
+	dr_mode = "host";
+};
+
+/* SDHC_2 isn't supported in U-Boot as of now */
+&sdhc_2 {
+	status = "disabled";
+};
-- 
2.43.0

Re: [PATCH 1/2] arm: dts: Add override for RB1

[Caleb Connolly]

On 4/7/25 15:28, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> 
> Add U-Boot override for RB1 to for USB in host mode as OTG mode isn't
> supported. Also, disable sdhc_2 as it's currently not supported, sdhc_1
> works fine though.
> 
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
>   arch/arm/dts/qrb2210-rb1-u-boot.dtsi | 11 +++++++++++
>   1 file changed, 11 insertions(+)
>   create mode 100644 arch/arm/dts/qrb2210-rb1-u-boot.dtsi
> 
> diff --git a/arch/arm/dts/qrb2210-rb1-u-boot.dtsi b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
> new file mode 100644
> index 00000000000..1e136ee405a
> --- /dev/null
> +++ b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
> @@ -0,0 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/* This is usually OTG but U-Boot doesn't support that properly */
> +&usb_dwc3 {
> +	dr_mode = "host";
> +};
> +
> +/* SDHC_2 isn't supported in U-Boot as of now */

I'd rather avoid disabling this here, I guess it's just missing clocks 
and regulators which doesn't justify modifying DT. An error that mmc1 
couldn't be enabled seems fine to me?> +&sdhc_2 {
> +	status = "disabled";
> +};
-- 
Caleb (they/them)

Re: [PATCH 1/2] arm: dts: Add override for RB1

[Sumit Garg]

On Tue, Apr 08, 2025 at 02:17:29PM +0200, Caleb Connolly wrote:
> 
> 
> On 4/7/25 15:28, Sumit Garg wrote:
> > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > 
> > Add U-Boot override for RB1 to for USB in host mode as OTG mode isn't
> > supported. Also, disable sdhc_2 as it's currently not supported, sdhc_1
> > works fine though.
> > 
> > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > ---
> >   arch/arm/dts/qrb2210-rb1-u-boot.dtsi | 11 +++++++++++
> >   1 file changed, 11 insertions(+)
> >   create mode 100644 arch/arm/dts/qrb2210-rb1-u-boot.dtsi
> > 
> > diff --git a/arch/arm/dts/qrb2210-rb1-u-boot.dtsi b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
> > new file mode 100644
> > index 00000000000..1e136ee405a
> > --- /dev/null
> > +++ b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
> > @@ -0,0 +1,11 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +/* This is usually OTG but U-Boot doesn't support that properly */
> > +&usb_dwc3 {
> > +	dr_mode = "host";
> > +};
> > +
> > +/* SDHC_2 isn't supported in U-Boot as of now */
> 
> I'd rather avoid disabling this here, I guess it's just missing clocks and
> regulators which doesn't justify modifying DT. An error that mmc1 couldn't
> be enabled seems fine to me?

I totally echo with your thinking that we should avoid modifying DT but
at the same point we shouldn't enable peripherals in U-Boot which throws
errors. It's also possible that U-Boot misconfiguring mmc1 which might
turn as a problem for later stages.

I have been totally working with a remote lab to fix issues on RB1. I
will soon get one on my desk then I will be able to fix mmc1 too.

-Sumit

> > +&sdhc_2 {
> > +	status = "disabled";
> > +};
> -- 
> Caleb (they/them)
> 

Re: [PATCH 1/2] arm: dts: Add override for RB1

[Caleb Connolly]

On 4/8/25 15:46, Sumit Garg wrote:
> On Tue, Apr 08, 2025 at 02:17:29PM +0200, Caleb Connolly wrote:
>>
>>
>> On 4/7/25 15:28, Sumit Garg wrote:
>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>
>>> Add U-Boot override for RB1 to for USB in host mode as OTG mode isn't
>>> supported. Also, disable sdhc_2 as it's currently not supported, sdhc_1
>>> works fine though.
>>>
>>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>> ---
>>>    arch/arm/dts/qrb2210-rb1-u-boot.dtsi | 11 +++++++++++
>>>    1 file changed, 11 insertions(+)
>>>    create mode 100644 arch/arm/dts/qrb2210-rb1-u-boot.dtsi
>>>
>>> diff --git a/arch/arm/dts/qrb2210-rb1-u-boot.dtsi b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
>>> new file mode 100644
>>> index 00000000000..1e136ee405a
>>> --- /dev/null
>>> +++ b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
>>> @@ -0,0 +1,11 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +
>>> +/* This is usually OTG but U-Boot doesn't support that properly */
>>> +&usb_dwc3 {
>>> +	dr_mode = "host";
>>> +};
>>> +
>>> +/* SDHC_2 isn't supported in U-Boot as of now */
>>
>> I'd rather avoid disabling this here, I guess it's just missing clocks and
>> regulators which doesn't justify modifying DT. An error that mmc1 couldn't
>> be enabled seems fine to me?
> 
> I totally echo with your thinking that we should avoid modifying DT but
> at the same point we shouldn't enable peripherals in U-Boot which throws
> errors. It's also possible that U-Boot misconfiguring mmc1 which might

I disagree, DT isn't enabling or disabling peripherals, it's describing 
hardware. U-Boot lacking proper support for that hardware isn't a good 
justification to disable it. Especially since you might boot Linux with 
the same DT and now have no working sdcard for seemingly no reason.

An error in U-Boot is exactly the behaviour we want to see, masking it 
only created confusion.> turn as a problem for later stages.
> 
> I have been totally working with a remote lab to fix issues on RB1. I
> will soon get one on my desk then I will be able to fix mmc1 too.

In that case we can surely land the proper fixes for 2025.07 anyway, so 
I'd just keep the errors until then.

Kind regards,>
> -Sumit
> 
>>> +&sdhc_2 {
>>> +	status = "disabled";
>>> +};
>> -- 
>> Caleb (they/them)
>>

-- 
Caleb (they/them)

Re: [PATCH 1/2] arm: dts: Add override for RB1

[Sumit Garg]

On Tue, Apr 08, 2025 at 04:43:49PM +0200, Caleb Connolly wrote:
> 
> 
> On 4/8/25 15:46, Sumit Garg wrote:
> > On Tue, Apr 08, 2025 at 02:17:29PM +0200, Caleb Connolly wrote:
> > > 
> > > 
> > > On 4/7/25 15:28, Sumit Garg wrote:
> > > > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > 
> > > > Add U-Boot override for RB1 to for USB in host mode as OTG mode isn't
> > > > supported. Also, disable sdhc_2 as it's currently not supported, sdhc_1
> > > > works fine though.
> > > > 
> > > > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > ---
> > > >    arch/arm/dts/qrb2210-rb1-u-boot.dtsi | 11 +++++++++++
> > > >    1 file changed, 11 insertions(+)
> > > >    create mode 100644 arch/arm/dts/qrb2210-rb1-u-boot.dtsi
> > > > 
> > > > diff --git a/arch/arm/dts/qrb2210-rb1-u-boot.dtsi b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
> > > > new file mode 100644
> > > > index 00000000000..1e136ee405a
> > > > --- /dev/null
> > > > +++ b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
> > > > @@ -0,0 +1,11 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +
> > > > +/* This is usually OTG but U-Boot doesn't support that properly */
> > > > +&usb_dwc3 {
> > > > +	dr_mode = "host";
> > > > +};
> > > > +
> > > > +/* SDHC_2 isn't supported in U-Boot as of now */
> > > 
> > > I'd rather avoid disabling this here, I guess it's just missing clocks and
> > > regulators which doesn't justify modifying DT. An error that mmc1 couldn't
> > > be enabled seems fine to me?
> > 
> > I totally echo with your thinking that we should avoid modifying DT but
> > at the same point we shouldn't enable peripherals in U-Boot which throws
> > errors. It's also possible that U-Boot misconfiguring mmc1 which might
> 
> I disagree, DT isn't enabling or disabling peripherals, it's describing
> hardware.

It would be helpful if you can describe the use-case for "status"
property then.

> U-Boot lacking proper support for that hardware isn't a good
> justification to disable it. Especially since you might boot Linux with the
> same DT and now have no working sdcard for seemingly no reason.

We shouldn't use same DT unless both U-Boot and Linux support that
without modifications and *not* being in a broken state. The similar argument
holds true for USB OTG mode too.

> 
> An error in U-Boot is exactly the behaviour we want to see, masking it only
> created confusion.> turn as a problem for later stages.

IMO, our first priority should be to fix U-Boot issues and then see if
we can use unmodified DT.

> > 
> > I have been totally working with a remote lab to fix issues on RB1. I
> > will soon get one on my desk then I will be able to fix mmc1 too.
> 
> In that case we can surely land the proper fixes for 2025.07 anyway, so I'd
> just keep the errors until then.

Fixing errors in mainline will help other people confidence who are
trying to boot U-Boot on RB1. If you still have a strong preference to
keep SD card support enabled in broken state then I can live with that
until I fix it for real.

-Sumit

Re: [PATCH 1/2] arm: dts: Add override for RB1

[Caleb Connolly]

On 4/9/25 14:35, Sumit Garg wrote:
> On Tue, Apr 08, 2025 at 04:43:49PM +0200, Caleb Connolly wrote:
>>
>>
>> On 4/8/25 15:46, Sumit Garg wrote:
>>> On Tue, Apr 08, 2025 at 02:17:29PM +0200, Caleb Connolly wrote:
>>>>
>>>>
>>>> On 4/7/25 15:28, Sumit Garg wrote:
>>>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>>
>>>>> Add U-Boot override for RB1 to for USB in host mode as OTG mode isn't
>>>>> supported. Also, disable sdhc_2 as it's currently not supported, sdhc_1
>>>>> works fine though.
>>>>>
>>>>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>> ---
>>>>>     arch/arm/dts/qrb2210-rb1-u-boot.dtsi | 11 +++++++++++
>>>>>     1 file changed, 11 insertions(+)
>>>>>     create mode 100644 arch/arm/dts/qrb2210-rb1-u-boot.dtsi
>>>>>
>>>>> diff --git a/arch/arm/dts/qrb2210-rb1-u-boot.dtsi b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
>>>>> new file mode 100644
>>>>> index 00000000000..1e136ee405a
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
>>>>> @@ -0,0 +1,11 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>> +
>>>>> +/* This is usually OTG but U-Boot doesn't support that properly */
>>>>> +&usb_dwc3 {
>>>>> +	dr_mode = "host";
>>>>> +};
>>>>> +
>>>>> +/* SDHC_2 isn't supported in U-Boot as of now */
>>>>
>>>> I'd rather avoid disabling this here, I guess it's just missing clocks and
>>>> regulators which doesn't justify modifying DT. An error that mmc1 couldn't
>>>> be enabled seems fine to me?
>>>
>>> I totally echo with your thinking that we should avoid modifying DT but
>>> at the same point we shouldn't enable peripherals in U-Boot which throws
>>> errors. It's also possible that U-Boot misconfiguring mmc1 which might
>>
>> I disagree, DT isn't enabling or disabling peripherals, it's describing
>> hardware.
> 
> It would be helpful if you can describe the use-case for "status"
> property then.

https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#status

These all describe the functionality of hardware, since implementation 
details of the software (U-Boot) which is parsing the DT has absolutely 
nothing to do with it.>
>> U-Boot lacking proper support for that hardware isn't a good
>> justification to disable it. Especially since you might boot Linux with the
>> same DT and now have no working sdcard for seemingly no reason.
> 
> We shouldn't use same DT unless both U-Boot and Linux support that
> without modifications and *not* being in a broken state. The similar argument
> holds true for USB OTG mode too.
Well, the main difference with the OTG fixup is that we undo it later 
on, so if we boot an OS with this DT it won't have the override -- our 
hacks aren't exposed.

> 
>>
>> An error in U-Boot is exactly the behaviour we want to see, masking it only
>> created confusion.> turn as a problem for later stages.
> 
> IMO, our first priority should be to fix U-Boot issues and then see if
> we can use unmodified DT.
> 
>>>
>>> I have been totally working with a remote lab to fix issues on RB1. I
>>> will soon get one on my desk then I will be able to fix mmc1 too.
>>
>> In that case we can surely land the proper fixes for 2025.07 anyway, so I'd
>> just keep the errors until then.
> 
> Fixing errors in mainline will help other people confidence who are
> trying to boot U-Boot on RB1. If you still have a strong preference to
> keep SD card support enabled in broken state then I can live with that
> until I fix it for real.

I decided to just have a crack at it and managed to get everything 
cleaned up. sdcard seems to work on my RB1 with these patches on top of 
qcom-next and the u-boot specific DTS hacks are removed.

USB phy init seems to fail for me, but the board I'm testing on is some 
super early DVT so I'm hoping it's a silicon issue....

Please give these a spin and let me know how it goes.

https://lore.kernel.org/u-boot/20250409-livetree-fixup-v1-0-76dfea80b07f@linaro.org

Kind regards,>
> -Sumit
-- 
Caleb (they/them)

Re: [PATCH 1/2] arm: dts: Add override for RB1

[Sumit Garg]

On Wed, Apr 09, 2025 at 07:23:09PM +0200, Caleb Connolly wrote:
> 
> 
> On 4/9/25 14:35, Sumit Garg wrote:
> > On Tue, Apr 08, 2025 at 04:43:49PM +0200, Caleb Connolly wrote:
> > > 
> > > 
> > > On 4/8/25 15:46, Sumit Garg wrote:
> > > > On Tue, Apr 08, 2025 at 02:17:29PM +0200, Caleb Connolly wrote:
> > > > > 
> > > > > 
> > > > > On 4/7/25 15:28, Sumit Garg wrote:
> > > > > > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > > 
> > > > > > Add U-Boot override for RB1 to for USB in host mode as OTG mode isn't
> > > > > > supported. Also, disable sdhc_2 as it's currently not supported, sdhc_1
> > > > > > works fine though.
> > > > > > 
> > > > > > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > > ---
> > > > > >     arch/arm/dts/qrb2210-rb1-u-boot.dtsi | 11 +++++++++++
> > > > > >     1 file changed, 11 insertions(+)
> > > > > >     create mode 100644 arch/arm/dts/qrb2210-rb1-u-boot.dtsi
> > > > > > 
> > > > > > diff --git a/arch/arm/dts/qrb2210-rb1-u-boot.dtsi b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
> > > > > > new file mode 100644
> > > > > > index 00000000000..1e136ee405a
> > > > > > --- /dev/null
> > > > > > +++ b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
> > > > > > @@ -0,0 +1,11 @@
> > > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > > +
> > > > > > +/* This is usually OTG but U-Boot doesn't support that properly */
> > > > > > +&usb_dwc3 {
> > > > > > +	dr_mode = "host";
> > > > > > +};
> > > > > > +
> > > > > > +/* SDHC_2 isn't supported in U-Boot as of now */
> > > > > 
> > > > > I'd rather avoid disabling this here, I guess it's just missing clocks and
> > > > > regulators which doesn't justify modifying DT. An error that mmc1 couldn't
> > > > > be enabled seems fine to me?
> > > > 
> > > > I totally echo with your thinking that we should avoid modifying DT but
> > > > at the same point we shouldn't enable peripherals in U-Boot which throws
> > > > errors. It's also possible that U-Boot misconfiguring mmc1 which might
> > > 
> > > I disagree, DT isn't enabling or disabling peripherals, it's describing
> > > hardware.
> > 
> > It would be helpful if you can describe the use-case for "status"
> > property then.
> 
> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#status
> 
> These all describe the functionality of hardware, since implementation
> details of the software (U-Boot) which is parsing the DT has absolutely
> nothing to do with it.

Generally in Linux, we don't enable complete hardware support in one go
but it is rather incremently enabled where people make use of this
"status" property. So IMHO, it shouldn't be anything different for
U-Boot too.

> > > U-Boot lacking proper support for that hardware isn't a good
> > > justification to disable it. Especially since you might boot Linux with the
> > > same DT and now have no working sdcard for seemingly no reason.
> > 
> > We shouldn't use same DT unless both U-Boot and Linux support that
> > without modifications and *not* being in a broken state. The similar argument
> > holds true for USB OTG mode too.
> Well, the main difference with the OTG fixup is that we undo it later on, so
> if we boot an OS with this DT it won't have the override -- our hacks aren't
> exposed.

It's really nice to see the fixups using OF_LIVE.

> 
> > 
> > > 
> > > An error in U-Boot is exactly the behaviour we want to see, masking it only
> > > created confusion.> turn as a problem for later stages.
> > 
> > IMO, our first priority should be to fix U-Boot issues and then see if
> > we can use unmodified DT.
> > 
> > > > 
> > > > I have been totally working with a remote lab to fix issues on RB1. I
> > > > will soon get one on my desk then I will be able to fix mmc1 too.
> > > 
> > > In that case we can surely land the proper fixes for 2025.07 anyway, so I'd
> > > just keep the errors until then.
> > 
> > Fixing errors in mainline will help other people confidence who are
> > trying to boot U-Boot on RB1. If you still have a strong preference to
> > keep SD card support enabled in broken state then I can live with that
> > until I fix it for real.
> 
> I decided to just have a crack at it and managed to get everything cleaned
> up. sdcard seems to work on my RB1 with these patches on top of qcom-next
> and the u-boot specific DTS hacks are removed.

Great, you beat me to that. I have dropped the RB1 DT override patch
from the v2 [1] in favour of your patch-set.

> 
> USB phy init seems to fail for me, but the board I'm testing on is some
> super early DVT so I'm hoping it's a silicon issue....

I repoduced it on my remote RB1 setup. The PHY power on was broken by
recent addition of SM660 platform support. I fixed that as part of v2 [1]
too.

> 
> Please give these a spin and let me know how it goes.
> 
> https://lore.kernel.org/u-boot/20250409-livetree-fixup-v1-0-76dfea80b07f@linaro.org

It really works fine for me without any pinctrl error for SD card,
thanks.

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=452055

-Sumit

[PATCH 2/2] qcom_defconfig: Disable MMC HS200 mode support

[Sumit Garg]

From: Sumit Garg <sumit.garg@oss.qualcomm.com>

Currently the msm_sdhci doesn't yet support DLL configurations which are
required to enable bus speeds greater that 100MHz. So disable HS200 mode
support as of now as it requires bus speeds of 200MHz.

This should fix eMMC issues reported on RB1.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
---
 configs/qcom_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
index a2b54b95f19..537806450dc 100644
--- a/configs/qcom_defconfig
+++ b/configs/qcom_defconfig
@@ -81,7 +81,6 @@ CONFIG_QCOM_HYP_SMMU=y
 CONFIG_MISC=y
 CONFIG_NVMEM=y
 CONFIG_I2C_EEPROM=y
-CONFIG_MMC_HS200_SUPPORT=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ADMA=y
 CONFIG_MMC_SDHCI_MSM=y
-- 
2.43.0

Re: [PATCH 2/2] qcom_defconfig: Disable MMC HS200 mode support

[Caleb Connolly]

On 4/7/25 15:28, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> 
> Currently the msm_sdhci doesn't yet support DLL configurations which are
> required to enable bus speeds greater that 100MHz. So disable HS200 mode
> support as of now as it requires bus speeds of 200MHz.
> 
> This should fix eMMC issues reported on RB1.

This fixes the write corruption issues? Nice find!!

Is this a problem on ALL Qualcomm platforms? the sdcard seems to work 
fine on other boards, would this reduce their performance?

> 
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
>   configs/qcom_defconfig | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
> index a2b54b95f19..537806450dc 100644
> --- a/configs/qcom_defconfig
> +++ b/configs/qcom_defconfig
> @@ -81,7 +81,6 @@ CONFIG_QCOM_HYP_SMMU=y
>   CONFIG_MISC=y
>   CONFIG_NVMEM=y
>   CONFIG_I2C_EEPROM=y
> -CONFIG_MMC_HS200_SUPPORT=y
>   CONFIG_MMC_SDHCI=y
>   CONFIG_MMC_SDHCI_ADMA=y
>   CONFIG_MMC_SDHCI_MSM=y

-- 
Caleb (they/them)

Re: [PATCH 2/2] qcom_defconfig: Disable MMC HS200 mode support

[Sumit Garg]

On Mon, Apr 07, 2025 at 04:30:44PM +0200, Caleb Connolly wrote:
> 
> 
> On 4/7/25 15:28, Sumit Garg wrote:
> > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > 
> > Currently the msm_sdhci doesn't yet support DLL configurations which are
> > required to enable bus speeds greater that 100MHz. So disable HS200 mode
> > support as of now as it requires bus speeds of 200MHz.
> > 
> > This should fix eMMC issues reported on RB1.
> 
> This fixes the write corruption issues? Nice find!!

Yeah, thanks.

> 
> Is this a problem on ALL Qualcomm platforms? the sdcard seems to work fine
> on other boards, would this reduce their performance?

Yes this problem should affect all Qualcomm platforms but it hasn't been
seen there as mostly SD cards available don't support HS200 mode. The SD
cards usually works in high speed mode whose performance remains
unaffected by this change. It only affects RB1/RB2 as eMMC flash on
these support HS200 mode but the U-Boot driver currently is incapable of
supporting that.

-Sumit

> 
> > 
> > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > ---
> >   configs/qcom_defconfig | 1 -
> >   1 file changed, 1 deletion(-)
> > 
> > diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
> > index a2b54b95f19..537806450dc 100644
> > --- a/configs/qcom_defconfig
> > +++ b/configs/qcom_defconfig
> > @@ -81,7 +81,6 @@ CONFIG_QCOM_HYP_SMMU=y
> >   CONFIG_MISC=y
> >   CONFIG_NVMEM=y
> >   CONFIG_I2C_EEPROM=y
> > -CONFIG_MMC_HS200_SUPPORT=y
> >   CONFIG_MMC_SDHCI=y
> >   CONFIG_MMC_SDHCI_ADMA=y
> >   CONFIG_MMC_SDHCI_MSM=y
> 
> -- 
> Caleb (they/them)
> 

Re: [PATCH 2/2] qcom_defconfig: Disable MMC HS200 mode support

[Caleb Connolly]

On 4/8/25 06:29, Sumit Garg wrote:
> On Mon, Apr 07, 2025 at 04:30:44PM +0200, Caleb Connolly wrote:
>>
>>
>> On 4/7/25 15:28, Sumit Garg wrote:
>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>
>>> Currently the msm_sdhci doesn't yet support DLL configurations which are
>>> required to enable bus speeds greater that 100MHz. So disable HS200 mode
>>> support as of now as it requires bus speeds of 200MHz.
>>>
>>> This should fix eMMC issues reported on RB1.
>>
>> This fixes the write corruption issues? Nice find!!
> 
> Yeah, thanks.
> 
>>
>> Is this a problem on ALL Qualcomm platforms? the sdcard seems to work fine
>> on other boards, would this reduce their performance?
> 
> Yes this problem should affect all Qualcomm platforms but it hasn't been
> seen there as mostly SD cards available don't support HS200 mode. The SD
> cards usually works in high speed mode whose performance remains
> unaffected by this change. It only affects RB1/RB2 as eMMC flash on
> these support HS200 mode but the U-Boot driver currently is incapable of
> supporting that.

Ok awesome. Could you include this info in the commit message? Then

Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>

Kind regards,>
> -Sumit
> 
>>
>>>
>>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>> ---
>>>    configs/qcom_defconfig | 1 -
>>>    1 file changed, 1 deletion(-)
>>>
>>> diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
>>> index a2b54b95f19..537806450dc 100644
>>> --- a/configs/qcom_defconfig
>>> +++ b/configs/qcom_defconfig
>>> @@ -81,7 +81,6 @@ CONFIG_QCOM_HYP_SMMU=y
>>>    CONFIG_MISC=y
>>>    CONFIG_NVMEM=y
>>>    CONFIG_I2C_EEPROM=y
>>> -CONFIG_MMC_HS200_SUPPORT=y
>>>    CONFIG_MMC_SDHCI=y
>>>    CONFIG_MMC_SDHCI_ADMA=y
>>>    CONFIG_MMC_SDHCI_MSM=y
>>
>> -- 
>> Caleb (they/them)
>>

-- 
Caleb (they/them)

Re: [PATCH 2/2] qcom_defconfig: Disable MMC HS200 mode support

[Sumit Garg]

On Tue, Apr 08, 2025 at 02:13:55PM +0200, Caleb Connolly wrote:
> 
> 
> On 4/8/25 06:29, Sumit Garg wrote:
> > On Mon, Apr 07, 2025 at 04:30:44PM +0200, Caleb Connolly wrote:
> > > 
> > > 
> > > On 4/7/25 15:28, Sumit Garg wrote:
> > > > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > 
> > > > Currently the msm_sdhci doesn't yet support DLL configurations which are
> > > > required to enable bus speeds greater that 100MHz. So disable HS200 mode
> > > > support as of now as it requires bus speeds of 200MHz.
> > > > 
> > > > This should fix eMMC issues reported on RB1.
> > > 
> > > This fixes the write corruption issues? Nice find!!
> > 
> > Yeah, thanks.
> > 
> > > 
> > > Is this a problem on ALL Qualcomm platforms? the sdcard seems to work fine
> > > on other boards, would this reduce their performance?
> > 
> > Yes this problem should affect all Qualcomm platforms but it hasn't been
> > seen there as mostly SD cards available don't support HS200 mode. The SD
> > cards usually works in high speed mode whose performance remains
> > unaffected by this change. It only affects RB1/RB2 as eMMC flash on
> > these support HS200 mode but the U-Boot driver currently is incapable of
> > supporting that.
> 
> Ok awesome. Could you include this info in the commit message? Then

Sure, I can expand the commit message.

> 
> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
>

Thanks.

-Sumit

[PATCH 0/2] RB1 fixes

[Sumit Garg]

The eMMC on RB1 boards supports HS200 mode but currently the msm_shdci
driver in U-Boot is missing DLL configuration required for HS200 mode to
work. Hence disable HS200 for now until proper support is in place.

Apart from that, add DT override for USB to work in host mode as otg
mode isn't supported. Along with that disable sdhci_2 which doesn't work
as of now.

There is another patch related to clk_stub posted here [1] which allows
the MMC clocks to be probed properly.

[1] https://patchwork.ozlabs.org/project/uboot/patch/20250407120536.236003-4-jorge.ramirez@oss.qualcomm.com/

Sumit Garg (2):
  arm: dts: Add override for RB1
  qcom_defconfig: Disable MMC HS200 mode support

 arch/arm/dts/qrb2210-rb1-u-boot.dtsi | 11 +++++++++++
 configs/qcom_defconfig               |  1 -
 2 files changed, 11 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/qrb2210-rb1-u-boot.dtsi

-- 
2.43.0

[PATCH 1/2] arm: dts: Add override for RB1

[Sumit Garg]

Add U-Boot override for RB1 to for USB in host mode as OTG mode isn't
supported. Also, disable sdhc_2 as it's currently not supported, sdhc_1
works fine though.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
---
 arch/arm/dts/qrb2210-rb1-u-boot.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100644 arch/arm/dts/qrb2210-rb1-u-boot.dtsi

diff --git a/arch/arm/dts/qrb2210-rb1-u-boot.dtsi b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
new file mode 100644
index 00000000000..1e136ee405a
--- /dev/null
+++ b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/* This is usually OTG but U-Boot doesn't support that properly */
+&usb_dwc3 {
+	dr_mode = "host";
+};
+
+/* SDHC_2 isn't supported in U-Boot as of now */
+&sdhc_2 {
+	status = "disabled";
+};
-- 
2.43.0