Subject: [PATCH v4 4/7] cpufreq: add clk-reg cpufreq driver

From: [email-masked] (Mark Brown)
Date: Mon, 26 Dec 2011 11:10:30 +0000

On Sat, Dec 24, 2011 at 11:52:29PM +0800, Richard Zhao wrote:
> On Sat, Dec 24, 2011 at 01:42:29PM +0000, Mark Brown wrote:
> > On Sat, Dec 24, 2011 at 09:28:33PM +0800, Richard Zhao wrote:

> > > If you think regulator thansition latency is board specific, then the board
> > > dts can overrite it.

> > We should just query this information from the regulator subsystem
> > (there's hooks but currently nothing implements them).  The regulators
> > can define their own bindings if they need to read it from device tree,
> > most of them should be able to do this as a function of knowing about
> > the device.  None of this is specific to cpufreq so cpufreq shouldn't
> > have to define its own support for this.

> I'd like to query the latency by call clk and regulator APIs. but as you said
> both of them have not implemented it yet. I think, for now, we can use the

The *call* is there in the regulator subsystem, it's just that none of
the drivers back it up with an actual implementation yet.  Which turns
out to be a good thing as cpufreq can't currently understand variable
latencies and the governors don't deal well with non-trivial latencies
anyway.

> property to get the total latency. Once I can get it at runtime, I'll remove
> it. So the definition of trans-latency is just the same as cpufreq transition_latency,
> people get less confused. What do you think?

The problem with device tree is that once you've defined a binding
you're stuck with it, it's very hard to change - witness all the magic
number based stuff with the interrupt bindings for example