Re: [PATCH 0/3] arm64: dts: qcom: monaco: Enable SDHCI storage support

[Monish Chunara <monish.chunara@oss.qualcomm.com>]

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