android: lowmemorykiller: modify return values to avoid extra calls

If the shrinker returns a large cache size, it will get called
repeatedly, proportional to the cache size divided by 128.  If
no processes to kill were found on the last pass through the
shrinker, there is no reason calling it again immediately will
find a process to kill.

Avoid the extra calls to the shrinker by:
Returning 0 when the shrinker is called with 0 and there are plenty
of free or file pages.  Avoids calling the shrinker at all during
this pass.
Returning rem when a thread is already dying.  Avoids telling the
shrinker core that the lowmemorykiller is making immense amounts
of forward progress.
Returning -1 when no process was selected for death.  Avoids calling
the shrinker again when nothing has changed.

Change-Id: I08f06063084f6070e71ac6afa7b14377149f3685
Signed-off-by: Colin Cross <ccross@android.com>
Staging: android: binder: Add binder buffers to kmemleak

Some binder_transaction structs are only referenced by a
binder_buffer. This could cause kmemleak to report them as
unreferenced.

Change-Id: I939540faa547afac4284f70f0e08ceb57a7a823d
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Staging: android: binder: Fix memory leak on thread/process exit

If a thread or process exited while a reply, one-way transaction or
death notification was pending, the struct holding the pending work
was leaked.

Change-Id: I2eaafaba1c0ecda3ec0872d449dc16d0721c21e7
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Staging: android: binder: Allow using highmem for binder buffers

The default kernel mapping for the pages allocated for the binder
buffers is never used. Set the __GFP_HIGHMEM flag when allocating
these pages so we don't needlessly use low memory pages that may
be required elsewhere.

Change-Id: I19be5fd89c194abcb8b041e2dd6c4d71ae7b1cc2
Signed-off-by: Arve Hjønnevåg <arve@android.com>
msm: pm: Support for Krait Retention

Introduce a new low power state for Krait, retention.
This state will lower the voltage to the Krait core to
retention voltage in addition to clock gating. This state
will be in between WFI and Standalone power collapse in
terms of time overhead and power savings.

Change-Id: I6b1f0a0d2e4954a705a047fd4a07f4dd1fb3518a
Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
(cherry picked from commit d27ca4a7526a890f9d2979acefda3561e49d2e66)

Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
(cherry picked from commit 3af7249c36ab53923fdf216df3b3ba2c7f847851)

Signed-off-by: Derek Cannata <thederekjay@gmail.com>
msm: pm: Adjust for events with hard wakeups

Get the next event and setup a new timer to expire
earlier than the next event after accounting for the
latency of the low power state being entered. This
will ensure that the core is active to handle the event
when it arrives.

(cherry picked from commit dc318fd0c3d04f7af9720af50c0eb0c6ed2653e9)
Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>

Change-Id: I6609a886df227c68ce78e270ef7d235e07725d44
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
msm: pm-8x60: Fix bug where device enter low power mode

An incorrect ordering in the check of allowed modes, results in
standalone power collapse not getting selected when the secondary
cores are online.

Change-Id: Idc7177b78bd0ce7563cc27afbf6c12d3bc1f9f9a
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
msm: pm: Add support for retention on each core

Allow each core on 8974 to enter retention and retain
the state of the CPU. On 8960 as hardware restriction does
not permit all cores to enter retention at the same time,
allow only core 0 to enter retention when all other cores
are offline to maintain backward compatibility.

Change-Id: I6690e901afc9fa3a27010c264fa3acc9a0722c1a
Signed-off-by: Priyanka Mathur <pmathur@codeaurora.org>
msm: pm-8x60: Do not default to WFI when not enabled

Return MSM_PM_SLEEP_MODE_NOT_SELECTED in msm_pm_idle_prepare as the
default mode instead of WFI. Skip enter low power mode when this
mode is selected.

Change-Id: Id4a07ba1353b358726c81ed441e0327a9154de8a
Signed-off-by: Priyanka Mathur <pmathur@codeaurora.org>
msm: pm: Add API to enable/disable retention mode

On 8974 targets, retention mode voltage is controlled by the LDO
regulator, which in turn is powered through a ganged PMIC regulators. At
certain low voltage levels, the ganged PMIC will not be able to power
the LDO retention voltage. The regulator framework would invoke this
API to enable/disable retention mode in these scenarios.

When disabling retention modes, send a IPI to wakeup all online cores
out of idle, to ensure that no core is in a retention low power mode.
Also, disabled support for retention during suspend/hotplug operations
to ensure that a CPU isn't already in retention when the voltage is
lowered. This shouldn't have an effect on suspend, as the driver always
chooses the deepest sleep mode for suspend/hotplug.

Change-Id: I0af18168968c2aaf05ca99188d30762612c87de6
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
msm: tracing: Add ftrace support for LPM driver

Add trace event support to capture various parameters
of low power modes like power collapse, standalone power
collapse, retention and wfi during its entry and exit.

Change-Id: I0f8b918702ae47b354aa193aa7ef20b48110fb0f
Signed-off-by: Priyanka Mathur <pmathur@codeaurora.org>
msm: tracing: Add ftrace support for LPM resources

Add trace event support to capture sleep value for
each of the lpm resources l2, pxo, vdd mem and vdd
dig during power collapse.

Change-Id: Ie0d7528ecd5a87631ff584953bfe0bd77043add9
Signed-off-by: Priyanka Mathur <pmathur@codeaurora.org>
msm: pm-8x60: Merge msm_pm_idle_prepare into msm_pm_idle_enter

Modify LPM drivers to call msm_pm_idle_enter when idle. enter_sleep will
look at available time to sleep and the latencies of different low power
modes and decide the low power mode to enter. It returns the low power
mode enumeration back to cpuidle.

Change-Id: Icbdaa6604824ea7d10c27f2d932d47d354da425e
Signed-off-by: Priyanka Mathur <pmathur@codeaurora.org>

Conflicts:

	arch/arm/mach-msm/cpuidle.c
mach-msm: trace: fixup
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>
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>
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>