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

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

On Thu, Mar 05, 2026 at 06:51:09AM +0200, Dmitry Baryshkov wrote:
> 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
>
As per latest discussions and the approach finalized, will be updated in the V2
series, such that the default scenario is honoured and no-sd-no-emmc case is
also avoided. 

Thanks for the detailed discussion and suggestions.

Thanks and Regards,
Monish