[PATCH 1/3] rockchip: rk35xx: Remove use of eMMC DDR52 mode

[Jonas Karlman]

Hi Quentin,

On 2024-02-01 13:40, Quentin Schulz wrote:
> Hi Jonas,
> 
> On 2/1/24 11:51, Jonas Karlman wrote:
>> Hi Quentin,
>>
>> On 2024-02-01 11:18, Quentin Schulz wrote:
>>> Hi Jonas,
>>>
>>> On 1/27/24 12:15, Jonas Karlman wrote:
>>>> Hi Eugen,
>>>>
>>>> On 2024-01-27 04:48, Eugen Hristev wrote:
>>>>> Hi Jonas,
>>>>>
>>>>>
>>>>> On 1/27/24 01:26, Jonas Karlman wrote:
>>>>>> Writing to eMMC using DDR52 mode does not work reliably or at all on
>>>>>> RK356x and RK3588 boards.
>>>>>>
>>>>>
>>>>>
>>>>> This is related to the old issue I encountered last year with mmc write?
>>>>
>>>> Yes, I think it is.
>>>>
>>>> I did some testing on RK3566/RK3568/RK3588S/RK3588 boards with different
>>>> eMMC modules with following result:
>>>>
>>>> Read seem to work with all enabled modes:
>>>> RK3566: MMC legacy, MMC High Speed (26MHz), MMC High Speed (52MHz),
>>>>           MMC DDR52 (52MHz) and HS200 (200MHz)
>>>> RK3568/RK3588S/RK3588: all above + HS400 (200MHz) and HS400ES (200MHz)
>>>>
>>>> However, write had issues with some of the modes:
>>>> MMC DDR52 (52MHz): all RK35xx
>>>> HS400/HS400ES: only on RK3568 after changing hs400_txclk_tapnum to 8
>>>>
>>>> HS200 seem to be the most stable write speed that worked on all SoCs.
>>>>
>>>> So, dropping MMC DDR52 (52MHz) and enable use of HS200 (200MHz) seem to
>>>> be the best option to get speedy and working read and write eMMC.
>>>>
>>>
>>> 1) we have this enabled on RK3588 Jaguar in upstream Linux... I may have
>>> improperly tested it then, would you mind sharing how you tested this
>>> mode on RK3588 so I can reproduce this and fix it on our product if
>>> we're impacted? I assume because we have HS200/HS400/HS400-ES enabled,
>>> DDR52 would never be used? (our eMMC is soldered and support the former
>>> modes).
>>
>> My main mode of testing eMMC in U-Boot has been to enable following
>> Kconfig options,
>>
>> CONFIG_MMC_HS200_SUPPORT=y
>> CONFIG_MMC_HS400_SUPPORT=y
>> CONFIG_MMC_HS400_ES_SUPPORT=y
>> CONFIG_MMC_SPEED_MODE_SET=y
>>
>> and from U-Boot cli run following,
>>
>> => mmc rescan <mode> && mmc info && mmc read 10000000 2000 10000
>> => mmc rescan <mode> && mmc info && mmc write 20000000 4000 10000
>>
>> for each of the modes below.
>>
>>    0 = MMC legacy
>>    1 = MMC High Speed (26MHz)
>>    3 = MMC High Speed (52MHz)
>>    4 = MMC DDR52 (52MHz)
>>    10 = HS200 (200MHz)
>>    11 = HS400 (200MHz)
>>    12 = HS400ES (200MHz)
>>
>> on different boards and different eMMC modules.
>>
>> Using some modes the read or write return ERROR instead of OK. When
>> ERROR was reported a rescan or board reset was needed to test next mode.
>>
>> Please also note that I have only tested in U-Boot, not in linux.
>>
> 
> Thanks for the tips on how to test these.
> 
> I have run the following commands on an RK3588 Jaguar (master branch + 
> your v6.8-rc1 DTS sync patch series + Jaguar patch series):
> 
> => for j in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19; do for i 
> in 0 1 3 4 10 11 12; do mmc rescan $i && mmc read 10000000 2000 100000; 
> if test $? -ne 0; then echo $i FAILED; fi; done; done
> 
> Which is 20 iterations of an mmc read at each of the 7 supported modes. 
> The result is:
> 1 fail in HS200, 2 fails in HS400, the rest passes just fine.

I am wondering if your HS200 fails could be because MMC DDR52 (52MHz)
was being tested prior to the HS200 mode.

What happens if you exclude the mmc-ddr-1_8v prop and mode 4 in your
test loops?

I did some quick re-test on a ROCK 5A (rk3588s) and ROCK 5B (rk3588)
with DDR52 removed and could only see very few read fails with HS400.

> 
> => for j in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19; do for i 
> in 0 1 3 4 10 11 12; do mmc rescan $i && mmc write 20000000 4000 100000; 
> if test $? -ne 0; then echo $i FAILED; fi; done; done
> 
> Which is 20 iterations of an mmc write at each of the 7 supported modes. 
> The result is:
> 20 fails in DDR52, 2 fails in HS200, the rest passes just fine.
> 
> So it seems DDR52, HS200 and HS400 aren't stable on my board, but 
> HS400ES somehow is (which is enabled in our defconfig).

Please re-test with DDR52 mode skipped and see if you get any other
result for HS200 mode.

And you are correct, HR400ES seem to also be working fine on my RK3588
boards. I can see now that on my old testing commit [1] I only mention
and drop the hs400 mode and not the hs400es mode for rk3588. Could also
be the change to emmc_data_strobe pinctrl that got synced from linux
v6.7 that help improve HR400ES mode results.

>From a very quick re-test on two boards with two different emmc modules
I could only see a few "Select HS400 failed -70" lines being reported
when testing read and/or write using your test loops (with a few modes
skipped and smaller amount of data to read/write). Remaining modes seem
to be working okay.

[1] https://github.com/Kwiboo/u-boot-rockchip/commit/cb1521aea8dee730bddcc5772afa28aa71fc69f9
[2] https://lore.kernel.org/all/20231205202900.4617-2-CFSworks@gmail.com/

Regards,
Jonas

> 
> I'll check if there's an easier way to test the Linux kernel than 
> rebooting with a newer DTB between every try.
> 
> Cheers,
> Quentin
> 
>>>
>>> 2) Why are we not enabling HS400/HS400-ES for RK3588 boards? You seem to
>>> be saying there are issues with HS400/HS400-ES on RK3568 but you didn't
>>> mention the status for RK3588. Did I misunderstand the last sentence?
>>> Can you please rephrase in that case?
>>
>> I can see now that my wording was very confusing.
>>
>> Write for HS400/HS400ES mode only worked on RK3568 after modification to
>> the driver, on RK3588 write always returned error for me.
>>
>> So on RK3568 HS400 modes could be made work, on remaining SoCs there was
>> issues.
>>
>> Regards,
>> Jonas
>>
>>>
>>> Cheers,
>>> Quentin
>>