AM6442: eMMC register configurations for various speed modes

Hi Tashiro-san,

I will review the information and get back to you in a few days.

Hi Tashiro-san,

Koichiro Tashiro said:

When HS200 is disabled and High Speed DDR is configured, MMCSD0_SS_PHY_CTRL_4_REG @ 0x0FA1810C value is 0x00106000.
But according to datasheet table 7-66, the value should be 0x00106103.

It appears the MMC driver has a bug which has been fixed in SDK8.6 kernel.

Can you please ask the customer to test the SDK8.6 kernel, or apply the following patch to the SDK8.4 kernel (I just created the patch from SDK8.6 kernel, but didn't test it with SDK8.4 kernel though).

From 9c878c3dc642f7f1f3ab6ca7f812cd43fe7ed7d8 Mon Sep 17 00:00:00 2001
From: Nitin Yadav <n-yadav@ti.com>
Date: Mon, 28 Nov 2022 16:25:37 +0530
Subject: [PATCH] drivers: mmc: host: sdhci_am654: update OTAP and ITAP delay

Linux is fail to detect class U1 UHS SD cards (such as microcenter)
due to incorrect OTAP and ITAP delay select values. Update OTAP and
ITAP delay select values and masks based on recommeded RIOT values.

Signed-off-by: Nitin Yadav <n-yadav@ti.com>
---
 drivers/mmc/host/sdhci_am654.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c
index 41d409553aaa..96dd86efea9e 100644
--- a/drivers/mmc/host/sdhci_am654.c
+++ b/drivers/mmc/host/sdhci_am654.c
@@ -310,6 +310,7 @@ static void sdhci_j721e_4bit_set_clock(struct sdhci_host *host,
 	struct sdhci_am654_data *sdhci_am654 = sdhci_pltfm_priv(pltfm_host);
 	unsigned char timing = host->mmc->ios.timing;
 	u32 otap_del_sel;
+	u32 itap_del_sel;
 	u32 mask, val;
 
 	/* Setup DLL Output TAP delay */
@@ -321,7 +322,14 @@ static void sdhci_j721e_4bit_set_clock(struct sdhci_host *host,
 	mask = OTAPDLYENA_MASK | OTAPDLYSEL_MASK;
 	val = (0x1 << OTAPDLYENA_SHIFT) |
 	      (otap_del_sel << OTAPDLYSEL_SHIFT);
+
+	itap_del_sel = sdhci_am654->itap_del_sel[timing];
+	mask |= ITAPDLYSEL_MASK | ITAPDLYENA_MASK;
+	val |= (1 << ITAPDLYENA_SHIFT) | (itap_del_sel << ITAPDLYSEL_SHIFT);
+	regmap_update_bits(sdhci_am654->base, PHY_CTRL4, ITAPCHGWIN_MASK,
+			   1 << ITAPCHGWIN_SHIFT);
 	regmap_update_bits(sdhci_am654->base, PHY_CTRL4, mask, val);
+	regmap_update_bits(sdhci_am654->base, PHY_CTRL4, ITAPCHGWIN_MASK, 0);
 
 	regmap_update_bits(sdhci_am654->base, PHY_CTRL5, CLKBUFSEL_MASK,
 			   sdhci_am654->clkbuf_sel);
-- 
2.34.1

Hi Bin,

The customer tried the patch on SDK8.4, but it does not help.
They also tried SDK8.6 kernel on AM64xevm and confirm the issue exists.
Did you confirm the register values are ok with SDK8.6?

Thanks and regards,
Koichiro Tashiro

Hi Bin,

Could you reply to above questions?
This item is the one of top priority items at the customer.

Thanks and regards,
Koichiro Tashiro

Hi Bin,

I think the question itself is not difficult to answer if the bug was understood and fixed in SDK8.6.
When you can provide the answer?

Thanks and regards,
Koichiro Tashiro

Hi Tashiro-san,

Sorry for my late response.

I believe I checked the register value in SDK8.6 some time ago and it is correct. I will double check it again tomorrow morning and let you know.

Hi Tashiro-San,

I was having hardware setup issue. I will continue working on this on Tuesday.

Hi Tashiro-san,

Koichiro Tashiro said:

When HS200 is disabled and High Speed DDR is configured, MMCSD0_SS_PHY_CTRL_4_REG @ 0x0FA1810C value is 0x00106000.
But according to datasheet table 7-66, the value should be 0x00106103.

I believe the reason is that the ITAPDELAY values are not specified in kernel device tree, there is no ti,itap-del-sel-* properties in sdhci0 and sdhci1 nodes in k3-am64-main.dtsi. I have asked our sw dev team why the ITAPDELAY values are not defined in kernel device tree, and will update once I get a response.

Hi Bin,

Did you get feedback from software team?

I guess the ITAPDELAY values need to be configured properly.
What would be the solution?

Thanks and regards,
Koichiro Tashiro

Hi Tashiro,

The software team likely won't be able to look into this after the SDK9.0 release, so I updated the kernel device tree based on the TAP DELAY data in the AM64x Datasheet, please share the patch below with the customer:

diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index d273a9988056..22d08e53a8df 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -472,6 +472,9 @@ sdhci0: mmc@fa10000 {
                ti,otap-del-sel-mmc-hs = <0x0>;
                ti,otap-del-sel-ddr52 = <0x6>;
                ti,otap-del-sel-hs200 = <0x7>;
+               ti,itap-del-sel-legacy = <0x10>;
+               ti,itap-del-sel-mmc-hs = <0xa>;
+               ti,itap-del-sel-ddr52 = <0x3>;
        };
 
        sdhci1: mmc@fa00000 {
@@ -483,12 +486,16 @@ sdhci1: mmc@fa00000 {
                clock-names = "clk_ahb", "clk_xin";
                ti,trm-icp = <0x2>;
                ti,otap-del-sel-legacy = <0x0>;
-               ti,otap-del-sel-sd-hs = <0xf>;
+               ti,otap-del-sel-sd-hs = <0x0>;
                ti,otap-del-sel-sdr12 = <0xf>;
                ti,otap-del-sel-sdr25 = <0xf>;
                ti,otap-del-sel-sdr50 = <0xc>;
                ti,otap-del-sel-sdr104 = <0x6>;
                ti,otap-del-sel-ddr50 = <0x9>;
+               ti,itap-del-sel-legacy = <0x0>;
+               ti,itap-del-sel-sd-hs = <0x0>;
+               ti,itap-del-sel-sdr12 = <0x0>;
+               ti,itap-del-sel-sdr25 = <0x0>;
                ti,clkbuf-sel = <0x7>;
        };

Hi Bin,

Thanks!
Could you confirm below points?
1) Which SDK version the patch works for? SDK8.6?
2) Did you check it works on TI EVM?

Thanks and regards,
Koichiro Tashiro

Hi Tashiro-san,

Koichiro Tashiro said:

1) Which SDK version the patch works for? SDK8.6?

Yes.

Koichiro Tashiro said:

2) Did you check it works on TI EVM?

I didn't have time yesterday to test this device tree patch on the EVM. However, while testing it today, I discovered a kernel MMC driver bug which would prevent the 8-bit eMMC ITAP delay to be programmed property to PHY_CTRL4 register, even with this device tree patch defining the ITAP delay values.

The new driver bug is similar to the one fixed by the kernel patch I shared on May 1 above. But that kernel patch only fixes the issue for 4-bit mode (mainly for SD cards), but not for 8-bit mode (which eMMC mainly uses).

I have reported the driver bug to our software dev team. I will keep you posted.

Hi Bin,

Bin Liu said:

I have reported the driver bug to our software dev team.

If the new bug is the similar to the previous one, could you give me the patch to fix it?
As you know, the customer has a few issues related to eMMC, I would like to check these issues are related to this register configuration mismatch.

Thanks and regards,
Koichiro Tashiro

Hi Bin,

Could you reply to this item?

Thanks and regards,
Koichiro Tashiro

Hi Tashiro-san,

Fixing the 8-bit mode ITAP delay setting is in a separate driver function. Touching it would affect other use cases, a thorough test is requires to ensure the patch doesn't break anything else. So the patch should come from the sw dev team, not me. I will let you know when the patch is available.

Hi Bin,

I see. Please inform me when the patch will be available.

Thanks and regards,
Koichiro Tashiro

Hi Bin,

Could you let me know when the patch will be released?
The customer wants to get the patch next week.

Thanks and regards,
Koichiro Tashiro

Hi Tashiro-san,

Sorry for the delay. I just pinged the dev team for an update. I will let you know once I heard back.

Hi Bin,

I saw some activities on JIRA, but it is not clear when it will be fixed.
The customer is very frustrated with no response from TI.
Can you get any fix schedule at least?

Thanks and regards,
Koichiro Tashiro

Hi Tashiro-san,

We should expect the fix patch in a week or two.

Hello Tashiro,

Just giving you a status update while Bin is away. The driver team is currently evaluating a fix that may affect multiple platforms so it sounds like it'll be another week or two for further testing. If they are done early we will update the ticket accordingly.

Regards,

Randolph

Hi Tashiro-san,

Please ask the customer to test the kernel patch attached below. It has been validated on AM64x SDK8.6 kernel.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0001_2D00_Fix_2D00_eMMc_2D00_ITAP_2D00_Values_2D00_issue.patch

Hi Bin,

Thanks for the patch! I let the customer check it.

When it will be officially released?

Thanks and regards,
Koichiro Tashiro

Hi Tashiro-san,

It should be integrated in SDK 9.1.

Hi Bin,

When SDK9.1 will be released?

Thanks and regards,
Koichiro Tashiro

December 15.

Hi Bin,

The customer tested the patch with all SD and eMMC speed configurations.
Please see attached excel.
patch results.xlsx
As you can see, now ITAPDLYSEL for all eMMC modes are corrected.
But SELDLYTXCLK, SELDLYRXCLK and FREQSEL for "High Speed DDR" are still incorrect.

For SD card, OTAPDLYENA and OTAPDLYSEL for "High Speed" and "Default Speed" are incorrect.

Thanks and regards,
Koichiro Tashiro

Hey Koichiro,

Just updating this ticket to say we've passed this info along to the development team.

Regards,

Randolph

Hi Tashiro-san,

Koichiro Tashiro said:

But SELDLYTXCLK, SELDLYRXCLK and FREQSEL for "High Speed DDR" are still incorrect.

Sorry for the delay. The kernel DT patch below should fix this issue.

diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index ac7b2b061680..4b62deb34225 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -480,6 +480,7 @@ sdhci0: mmc@fa10000 {
                ti,otap-del-sel-mmc-hs = <0x0>;
                ti,otap-del-sel-ddr52 = <0x6>;
                ti,otap-del-sel-hs200 = <0x7>;
+               ti,clkbuf-sel = <0x7>;
        };

        sdhci1: mmc@fa00000 {

Koichiro Tashiro said:

For SD card, OTAPDLYENA and OTAPDLYSEL for "High Speed" and "Default Speed" are incorrect.

The Datasheet will be updated. OTAPDLYENA should be '1' for all modes.

Hi Bin,

Thanks for updates.

Bin Liu said:

The Datasheet will be updated. OTAPDLYENA should be '1' for all modes.

How about OTAPDLYSEL value for High speed? It is 0x0 in datasheet, but configured value is 0xf.

Thanks and regards,
Koichiro Tashiro

Hi Tashiro-san,

Does the customer still test with SDK8.6?

I don't see 0xf on my EVM with SDK8.6:

root@am64xx-evm:~# devmem2 0x0fa0810c w
/dev/mem opened.
Memory mapped at address 0xffffb1e19000.
Read at address  0x0FA0810C (0xffffb1e1910c): 0x00100100

root@am64xx-evm:~# dmesg|grep mmc1
[    3.644421] vdd_mmc1: supplied by vsys_3v3
[    3.656884] mmc1: CQHCI version 5.10
[    3.708526] mmc1: SDHCI controller on fa00000.mmc [fa00000.mmc] using ADMA 64-bit
[    3.756477] mmc1: new high speed SDHC card at address aaaa
[    3.762869] mmcblk1: mmc1:aaaa SC16G 14.8 GiB

Hi Bin,

I see. The customer still see 0xf on their board.
They will check it on TI EVM.
BTW, did you use the board with silicon revision 2(SR2), correct?

Thanks and regards,
Koichiro Tashiro

Yes, I use the GPEVM with SR2.0:

U-Boot 2021.01-g2ee8efd654 (Feb 27 2023 - 13:48:24 +0000)

SoC:   AM64X SR2.0 HS-FS
Model: Texas Instruments AM642 EVM
Board: AM64-EVM rev C

Hi Bin,

The customer also tried with SDK8.6 on TI EVM, but they saw 0xf.

[    2.745151] mmc0: SD Debug
[    2.747868] mmc0: [0x0FA0810C] = 0x0010f100
[    2.752055] mmc0: [0x0FA08110] = 0x00000007

Hi Tashiro-san,

I will validate this later this week on a fresh SDK 8.6 kernel branch to ensure we are on the same page.

Hi Bin,

Could you update the validation result on your side?
And please provide your device tree, too. The customer wants to try the same settings.

Thanks and regards,
Koichiro Tashiro

Hi Bin,

The customer confirmed the issue is solved on their side.
Thanks a lot for your long support on this!

Bin Liu said:

I will submit a sw ticket to get it corrected:

Yes. Please make sure the fix will be applied to an official SDK, too.

Thanks and regards,
Koichiro Tashiro

Hi Tashiro-san,

Thanks for confirming.

Yes, the ticket LCPD-36868 has been submitted yesterday to track this issue.