Devicetree
 help / color / mirror / Atom feed
From: "Kathpalia, Tanmay" <tanmay.kathpalia@altera.com>
To: tze.yee.ng@altera.com, Adrian Hunter <adrian.hunter@intel.com>,
	linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	devicetree@vger.kernel.org, Ulf Hansson <ulfh@kernel.org>
Subject: Re: [PATCH v3 2/4] mmc: sdhci-cadence6: program PHONY_DQS_TIMING for extended-read DDR
Date: Sun, 15 Nov 2026 20:21:26 +0530	[thread overview]
Message-ID: <da0da5ca-164e-45cf-8921-598d67d6a42b@altera.com> (raw)
In-Reply-To: <20261106-sd_cadence_ddr50_v3-v3-2-cb50afece614@altera.com>


On 06-11-2026 11:46, tze.yee.ng@altera.com wrote:
> From: Tze Yee Ng <tze.yee.ng@altera.com>
>
> The SD6HC PHY left PHONY_DQS_TIMING (phy_ctrl_reg[9:4]) at 0 in all
> modes. Per the Cadence DLL PHY documentation it must be the rebar (RE#)
> pulse width in clk_phy cycles minus 1 in extended read mode, and 0
> otherwise. Leaving it 0 in extended-read DDR duplicates one DDR edge
> (the silent odd/even edge-capture defect).
>
> On this integration the rebar pulse is 2 clk_phy cycles, so extended-

In the U-Boot thread you said this width is documented in the Cadence 
SD/eMMC DFI spec; in v1 here
you said there is no IP-level document. Which is it? If documented, 
please cite it here and in the
macro comment. If it is Agilex5-specific, please take it from the 
altr,agilex5-sd6hc match data
instead of a constant for every cdns,sd6hc user.

> read DDR needs 1; confirmed on DDR50 hardware (1 captures both beats, 2

In v1 you confirmed DDR52 was validated too and said you would name both 
modes.

> corrupts reads). Derive it from the extended-read-mode state and apply
> it only in DDR modes, since SDR extended-read samples a single edge and
> is unaffected.

In v1 you agreed this is not proof ("Agreed the single-edge argument 
alone is not proof") and kept
these modes at 0 because they pass there. On 5 Nov, in the U-Boot 
thread, you wrote the opposite
rule: by the PHY guide the value "is 1 in extended-read mode and 0 
otherwise", and U-Boot v2 does
set 1 for the divided SDR modes. This patch still leaves them at 0, so 
the two trees disagree. The
PHY guide is not limited to DDR: 0 when extended read is off, and the 
rebar width minus 1 when it
is on. With the rebar width of 2, that is 1 in every extended-read mode. 
Please program 1 in these
modes here as well.

>
> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
> ---
> Changes in v3:
> - No change; retains Adrian's Acked-by.
>
> Changes in v2:
> - Added Adrian's Acked-by.
> - Reworded the commit message to drop the "generic to any SD6HC-PHY SoC"
>    framing. (Adrian Hunter)
> ---
>   drivers/mmc/host/sdhci-cadence-phy-v6.c | 15 +++++++++++++++
>   1 file changed, 15 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-cadence-phy-v6.c b/drivers/mmc/host/sdhci-cadence-phy-v6.c
> index 22d56bb46d75..8d6a9c26c139 100644
> --- a/drivers/mmc/host/sdhci-cadence-phy-v6.c
> +++ b/drivers/mmc/host/sdhci-cadence-phy-v6.c
> @@ -90,6 +90,9 @@
>   #define SDHCI_CDNS6_PHY_CTRL_REG			0x2080
>   #define   SDHCI_CDNS6_PHY_CTRL_PHONY_DQS_TIMING			GENMASK(9, 4)
>   
> +/* Width of this controller's rebar (RE#) pulse in clk_phy cycles. */
> +#define SDHCI_CDNS6_PHY_REBAR_PULSE_CYCLES	2
> +

The commit says "this integration", the comment says "this controller". 
Please make them match,
with a source (see above).

>   /* Default PHY settings */
>   #define SDHCI_CDNS6_PHY_DEFAULT_IOCELL_DELAY		2500
>   #define SDHCI_CDNS6_PHY_DEFAULT_DELAY_ELEMENT		24
> @@ -143,6 +146,9 @@ struct sdhci_cdns6_phy {
>   	bool cp_use_phony_dqs;		/* bit [20] */
>   	bool cp_use_phony_dqs_cmd;	/* bit [19] */
>   
> +	/* PHY_CTRL register fields */
> +	u32 cp_phony_dqs_timing;
> +

u8 with /* bits [9:4] */, similar to the other cp_* fields.

>   	/* HRS07 register - IO delay Information */
>   	u8 sdhc_rw_compensate;		/* bits [20:16] */
>   	u8 sdhc_idelay_val;		/* bits [4:0] */
> @@ -517,6 +523,13 @@ static void sdhci_cdns6_phy_calc_dat_in(struct sdhci_cdns6_phy *phy)
>   	if (phy->mode == MMC_TIMING_MMC_HS200)
>   		phy->cp_read_dqs_delay = phy->hs200_tune_val;
>   
> +	if (phy->sdhc_extended_rd_mode &&
> +	    (phy->mode == MMC_TIMING_UHS_DDR50 ||
> +	     phy->mode == MMC_TIMING_MMC_DDR52))
> +		phy->cp_phony_dqs_timing = SDHCI_CDNS6_PHY_REBAR_PULSE_CYCLES - 1;
> +	else
> +		phy->cp_phony_dqs_timing = 0;
> +

The PHY guide asks for width - 1 whenever extended read is on, which 
here also covers DS/HS/SDR
modes. In U-Boot v2 you now do exactly that (1 in every extended-read 
mode), and said it matches
the Linux change, but this patch keeps those modes at 0. It's confusing, 
I would suggest to follow
the Cadence PHY user guide.

>   	if (strobe_dat) {
>   		/* dqs loopback input via IO cell */
>   		hcsdclkadj += phy->iocell_input_delay;
> @@ -715,6 +728,8 @@ int sdhci_cdns6_phy_init(struct sdhci_cdns_priv *priv)
>   
>   	reg = sdhci_cdns6_read_phy_reg(priv, SDHCI_CDNS6_PHY_CTRL_REG);
>   	reg &= ~SDHCI_CDNS6_PHY_CTRL_PHONY_DQS_TIMING;
> +	reg |= FIELD_PREP(SDHCI_CDNS6_PHY_CTRL_PHONY_DQS_TIMING,
> +			  phy->cp_phony_dqs_timing);

This write always runs with the loopback DQS selected. The setting you 
tested was the phony DQS
(use_lpbk_dqs = 0) and a read delay of 96. The PHY guide says this field 
times the phony strobe,
so with loopback it may change nothing. Does this patch by itself fix 
the bad reads on the
default loopback path? If not, please put it after patch 4, or merge it 
into patch 4.


  parent reply	other threads:[~2026-11-15 14:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06  6:16 [PATCH v3 0/4] mmc: sdhci-cadence: SD6HC DDR50/DDR52 read-path tuning and fixes tze.yee.ng
2026-11-06  6:16 ` [PATCH v3 1/4] mmc: sdhci-cadence: abort failed tuning command on SD6HC tze.yee.ng
2026-11-06  6:16 ` [PATCH v3 2/4] mmc: sdhci-cadence6: program PHONY_DQS_TIMING for extended-read DDR tze.yee.ng
2026-11-06  6:22   ` sashiko-bot
2026-11-15 14:51   ` Kathpalia, Tanmay [this message]
2026-11-06  6:16 ` [PATCH v3 3/4] dt-bindings: mmc: cdns,sd6hc: add SD6HC DDR50 read-path tuning tze.yee.ng
2026-11-06 12:40   ` Krzysztof Kozlowski
2026-11-06  6:16 ` [PATCH v3 4/4] mmc: sdhci-cadence6: read SD6HC DDR50 tuning from device tree tze.yee.ng

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=da0da5ca-164e-45cf-8921-598d67d6a42b@altera.com \
    --to=tanmay.kathpalia@altera.com \
    --cc=adrian.hunter@intel.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=tze.yee.ng@altera.com \
    --cc=ulfh@kernel.org \
    /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