Hi Mark,
On Thu, 1 Dec 2011, Mark Brown wrote:
> On Wed, Nov 30, 2011 at 11:39:59PM -0700, Paul Walmsley wrote:
>
> > Clock rate/parent-change notifiers are requirements for DVFS use-cases,
> > and they must be paired with something like the
> > clk_{allow,block}_rate_change() functions to work efficiently. I intend
> > to comment on this later; it's not a simple problem. It might be worth
> > noting that Tero and I implemented a simplified version of this for the
> > N900.
>
> I'm thinking that if we're going to have clk_{allow,block}_rate_change()
> we may as well make that the main interface to enable rate changes - if
> a device wants to change the clock rate it allows rate changes using
> that interface rather than by disabling the clocks. I've got devices
> which can do glitch free updates of active clocks so having to disable
> would be a real restriction, and cpufreq would have issues with actually
> disabling the clock too I expect.
The intention behind the clk_{allow,block}_rate_change() proposal was to
allow the current user of the clock to change its rate without having to
call clk_{allow,block}_rate_change(), if that driver was the sole user of
the clock.
So for example, if you had a driver that did:
c = clk_get(dev, clk_name);
clk_enable(c);
clk_set_rate(c, clk_rate);
and c was currently not enabled by any other driver on the system, and
nothing else had called clk_block_rate_change(c), then the rate change
would be allowed to proceed. (modulo any notifier activity, etc.)
So clk_{allow,block}_rate_change() was simply intended to allow or
restrict other users of the same clock, not the current user.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
