summaryrefslogtreecommitdiff
path: root/drivers/cpufreq
AgeCommit message (Collapse)AuthorFilesLines
2013-10-26cpufreq: Implement light weight ->target_index() routineViresh Kumar45-725/+219
Currently, the prototype of cpufreq_drivers target routines is: int target(struct cpufreq_policy *policy, unsigned int target_freq, unsigned int relation); And most of the drivers call cpufreq_frequency_table_target() to get a valid index of their frequency table which is closest to the target_freq. And they don't use target_freq and relation after that. So, it makes sense to just do this work in cpufreq core before calling cpufreq_frequency_table_target() and simply pass index instead. But this can be done only with drivers which expose their frequency table with cpufreq core. For others we need to stick with the old prototype of target() until those drivers are converted to expose frequency tables. This patch implements the new light weight prototype for target_index() routine. It looks like this: int target_index(struct cpufreq_policy *policy, unsigned int index); CPUFreq core will call cpufreq_frequency_table_target() before calling this routine and pass index to it. Because CPUFreq core now requires to call routines present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time. This also marks target() interface as deprecated. So, that new drivers avoid using it. And Documentation is updated accordingly. It also converts existing .target() to newly defined light weight .target_index() routine for many driver. Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Russell King <linux@arm.linux.org.uk> Acked-by: David S. Miller <davem@davemloft.net> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net>
2013-10-26Merge back earlier 'pm-cpufreq' material.Rafael J. Wysocki65-1443/+405
Conflicts: drivers/cpufreq/omap-cpufreq.c
2013-10-26PM / OPP: rename header to linux/pm_opp.hNishanth Menon6-6/+6
Since Operating Performance Points (OPP) functions are specific to device specific power management, be specific and rename opp.h to pm_opp.h Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-26PM / OPP: rename data structures to dev_pm equivalentsNishanth Menon4-6/+6
Since Operating Performance Points (OPP) data structures are specific to device specific power management, be specific and rename opp_* data structures in OPP library with dev_pm_opp_* equivalent. Affected structures are: struct opp enum opp_event Minor checkpatch warning resulting of this change was fixed as well. Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-26PM / OPP: rename functions to dev_pm_opp*Nishanth Menon5-32/+33
Since Operating Performance Points (OPP) functions are specific to device specific power management, be specific and rename opp_* accessors in OPP library with dev_pm_opp_* equivalent. Affected functions are: opp_get_voltage opp_get_freq opp_get_opp_count opp_find_freq_exact opp_find_freq_floor opp_find_freq_ceil opp_add opp_enable opp_disable opp_get_notifier opp_init_cpufreq_table opp_free_cpufreq_table Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-25acpi-cpufreq: Fail initialization if driver cannot be registeredRafael J. Wysocki1-4/+4
Make acpi_cpufreq_init() return error codes when the driver cannot be registered so that the module doesn't stay useless in memory and so that acpi_cpufreq_exit() doesn't attempt to unregister things that have never been registered when the module is unloaded. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
2013-10-22intel_pstate: Correct calculation of min pstate valueDirk Brandewie1-2/+3
The minimum pstate is supposed to be a percentage of the maximum P state available. Calculate min using max pstate and not the current max which may have been limited by the user Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-22intel_pstate: Improve accuracy by not truncating until final resultBrennan Shacklett1-18/+15
This patch addresses Bug 60727 (https://bugzilla.kernel.org/show_bug.cgi?id=60727) which was due to the truncation of intermediate values in the calculations, which causes the code to consistently underestimate the current cpu frequency, specifically 100% cpu utilization was truncated down to the setpoint of 97%. This patch fixes the problem by keeping the results of all intermediate calculations as fixed point numbers rather scaling them back and forth between integers and fixed point. References: https://bugzilla.kernel.org/show_bug.cgi?id=60727 Signed-off-by: Brennan Shacklett <bpshacklett@gmail.com> Acked-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-18cpufreq / governor: Remove fossil commentLan Tianyu1-11/+0
cpufreq_set_policy() has been changed to origin __cpufreq_set_policy() and policy->lock has been converted to rewrite lock by commit 5a01f2. So remove the comment. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17cpufreq: exynos4210: Use the common clock framework to set APLL clock rateLukasz Majewski1-59/+8
In the exynos4210_set_apll() function, the APLL frequency is set with direct register manipulation. Such approach is not allowed in the common clock framework. The frequency is changed, but the corresponding clock value is not updated. This causes wrong frequency read from cpufreq's cpuinfo_cur_freq sysfs attribute. Also direct manipulation with PLL's S parameter has been removed. It is already done at PLL35xx code. Tested at: - Exynos4210 - Trats board (linux 3.12-rc4) Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Reviewed-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17cpufreq: exynos4x12: Use the common clock framework to set APLL clock rateLukasz Majewski1-61/+8
In the exynos4x12_set_apll() function, the APLL frequency is set with direct register manipulation. Such approach is not allowed in the common clock framework. The frequency is changed, but the corresponding clock value is not updated. This causes wrong frequency read from cpufreq's cpuinfo_cur_freq sysfs attribute. Also direct manipulation with PLL's S parameter has been removed. It is already done at PLL35xx code. Tested at: - Exynos4412 - Trats2 board (linux 3.12-rc4) Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Tomasz Figa <t.figa@samsung.com> Reviewed-by: Yadwinder Singh Brar <yadi.brar@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17cpufreq: Detect spurious invocations of update_policy_cpu()Srivatsa S. Bhat1-1/+1
The function update_policy_cpu() is expected to be called when the policy->cpu of a cpufreq policy is to be changed: ie., the new CPU nominated to become the policy->cpu is different from the old one. Print a warning if it is invoked with new_cpu == old_cpu, since such an invocation might hint at a faulty logic in the caller. Suggested-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17cpufreq: pmac64: enable cpufreq on iMac G5 (iSight) modelAaro Koskinen1-1/+2
Enable cpufreq on iMac G5 (iSight) model. Tested with the 2.1 GHz version. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17cpufreq: pmac64: provide cpufreq transition latency for older G5 modelsAaro Koskinen1-1/+3
Currently cpufreq ondemand governor cannot used on older G5 models, because the transition latency is set to CPUFREQ_ETERNAL. Provide a value based on a measurement on Xserve G5, which happens to be also the highest allowed latency. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17cpufreq: pmac64: speed up frequency switchAaro Koskinen1-3/+3
Some functions on switch path use msleep() which is inaccurate, and depends on HZ. With HZ=100 msleep(1) takes actually over ten times longer. Using usleep_range() we get more accurate sleeps. I measured the "pfunc_slewing_done" polling to take 300us at max (on 2.3GHz dual-processor Xserve G5), so using 500us sleep there should be fine. With the patch, g5_switch_freq() duration drops from ~50ms to ~10ms on Xserve with HZ=100. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17cpufreq: highbank-cpufreq: Enable Midway/ECX-2000Mark Langsdorf1-1/+2
Calxeda's new ECX-2000 part uses the same cpufreq interface as highbank, so add it to the driver's compatibility list. This is a minor change that can safely be applied to the 3.10 and 3.11 stable trees. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17exynos-cpufreq: fix false return check from "regulator_set_voltage"Manish Badarkhe1-1/+1
Currently, code checks false return value from "regulator_set_voltage" to show failure message. Modify the code to check proper return value from "regulator_set_voltage". Signed-off-by: Manish Badarkhe <badarkhe.manish@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17speedstep-centrino: Remove unnecessary bracesEvgeny Kapaev1-2/+1
As per coding style, braces {} are not necessary for single statement block Signed-off-by: Evgeny Kapaev <orener300@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17acpi-cpufreq: Add comment under ACPI_ADR_SPACE_SYSTEM_IO caseViresh Kumar1-1/+6
policy->cur is now set by cpufreq core when cpufreq_driver->get() is defined and so drivers aren't required to set it. When space_id is ACPI_ADR_SPACE_SYSTEM_IO for acpi cpufreq driver it doesn't set ->get to a valid function pointer and so policy->cur is required to be set by driver. This is already followed in acpi-cpufreq driver. This patch adds a comment describing why we need to set policy->cur from driver. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17cpufreq: s3c64xx: Rename index to driver_dataCharles Keepax1-1/+1
The index field of cpufreq_frequency_table has been renamed to driver_data by commit 5070158 (cpufreq: rename index as driver_data in cpufreq_frequency_table). This patch updates the s3c64xx driver to match. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Cc: 3.11+ <stable@vger.kernel.org> # 3.11+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17cpufreq: arm-big-little: use clk_get instead of clk_get_sysSudeep KarkadaNagesha1-1/+1
Currently clk_get_sys is used with cpu-cluster.<n> as the device id which is incorrect. It should be connection/consumer ID instead. It is possible to specify input clock in the cpu device node along with the optional clock-name. clk_get_sys can't handle that. This patch replaces clk_get_sys with clk_get to extend support for clocks specified in the device tree cpu node. Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17cpufreq: exynos: Show a list of available frequenciesJungseok Lee1-0/+1
This patch adds freq_attr to show a list of exynos5440 scaling available frequencies through sysfs. Common exynos driver already supports this attribute. Signed-off-by: Jungseok Lee <jays.lee@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17intel_pstate: Fix type mismatch warningRafael J. Wysocki1-3/+4
The expression in line 398 of intel_pstate.c causes the following warning to be emitted: drivers/cpufreq/intel_pstate.c:398:3: warning: left shift count >= width of type which happens because unsigned long is 32-bit on some architectures. Fix that by using a helper u64 variable and simplify the code slightly. Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: probe the Integrator cpufreq driver from DTLinus Walleij1-18/+43
This makes the Integrator cpufreq driver probe from the core module device tree node through it's registered platforms device, getting the memory base from the device tree, remapping it and removing dependencies to <mach/platform.h> and <mach/hardware.h> by moving the two affected CM register offsets into the driver. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-10-16cpufreq / intel_pstate: Fix max_perf_pct on resumeDirk Brandewie1-4/+3
If the system is suspended while max_perf_pct is less than 100 percent or no_turbo set policy->{min,max} will be set incorrectly with scaled values which turn the scaled values into hard limits. References: https://bugzilla.kernel.org/show_bug.cgi?id=61241 Reported-by: Patrick Bartels <petzicus@googlemail.com> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Cc: 3.9+ <stable@vger.kernel.org> # 3.9+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: tegra: use cpufreq_generic_init()Viresh Kumar1-4/+9
Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: spear: use cpufreq_generic_init()Viresh Kumar1-12/+2
Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: sa11x0: use cpufreq_generic_init()Viresh Kumar2-10/+2
Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: s5pv210: use cpufreq_generic_init()Viresh Kumar1-3/+1
Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: s3c: use cpufreq_generic_init()Viresh Kumar3-19/+5
Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: pmac64: use cpufreq_generic_init()Viresh Kumar1-8/+1
Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: pmac32: use cpufreq_generic_init()Viresh Kumar1-6/+1
Use generic cpufreq_generic_init() routine instead of replicating the same code here. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: pasemi: use cpufreq_generic_init()Viresh Kumar1-8/+1
Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: omap: use cpufreq_generic_init()Viresh Kumar1-30/+11
Use generic cpufreq_generic_init() routine instead of replicating the same code here. This also rearranges the code a bit to make it more sensible. Also removes some unnecessary checks. Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: maple: use cpufreq_generic_init()Viresh Kumar1-8/+1
Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: loongson2: use cpufreq_generic_init()Viresh Kumar1-2/+1
Use generic cpufreq_generic_init() routine instead of replicating the same code here. This driver wasn't setting transition_latency and so is getting set to 0 by default. Lets mark it explicitly by calling the generic routine with transition_latency as 0. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: kirkwood: use cpufreq_generic_init()Viresh Kumar1-4/+1
Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: imx6q: use cpufreq_generic_init()Viresh Kumar1-12/+1
Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: exynos: use cpufreq_generic_init()Viresh Kumar2-18/+3
Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: dbx500: use cpufreq_generic_init()Viresh Kumar1-20/+1
Use generic cpufreq_generic_init() routine instead of replicating the same code here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: davinci: use cpufreq_generic_init()Viresh Kumar1-9/+1
Use generic cpufreq_generic_init() routine instead of replicating the same code here. Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: cris: use cpufreq_generic_init()Viresh Kumar2-9/+2
Use generic cpufreq_generic_init() routine instead of replicating the same code here. Cc: Mikael Starvik <starvik@axis.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: cpufreq-cpu0: use cpufreq_generic_init()Viresh Kumar1-18/+1
Use generic cpufreq_generic_init() routine instead of replicating the same code here. Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: remove CONFIG_CPU_FREQ_TABLEViresh Kumar6-48/+1
CONFIG_CPU_FREQ_TABLE will be always enabled when cpufreq framework is used, as cpufreq core depends on it. So, we don't need this CONFIG option anymore as it is not configurable. Remove CONFIG_CPU_FREQ_TABLE and update its users. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: create cpufreq_generic_init() routineViresh Kumar2-0/+32
Many CPUFreq drivers for SMP system (where all cores share same clock lines), do similar stuff in their ->init() part. This patch creates a generic routine in cpufreq core which can be used by these so that we can remove some redundant code. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: unicore2: don't initialize part of policy set by coreViresh Kumar1-1/+0
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 <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: tegra: don't initialize part of policy set by coreViresh Kumar1-2/+1
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: Stephen Warren <swarren@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: speedstep: don't initialize part of policy set by coreViresh Kumar3-32/+1
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: David S. Miller <davem@davemloft.net> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: spear: don't initialize part of policy set by coreViresh Kumar1-2/+0
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 <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: sh: don't initialize part of policy set by coreViresh Kumar1-2/+0
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: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>