On 8/21/2026 1:38 PM, [email protected] wrote:
From: Tze Yee Ng <[email protected]>
After reprogramming the PHY and releasing the DLL reset, the PHY/DLL
needs time to relock before the first data transfer is issued.
Add a 5ms settle delay at the end of sdhci_cdns6_phy_adj().
Fixes: fe11aa0b8ca3 ("mmc: sdhci-cadence: Add support for Cadence sdmmc v6")
Signed-off-by: Tze Yee Ng <[email protected]>
---
drivers/mmc/sdhci-cadence6.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/mmc/sdhci-cadence6.c b/drivers/mmc/sdhci-cadence6.c
index 93cb19ecaaf..407eae96dd4 100644
--- a/drivers/mmc/sdhci-cadence6.c
+++ b/drivers/mmc/sdhci-cadence6.c
@@ -11,6 +11,7 @@
#include <linux/bitfield.h>
#include <linux/bitops.h>
#include <linux/bug.h>
+#include <linux/delay.h>
#include <linux/io.h>
#include <linux/iopoll.h>
#include <linux/sizes.h>
@@ -302,6 +303,17 @@ int sdhci_cdns6_phy_adj(struct udevice *dev, struct
sdhci_cdns_plat *plat, u32 m
/* Set HRS07 register */
writel(sdhci_cdns6_ctrl_cfgs[3].val, plat->hrs_addr + SDHCI_CDNS_HRS07);
+ /*
+ * Wait for the PHY/DLL to settle before the first data transfer.
+ * The HRS09.PHY_INIT_COMPLETE handshake polled above only covers DLL
+ * relock, not the analog read/write path retiming that follows a
+ * timing change. Without this extra settle (together with the HRS05
+ * posted-write flush in sdhci_cdns6_write_phy_reg()) the first
Did you still see the DDR50 CRC with mdelay(5) and without patch 1?
+ * transfer after a DDR50 mode switch intermittently returns a CRC
+ * error.
+ */
+ mdelay(5);
+
Where does 5 ms come from? A delay sweep on the board, or the Linux
usleep_range(5000, 5500)? Did you try other delays on U-Boot (1 ms /
2 ms / 10 ms, …) and see when it starts passing?
