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.