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.
next prev parent reply other threads:[~2026-11-15 14:51 UTC|newest]
Thread overview: 7+ 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-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
all inboxes | Powered by JetHome®