[PATCH v7 00/12] clk: Improve clock range handling

[Maxime Ripard]

Hi,

On Fri, Mar 11, 2022 at 07:08:39PM -0800, Stephen Boyd wrote:
> Quoting Maxime Ripard (2022-02-25 06:35:22)
> > Hi,
> > 
> > This is a follow-up of the discussion here:
> > https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/
> > 
> > and here:
> > https://lore.kernel.org/all/20210914093515.260031-1-maxime@cerno.tech/
> > 
> > While the initial proposal implemented a new API to temporarily raise and lower
> > clock rates based on consumer workloads, Stephen suggested an
> > alternative approach implemented here.
> > 
> > The main issue that needed to be addressed in our case was that in a
> > situation where we would have multiple calls to clk_set_rate_range, we
> > would end up with a clock at the maximum of the minimums being set. This
> > would be expected, but the issue was that if one of the users was to
> > relax or drop its requirements, the rate would be left unchanged, even
> > though the ideal rate would have changed.
> > 
> > So something like
> > 
> > clk_set_rate(user1_clk, 1000);
> > clk_set_min_rate(user1_clk, 2000);
> > clk_set_min_rate(user2_clk, 3000);
> > clk_set_min_rate(user2_clk, 1000);
> > 
> > Would leave the clock running at 3000Hz, while the minimum would now be
> > 2000Hz.
> > 
> > This was mostly due to the fact that the core only triggers a rate
> > change in clk_set_rate_range() if the current rate is outside of the
> > boundaries, but not if it's within the new boundaries.
> > 
> > That series changes that and will trigger a rate change on every call,
> > with the former rate being tried again. This way, providers have a
> > chance to follow whatever policy they see fit for a given clock each
> > time the boundaries change.
> > 
> > This series also implements some kunit tests, first to test a few rate
> > related functions in the CCF, and then extends it to make sure that
> > behaviour has some test coverage.
> > 
> > Let me know what you think
> 
> Thanks. I'm going to apply this to clk-next but not the last two drm
> patches. That is OK?

Yes, that will be perfect, thanks!
Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20220316/46e021c3/attachment.sig>