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.