Messages in this thread | | | Date | Wed, 09 Jul 2014 10:41:35 -0700 | From | Stephen Boyd <> | Subject | Re: [PATCH 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2 |
| |
On 07/07/14 21:50, Viresh Kumar 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. > > @Stephen: Do you still want find_rate_changer() stuff in this series only > and or this can go into 3.17 without anymore changes and lets finalize > the bindings Mike suggested and then update this code? > >
Finding the rate change is not necessary for me. I don't imagine my code will be getting into 3.17 anyway though so I'm no in a rush to merge anything immediately.
I still prefer the common clock framework API. If we go ahead with the find_rate_changer() stuff we've pretty well insulated this driver from any DTisms, which is nice. The only thing left would be transition-latency and voltage-tolerance, but those are already optional so you really don't need to even run on a DT enabled platform to use this code.
-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
| |