[CPUFREQ] ondemand: add down_differential per cafs/msm-2.6.38
[CPUFREQ] ondemand: remove mutex from store_down_differential
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>
[CPUFREQ] move (un)lock_policy_rwsem_write define to header
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
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
Signed-off-by: Anitha Anand <anithas@codeaurora.org>
(cherry picked from commit 3dd6509401d44d16231002fbe8674f4e5f29a1a2)

Change-Id: I37a3d97bc74c828669e71af52d8f4012f108e917
Signed-off-by: Swetha Basineni <sbasin@codeaurora.org>

Conflicts:

	drivers/cpufreq/cpufreq_ondemand.c
[CPUFREQ] oops we arent multi-cpu ready
[CPUFREQ] Don't set stat->last_index to -1 if the pol->cur has incorrect value.

If the driver submitted an non-existing pol>cur value (say it
used the default initialized value of zero), when the cpufreq
stats tries to setup its initial values it incorrectly sets
stat->last_index to -1 (or 0xfffff...). And cpufreq_stats_update
tries to update at that index location and fails.

This can be caused by:

stat->last_index = freq_table_get_index(stat, policy->cur);

not finding the appropiate frequency in the table (b/c the policy->cur
is wrong) and we end up crashing. The fix however is
concentrated in the 'cpufreq_stats_update' as the last_index
(and old_index) are updated there. Which means it can reset
the last_index to -1 again and on the next iteration cause a crash.

Without this patch, the following crash is observed:

powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3700+ (1 cpu cores) (version 2.20.00)
powernow-k8: fid 0x2 (1000 MHz), vid 0x12
powernow-k8: fid 0xa (1800 MHz), vid 0xa
powernow-k8: fid 0xc (2000 MHz), vid 0x8
powernow-k8: fid 0xe (2200 MHz), vid 0x8
Marking TSC unstable due to cpufreq changes
powernow-k8: fid trans failed, fid 0x2, curr 0x0
BUG: unable to handle kernel paging request at ffff880807e07b78
IP: [<ffffffff81479163>] cpufreq_stats_update+0x46/0x5b
.. snip..
Pid: 1, comm: swapper Not tainted 3.0.0-rc2 #45 MICRO-STAR INTERNATIONAL CO., LTD MS-7094/MS-7094
..snip..
Call Trace:
 [<ffffffff81479248>] cpufreq_stat_notifier_trans+0x48/0x7c
 [<ffffffff81095d68>] notifier_call_chain+0x32/0x5e
 [<ffffffff81095e6b>] __srcu_notifier_call_chain+0x47/0x63
 [<ffffffff81095e96>] srcu_notifier_call_chain+0xf/0x11
 [<ffffffff81477e7a>] cpufreq_notify_transition+0x111/0x134
 [<ffffffff8147b0d4>] powernowk8_target+0x53b/0x617
 [<ffffffff8147723a>] __cpufreq_driver_target+0x2e/0x30
 [<ffffffff8147a127>] cpufreq_governor_dbs+0x339/0x356
 [<ffffffff81477394>] __cpufreq_governor+0xa8/0xe9
 [<ffffffff81477525>] __cpufreq_set_policy+0x132/0x13e
 [<ffffffff8147848d>] cpufreq_add_dev_interface+0x272/0x28c

Reported-by: Tobias Diedrich <ranma+xen@tdiedrich.de>
Tested-by: Tobias Diedrich <ranma+xen@tdiedrich.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Revert "clean up merge error"

This reverts commit 9bb51f3a9b4fabfd5b9ec38c4a66a7a1c1f87809.

this wasnt an error and should be there
[CPUFREQ] ondemand: add filter for dbs_input_connect

only rampup cpu on certain inputs (patch from shaky156)