Devicetree
 help / color / mirror / Atom feed
From: Monish Chunara <monish.chunara@oss.qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: andersson@kernel.org, konradybcio@kernel.org, robh@kernel.org,
	krzk+dt@kernel.org, conor+dt@kernel.org, mani@kernel.org,
	linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, sarthak.garg@oss.qualcomm.com,
	pradeep.pragallapati@oss.qualcomm.com,
	nitin.rawat@oss.qualcomm.com
Subject: Re: [PATCH 0/3] arm64: dts: qcom: monaco: Enable SDHCI storage support
Date: Mon, 2 Mar 2026 20:07:23 +0530	[thread overview]
Message-ID: <aaWgo/FYDhCVvaX/@hu-mchunara-hyd.qualcomm.com> (raw)
In-Reply-To: <ltuoonopd2fmxhxnfmezflwqicyagha3jchxl3inputbtnpvhm@gsgnsccr62pk>

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

  reply	other threads:[~2026-03-02 14:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-27 10:50 [PATCH 0/3] arm64: dts: qcom: monaco: Enable SDHCI storage support Monish Chunara
2026-02-27 10:50 ` [PATCH 1/3] arm64: dts: qcom: monaco: Move eMMC CQE support from SoC to board DT Monish Chunara
2026-02-27 20:05   ` Dmitry Baryshkov
2026-02-27 10:50 ` [PATCH 2/3] arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay Monish Chunara
2026-02-27 20:03   ` Dmitry Baryshkov
2026-03-02 14:24     ` Monish Chunara
2026-03-23 14:15       ` Konrad Dybcio
2026-06-16 12:30         ` Monish Chunara
2026-06-16 13:01           ` Konrad Dybcio
2026-02-27 10:50 ` [PATCH 3/3] arm64: dts: qcom: monaco-evk: Add SDHCI support for eMMC " Monish Chunara
2026-02-27 20:05 ` [PATCH 0/3] arm64: dts: qcom: monaco: Enable SDHCI storage support Dmitry Baryshkov
2026-03-02 14:37   ` Monish Chunara [this message]
2026-03-02 14:47     ` Dmitry Baryshkov
2026-03-02 15:05       ` Monish Chunara
2026-03-05  4:51         ` Dmitry Baryshkov
2026-06-16 12:32           ` Monish Chunara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aaWgo/FYDhCVvaX/@hu-mchunara-hyd.qualcomm.com \
    --to=monish.chunara@oss.qualcomm.com \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=nitin.rawat@oss.qualcomm.com \
    --cc=pradeep.pragallapati@oss.qualcomm.com \
    --cc=robh@kernel.org \
    --cc=sarthak.garg@oss.qualcomm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox