aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/cpufreq/s5pv210-cpufreq.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2014-05-27cpufreq: s5pv210: drop check for CONFIG_PM_VERBOSEPaul Bolle1-4/+2
A pr_err() was added in v3.1. It was guarded by a check for CONFIG_PM_VERBOSE. The Kconfig symbol PM_VERBOSE was removed in v3.0. So this pr_err() has never been used. Drop that check and clean up the message a bit. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-07cpufreq: create another field .flags in cpufreq_frequency_tableViresh Kumar1-6/+6
Currently cpufreq frequency table has two fields: frequency and driver_data. driver_data is only for drivers' internal use and cpufreq core shouldn't use it at all. But with the introduction of BOOST frequencies, this assumption was broken and we started using it as a flag instead. There are two problems due to this: - It is against the description of this field, as driver's data is used by the core now. - if drivers fill it with -3 for any frequency, then those frequencies are never considered by cpufreq core as it is exactly same as value of CPUFREQ_BOOST_FREQ, i.e. ~2. The best way to get this fixed is by creating another field flags which will be used for such flags. This patch does that. Along with that various drivers need modifications due to the change of struct cpufreq_frequency_table. Reviewed-by: Gautham R Shenoy <ego@linux.vnet.ibm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-06cpufreq: s5pv210: Use cpufreq_generic_suspend()Viresh Kumar1-46/+3
The cpufreq core now supports suspending and resuming of cpufreq drivers and governors during systems suspend and resume, so use the common infrastructure instead of defining special PM notifiers for the same thing. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17cpufreq: introduce cpufreq_generic_get() routineViresh Kumar1-15/+6
CPUFreq drivers that use clock frameworks interface,i.e. clk_get_rate(), to get CPUs clk rate, have similar sort of code used in most of them. This patch adds a generic ->get() which will do the same thing for them. All those drivers are required to now is to set .get to cpufreq_generic_get() and set their clk pointer in policy->clk during ->init(). Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: 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>
2014-01-06cpufreq: Mark ARM drivers with CPUFREQ_NEED_INITIAL_FREQ_CHECK flagViresh Kumar1-1/+1
Sometimes boot loaders set CPU frequency to a value outside of frequency table present with cpufreq core. In such cases CPU might be unstable if it has to run on that frequency for long duration of time and so its better to set it to a frequency which is specified in frequency table. On some systems we can't really say what frequency we're running at the moment and so for these we shouldn't check if we are running at a frequency present in frequency table. And so we really can't force this for all the cpufreq drivers. Hence we are created another flag here: CPUFREQ_NEED_INITIAL_FREQ_CHECK that will be marked by platforms which want to go for this check at boot time. Initially this is done for all ARM platforms but others may follow if required. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-31cpufreq: move freq change notifications to cpufreq coreViresh Kumar1-10/+6
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-40/+14
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-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: s5pv210: 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: s5pv210: 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 s5pv210 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: s5pv210: use cpufreq_table_validate_and_show()Viresh Kumar1-3/+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-04-02cpufreq: Notify all policy->cpus in cpufreq_notify_transition()Viresh Kumar1-3/+2
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>
2011-07-13[CPUFREQ] s5pv210: make needlessly global symbols staticAxel Lin1-2/+2
The following symbols are needlessly defined global: s5pv210_verify_speed s5pv210_getspeed Make them static. Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-07-13[CPUFREQ] S5PV210: Add reboot notifier to prevent system hangHuisung Kang1-0/+19
When system reboot, the CPUFREQ level should be 800MHz to prevent system lockup. Signed-off-by: Huisung Kang <hs1218.kang@samsung.com> Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-07-13[CPUFREQ] S5PV210: Adjust udelay prior to voltage scaling downTodd Poynor1-2/+2
Voltage scaling accesses the MAX8998 regulators over bit-banged I2C with lots of udelays. In the case of decreasing CPU speed, the number of loops per us for udelay needs to be adjusted prior to decreasing voltage to avoid delaying for up to 10X too long. Signed-off-by: Todd Poynor <toddpoynor@google.com> Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-07-13[CPUFREQ] S5PV210: Lock a mutex while changing the cpu frequencyArve Hjønnevåg1-9/+19
Without this lock the call to change the frequency for suspend could switch to a new frequency while another thread was still changing the cpu voltage. Signed-off-by: Arve Hjønnevåg <arve@android.com> Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-07-13[CPUFREQ] S5PV210: Add pm_notifier to prevent system unstableHuisung Kang1-0/+34
Minimum 800MHz is needed to enter/exit suspend mode due to voltage mismatch. Signed-off-by: Huisung Kang <hs1218.kang@samsung.com> Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-07-13[CPUFREQ] S5PV210: Add arm/int voltage control supportJonghwan Choi1-3/+68
Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-07-13[CPUFREQ] S5PV210: Add additional symantics for "relation" in cpufreq with pmHuisung Kang1-0/+28
Relation has an additional symantics other than standard. s5pv310_target funtion have below additional relation. - DISABLE_FURTHER_CPUFREQ : disable further access to target - ENABLE_FURTHER_CPUFRER : enable access to target Signed-off-by: Huisung Kang <hs1218.kang@samsung.com> Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-07-13[CPUFREQ] s5pv210-cpufreq.c: Add missing clk_putJulia Lawall1-8/+17
The successive calls to clk_get each call clk_put in the case of failure, but this is not done for subsequent error handling code. The calls to clk_get are moved to the end of the function, and appropriate gotos are added. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r exists@ expression e1,e2; statement S; @@ e1 = clk_get@p1(...); ... when != e1 = e2 when != clk_put(e1) when any if (...) { ... when != clk_put(e1) when != if (...) { ... clk_put(e1) ... } * return@p3 ...; } else S // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-07-13[CPUFREQ] Move ARM Samsung cpufreq drivers to drivers/cpufreq/Kukjin Kim1-0/+484
According to discussion of the ARM arch subsystem migration, ARM cpufreq drivers move to drivers/cpufreq. So this patch adds Kconfig.arm for ARM like x86 and adds Samsung S5PV210 and EXYNOS4210 cpufreq driver compile in there. As a note, otherw will be moved. Cc: Dave Jones <davej@redhat.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>