Hi Quentin,
On 10/12/2026 6:11 PM, Quentin Schulz wrote:
> Hi Jonas,
>
> On 10/12/26 1:15 PM, Jonas Karlman wrote:
>> The RK35xx clock drivers typically initializes a few clocks when probed,
>> with some clocks only in SPL. However, the clock driver is only probed
>> on demand, so this initialization is fully skipped when no SPL consumer
>> requests a clock, e.g. when booting from RAM/USB.
>>
>> Prior to the commit c6bba31dbdd4 ("rockchip: spl-boot-order: Defer probe
>> of boot device") all boot devices where typically probed, with a side
>> effect that clock driver likely also where probed, prior to the SPL
>> boot_from_devices() call.
>>
>> This series flag RK35xx clock drivers to be probed after bind in SPL to
>> help ensure a deterministic probe and clock initialization behavior
>> prior to booting from devices.
>>
>> This should help restore old behavior, e.g. that SPLL is initialized on
>> RK3588 and CPU core rate is initialized on RK3576 when booting from
>> RAM/USB.
>>
>> The series may possible depend on the series "rockchip: Miscellaneous
>> RK35xx clock fixes" [1] for a clean apply.
>>
>> Changes in v2:
>> - Update cover letter and commit messages
>> - Collect r-b and t-b tags
>>
>> [1] https://patch.msgid.link/[email protected]/
>>
>> Jonas Karlman (4):
>> clk: rockchip: rk3568: Always initialize clocks in SPL
>> clk: rockchip: rk3588: Always initialize clocks in SPL
>> clk: rockchip: rk3576: Always initialize clocks in SPL
>> clk: rockchip: rk3528: Always initialize clocks in SPL
>>
>
> The RK3506 clock driver is notably missing from this list of "RK35xx
> clock drivers". I'm assuming this is because support for the RK3506
> clock driver got merged after commit c6bba31dbdd4 ("rockchip:
> spl-boot-order: Defer probe of boot device"), so it means if it's
> broken, it just never worked in the first place and we should rather dig
> into the problem instead of doing what we do for the other RK35xx SoCs,
> was this your conclusion as well or did I just incorrectly extrapolate?
The RK3506 clock driver currently initialize a few clocks from bind()
in XPL :-S
So it is not affected, or rather it worked around the issue for USB/RAM
boot in a different way. Should probably have mentioned something about
the RK3506 situation in cover letter.
In my work-in-progress branch at [1] I have a "WIP: clk: rockchip:
rk3506: Rework early clock init" commit that re-work that clock init to
use similar probe-after-bind style. I likely just deferred rk3506 for a
future refactor series as it was already "working" and the diff to
change it was very different to the patches in this series.
[1]
https://git.u-boot-project.org/u-boot/contributors/kwiboo/u-boot/-/commits/rk3562/drivers/clk/rockchip/clk_rk3506.c
Regards,
Jonas
>
> Cheers,
> Quentin
