During scaling up of cpu frequency, loops_per_jiffy
is updated upon invoking PRECHANGE notifier.
If setting to new frequency fails in cpufreq driver,
lpj is left at incorrect value.

Hence update lpj only if cpu frequency is changed,
i.e. upon invoking POSTCHANGE notifier.

Penalty would be that during time period between
changing cpu frequency & invocation of POSTCHANGE
notifier, udelay(x) may not gurantee minimal delay
of 'x' us for frequency scaling up operation.

Perhaps a better solution would be to define
CPUFREQ_ABORTCHANGE & handle accordingly, but then
it would be more intrusive (using ABORTCHANGE may
help drivers also; if any has registered notifier
and expect POST for a PRECHANGE, their needs can
be taken care using ABORT)
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Signed-off-by: NDave Jones <davej@redhat.com>

CPU frequency is guranteed to be changed on notifier callback with
CPUFREQ_POSTCHANGE. Notifier callback with CPUFREQ_PRECHANGE does
not gurantee a change in frequency; after it, if cpufreq driver is
unable to change CPU to new frequency. This results in wrong
information being fed to user (if setting CPU frequency fails)
upon doing like,

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed

Hence in userspace governer update cpu_cur_freq only if notifier
has been called with POSTCHANGE.
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Signed-off-by: NDave Jones <davej@redhat.com>

CPUFREQ Remove wall variable from cpufreq_gov_dbs_init()

Remove wall variable from cpufreq_gov_dbs_init() as
get_cpu_idle_time_us() no longer updates the last_update_time
unconditionally. Passing non-NULL last_update_time address
will result in accounting additional idle time with
update_ts_time_stats() before returning idle_sleeptime.
Signed-off-by: NKamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Signed-off-by: NDave Jones <davej@redhat.com>
--
 drivers/cpufreq/cpufreq_ondemand.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

This patch is modify code for stable working
1. Remove unused register access code
2. Change sequence for frequency changing
Signed-off-by: NJaecheol Lee <jc.lee@samsung.com>
Signed-off-by: NJonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: NJongpill Lee <boyko.lee@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NDave Jones <davej@redhat.com>

This patch is changes frequency table for cpu divider for stable frequency.
Signed-off-by: NJaecheol Lee <jc.lee@samsung.com>
Signed-off-by: NJongpill Lee <boyko.lee@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NDave Jones <davej@redhat.com>

This patch removes code for bus on cpufreq because the code
for bus frequency changing moves to busfreq driver.
So code about bus on cpufreq is not necessary.
Signed-off-by: NJaecheol Lee <jc.lee@samsung.com>
Signed-off-by: NJongpill Lee <boyko.lee@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NDave Jones <davej@redhat.com>

They're already consistent but it saves remembering to do so.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NDave Jones <davej@redhat.com>

The variable i is removed by commit ded84337
"[CPUFREQ] db8500: remove unneeded for loop iteration over freq_table",
but current code to print available frequencies still uses the i variable.
Thus add the i variable back to fix below buld error:

  CC      drivers/cpufreq/db8500-cpufreq.o
drivers/cpufreq/db8500-cpufreq.c: In function 'db8500_cpufreq_init':
drivers/cpufreq/db8500-cpufreq.c:123: error: 'i' undeclared (first use in this function)
drivers/cpufreq/db8500-cpufreq.c:123: error: (Each undeclared identifier is reported only once
drivers/cpufreq/db8500-cpufreq.c:123: error: for each function it appears in.)
make[2]: *** [drivers/cpufreq/db8500-cpufreq.o] Error 1
make[1]: *** [drivers/cpufreq] Error 2
make: *** [drivers] Error 2

This patch also fixes using uninitialized i variable as array index.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NDave Jones <davej@redhat.com>

Minor fixups to work starting with v3.2:
- use the new omap_device API for getting a device by name.
- need to include <linux/module.h>
Signed-off-by: NKevin Hilman <khilman@ti.com>

We use a single frequency table for multiple CPUs. But, with
OMAP4, since we have multiple CPUs, the cpu_init call for CPU1
causes freq_table previously allocated for CPU0 to be overwritten.
In addition, we dont free the table on exit path.

We solve this by maintaining an atomic type counter to ensure
just a single table exists at a given time.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Release the mpu_clk in fail paths.
Reported-by: NTodd Poynor <toddpoynor@google.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

OMAP2 is the only family using clk_[init|exit]_cpufreq_table, however,
the cpufreq code does not currently use clk_init_cpufreq_table. As a
result, it is unusuable for OMAP2 and only usable only on platforms
using OPP library.

Remove the unbalanced clk_exit_cpufreq_table().  Any platforms where
OPPs are not availble will fail on init because a freq table will not
be properly initialized.
Signed-off-by: NNishanth Menon <nm@ti.com>
[khilman@ti.com: changelog edits, and graceful failure mode changes]
Signed-off-by: NKevin Hilman <khilman@ti.com>

OMAP2+ all have frequency tables, hence the hacks we had for older
silicon do not need to be carried forward. As part of this change,
use cpufreq_frequency_table_target to find the best match for
frequency requested.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

if we do not have mpu_dev we normally fail in cpu_init. It is better
to fail driver registration if the devices are not available.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Clk name does'nt need to dynamically detected during clk init.
move them off to driver initialization, if we dont have a clk name,
there is no point in registering the driver anyways. The actual clk
get and put is left at cpu_init and exit functions.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Sometimes, bootloaders starts up with a frequency which is not
in the OPP table. At cpu_init, policy->cur contains the frequency
we pick at boot.  It is possible that system might have fixed
it's boot frequency later on as part of power initialization.
After this condition, the first call to omap_target results in the
following:

omap_getspeed(actual device frequency) != policy->cur(frequency that
cpufreq thinks that the system is at), and it is possible that
freqs.old == freqs.new (because the governor requested a scale down).

We exit without triggering the notifiers in the current code, which
does'nt let code which depends on cpufreq_notify_transition to have
accurate information as to what the system frequency is.

Instead, we do a normal transition if policy->cur is wrong, then,
freqs.old will be the actual cpu frequency, freqs.new will be the
actual new cpu frequency and all required notifiers have the accurate
information.
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NColin Cross <ccross@google.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Enable all CPUs in the shared policy in the CPU init callback.
Otherwise, the governor CPUFREQ_GOV_START event is invoked with
a policy that only includes the first CPU, leaving other CPUs
uninitialized by the governor.
Signed-off-by: NTodd Poynor <toddpoynor@google.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

On OMAP SMP configuartion, both processors share the voltage
and clock. So both CPUs needs to be scaled together and hence
needs software co-ordination.

Also, update lpj with reference value to avoid progressive error.

Adjust _both_ the per-cpu loops_per_jiffy and global lpj. Calibrate
them with with reference to the initial values to avoid a
progressively bigger and bigger error in the value over time.

While at this, re-use the notifiers for UP/SMP since on UP machine or
UP_ON_SMP policy->cpus mask would contain only the boot CPU.

Based on initial SMP support by Santosh Shilimkar.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
[khilman@ti.com: due to overlap/rework, combined original Santosh patch
                 and Russell's rework]
Signed-off-by: NKevin Hilman <khilman@ti.com>

Move OMAP cpufreq driver from arch/arm/mach-omap2 into
drivers/cpufreq, along with a few cleanups:

- generalize support for better handling of different SoCs in the OMAP
- use OPP layer instead of OMAP clock internals for frequency table init
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
[khilman@ti.com: move to drivers]
Signed-off-by: NKevin Hilman <khilman@ti.com>

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: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

So that we can clean up the header files and not be relying
on implicit includes from device.h ---> module.h
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

This adds support for the 200 MHz frequency mode of the
DB8500 SoC, and prints the available frequencies at init
time.

Cc: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NDave Jones <davej@redhat.com>

Don't know why to do the loop iteration here. It looks unneeded.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NDave Jones <davej@redhat.com>

We have various bootloaders for Exynos4210 machines. Some of they
set the ARM core frequency at boot time even when the boot is a resume
from suspend-to-RAM. Such changes may create inconsistency in the
data of CPUFREQ driver and have incurred hang issues with suspend-to-RAM.

This patch enables to save and restore CPU frequencies with pm-notifier and
sets the frequency at the initial (boot-time) value so that there wouldn't
be any inconsistency between bootloader and kernel. This patch does not
use CPUFREQ's suspend/resume callbacks because they are syscore-ops, which
do not allow to use mutex that is being used by regulators that are used by
the target function.

This also prevents any CPUFREQ transitions during suspend-resume context,
which could be dangerous at noirq-context along with regulator framework.
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NDave Jones <davej@redhat.com>

The same clock is used for all cpus so we must notify the frequency change
for each one in order to update the configuration of all twd clockevents.

change since V1:
* use policy->cpus instead of cpu_online_mask
Signed-off-by: NVincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: NDave Jones <davej@redhat.com>

Add new module option "set_max_voltage".
One of the lessons learned from Adaptive Powersaver is that voltage values
returned by processor are for worst case scenario. But required voltage
is changing with CPU temperature. And even processors produced in the same
batch can have different minimum voltage necessary for stable work at
specified frequency.
On Elonex Webbook, once system starts, temperature never drops below
48 deg. C. Loading module after systems start allows user to lower CPU
voltage and still have stable system.
Sadly C7 doesn't allow code to set frequency or voltage from outside limits.
If you ask it to set voltage lower then minimum it will ignore you. Thats
why it isn't possible to change minimum voltage for minimum frequency too.
Changing maximum voltage on Elonex Webbook leads to very good results. Looks
like VIA C7 1.6GHz 1084mV can safetly run at 892mV. This means 83% of
orginal value. If same percentage applies to power generated it means 12.5W
in the place of 15W. Not much, but it is better then nothing.
Only C7-M makes it possible.
If voltage is too low by 16mV or more you will experience kernel panic.
If voltage is too low by 32mV or more you will experience system freeze.
Signed-off-by: NRafał Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>

Call ACPI function to get BIOS limit for CPU frequency.
Fail if processor would like to run at higher frequency.
Allow user to ignore BIOS limit.

eps: Detected VIA Model D C7-M
eps: Current voltage = 1084mV
eps: Current multiplier = 16
eps: Highest voltage = 1084mV
eps: Highest multiplier = 16
eps: Lowest voltage = 844mV
eps: Lowest multiplier = 4
eps: ACPI limit 1.60GHz
Signed-off-by: NRafał Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>

Some systems are using 1,2Ghz@844mV processors running at 600MHz@796mV.
Try to detect such systems and don't touch anything on it. If CPU doesn't have
P-States in BIOS it should run at maximum frequency.
Allow user to bypass checks by means of two new options.
Don't set frequency to maximum on module unloading to avoid bada boom.
It is also possible that some processors may have incorrect values in min/max
registers caused by error in manufacturing process. Probably it would be BIOS
job to set them to right frequency and P-States tables would have correct
values inside.
Two additional sanity checks for voltage.
Signed-off-by: NRafał Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>

This patch enables 'scaling_available_frequencies' attribute
showing list of available frequencies.
Signed-off-by: NDonggeun Kim <dg77.kim@samsung.com>
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NKyungMin Park <kyungmin.park@samsung.com>
Signed-off-by: NDave Jones <davej@redhat.com>

Now that we have a shared API between the DB8500 and DB5500
PRCMU's, switch to using this neutral API instead. We delete the
parts of db8500-prcmu.h that is now PRCMU-neutral, and calls will
be diverted to respective driver. Common registers are in
dbx500-prcmu-regs.h and common accessors and defines in
<linux/mfd/dbx500-prcmu.h> This way we get a a lot more
abstraction and code reuse.
Signed-off-by: NMattias Nilsson <mattias.i.nilsson@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

per_cpu(processors, n) can be NULL, resulting in:

  Loading CPUFreq modules[  437.661360] BUG: unable to handle kernel NULL pointer dereference at (null)
  IP: [<ffffffffa0434314>] pcc_cpufreq_cpu_init+0x74/0x220 [pcc_cpufreq]

It's better to avoid the oops by failing the driver, and allowing the
system to boot.
Signed-off-by: NNaga Chumbalkar <nagananda.chumbalkar@hp.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Len Brown <lenb@kernel.org>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

update_ts_time_stat currently updates idle time even if we are in
iowait loop at the moment. The only real users of the idle counter
(via get_cpu_idle_time_us) are CPU governors and they expect to get
cumulative time for both idle and iowait times.
The value (idle_sleeptime) is also printed to userspace by print_cpu
but it prints both idle and iowait times so the idle part is misleading.

Let's clean this up and fix update_ts_time_stat to account both counters
properly and update consumers of idle to consider iowait time as well.
If we do this we might use get_cpu_{idle,iowait}_time_us from other
contexts as well and we will get expected values.
Signed-off-by: NMichal Hocko <mhocko@suse.cz>
Cc: Dave Jones <davej@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Link: http://lkml.kernel.org/r/e9c909c221a8da402c4da07e4cd968c3218f8eb1.1314172057.git.mhocko@suse.czSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Acked-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add simple cpufreq driver for Maple-based boards (ppc970fx evaluation
kit and others). Driver is based on a cpufreq driver for 64-bit powermac
boxes with all pmac-dependant features removed and simple cleanup
applied.
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The following symbols are needlessly defined global:
  s5pv210_verify_speed
  s5pv210_getspeed

Make them static.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NDave Jones <davej@redhat.com>

The following symbols are needlessly defined global:
  exynos4_verify_speed
  exynos4_getspeed
  exynos4_set_clkdiv

Make them static.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NDave Jones <davej@redhat.com>

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: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NDave Jones <davej@redhat.com>

When system reboot, the CPUFREQ level should be 800MHz to prevent
system lockup.
Signed-off-by: NHuisung Kang <hs1218.kang@samsung.com>
Signed-off-by: NJonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NDave Jones <davej@redhat.com>

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: NTodd Poynor <toddpoynor@google.com>
Signed-off-by: NJonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NDave Jones <davej@redhat.com>

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: NArve Hjønnevåg <arve@android.com>
Signed-off-by: NJonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NDave Jones <davej@redhat.com>