On Mon, Dec 26, 2011 at 11:10:30AM +0000, Mark Brown wrote: > 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. but clk API don't have such calls. and many SoCs only adjust clk frequencies, using one single voltage. > > > 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 So what's your suggestion? We can not set transition_latency to set random number. Thanks Richard -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
