Re: [RFD] Voltage dependencies for clocks (DVFS)

[Kevin Hilman <khilman@baylibre.com>]

[ sorry, a little late to the party ]

[...]

> Would there be some way to prevent consumers from directly calling
> clk_set_rate or clk_enable and force them to go via another framework
> for these calls?  It would at least prevent people from using the
> "wrong" interface and bypassing voltage requirements.  That of course
> means having to mirror any of the clk APIs that update clock state
> into genpd/opp, which Stephen finds distasteful (and I agree).

Chiming in late to this thread with a a bit of historical perspecitve
(and over simplification): doing exactly this was part of the goal of of
genpd in the first place.

Before genpd, it used to be the case where lots of drivers only used the
clk API for idle power management (clock gating).  Essentially a bunch
of clk_enable/disable calls based on activity.  This didn't scale well
for lots of reasons, but a primary one was that the same IP could be
integrated differnetly on differnent SoCs, thus have different clocks
for gating (or no clock gating.)

With genpd, we could remove all of the clock-specific stuff from
consumers and replace with a more generic pm_runtime calls, putting the
intelligence, such as SoC integration knowledge and some goverors around
whether or not to *actually* gate clocks, into the genpd
callbacks/governors, which, being pluggable, could be highly SoC
specific.

IMO, at a high level, in this thread, we're having exactly the same
conversation again, with the difference being we're talking about
active/performace states and not idle states.

While active states are definitely more complex, and have more
dependencies, I don't see why the general approach on of the solution
should not be the same as it was for idle management.

Basically, I'm agreeing with the general direction this thread seems to
be going that using the new active/performance features of genpd, and
having genpd callbacks/goverors that Know All The Things seems like the
obvious direction to go.

However, the hard part remains, and that is defining the right consumer
layer to give all the hints/requests so that the super-smart genpd
governors can do the right thing.

Kevin