Re: Scaling back down a shared clock
From: Abel Vesa <abelvesa@kernel.org>
Date: 2021-03-25 09:59:18
On 21-03-19 16:03:55, Maxime Ripard wrote:
Hi Mike, Stephen, The SoCs used in the RaspberryPi have a bunch of shared clocks (between two HDMI controllers for example) that need to be at a given minimum rate for each instance (based on the resolution for the HDMI controllers), but don't really have any maximum requirement other than the operating boundaries of that clock. We've supported it so far using the clk_set_min_rate function which handles nicely that requirement and the fact that it's shared. However, those clocks run at a fairly high frequency and there's some interest in keeping them at their minimum to draw less power. Currently, if we increase the minimum to a rate higher than the current clock rate, it will raise its rate, but once that minimum is lowered the clock rate doesn't change (which makes sense). How could we put some kind of downward pressure on the clock rate to make it run at its minimum all the time? It looks like the PM QoS framework implements something similar for the bus bandwidth, except that it's not really a bus that have this requirement here.
Maybe interconnect + devfreq is the solution here. I did something similar here: https://lore.kernel.org/lkml/1613750416-11901-1-git-send-email-abel.vesa@nxp.com/ (local)
We were thinking about either adding a flag to the clock that would make it run always at its lowest frequency, or to introduce a "boost" API to bump temporarily the clock rate and then once done brings it back to its default rate. The first one though would be a bit dangerous, since it's mostly use-case based, and if we don't get any clock user reporting a minimum it might have a bunch of weird side effects, making clk_set_rate_min required de facto while it wasn't before. The boost API semantics would probably have a bunch of weird corner cases. For example, how long is "temporarily" exactly, since for all we know it might actually last forever. What would happen if we change the boundaries or even the rate of the clock during a boost? etc. I'd really like to get your opinion on this before I start working on something. Thanks! Maxime