Hi Quentin,
On 10/12/2026 6:00 PM, Quentin Schulz wrote:
> Hi Jonas,
>
> On 10/12/26 1:15 PM, Jonas Karlman wrote:
>> The RK3568 clock driver initializes ACLK_BUS to 150 MHz when probed in
>> SPL. However, the driver is only probed on demand, so this
>> initialization is 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
>> boot_from_devices() call.
>>
>> Flag the clock driver to be probed after bind in SPL to help ensure a
>> deterministic probe and clock initialization behavior prior to booting
>> from devices.
>>
>> Signed-off-by: Jonas Karlman <[email protected]>
>> Reviewed-by: Simon Glass <[email protected]>
>> ---
>> Changes in v2:
>> - Update commit message
>> - Collect r-b tag
>> ---
>> drivers/clk/rockchip/clk_rk3568.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/clk/rockchip/clk_rk3568.c
>> b/drivers/clk/rockchip/clk_rk3568.c
>> index 9f3e9322161e..5a05f1b4de00 100644
>> --- a/drivers/clk/rockchip/clk_rk3568.c
>> +++ b/drivers/clk/rockchip/clk_rk3568.c
>> @@ -2934,6 +2934,10 @@ static int rk3568_clk_bind(struct udevice *dev)
>> struct udevice *sys_child;
>> struct sysreset_reg *priv;
>>
>> + /* Ensure clocks are initialized after bind in SPL build */
>> + if (IS_ENABLED(CONFIG_SPL_BUILD))
>> + dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND);
>> +
>
> There's pmucru in this driver as well, shouldn't we also probe it after
> bind? Or how did you decide only the cru driver should be probed after
> bind and not pmucru?
Good catch, I am not sure if I decided to exclude it or just missed it.
Looking at the the code and DT references I do not think we need to
probe pmucru other than to be consistent, at first glance it looks to be
related to video and pcie. It most likely was not probed until U-Boot
proper, but will look closer and run some tests.
> As a general note for the commit log in v2, they are good enough for me.
> It clearly states we go back to what we used to do as a stop-gap measure
> to fix various issues we hadn't when we used to probe all boot devices,
> and hopefully we'll fix this properly once we know better. I don't
> really like it, but I think it's reasonable.
Fully agree. At this time I cannot see how we can solve this more
properly but as you mention hopefully we will know better in future :-)
Regards,
Jonas
>
> Cheers,
> Quentin
