Quoting Nishanth Menon (2014-02-18 12:32:18) > From: Mike Turquette <mturquette@xxxxxxxxxx> > > This patch provides helper functions for drivers that wish to scale > voltage through the clock rate-change notifiers. The approach taken > is that the user-driver(cpufreq/devfreq) do not care about the > details of the OPP table, nor does it care about handling the voltage > regulator directly. > > By using the clk notifier flags, we are able to sequence the operations > in the right order. The current logic is heavily influenced by > implementation done in cpufreq-cpu0. > > [nm@xxxxxx: Fixes in logic, and broken out from clk to allow building > a generic voltagedomain solution independent of cpufreq] > Signed-off-by: Nishanth Menon <nm@xxxxxx> > Signed-off-by: Mike Turquette <mturquette@xxxxxxxxxx> Not-signed-off-by: Mike Turquette <mturquette@xxxxxxxxxx> I haven't reviewed this series and it is a pretty big deviation from my original RFC. You can have authorship of the patches if you want. I'm not sure about trying to capture the "voltdm" as a core concept. It feels a bit unwieldy to me. I have wondered about making an abstract "performance domain" which is the dvfs analogue to generic power domains. This a reasonable split since gpd are good for idle power savings (e.g. clock gate, power gate, sleep state, etc) and "perf domains" would be good for active power savings (dvfs). Having a generic container for performance domains might make a good place to stuff all of this glue logic that we keep running into (e.g. CPU and GPU max frequencies that are related), and it might make another nice knob for the thermal folks to use. For the case of the OMAP voltage domains, it would be a place to stuff all of the VC/VP -> ABB -> Smart Reflex AVS stuff. Anyways, I don't have a real proposal. I just don't want my name on these patches since they are really yours now. I might resurrect them some day in a different context. Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html