On Fri, Feb 7, 2014 at 11:37 AM, Nishanth Menon <nm@xxxxxx> wrote: > On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@xxxxxxx> wrote: >> >> Yes I thought of exactly similar clock setup, but was not convinced that it >> should be part of OPP. In that case it looks like we are trying to represent >> clock internals through some OPP bindings. > > And this series (rightly) does not make it an OPP behavior. instead > all it does is to list the boost-frequencies and mark those in cpufreq > table. the description is left to the dts and implementation to the > clock drivers involved. One more thing, before I forget -> currently dev_pm_opp_[init|free]_cpufreq_table is in drivers/base/power/opp.c -> this probably should go away to drivers/cpufreq to keep opp.c independent of frameworks using it. i dont see any code that is introduced in the mentioned functions as being OPP behavior specific, instead, I consider them as cpufreq+opp behaviors, which this change fits into. Regards, Nishanth Menon -- 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
