[PATCH v7 06/12] clk: Always set the rate on clk_set_range_rate

Stephen Boyd sboyd at kernel.org
Thu Mar 24 19:09:05 UTC 2022


Quoting Maxime Ripard (2022-03-23 01:51:40)
> Hi,
> 
> 
> The whole point of this patch is to give an opportunity to every driver
> to change the rate whenever the boundaries have changed, so we very much
> want to have the option to change it if clk_set_rate() has never been
> called.
> 
> However, I think the issue is why req_rate would be 0 in the first
> place?
> 
> req_rate is initialized to what recalc_rate returns:
> https://elixir.bootlin.com/linux/latest/source/drivers/clk/clk.c#L3607
> 
> So the case where req_rate is 0 shouldn't occur unless you had an
> explicit clk_set_rate to 0, or if your clock was orphaned at some point.
> 
> Judging from the code, it seems like the latter is the most plausible.
> Indeed, __clk_core_init() will set req_rate to 0 if the clock is
> orphaned (just like rate and accuracy), and
> clk_core_reparent_orphans_nolock will be in charge of updating them when
> the clock is no longer an orphan.
> 
> However, clk_core_reparent_orphans_nolock() will update rate by calling
> __clk_recalc_rate and accuracy by calling __clk_recalc_accuracies, but
> it never sets req_rate.
> 
> I'm not sure if this is the right patch, Stephen will tell, but could
> you test:

It looks correct to me. Would be helpful to have some comment of course
that we're setting a default req_rate because we want a
clk_set_rate_range() before clk_set_rate() to work properly when this
clk is initially an orphan. We should be able to code up a test case for
that too by registering an orphan and then registering the parent and
then calling clk_set_rate_range().


More information about the dri-devel mailing list