On Wednesday, July 16, 2014 07:28:15 PM Thomas Petazzoni wrote:
Dear Viresh Kumar,
On Wed, 16 Jul 2014 21:31:54 +0530, Viresh Kumar wrote:
Cc'ing Thomas,
Thanks. Also adding Jason Cooper, Andrew Lunn, Grégory Clement and Sebastian Hesselbart (the mvebu platform maintainers, which include Marvell Armada XP).
On 8 July 2014 10:20, Viresh Kumar viresh.kumar@linaro.org wrote:
On 4 July 2014 09:51, Viresh Kumar viresh.kumar@linaro.org wrote:
Yeah, having something like what you suggested from DT is the perfect solution to get over this. The only reason why I am not touching that here is to not delay other patches just because of that.
There are separate threads going on for that and probably somebody else was trying to push for that.
That's it, nothing more. I would definitely like to use those bindings instead of the crazy routines we are trying here, once that is finalized :)
Do we have some kind of agreement for this temporary solution? Anyways I will kick the other thread again to resolve the bindings soon.
Hi Mike/Rafael,
Thomas has a dependency on the patch adding "find_siblings()": http://www.spinics.net/lists/arm-kernel/msg348080.html
Would it be fine to get this temporary solution (Only within cpufreq-cpu0 file, so that it doesn't become an API) for now and updating it later once bindings are closed?
I have tried pinging on the other thread as well, but no one replied. And it looks those bindings are going to take some time to settle.
Alternatively, I could respin my Armada XP specific cpufreq driver, until a proper cpufreq-generic driver is sorted out, if that's needed. Since I was told by Viresh that the cpufreq-generic driver supporting independent per-CPU clocks would be merged for 3.17, I based my cpufreq development on that. Please let us know quickly if that's not going to be the case,
First off, I'm sorry I may not be able to do that quickly. I'll let you know when I get to that material.
so that we can enable cpufreq on Armada XP in 3.17, even if it's done with a separate cpufreq driver, until cpufreq-generic issues get sorted out.
If you target the generic one, I'd strongly recommend against trying to do a separate driver even if the generic thing is not ready for the merge window.
Kind regards, Rafael