Fix get_time for Samsung vibrator and re-enable KTIME_SCALAR
[CPUFREQ] CPUfreq ondemand: update sampling rate without waiting for next sampling

When a new sampling rate is shorter than the current one, (e.g., 1 sec
--> 10 ms) regardless how short the new one is, the current ondemand
mechanism wait for the previously set timer to be expired.

For example, if the user has just expressed that the sampling rate
should be 10 ms from now and the previous was 1000 ms, the new rate may
become effective 999 ms later, which could be not acceptable for the
user if the user has intended to speed up sampling because the system is
expected to react to CPU load fluctuation quickly from __now__.

In order to address this issue, we need to cancel the previously set
timer (schedule_delayed_work) and reset the timer if resetting timer is
expected to trigger the delayed_work ealier.

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Dave Jones <davej@redhat.com>
msm: cpufreq: Fix store_powersave_bias to account for sync' CPUs.

Current code assumes that all online CPUs runs their own timers to
collect CPU samples for demand based switching (dbs). But in case of
synchronous CPUs, ondemand governor registers only one timer at init
time because both CPUs are accounted in the same timer call. Hence
trying to restart/cancel dbs timers for all online CPUs is not legal
for these CPUs. This change fixes above function to restart/cancel
timers only once for group of synchronous CPUs.

Change-Id: I23f1697783a65f125679a07a076620e8fa5e62d5
Signed-off-by: Krishna Vanka <kvanka@codeaurora.org>
msm: cpufreq: Fix the race between dbs_refresh and hotplug.

The demand based switching responds to input events and schedules
work items on all online cpus to increase the frequency. This will
call the dbs_refresh_callback on respective cpu. If this work item
kicks in while cpu1 is progressing its way through cpufreq_add_dev,
there is a chance that work item grabs the cpu_policy_rwsem of cpu1
and relases that of cpu0, when add device is working through releas-
ing lock of cpu1 and reaquiring that of cpu0. This is locking out
cpu1 when it tries to come up online next time. The fix is hold the
hot plug lock while processing refresh work items.

CRs-Fixed: 362444
Change-Id: I57db7c7a9b58369bf059302896f3bf9eca2bc2bb
Signed-off-by: Krishna Vanka <kvanka@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>
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>
msm: rpc: hold spinlock while doing wait_event

To prevent a race condition between wake_up called by
msm_rpcrouter_xprt_notify and wait_event in rr_read
hold a spinlock irqsave to prevent the system from going into
sleep when there is pending SMD data to process.

CRs-Fixed: 393416
Signed-off-by: Angshuman Sarkar <angshuman@codeaurora.org>
(cherry picked from commit 902de08f6670ddba147609e8b9f895dadf2275d9)

Change-Id: Ib7d8a868e1e968fcc8eeca53e2c1c2eeec8dd965
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
Squashed update of kernel from 3.0.65 to 3.0.66
Revert "lowmemorykiller: Compact memory when killing processes"

This reverts commit 77da76068d5c1471d9727ab0c961a71862a040c7.
Revert "ondemand: Add support to consider other cpu load when scaling frequencies"

This reverts commit c48999edb169a929f969862a4254c0313d664db0.
Update defconfigs