On Tue, Jul 15, 2025 at 01:16:44PM +0200, Jonas Karlman wrote: >Hi Peng, > >On 7/15/2025 3:15 AM, Peng Fan wrote: >>> Subject: [PATCH v2] mmc: rockchip_sdhci: Set xx_TAP_VALUE for >>> RK3528 >>> >>> eMMC erase and write support on RK3528 is somewhat unreliable, >>> sometime e.g. mmc erase and write commands will fail with an error. >>> >>> Use the delay line lock value for half card clock cycle, >>> DLL_LOCK_VALUE, to set a manual xx_TAP_VALUE to fix the unreliable >>> eMMC support. >>> >>> This is only enabled for RK3528, remaining SoCs still use the automatic >>> tap value, (DLL_LOCK_VALUE * 2) % 256, same value we configure >>> manually for RK3528. >> >> May I ask how linux kernel handle this issue you spotted? > >I am not yet sure if or how this issue may be affecting Linux. > >This issue turned up when I was testing eMMC on my ArmSoM Sige1 board, >where a simple "mmc erase 40 5000" to remove an existing bootloader or >use "mmc write $fileaddr 40 5000" to write the new bootloader >unexpectedly resulted in an ERROR. > >When using the generic-rk3528 target (a minimal generic device tree) the >emmc module seems to initialize correctly: > > => mmc dev 0 > rk3568_sdhci_config_dll: clock=400000 enable=0 > rk3568_sdhci_config_dll: clock=400000 enable=1 > rk3568_sdhci_config_dll: clock=25000000 enable=0 > rk3568_sdhci_config_dll: clock=25000000 enable=1 > rk3568_sdhci_config_dll: clock=25000000 enable=0 > rk3568_sdhci_config_dll: clock=25000000 enable=1 > rk3568_sdhci_config_dll: clock=200000000 enable=0 > rk3568_sdhci_config_dll: clock=200000000 enable=1 > rk3568_sdhci_config_dll: dll_tap_value=2007600 DLL_LOCK_VALUE=3b > switch to partitions #0, OK > mmc0(part 0) is current device > => > >However when using a real device tree for the board the sdhci init seem >to sometime behave differently: > > => mmc dev 0 > rk3568_sdhci_config_dll: clock=400000 enable=0 > rk3568_sdhci_config_dll: clock=400000 enable=1 > rk3568_sdhci_config_dll: clock=25000000 enable=0 > rk3568_sdhci_config_dll: clock=25000000 enable=1 > rk3568_sdhci_config_dll: clock=25000000 enable=0 > rk3568_sdhci_config_dll: clock=25000000 enable=1 > rk3568_sdhci_config_dll: clock=200000000 enable=0 > rk3568_sdhci_config_dll: clock=200000000 enable=1 > rk3568_sdhci_config_dll: dll_tap_value=2007600 DLL_LOCK_VALUE=3b > rk3568_sdhci_config_dll: clock=25000000 enable=0 > rk3568_sdhci_config_dll: clock=25000000 enable=1 > rk3568_sdhci_config_dll: clock=25000000 enable=0 > rk3568_sdhci_config_dll: clock=25000000 enable=1 > rk3568_sdhci_config_dll: clock=25000000 enable=0 > rk3568_sdhci_config_dll: clock=25000000 enable=1 > rk3568_sdhci_config_dll: clock=200000000 enable=0 > rk3568_sdhci_config_dll: clock=200000000 enable=1 > rk3568_sdhci_config_dll: dll_tap_value=2007600 DLL_LOCK_VALUE=3b > rk3568_sdhci_config_dll: clock=25000000 enable=0 > rk3568_sdhci_config_dll: clock=25000000 enable=1 > rk3568_sdhci_config_dll: clock=25000000 enable=0 > rk3568_sdhci_config_dll: clock=25000000 enable=1 > rk3568_sdhci_config_dll: clock=25000000 enable=0 > rk3568_sdhci_config_dll: clock=25000000 enable=1 > rk3568_sdhci_config_dll: clock=25000000 enable=0 > rk3568_sdhci_config_dll: clock=25000000 enable=1 > rk3568_sdhci_config_dll: clock=25000000 enable=0 > rk3568_sdhci_config_dll: clock=25000000 enable=1 > rk3568_sdhci_config_dll: clock=52000000 enable=0 > rk3568_sdhci_config_dll: clock=52000000 enable=1 > switch to partitions #0, OK > mmc0(part 0) is current device > => > >or something similar could be observed. > >Please note that above code that is run print out the value that would >have been used for dll_tap_value but it never uses it to configure the >manual tap values. > >However when the dll_tap_value are used the initialization seem to be >back to working normally (single cycle) and erase/write starts working. > >Possible that some other underlying power, clock or timing issue is >causing this discrepancy. > >To my knowlede Linux is using interrups during sdhci card inizialization >compared to U-Boot, so Linux may not be affected of this issue. >
Thanks for explaining this. This patch is delegated to Kever who knows more on the SoC, so I will let him to decide. Thanks, Peng
