On 07/07/14 21:50, Viresh Kumar wrote: > On 4 July 2014 09:51, Viresh Kumar <viresh.kumar@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
