msm: mpm: Fix buffer overflow in bitmap

Change-Id: Id6db59771438228c7387bf71eefa637c51f7f5b8
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
msm: rpm: Make RPM control offset enum target-specific

Make RPM control offset enum target specific, as they are not common
between MSM8660 and MSM8960.

Change-Id: Ia969b7d700ceeae92b1d8eb00816e3789a7279fe
Signed-off-by: Eugene Seah <eseah@codeaurora.org>
msm: rpm: Check and validate RPM driver version

An incompatible RPM driver version may cause Linux to boot with
RPM ignoring all requests from Linux, to prevent that, ensure
the versions are compatible before intializing the RPM driver.

Board will fail to boot if the RPM driver detects an incompatible
version.

Change-Id: Id3c39528723bcfe2509c1e78d6ed0b600c182e5b
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
kgsl: Fix compiling when CONFIG_MSM_IOMMU is disabled
iprj: Disable some annoying logspam
cpufreq: interactive: New 'interactive' governor

New interactive governor.

This governor is designed for latency sensitive workloads, UI interaction for
example.

Advantages:
+ significantly more responsive to ramp cpu up when required (UI interaction)
+ more consistent ramping, existing governors do their cpu load sampling in a
workqueue context, the 'interactive' governor does this in a timer context, which
gives more consistent cpu load sampling.
+ higher priority for cpu frequency increase, rt_workqueue is used for scaling
up, giving the remaining tasks the cpu performance benefit, unlike existing
governors which schedule rampup work to occur after your performance starved
tasks have completed.

Existing governors sample cpu load at a particular rate, typically
every X ms. Which can lead to under powering UI threads when the user has
interacted with an idle system until the next sample period happns.

The 'interactive' governor has a different approach. Instead of sampling the cpu
at a specified rate, the governor will scale the cpu frequency up when coming
out of idle. When the cpu comes out of idle, a timer is configured to fire
within 1-2 ticks. If the cpu is 100% busy from exiting idle to when the timer
fires then we assume the cpu is underpowered and ramp to MAX speed.

If the cpu was not 100% busy, then the governor evaluates the cpu load over the
last 'min_sample_rate' (default 50000 uS) to determine the cpu speed to ramp down
to.

There is only one tuneable for this governor:
/sys/devices/system/cpu/cpufreq/interactive/min_sample_rate:
	The minimum ammount of time to spend at the current frequency before
	ramping down. This is to ensure that the governor has seen enough
	historic cpu load data to determine the appropriate workload.
	Default is 5000 uS.

Signed-off-by: Mike Chan <mike@android.com>
Change-Id: I686d2f57b0ed9cbb73217403b7438be5719588d2

cpufreq: interactive: Fix potential division by zero

cpufreq: interactive: Changes to interactive governor

Changes include:
* May scale up to intermediate speeds after scaling down, rather than
scale to max speed and then only scale down until max speed needed.

* Tweaked thresholds at which max speed requested (previously CPU must
have been 100% busy since idle exit timer started, now will go max if at
least 85% busy) and default minimum sample time raised to 80ms. Tweaking
based on UI tests, still in progress.

* SMP fixes.

* Fixed attempted multiple delete of sysfs group on governor stop.
Set a just-in-case-CPU-goes-busy-again timer even if nr_running == 0 at
timer function run time, but cancel if that CPU goes idle (and don't
re-arm timer if that CPU is currently idle).

* Re-evaluate speed if a CPU goes idle while above min speed (and no timer
currently set) in case the platform requires all CPUs to be at the same
speed.

* Realtime workqueues disappeared upstream, convert speed up workqueue to
a realtime task. Average scheduling latency measured significantly less
than WQ_HIGHPRI.

* Timers are not deferrable, must wake CPU from idle, since we now
re-evaluate speed for idle CPUs.

* CPU load is computed from higher of short-term load since idle exit vs.
long-term load since last frequency change, to avoid dropping speed
during temporary dips in load on long-term-busy CPU.

* Avoid 1 CPU starting new idle exit load eval interval in a race with
timer running on another CPU.

* New fugly debugging printfs should be reworked or go away eventually.

Change-Id: I606b5c1850637c35a7814309df12362d5c044825
via: https://review.source.android.com//#change,15809
cpufreq interactive governor save/restore IRQs around cpumask spinlocks

Need to use irqsave/restore spin locking for cpumasks since these
are accessed in timers and in thread context.

Change-Id: I4a53eaf0ced7e73b445feddba90ec11482de9126
Signed-off-by: Todd Poynor <toddpoynor@google.com>
cpufreq interactive governor: fix crash on CPU shutdown

Don't reference the saved copy of the CPU's cpufreq policy
pointer after the governor has been stopped for the CPU.

When the governor is stopped for a CPU:

* Use del_timer_sync() to wait for a currently-running timer
function to stop.

* Delete the timer when the governor is stopped for the
associated CPU, not when the last CPU is stopped.

* Flush any speed down work ongoing.

* Reset the timestamp that is used to tell if the timer function
has had a chance to run since last idle exit.

Check the governor enabled flag for the CPU before re-arming the
timer from within the timer function and at idle exit (in case
stopping the governor at runtime).

Check the governor enabled flag for the CPU in the worker
function and thread before using the policy pointer.  (There is
still a tiny window in the thread that needs more work to close.)

Change-Id: Ifaddf7a495a8dae15a579a57bdc654f7c47f6ada
Signed-off-by: Todd Poynor <toddpoynor@google.com>
CPU hotplug, re-create sysfs directory and symlinks

commit 27ecddc2a9f99ce4ac9a59a0acd77f7100b6d034 upstream.

When we discover CPUs that are affected by each other's
frequency/voltage transitions, the first CPU gets a sysfs directory
created, and rest of the siblings get symlinks. Currently, when we
hotplug off only the first CPU, all of the symlinks and the sysfs
directory gets removed. Even though rest of the siblings are still
online and functional, they are orphaned, and no longer governed by
cpufreq.

This patch, given the above scenario, creates a sysfs directory for
the first sibling and symlinks for the rest of the siblings.

Please note the recursive call, it was rather too ugly to roll it
out. And the removal of redundant NULL setting (it is already taken
care of near the top of the function).

Signed-off-by: Jacob Shin <jacob.shin@amd.com>
Acked-by: Mark Langsdorf <mark.langsdorf@amd.com>
Reviewed-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
cpufreq: interactive: fix possible Division by zero.

The following dump was seen sometimes while resuming,
the only division by zero on this function can happen after
delta_time is reassigned, since at the start of the
function, there is jump that protects against values
less than 1000.

After that, If delta_time and delta_idle == 0,
we will hit a div 0

Division by zero in kernel.
Backtrace:
[<c0057184>] (dump_backtrace+0x0/0x110) from [<c05d5ecc>] (dump_stack+0x18/0x1c)
r6:010f3000 r5:c113dfb0 r4:c004afb0 r3:c6ff0000
[<c05d5eb4>] (dump_stack+0x0/0x1c) from [<c00572cc>] (__div0+0x1c/0x20)
[<c00572b0>] (__div0+0x0/0x20) from [<c02195d4>] (Ldiv0+0x8/0x10)
[<c03dfd64>] (cpufreq_interactive_timer+0x0/0x2c0) from [<c00a7efc>] (run_timer_softirq+0x154/0x260)
[<c00a7da8>] (run_timer_softirq+0x0/0x260) from [<c00a0c8c>] (__do_softirq+0xc8/0x194)
[<c00a0bc4>] (__do_softirq+0x0/0x194) from [<c00a1008>] (irq_exit+0xb4/0xb8)
[<c00a0f54>] (irq_exit+0x0/0xb8) from [<c00584b4>] (ipi_timer+0x44/0x48)
r4:c004a040 r3:00000001
[<c0058470>] (ipi_timer+0x0/0x48) from [<c004c3e4>] (do_local_timer+0x68/0x84)
r5:c004ae2c r4:c07991e8
[<c004c37c>] (do_local_timer+0x0/0x84) from [<c0052948>] (__irq_svc+0x48/0xe0)
cpufreq interactive governor: Update target frequency calculation

Updated target frequency calculation algorithm to take into account
current rate CPU is running at:

- When CPU is running below go_maxspeed_load threshold, adjust the
target frequency based on current rate to reach tunable sustainable
load (instead of applying cpu load to max possible cpu rate).

Tuned by setting new node ("0" falls back to using max_rate):
/sys/devices/system/cpu/cpufreq/interactive/sustain_load

- When CPU is running at/above go_maxspeed_load threshold, ramp the
target frequency starting from current exponentially with tunable base
(instead of immediate jump to maximum cpu rate).

Tuned by setting new node ("0" falls back to jump to max_rate):
/sys/devices/system/cpu/cpufreq/interactive/boost_factor

Defaults for the new tunning parameters are set to "0" - so no changes
in governor default behavior.

Original-Change-Id: Ie845d747239ba177e6f06b73965c3213649f8135
Reviewed-on: http://git-master/r/34583
Reviewed-by: Aleksandr Frid <afrid@nvidia.com>
Tested-by: Aleksandr Frid <afrid@nvidia.com>
Reviewed-by: Chih-Lung Huang <lhuang@nvidia.com>
Reviewed-by: Scott Williams <scwilliams@nvidia.com>
Reviewed-by: Narendra Damahe <ndamahe@nvidia.com>
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
Reviewed-by: Diwakar Tundlam <dtundlam@nvidia.com>
cpufreq: interactive: support shared CPU scaling

Change-Id: Id5267f04067bf023f6b140b4de2e88ef7287e941
Signed-off-by: Todd Poynor <toddpoynor@google.com>
cpufreq: interactive: remove debug trace code

Remove debug trace code in preparation of upstreaming

Change-Id: I0905885e75031f5e9d7cb06878fb68c1fd06d4fe
Signed-off-by: Allen Martin <amartin@nvidia.com>
cpufreq: interactive: Add error checking on sysfs interfaces

This adds better error checking on tunable parameters on sysfs
interfaces.  Also fixes return value from these functions, previously
on success they would return 0 which would cause a infinite loop.

Change-Id: Ic05038492166f8673d007202092471f98a2f0dfa
Signed-off-by: Allen Martin <amartin@nvidia.com>
cpufreq: interactive: add sysfs control for timer rate

Add a new sysfs control that tunes the rate of the timer used to
increase cpu frequency

Change-Id: I1aa13ae54bb43aff5b3688984d2955f56aae1658
Signed-off-by: Allen Martin <amartin@nvidia.com>
cpufreq: interactive: cleanup checkpatch warnings

Cleanup some style warnings reported by checkpatch

Change-Id: Ie2e6903d52867fb3347e009d7efa3bc4ca755cea
Signed-off-by: Allen Martin <amartin@nvidia.com>

Conflicts:

	drivers/cpufreq/cpufreq_interactive.c
cpufreq: interactive: fix checkpatch warnings on long lines

Fix up checkpatch warning introduced by long lines in timer_rate
patch.

Change-Id: I22b105dafb1b49390799bb7577464da03f0f8afb
Signed-off-by: Allen Martin <amartin@nvidia.com>
cpufreq: interactive: Fix handling of SMP where CPUs must scale in tandem

The interactive governor relies on quirks of the Tegra 2 cpufreq
implementation for handling SMP systems where the CPUs do not have
separate rate controls.  It needs to determine the maximum rate
for all CPUs covered by the policy and set that speed.

Change-Id: I1ed9fa171e5a9c45a1fa5944e3fa823eb157e81f
Signed-off-by: Todd Poynor <toddpoynor@google.com>
cpufreq: interactive governor: go to intermediate hi speed before max

* Add attribute hispeed_freq, which defaults to max.

* Rename go_maxspeed_load to go_hispeed_load.

* If hit go_hispeed_load and at min speed, go to hispeed_freq;
  if hit go_hispeed_load and already above min speed go to max
  speed.

Change-Id: I1050dec5f013fc1177387352ba787a7e1c68703e
Signed-off-by: Todd Poynor <toddpoynor@google.com>
cpufreq: use system_wq instead of dedicated workqueues

With cmwq, there's no reason for cpufreq drivers to use separate
workqueues.  Remove the dedicated workqueues from cpufreq_conservative
and cpufreq_ondemand and use system_wq instead.  The work items are
already sync canceled on stop, so it's already guaranteed that no work
is running on module exit.

Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Dave Jones <davej@redhat.com>
Cc: cpufreq@vger.kernel.org