- 15 Oct, 2013 40 commits
-
-
Viresh Kumar authored
Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). Cc: Tony Luck <tony.luck@intel.com> Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Viresh Kumar authored
Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). Signed-off-by:
-
Viresh Kumar authored
Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). Signed-off-by:
Amit Daniel Kachhap <amit.daniel@samsung.com> Acked-by:
Kukjin Kim <kgene.kim@samsung.com> Signed-off-by:
-
Viresh Kumar authored
Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). Signed-off-by:
-
Viresh Kumar authored
Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). Signed-off-by:
-
Viresh Kumar authored
Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Viresh Kumar authored
Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by:
-
Viresh Kumar authored
Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). Cc: Mikael Starvik <starvik@axis.com> Signed-off-by:
Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by:
-
Viresh Kumar authored
Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). Signed-off-by:
-
Viresh Kumar authored
Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Viresh Kumar authored
Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). Cc: Steven Miao <realmz6@gmail.com> Signed-off-by:
-
Viresh Kumar authored
Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). Acked-by:
Hans-Christian Egtvedt <egtvedt@samfundet.no> Signed-off-by:
-
Viresh Kumar authored
Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). Signed-off-by:
-
Viresh Kumar authored
Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). Signed-off-by:
-
Viresh Kumar authored
Almost all drivers set policy->cur with current CPU frequency in their ->init() part. This can be done for all of them at core level and so they wouldn't need to do it. This patch adds supporting code in cpufreq core for calling get() after we have called init() for a policy. Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the Tegra driver. Cc: Stephen Warren <swarren@nvidia.com> Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the speedstep driver. Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the spear driver. Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the sparc driver. Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the sh driver. Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the sc520 driver. Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the sa11x0 driver. Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the s5pv210 driver. Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the s3cx4xx driver. Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the PXA driver. Cc: Eric Miao <eric.y.miao@gmail.com> Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the ppc_cbe driver. Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the ppc-corenet driver. Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the powernow driver. Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the pmac driver. Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the pasemi driver. Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the p4-clockmod driver. Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the OMAP driver. Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the maple driver. Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the loongson2 driver. Cc: John Crispin <blogic@openwrt.org> Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the longhaul driver. Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the kirkwood driver. Tested-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines for in the imx6q driver. Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the ia64-acpi driver. Cc: Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the exynos driver. Signed-off-by:
-
Viresh Kumar authored
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the elanfreq driver. Signed-off-by:
-
