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