Thread (7 messages) 7 messages, 4 authors, 2021-03-25

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
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help