Re: [PATCH v4 4/7] cpufreq: add clk-reg cpufreq driver
On Sat, Dec 24, 2011 at 11:52:29PM +0800, Richard Zhao wrote: > On Sat, Dec 24, 2011 at 01:42:29PM +, 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 4/7] cpufreq: add clk-reg cpufreq driver
On Mon, Dec 26, 2011 at 11:10:30AM +, 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 +, 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 4/7] cpufreq: add clk-reg cpufreq driver
On Mon, Dec 26, 2011 at 09:44:52PM +0800, Richard Zhao wrote: > On Mon, Dec 26, 2011 at 11:10:30AM +, Mark Brown wrote: Fix your mailer to word wrap properly please. > > 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. I've not suggested doing this in the clock API, only for the regulator. For the clocks it's less clear that it's useful as you don't have the bulk operations and it's much rarer to need them. > > 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. As I've repeatedly said I think you should define it to be the latency for the SoC only, not for the regulators. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 4/7] cpufreq: add clk-reg cpufreq driver
On Mon, Dec 26, 2011 at 02:22:34PM +, Mark Brown wrote: > On Mon, Dec 26, 2011 at 09:44:52PM +0800, Richard Zhao wrote: > > On Mon, Dec 26, 2011 at 11:10:30AM +, Mark Brown wrote: > > Fix your mailer to word wrap properly please. If you mean last mail I sent, I didn't see anything wrong. I use mutt. > > > > 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. > > I've not suggested doing this in the clock API, only for the regulator. > For the clocks it's less clear that it's useful as you don't have the > bulk operations and it's much rarer to need them. > > > > 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. > > As I've repeatedly said I think you should define it to be the latency > for the SoC only, not for the regulators. Sometimes, regulators are in SoC too. To avoid confusion, I'll use below: clk-trans-latency = <61036>; Thanks Richard > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro Android GB vs ICS bugs
Hi - I visited https://bugs.launchpad.net/linaro-android to create a couple of bugs for Panda ICS rootfs [1], I was surprised to see 268 open bugs there including ones about Panda. When I looked at them, a lot are about Gingerbread, some are about TI LT kernels but others about Panda are about other kernels. Well, I'm kind of happy I didn't get bothered about those bugs; we have some open bugs that are relevant that we're still working on which is fine. However... what's the plan about Gingerbread? We seem to have moved lock, stock and barrel to ICS, which although it happened a bit abruptly I can understand the reasoning for. Should we not close out the Android bugs about Gingerbread then with INVALID or WONTFIX? Or is the plan we will continue to make GB builds too? (That will need us to create another kernel with old SGX 1.7 stuff in if so, it's no big deal but we would need to know.) It's very difficult at the moment to see if a bug like "Panda: Bootup failures observed when HDMI cable is connected" https://bugs.launchpad.net/linaro-android/+bug/902046 is relevant, I don't think it is since it's about old tracking kernel on Gingerbread with 1.7 SGX. Then, we should nuke the bug so we can see the wood from the trees? Another kind of problem a real, old bug we fixed 6 weeks ago is not closed out https://bugs.launchpad.net/linaro-android/+bug/869537 -Andy [1] I didn't bother listing bugs for all the regressions ICS rootfs introduced generally since they're well known already, but these ones are interesting for TI LT ICS: Panda: 1080p background image memory allocation fails https://bugs.launchpad.net/linaro-android/+bug/908954 ICS: Panda: 1080p launcher screen positioning uses 720p origin https://bugs.launchpad.net/linaro-android/+bug/908956 ICS: All arches: No aplay / arecord or equivalent https://bugs.launchpad.net/linaro-android/+bug/908957 -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
