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.
