* Maxime Ripard <maxime@xxxxxxxxxx> [220407 13:43]:
> On Thu, Apr 07, 2022 at 02:08:05PM +0300, Tony Lindgren wrote:
> > It now boots, but does a lot of checks on the clocks before the timers
> > get initialized compared to v5.18-rc1.
>
> I was about to say that this is fairly normal with the new behaviour,
> but I've reworked the initial patch in that discussion to only call into
> clk_set_rate_range if there was a range on that clock to begin with.
>
> It should remove the huge majority of the checks you mentioned (and
> hopefully get rid of most of the side effects as well).
OK yeah thanks, looks good to me now. Boot time looks normal, timer clocks
are right, and runtime PM still works too.
> It shouldn't be there anymore after that rework, but I couldn't find
> wher the ssi_ssr_fck clock was defined? The only relevant driver seems
> to be omap_ssi_core.c but I don't see any clock driver registered there
> either.
I'm not seeing this warning any longer :)
FYI, this clock is defined here:
$ git grep ssi_ssr_fck_3430es2
arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi: ssi_ssr_fck: ssi_ssr_fck_3430es2 {
drivers/clk/ti/clk-3xxx.c: DT_CLK(NULL, "ssi_ssr_fck", "ssi_ssr_fck_3430es2"),
Yeah it's confusing, the clock is still created based on the node name.
I have some clean-up patches coming to fix most of the related make dtbs
checks warnings now that the clock driver changes got merged.
Regards,
Tony
