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?
Cheers, Quentin
