[PATCH v2] mmc: rockchip_sdhci: Set xx_TAP_VALUE for RK3528

[Peng Fan]

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