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

[Dragan Simic]

On 2024-02-05 14:45, Quentin Schulz wrote:
> On 2/5/24 14:40, Dragan Simic wrote:
>> On 2024-02-05 14:24, Jonas Karlman wrote:
>>> On 2024-02-05 10:40, Quentin Schulz wrote:
>>>> Shouldn't we also remove cap-mmc-highspeed?
>>>> 
>>>> I assume this is for MMC_HS? Which we discovered doesn't work
>>>> reliably?
>>> 
>>> Writing in lower speeds on RK356x does work better then on RK3588,
>>> however HS200 still seem to be more reliable overall and give more
>>> speed.
>>> 
>>> For RK3588 they could possible be removed, but since reading does 
>>> work
>>> and similar issue also existed in the fallback MMC legacy mode, I did
>>> not see that cleanup as important, or maybe more correctly it did not
>>> cross my mind to also remove these props :-), the fully broken ddr52
>>> felt more important.
>>> 
>>>> Since it could be in a different patch if you wanted to, for the
>>>> changes in this patch:
>>> 
>>> Agree, a possible cleanup of cap-mmc-highspeed props could be done in 
>>> a
>>> separate patch.
>>> 
>>> Alternatively any missing and appropriate modes currently in
>>> u-boot.dtsi
>>> should be added to linux DT and they can then be synced back to 
>>> U-Boot
>>> and any override/addition dropped from u-boot.dtsi files.
>> 
>> How about waiting until I fix the mode selection in the Linux kernel
>> drivers?  As I noted already, that's already on my TODO list, and
>> perhaps it would be good to test a bit again under Linux with those
>> fixes applied, before actually removing the buggy modes from the
>> kernel's RK356x and RK3588(s) SoC dtsi files.
> 
> While I appreciate there's some work that can be done in the Linux
> kernel for those low-speed modes, the properties in question are
> removed only from U-Boot's DTS and your future patches for the kernel
> wouldn't impact the bootloader anyway.
> 
> The issue right now is that U-Boot is currently broken because of
> those properties, which are only in U-Boot's DTS.
> 
> Not sure exactly why we should waiting on Linux kernel patches for
> merging work-arounds for U-Boot? What exactly are you suggesting we
> wait for? What can improve the situation?

Ah, sorry for the confusion, let me clarify a bit...

I just replied to the Jonas's remark about the need to eventually
have the same fixes and mode removals in the Linux kernel's SoC dtsi
files.  In other words, all I wrote was about those changes, not
about the changes on the U-Boot side.

Of course, there are no reasons for delaying these U-Boot fixes.