Cpufreq: Added input event hook to ramp up cpu frequency

This will cause switch to maximum opp immediately when user
interaction occurs, i.e. touchscreen input or keypad activity.

Change-Id: I0cfe32479ef62a967f359c1bf57f97eefde7e8f7
Signed-off-by: Tero Kristo <tero.kristo@nokia.com>
Signed-off-by: Jouni Hogander <jouni.hogander@nokia.com>
[bsteuer@quicinc.com: fixed cpu_dbs_info naming, added header]
Signed-off-by: Brian Steuer <bsteuer@codeaurora.org>

Conflicts:
	include/linux/cpufreq.h
cpufreq: Make sure input handler always runs on cpu0

Make sure that only a single input handle is registered for the
ondemand governor. Force the input handler to run on cpu0 so it
will not be migrated due to cpu hotplug.

Change-Id: Ic72c34355c629da01290cf1a5e81d534aaf83d86
Signed-off-by: Brian Steuer <bsteuer@codeaurora.org>
cpufreq: Use separate workqueue for input handler

Change-Id: Iabac5c8ada9342c23f40a3fd3598805738bb8a9c
Signed-off-by: Brian Steuer <bsteuer@codeaurora.org>
cpufreq: Check all online CPUs on input event

Previously, only the first CPU in an SMP system was bumped to the
maximum clock when receiving an input event. This worked fine on
uniprocessor systems or scenarios were other CPUs tended to be
powered down. In other situations, it is better to bump up the
clocks of all CPUs that are online. This will not affect the
situations mentioned above, but it will help others.

Change-Id: Id51ebefe57ada56cefb8474cdbfebe1230432680
Signed-off-by: Brian Steuer <bsteuer@codeaurora.org>
cpufreq: Fix input handler crash

When input handler is running on a CPU not in ondemand
governor, skip making CPU frequency changes.

CRs-Fixed: 299451
Change-Id: I9fe1ac3432d7b1613d1e3766e86160e4fe61d6ec
Signed-off-by: David Ng <dave@codeaurora.org>
cpufreq : Fix crash input event handler on governor switch

When an input event and CPU1 hotplug occurs at the same
time, a race condition can happen between cpufreq and
cpu hotplug resulting in a kernel panic.
When a hotplug operation is underway on CPU1,
__cpufreq_remove_dev is called. __cpufreq_remove_dev gets
the lock, proceeds to free the policy info of the current
governor and calls the ondemand governor with a STOP event.
If an input event occurs around the same time, it waits
for __cpufreq_remove_dev to release the lock. Meanwhile,
the ondemand governor clears some of its settings, but
fails to clear its local current policy. As soon as the
input event handler acquires the lock, it now uses the
invalid ondemand current policy handle to make frequency
changes. This results in a kernel panic.

Skip making frequency changes if this condition happens.

CRs-fixed: 327622,319348
Change-Id: I78227352fc66cc3ec5ab095c45eda76a92d1ba46
Signed-off-by: Anitha Anand <anithas@codeaurora.org>
cpufreq: Extend ondemand powersave_bias for negative range

Original ondemand powersave_bias parameter allows value
range from 0 (no powersave) to 1000 (100% reduction in
calculated CPU frequency).  This change extends powersave_bias
into the negative range (-1 to -1000) to allow a corresponding
boost to CPU frequency.  When set at either limit (-1000 or
1000), ondemand timer is cancelled as periodic load
sampling at sampling_rate is not necessary.

Change-Id: I2ee05729ceec20c2e2a4c6d9ca05cecd16ab161a
Signed-off-by: David Ng <dave@codeaurora.org>
cpufreq: Fix panic when setting sampling rate

Kernel panics when trying to set the sampling rate before the ondemand
governor CPUFREQ_GOV_START notification is received.

[<c078e500>] panic+0x15c
[<c0012354>] die+0x19c
[<c0018e60>] __do_kernel_fault+0x64
[<c0793660>] do_page_fault+0x3b8
[<c0008514>] do_DataAbort+0x134
[<c0791c58>] __dabt_svc+0x38
[<c02b5c68>] __list_add+0x38
[<c078f1b0>] __mutex_lock_slowpath+0x128
[<c078fc68>] mutex_lock+0x20
[<c05409c4>] store_sampling_rate+0x98
[<c02a6648>] kobj_attr_store+0x18
[<c0183124>] sysfs_write_file+0x108
[<c0131758>] vfs_write+0xac
[<c013188c>] sys_write+0x3c
[<c000e340>] ret_fast_syscall+0x0

Initialize the mutex as part of cpufreq_gov_dbs_init().

Change-Id: Ie9014407d724d7a0a81c076be47df5d08f513407
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
cpufreq: update the input even handler to handle sync cores correctly.

Input even handler is scheduling work items to update frequency on all
online cores. This is not required in case of sync cores. Hence this
handler is updated to change frequency only on one core per a group
of synchronous CPUs.

CRs-Fixed: 389200
Change-Id: I9c0af9c05c06517ed44f77253e2ac365b4894b5b
Signed-off-by: Krishna Vanka <kvanka@codeaurora.org>
cpufreq: Make down_differential parameter configurable.

The down_differential parameter determines the down threshold for
the governor to scale down the frequency and when made configurable
provides for a variable operating range for the governor.

Usage:
cat /sys/devices/system/cpu/cpu0/cpufreq/ondemand/down_differential
echo 30 >
/sys/devices/system/cpu/cpu0/cpufreq/ondemand/down_differential

Change-Id: Ice94b8ae961aa3df7f9582c2af2275414931faed
Signed-off-by: Brian Steuer <bsteuer@codeaurora.org>
Revert "cpufreq: update the input even handler to handle sync cores correctly."

This reverts commit 749884de4f5ce5788658260b46d15373a1d3b547.

Hotplug stability issues have been observed with the original change
when booting will maxcpus set to be less than the total number
of available CPUs. Revert the change until the issue is resolved.

Change-Id: Id9a26693e23bff83dce638918525411ca02dfc3e
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
cpufreq: Avoid using smp_processor_id() in preemptible context

Even though this work item runs on only one cpu at a time (due to
queue_work_on()) it is possible for the work item to be preempted
and so use of smp_processor_id() is illegal.

BUG: using smp_processor_id() in preemptible [00000000]
code: kworker/3:1/4162 caller is dbs_refresh_callback+0xc/0x188
[<c00151b0>] (unwind_backtrace+0x0/0x120) from [<c0279058>]
(debug_smp_processor_id+0xbc/0xf0)
[<c0279058>] (debug_smp_processor_id+0xbc/0xf0) from [<c0454b54>]
(dbs_refresh_callback+0xc/0x188)
[<c0454b54>] (dbs_refresh_callback+0xc/0x188) from [<c0087290>]
(process_one_work+0x354/0x648)
[<c0087290>] (process_one_work+0x354/0x648) from [<c0089754>]
(worker_thread+0x1a8/0x2a8)
[<c0089754>] (worker_thread+0x1a8/0x2a8) from [<c008e480>]
(kthread+0x90/0xa0)
[<c008e480>] (kthread+0x90/0xa0) from [<c000f438>]
(kernel_thread_exit+0x0/0x8)

The intent of the code is to determine which CPU this work item
is running on, which we can easily do by passing that information
in a wrapper struct around the work struct. Do this so we avoid
this problem.

Change-Id: I05ca0ff2b3cbaa239930463ea0760e3e9d75145f
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
ondemand: Add support to consider other cpu load when scaling frequencies

Currently only current cpu load is considered when frequency scaling.
As a side effect of this when scheduler migrates a thread to a slower
core, the execution time increases unexpectedly.

The new algorithm not only considers current cpu load for frequency
scaling, but also takes into account load of other online cpus. The
treshold for this can be controlled using up_threshold_any_cpu_load.
When the up_threshold_any_cpu_load is crossed in any cpu then the
current cpu is set to sync_freq.

Also, when more than one cpu is online a two step ramp-up mechanism
is used. When the up_threshold_multi_core is crossed the cpu is ramped
up to optimal_freq which is less than policy->max and set to a power
friendly value.

Change-Id: I64bed1b142cde1f239e73aa1f78981c78aaf59ce
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>
cpufreq: ondemand: Fix kernel warning in cpufreq_governor_dbs

GOV_STOP event destroys the timer_mutex and is not initialized back
upon GOV_START event.
The Kernel complains at mutex_lock(during GOV_LIMITS event) after
mutex_destroy.

[<c0014918>] (unwind_backtrace+0x0/0x11c)
[<c007c004>] (warn_slowpath_common+0x4c/0x64)
[<c007c034>] (warn_slowpath_null+0x18/0x1c)
[<c079eef8>] (__mutex_lock_slowpath+0x130/0x3c4)
[<c079f1ac>] (mutex_lock+0x20/0x3c) from [<c0540900>]
[<c0540900>] (cpufreq_governor_dbs+0x3c8/0x468)
[<c053d500>] (__cpufreq_governor+0x90/0xe0)
[<c053d774>] (__cpufreq_set_policy+0x224/0x258)
[<c053da58>] (cpufreq_add_dev_interface+0x2b0/0x308)
[<c053e784>] (cpufreq_add_dev+0x500/0x56c)
[<c079247c>] (cpufreq_cpu_callback+0x88/0x9c)
[<c07a2ca8>] (notifier_call_chain+0x38/0x68)
[<c007ded0>] (__cpu_notify+0x28/0x40)
[<c0790024>] (_cpu_up+0xe4/0x118)
[<c0790024>] (cpu_up+0x64/0x80)
[<c0765840>] (store_online+0x48/0x78)
[<c038d0c8>] (dev_attr_store+0x18/0x24)
[<c017be40>] (sysfs_write_file+0x108/0x13c)
[<c012cdfc>] (vfs_write+0xb0/0x128)
[<c012d034>](sys_write+0x38/0x64)

Change-Id: Ie2a796b17209243de731ccf2ab04b7f9e7048df8
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
cpufreq: Fix optimal_freq logic on ramp down

When ondemand governor decides to ramp down the frequency, the missing
check for frequency being lower than optimal_freq was causing frequency
to be ramped down to optimal_freq even if the frequency decided by ondemand
governor was higher.

Change-Id: I00f9ae4c61ccda4039f3338dee2c29b8cb790be4
Signed-off-by: Veena Sambasivan <veenas@codeaurora.org>
msm: Synchronize CPU frequency on thread migration

Sometimes when foreground threads, crucial for UI, migrate
from a core at higher frequency to the one running at a lower
frequency, it could badly affect performance for cases like
scrolling.
This change tries to raise the frequency of the destination core
to the same value as the source core, if it is not already running
at the same or higher frequency.  In order for the ondemand
governor to have a fair idea of load in the next sample, it also
reschedules the next sample one sampling interval from the
frequency transition after which the ondemand governor again
takes over.

Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
Change-Id: I9d2fbb166b0cc042d3fd57cea75a5066df4c794b

Conflicts:
	drivers/cpufreq/cpufreq_ondemand.c
cpufreq: Use dedicated high-priority workqueues

In the process of scaling CPU frequencies, cpufreq and the APIS is
calls may hold resources that will prevent threads critical for
system stability from running.

Specifically, thermal-mitigation software may need to respond
quickly to high-temperature conditions and throttle the CPU speed
in an effort to cool down. If the system is already in the middle
of a CPU frequency switch being executed on behalf of a cpufreq
governor, thermal mitigation will be blocked until the scaling
action has completed. If the system is under heave load of medium
or high-priority threads, this may take a long while and the system
may potentially surpass thermal limits in the meantime.

Resolve this by using high priority workqueues for all ondemand
and conservative governor scaling operations.  This will allow them
to complete promptly and release their hold on resources necessary
for maintaining system stability.

Change-Id: I2f56052c131442838036cf4cdd8059f7c09bb805
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
Signed-off-by: Ajay Dudani <adudani@codeaurora.org>
cpufreq: ondemand: change freq sync code to use per-CPU kthreads

The migration notifier may run in a context where it is not safe to
enqueue a work item. For example:

(__queue_work+0x1f4/0x40c)
(queue_work_on+0x34/0x44)
(dbs_migration_notify+0x2c/0x40)
(notifier_call_chain+0x38/0x68)
(__atomic_notifier_call_chain+0x34/0x44)
(atomic_notifier_call_chain+0x14/0x18)
(try_to_wake_up+0x350/0x36c)
(autoremove_wake_function+0xc/0x34)
(__wake_up_common+0x48/0x7c)
(__wake_up+0x3c/0x50)
(trustee_thread+0x1d0/0x528)
(kthread+0x80/0x8c)

The trustee code already takes a lock internal to the workqueue
implementation and is not expecting a wake up to come around and
enter the workqueue code again, where the same lock will be needed.

Instead of relying on a workqueue, use a per-CPU kthread to do
the frequency syncing.

Change-Id: I7555ee40867792fa8ec4ea8f9a6309323775e797
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
Signed-off-by: Ajay Dudani <adudani@codeaurora.org>

Conflicts:
	drivers/cpufreq/cpufreq_ondemand.c
cpufreq: ondemand: Fix store_powersave_bias() race with hotplug

store_powersave_bias() assumes that CPUs will not be taken offline or
brought online while executing its for_each_online_cpu() loops. Fix
this race by blocking hotplug while executing in these loop.

CRs-Fixed: 494407
Change-Id: I0d5520444ec21a8d9b12fb73c06ac8442449fa85
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
cpufreq: ondemand: Fix locking in store_powersave_bias

store_powersave_bias() assumes that dbs_info->cur_policy will
not change while it is executing. If it does, memory corruption
can potentially result. Fix this by acquiring the dbs_lock.

Most noticeably, this resolves timer-related list corruptions
encountered when queue_delayed_work_on() is called from within
store_powersave_bias() while a CPU is being hotplugged in and
out.

CRs-Fixed: 494407
Change-Id: I0fd5cbef6834545274cad9481e574ec50b37b871
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>