This series enables SDHCI storage support for both SD Card and eMMC on the
Qualcomm Monaco EVK platform.

The Monaco SoC shares the SDHCI controller between SD Card and eMMC use
cases. Previously, the common SoC dtsi unconditionally enabled the
'supports-cqe' property. This causes regression for SD cards, resulting
in timeouts and initialization failures during the probe sequence, as
the driver attempts to enable Command Queueing (CQE) logic incompatible
with the SD protocol.

To resolve this and enable full storage support, this series:

1. Moves the 'supports-cqe' property out of the common SoC dtsi. It is
   now only enabled in the specific eMMC configuration where it is
   supported.
2. Adds a device tree overlay to enable SD Card support (SDR/DDR modes).
3. Adds a device tree overlay to enable eMMC support. This configuration
   also explicitly disables the UFS controller to prevent power leakage,
   as the VCC regulator is shared between the UFS and eMMC rails on this
   platform.

Validated on Qualcomm Monaco EVK with both SD Card and eMMC modules.

Monish Chunara (3):
  arm64: dts: qcom: monaco: Move eMMC CQE support from SoC to board DT
  arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay
  arm64: dts: qcom: monaco-evk: Add SDHCI support for eMMC via overlay

 arch/arm64/boot/dts/qcom/Makefile             |  7 ++
 arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso | 46 ++++++++++++
 .../boot/dts/qcom/monaco-evk-sd-card.dtso     | 72 +++++++++++++++++++
 arch/arm64/boot/dts/qcom/monaco.dtsi          |  1 -
 arch/arm64/boot/dts/qcom/qcs8300-ride.dts     |  1 +
 5 files changed, 126 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso
 create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso

-- 
2.34.1

On Fri, Feb 27, 2026 at 04:20:52PM +0530, Monish Chunara wrote:
> This series enables SDHCI storage support for both SD Card and eMMC on the
> Qualcomm Monaco EVK platform.
> 
> The Monaco SoC shares the SDHCI controller between SD Card and eMMC use
> cases. Previously, the common SoC dtsi unconditionally enabled the
> 'supports-cqe' property. This causes regression for SD cards, resulting
> in timeouts and initialization failures during the probe sequence, as
> the driver attempts to enable Command Queueing (CQE) logic incompatible
> with the SD protocol.
> 
> To resolve this and enable full storage support, this series:
> 
> 1. Moves the 'supports-cqe' property out of the common SoC dtsi. It is
>    now only enabled in the specific eMMC configuration where it is
>    supported.
> 2. Adds a device tree overlay to enable SD Card support (SDR/DDR modes).
> 3. Adds a device tree overlay to enable eMMC support. This configuration
>    also explicitly disables the UFS controller to prevent power leakage,
>    as the VCC regulator is shared between the UFS and eMMC rails on this
>    platform.
> 
> Validated on Qualcomm Monaco EVK with both SD Card and eMMC modules.
> 
> Monish Chunara (3):
>   arm64: dts: qcom: monaco: Move eMMC CQE support from SoC to board DT
>   arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay
>   arm64: dts: qcom: monaco-evk: Add SDHCI support for eMMC via overlay

You are adding two overlays. But what does it mean? Does EVK has no uSD
/ eMMC at all, having both attachable via some kind of mezzanine? Is one
of them attachable? Or are both cases present onboard with the correct
one being selected by the DIP switch?

> 
>  arch/arm64/boot/dts/qcom/Makefile             |  7 ++
>  arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso | 46 ++++++++++++
>  .../boot/dts/qcom/monaco-evk-sd-card.dtso     | 72 +++++++++++++++++++
>  arch/arm64/boot/dts/qcom/monaco.dtsi          |  1 -
>  arch/arm64/boot/dts/qcom/qcs8300-ride.dts     |  1 +
>  5 files changed, 126 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso
>  create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
> 
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

On Fri, Feb 27, 2026 at 10:05:32PM +0200, Dmitry Baryshkov wrote:
> On Fri, Feb 27, 2026 at 04:20:52PM +0530, Monish Chunara wrote:
> > This series enables SDHCI storage support for both SD Card and eMMC on the
> > Qualcomm Monaco EVK platform.
> > 
> > The Monaco SoC shares the SDHCI controller between SD Card and eMMC use
> > cases. Previously, the common SoC dtsi unconditionally enabled the
> > 'supports-cqe' property. This causes regression for SD cards, resulting
> > in timeouts and initialization failures during the probe sequence, as
> > the driver attempts to enable Command Queueing (CQE) logic incompatible
> > with the SD protocol.
> > 
> > To resolve this and enable full storage support, this series:
> > 
> > 1. Moves the 'supports-cqe' property out of the common SoC dtsi. It is
> >    now only enabled in the specific eMMC configuration where it is
> >    supported.
> > 2. Adds a device tree overlay to enable SD Card support (SDR/DDR modes).
> > 3. Adds a device tree overlay to enable eMMC support. This configuration
> >    also explicitly disables the UFS controller to prevent power leakage,
> >    as the VCC regulator is shared between the UFS and eMMC rails on this
> >    platform.
> > 
> > Validated on Qualcomm Monaco EVK with both SD Card and eMMC modules.
> > 
> > Monish Chunara (3):
> >   arm64: dts: qcom: monaco: Move eMMC CQE support from SoC to board DT
> >   arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay
> >   arm64: dts: qcom: monaco-evk: Add SDHCI support for eMMC via overlay
> 
> You are adding two overlays. But what does it mean? Does EVK has no uSD
> / eMMC at all, having both attachable via some kind of mezzanine? Is one
> of them attachable? Or are both cases present onboard with the correct
> one being selected by the DIP switch?
> 

The monaco EVK has both storage devices present onboard and the desired one is
selected via a DIP switch. The overlay selection logic would be based on a
fitImage metadata entry that gets populated at UEFI level by determining the
currently selected storage device (eMMC/SD) on the device.

Hence, this approach becomes robust to enable the user for using either of the
two mediums, without any additional requirement of reflashing any images.

Regards,
Monish

On Mon, Mar 02, 2026 at 08:07:23PM +0530, Monish Chunara wrote:
> On Fri, Feb 27, 2026 at 10:05:32PM +0200, Dmitry Baryshkov wrote:
> > On Fri, Feb 27, 2026 at 04:20:52PM +0530, Monish Chunara wrote:
> > > This series enables SDHCI storage support for both SD Card and eMMC on the
> > > Qualcomm Monaco EVK platform.
> > > 
> > > The Monaco SoC shares the SDHCI controller between SD Card and eMMC use
> > > cases. Previously, the common SoC dtsi unconditionally enabled the
> > > 'supports-cqe' property. This causes regression for SD cards, resulting
> > > in timeouts and initialization failures during the probe sequence, as
> > > the driver attempts to enable Command Queueing (CQE) logic incompatible
> > > with the SD protocol.
> > > 
> > > To resolve this and enable full storage support, this series:
> > > 
> > > 1. Moves the 'supports-cqe' property out of the common SoC dtsi. It is
> > >    now only enabled in the specific eMMC configuration where it is
> > >    supported.
> > > 2. Adds a device tree overlay to enable SD Card support (SDR/DDR modes).
> > > 3. Adds a device tree overlay to enable eMMC support. This configuration
> > >    also explicitly disables the UFS controller to prevent power leakage,
> > >    as the VCC regulator is shared between the UFS and eMMC rails on this
> > >    platform.
> > > 
> > > Validated on Qualcomm Monaco EVK with both SD Card and eMMC modules.
> > > 
> > > Monish Chunara (3):
> > >   arm64: dts: qcom: monaco: Move eMMC CQE support from SoC to board DT
> > >   arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay
> > >   arm64: dts: qcom: monaco-evk: Add SDHCI support for eMMC via overlay
> > 
> > You are adding two overlays. But what does it mean? Does EVK has no uSD
> > / eMMC at all, having both attachable via some kind of mezzanine? Is one
> > of them attachable? Or are both cases present onboard with the correct
> > one being selected by the DIP switch?
> > 
> 
> The monaco EVK has both storage devices present onboard and the desired one is
> selected via a DIP switch. The overlay selection logic would be based on a
> fitImage metadata entry that gets populated at UEFI level by determining the
> currently selected storage device (eMMC/SD) on the device.
> 
> Hence, this approach becomes robust to enable the user for using either of the
> two mediums, without any additional requirement of reflashing any images.

You are answering a different question :-)

Let me formulate my question as a review comment:
- identify the default DIP switch position
- squash corresponding dtso into the dts
- leave only the default dts and non-default dtso to be applied by UEFI
  if necessary.

-- 
With best wishes
Dmitry

On Mon, Mar 02, 2026 at 04:47:41PM +0200, Dmitry Baryshkov wrote:
> On Mon, Mar 02, 2026 at 08:07:23PM +0530, Monish Chunara wrote:
> > On Fri, Feb 27, 2026 at 10:05:32PM +0200, Dmitry Baryshkov wrote:
> > > On Fri, Feb 27, 2026 at 04:20:52PM +0530, Monish Chunara wrote:
> > > > This series enables SDHCI storage support for both SD Card and eMMC on the
> > > > Qualcomm Monaco EVK platform.
> > > > 
> > > > The Monaco SoC shares the SDHCI controller between SD Card and eMMC use
> > > > cases. Previously, the common SoC dtsi unconditionally enabled the
> > > > 'supports-cqe' property. This causes regression for SD cards, resulting
> > > > in timeouts and initialization failures during the probe sequence, as
> > > > the driver attempts to enable Command Queueing (CQE) logic incompatible
> > > > with the SD protocol.
> > > > 
> > > > To resolve this and enable full storage support, this series:
> > > > 
> > > > 1. Moves the 'supports-cqe' property out of the common SoC dtsi. It is
> > > >    now only enabled in the specific eMMC configuration where it is
> > > >    supported.
> > > > 2. Adds a device tree overlay to enable SD Card support (SDR/DDR modes).
> > > > 3. Adds a device tree overlay to enable eMMC support. This configuration
> > > >    also explicitly disables the UFS controller to prevent power leakage,
> > > >    as the VCC regulator is shared between the UFS and eMMC rails on this
> > > >    platform.
> > > > 
> > > > Validated on Qualcomm Monaco EVK with both SD Card and eMMC modules.
> > > > 
> > > > Monish Chunara (3):
> > > >   arm64: dts: qcom: monaco: Move eMMC CQE support from SoC to board DT
> > > >   arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay
> > > >   arm64: dts: qcom: monaco-evk: Add SDHCI support for eMMC via overlay
> > > 
> > > You are adding two overlays. But what does it mean? Does EVK has no uSD
> > > / eMMC at all, having both attachable via some kind of mezzanine? Is one
> > > of them attachable? Or are both cases present onboard with the correct
> > > one being selected by the DIP switch?
> > > 
> > 
> > The monaco EVK has both storage devices present onboard and the desired one is
> > selected via a DIP switch. The overlay selection logic would be based on a
> > fitImage metadata entry that gets populated at UEFI level by determining the
> > currently selected storage device (eMMC/SD) on the device.
> > 
> > Hence, this approach becomes robust to enable the user for using either of the
> > two mediums, without any additional requirement of reflashing any images.
> 
> You are answering a different question :-)
> 
> Let me formulate my question as a review comment:
> - identify the default DIP switch position
> - squash corresponding dtso into the dts
> - leave only the default dts and non-default dtso to be applied by UEFI
>   if necessary.
> 

Thanks for clarifying. 

Default switch position is on eMMC on Monaco EVK. But as mentioned in the other
thread, there are a few boolean (flag) properties like 'no-sd', that conflicts
with SD card use case and cannot be deleted in an overlay file as
/delete-property/ cannot be used. Also cd-gpio and regulators used for SD card
would be redundant for eMMC.

And similarly 'no-mmc' added by default would be inappropriate for eMMC. This
being the reason, two separate overlays were added.

Regards,
Monish

On Mon, Mar 02, 2026 at 08:35:06PM +0530, Monish Chunara wrote:
> On Mon, Mar 02, 2026 at 04:47:41PM +0200, Dmitry Baryshkov wrote:
> > On Mon, Mar 02, 2026 at 08:07:23PM +0530, Monish Chunara wrote:
> > > On Fri, Feb 27, 2026 at 10:05:32PM +0200, Dmitry Baryshkov wrote:
> > > > On Fri, Feb 27, 2026 at 04:20:52PM +0530, Monish Chunara wrote:
> > > > > This series enables SDHCI storage support for both SD Card and eMMC on the
> > > > > Qualcomm Monaco EVK platform.
> > > > > 
> > > > > The Monaco SoC shares the SDHCI controller between SD Card and eMMC use
> > > > > cases. Previously, the common SoC dtsi unconditionally enabled the
> > > > > 'supports-cqe' property. This causes regression for SD cards, resulting
> > > > > in timeouts and initialization failures during the probe sequence, as
> > > > > the driver attempts to enable Command Queueing (CQE) logic incompatible
> > > > > with the SD protocol.
> > > > > 
> > > > > To resolve this and enable full storage support, this series:
> > > > > 
> > > > > 1. Moves the 'supports-cqe' property out of the common SoC dtsi. It is
> > > > >    now only enabled in the specific eMMC configuration where it is
> > > > >    supported.
> > > > > 2. Adds a device tree overlay to enable SD Card support (SDR/DDR modes).
> > > > > 3. Adds a device tree overlay to enable eMMC support. This configuration
> > > > >    also explicitly disables the UFS controller to prevent power leakage,
> > > > >    as the VCC regulator is shared between the UFS and eMMC rails on this
> > > > >    platform.
> > > > > 
> > > > > Validated on Qualcomm Monaco EVK with both SD Card and eMMC modules.
> > > > > 
> > > > > Monish Chunara (3):
> > > > >   arm64: dts: qcom: monaco: Move eMMC CQE support from SoC to board DT
> > > > >   arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay
> > > > >   arm64: dts: qcom: monaco-evk: Add SDHCI support for eMMC via overlay
> > > > 
> > > > You are adding two overlays. But what does it mean? Does EVK has no uSD
> > > > / eMMC at all, having both attachable via some kind of mezzanine? Is one
> > > > of them attachable? Or are both cases present onboard with the correct
> > > > one being selected by the DIP switch?
> > > > 
> > > 
> > > The monaco EVK has both storage devices present onboard and the desired one is
> > > selected via a DIP switch. The overlay selection logic would be based on a
> > > fitImage metadata entry that gets populated at UEFI level by determining the
> > > currently selected storage device (eMMC/SD) on the device.
> > > 
> > > Hence, this approach becomes robust to enable the user for using either of the
> > > two mediums, without any additional requirement of reflashing any images.
> > 
> > You are answering a different question :-)
> > 
> > Let me formulate my question as a review comment:
> > - identify the default DIP switch position
> > - squash corresponding dtso into the dts
> > - leave only the default dts and non-default dtso to be applied by UEFI
> >   if necessary.
> > 
> 
> Thanks for clarifying. 
> 
> Default switch position is on eMMC on Monaco EVK. But as mentioned in the other
> thread, there are a few boolean (flag) properties like 'no-sd', that conflicts
> with SD card use case and cannot be deleted in an overlay file as
> /delete-property/ cannot be used. Also cd-gpio and regulators used for SD card
> would be redundant for eMMC.
> 
> And similarly 'no-mmc' added by default would be inappropriate for eMMC. This
> being the reason, two separate overlays were added.

This only means one thing to me: UEFI mechanism needs to be changed from
applying the dtso into directly modifying the FDT in the DT_FIXUP protocol.

There are three options which needs to be removed this way:
- supported-cqe
- non-removable
- no-sd

> 
> Regards,
> Monish

-- 
With best wishes
Dmitry