summaryrefslogtreecommitdiff
path: root/drivers/cpufreq/s3c64xx-cpufreq.c
AgeCommit message (Collapse)AuthorFilesLines
2013-10-31cpufreq: move freq change notifications to cpufreq coreViresh Kumar1-32/+16
Most of the drivers do following in their ->target_index() routines: struct cpufreq_freqs freqs; freqs.old = old freq... freqs.new = new freq... cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE); /* Change rate here */ cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE); This is replicated over all cpufreq drivers today and there doesn't exists a good enough reason why this shouldn't be moved to cpufreq core instead. There are few special cases though, like exynos5440, which doesn't do everything on the call to ->target_index() routine and call some kind of bottom halves for doing this work, work/tasklet/etc.. They may continue doing notification from their own code as flag: CPUFREQ_ASYNC_NOTIFICATION is already set for them. All drivers are also modified in this patch to avoid breaking 'git bisect', as double notification would happen otherwise. 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: Stephen Warren <swarren@nvidia.com> Tested-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Nicolas Pitre <nicolas.pitre@linaro.org> Reviewed-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-25cpufreq: Implement light weight ->target_index() routineViresh Kumar1-14/+4
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-25Merge back earlier 'pm-cpufreq' material.Rafael J. Wysocki1-14/+3
Conflicts: drivers/cpufreq/omap-cpufreq.c
2013-10-16cpufreq: 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-16cpufreq: s3c: use cpufreq_generic_init()Viresh Kumar1-3/+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: s3c: 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: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: s3cx4xx: Use generic cpufreq routinesViresh Kumar1-9/+1
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 <viresh.kumar@linaro.org> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-30cpufreq: s3cx4xx: use cpufreq_table_validate_and_show()Viresh Kumar1-4/+1
Lets use cpufreq_table_validate_and_show() instead of calling cpufreq_frequency_table_cpuinfo() and cpufreq_frequency_table_get_attr(). Cc: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-30cpufreq: s3cx4xx: call cpufreq_frequency_table_get_attr()Viresh Kumar1-0/+3
This exposes frequency table of driver to cpufreq core and is required for core to guess what the index for a target frequency is, when it calls cpufreq_frequency_table_target(). And so this driver needs to expose it. Cc: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-08-10cpufreq: Drop the owner field from struct cpufreq_driverViresh Kumar1-1/+0
We don't need to set .owner = THIS_MODULE any more in cpufreq drivers as this field isn't used any more by the cpufreq core. This patch removes it and updates all dependent drivers accordingly. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-27Merge branch 'pm-cpufreq-arm' into pm-cpufreqRafael J. Wysocki1-2/+6
* pm-cpufreq-arm: cpufreq: tegra: call CPUFREQ_POSTCHANGE notfier in error cases cpufreq: s3c64xx: call CPUFREQ_POSTCHANGE notfier in error cases cpufreq: omap: call CPUFREQ_POSTCHANGE notfier in error cases cpufreq: imx6q: call CPUFREQ_POSTCHANGE notfier in error cases cpufreq: exynos: call CPUFREQ_POSTCHANGE notfier in error cases cpufreq: dbx500: call CPUFREQ_POSTCHANGE notfier in error cases cpufreq: davinci: call CPUFREQ_POSTCHANGE notfier in error cases cpufreq: arm-big-little: call CPUFREQ_POSTCHANGE notfier in error cases cpufreq: s3c2416: fix forgotten driver_data conversions
2013-06-24cpufreq: s3c64xx: call CPUFREQ_POSTCHANGE notfier in error casesViresh Kumar1-2/+6
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both should be called or both shouldn't be. In case we have started PRECHANGE notifier and found an error, we must call POSTCHANGE notifier with freqs.new = freqs.old to guarantee that sequence of calling notifiers is complete. This patch fixes it. Cc: Mark Brown <broonie@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2013-06-04cpufreq: rename index as driver_data in cpufreq_frequency_tableViresh Kumar1-1/+1
The "index" field of struct cpufreq_frequency_table was never an index and isn't used at all by the cpufreq core. It only is useful for cpufreq drivers for their internal purposes. Many people nowadays blindly set it in ascending order with the assumption that the core will use it, which is a mistake. Rename it to "driver_data" as that's what its purpose is. All of its users are updated accordingly. [rjw: Changelog] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-02cpufreq: Notify all policy->cpus in cpufreq_notify_transition()Viresh Kumar1-4/+3
policy->cpus contains all online cpus that have single shared clock line. And their frequencies are always updated together. Many SMP system's cpufreq drivers take care of this in individual drivers but the best place for this code is in cpufreq core. This patch modifies cpufreq_notify_transition() to notify frequency change for all cpus in policy->cpus and hence updates all users of this API. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-02-29[CPUFREQ] s3c64xx: Fix mis-cherry pick of VDDINTMark Brown1-7/+0
We don't have any of the other code for VDDINT, including the variable declaration, so don't try to get it as we can't build. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-12-09[CPUFREQ] s3c64xx: Use pr_fmt() for consistent log messagesMark Brown1-13/+22
They're already consistent but it saves remembering to do so. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-10-31cpufreq: Fix build of s3c64xx cpufreq driver for header changeMark Brown1-0/+1
The header change has removed an implicit include of module.h, breaking the build due to the use of THIS_MODULE. Fix that. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-07-13[CPUFREQ] S3C6410: Add some lower frequencies for 800MHz base clock operationMark Brown1-0/+2
By extension from the 667MHz based clocks currently supported add 100MHz and 200MHz operating points. Due to a lack of documentation these have not been confirmed as supported but by extension from the existing frequencies they should be OK, and I've given them quite a bit of runtime testing. The major risk is synchronization with the non-ARM clocks but as we can't currently scale the ARM PLL the risk should be relatively low. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-07-13[CPUFREQ] S3C64xx: Notify transition complete as soon as frequency changedMark Brown1-2/+2
The CPUFREQ_POSTCHANGE notification is used to update things that depend on the system clock rates. Since this may include the interfaces used to talk to the regulators do the notification before we try to update regulators to reflect lowered system clock rate. The voltage scaling is just a power optimisation and may not happen at all so there's no concern about it not having completed. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-07-13[CPUFREQ] S3C6410: Support 800MHz operation in cpufreqMark Brown1-0/+2
At least some newer S3C6410 silicon supports operation up to 800MHz rather than just 667MHz. Unfortunately I don't have access to any of documentation of this other than some running systems, add a new cpufreq table entry for this based on the behaviour of those systems. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-07-13[CPUFREQ] Move compile for S3C64XX cpufreq to /drivers/cpufreqKukjin Kim1-0/+269
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>