intelli/msm_thermal: initial coding for Qualcomm S4 Pro devices

an intelligent MSM thermal throttling kernel driver designed to replace the
closed sourced thermald(aemon) from Qualcomm.

The current driver can throttle the SOC via core frequency scaling or via
core hotplug with user configurable sysfs entries to adjust the throttling
temperature thresholds for each.

Derived from Qualcomm's Open source repo.

Signed-off-by: Paul Reioux <reioux@gmail.com>

adapted for e980
intelli-thermal: fix stats calculations

Signed-off-by: Paul Reioux <reioux@gmail.com>
build script: add ramdisk
update defconfig
intelli/msm_thermal: adjust temp
e980-custom-03b
android: lowmemorykiller: add lmk parameters tunning code.

There are cases that LMK doesn't run, even when it must run.
It is due to LMK shrinker not considering memory status per zone.
So add LMK parameters(other_free, other_file) tunnig code to
consider target zone of LMK shrinker.

Change-Id: I6f1f8660d5da920a0e3af45a160499965032081d

Conflicts:
	drivers/staging/android/lowmemorykiller.c
staging: android: lowmemorykiller: Add config option to support oom_adj values

The conversion to use oom_score_adj instead of the deprecated oom_adj
values breaks existing user-space code. Add a config option to convert
oom_adj values written to oom_score_adj values if they appear to be
valid oom_adj values.

Change-Id: I68308125059b802ee2991feefb07e9703bc48549
Signed-off-by: Arve Hjønnevåg <arve@android.com>

Conflicts:
	drivers/staging/android/lowmemorykiller.c
Revert "staging: android: lowmemorykiller: Don't count reserved free memory"

This reverts commit 4971f84bfce8bd180287c8cb94136ac89d328f1d

Change-Id: I6c51caef9c6bdf0ec86d2c155aab0313c54272e8
android/lowmemorykiller: Check all tasks for death pending

The lowmemorykiller uses the TIF_MEMDIE flag to help ensure it doesn't
kill another task until the memory from the previously killed task has
been returned to the system.

However the lowmemorykiller does not currently look at tasks who do not
have a tasks->mm, but just because a process doesn't have a tasks->mm
does not mean that the task's memory has been fully returned to the
system yet.

In order to prevent the lowmemorykiller from unnecessarily killing
multiple applications in a row the lowmemorykiller has been changed to
ensure that previous killed tasks are no longer in the process list
before attempting to kill another task.

Change-Id: I7d8a8fd39ca5625e6448ed2efebfb621f6e93845
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
android/lowmemorykiller: Selectively count free CMA pages

In certain memory configurations there can be a large number of
CMA pages which are not suitable to satisfy certain memory
requests.

This large number of unsuitable pages can cause the
lowmemorykiller to not kill any tasks because the
lowmemorykiller counts all free pages.
In order to ensure the lowmemorykiller properly evaluates the
free memory only count the free CMA pages if they are suitable
for satisfying the memory request.

Change-Id: I7f06d53e2d8cfe7439e5561fe6e5209ce73b1c90
CRs-fixed: 437016
Signed-off-by: Liam Mark <lmark@codeaurora.org>
android/lowmemorykiller: Wait for memory to be freed

The memory reclaim code needs to give time to the system to
return the memory from a killed process otherwise the memory
reclaim code could run continuously, in multiple threads,
which could starve both the watchdog thread and the thread
which is responsible for returning the memory from the
killed process.

Change-Id: Ib390dbb021cb6d41e74ac64eca6fef46367daf1e
CRs-fixed: 447740
Signed-off-by: Liam Mark <lmark@codeaurora.org>

Conflicts:
	drivers/staging/android/lowmemorykiller.c
android/lowmemorykiller: Ignore tasks with freed mm

A killed task can stay in the task list long after its
memory has been returned to the system, therefore
ignore any tasks whose mm struct has been freed.

Change-Id: I76394b203b4ab2312437c839976f0ecb7b6dde4e
CRs-fixed: 450383
Signed-off-by: Liam Mark <lmark@codeaurora.org>
lowmemorykiller: fix GCC-4.7 compiler warning

Signed-off-by: Paul Reioux <reioux@gmail.com>
Android ZRAM Optimizations: adapted from Samsung JF series kernel

Signed-off-by: Paul Reioux <reioux@gmail.com>
zram swap: LMK and memcontrol update from Samsung SGS 4 update 2 source drop

Signed-off-by: Paul Reioux <reioux@gmail.com>
sched: Reduce overestimating rq->avg_idle

Date	Thu, 29 Aug 2013 13:05:34 -0700

When updating avg_idle, if the delta exceeds some max value, then avg_idle
gets set to the max, regardless of what the previous avg was. This can cause
avg_idle to often be overestimated.

This patch modifies the way we update avg_idle by always updating it with the
function call to update_avg() first. Then, if avg_idle exceeds the max, we set
it to the max.

Signed-off-by: Jason Low <jason.low2@hp.com>
Reviewed-by: Rik van Riel <riel@redhat.com>

Signed-off-by: Paul Reioux <reioux@gmail.com>
sched: Consider max cost of idle balance per sched domain

Date    Thu, 29 Aug 2013 13:05:35 -0700

In this patch, we keep track of the max cost we spend doing idle load balancing
for each sched domain. If the avg time the CPU remains idle is less then the
time we have already spent on idle balancing + the max cost of idle balancing
in the sched domain, then we don't continue to attempt the balance. We also
keep a per rq variable, max_idle_balance_cost, which keeps track of the max
time spent on newidle load balances throughout all its domains. Additionally,
we swap sched_migration_cost used in idle_balance for rq->max_idle_balance_cost.

By using the max, we avoid overrunning the average. This further reduces the chance
we attempt balancing when the CPU is not idle for longer than the cost to balance.

I also limited the max cost of each domain to 5*sysctl_sched_migration_cost as
a way to prevent the max from becoming too inflated.

Signed-off-by: Jason Low <jason.low2@hp.com>

backported for Linux 3.4

Signed-off-by: Paul Reioux <reioux@gmail.com>
sched: Periodically decay max cost of idle balance

This RFC patch builds on patch 2 and periodically decays that max value to
do idle balancing per sched domain.

Though we want to decay it fairly consistently, we may not want to lower it by
too much each time, especially since avg_idle is capped based on that value.
So I thought that decaying the value every second and lowering it by half a
percent each time appeared to be fairly reasonable.

This change would allow us to remove the limit we set on each domain's max cost
to idle balance. Also, since the max can be reduced now, we now have to
update rq->max_idle balance_cost more frequently. So after every idle balance,
we loop through the sched domain to find the max sd's newidle load balance cost
for any one domain. Then we will set rq->max_idle_balance_cost to that value.

Since we are now decaying the max cost to do idle balancing, that max cost can
also become not high enough. One possible explanation for why is that
besides the time spent on each newidle load balance, there are other costs
associated with attempting idle balancing. Idle balance also releases and
reacquires a spin lock. That cost is not counted when we keep track of each
domain's cost to do newidle load balance. Also, acquiring the rq locks can
potentially prevent other CPUs from running something useful. And after
migrating tasks, it might potentially have to pay the costs of cache misses and
refreshing tasks' cache.

Because of that, this patch also compares avg_idle with max cost to do idle
balancing + sched_migration_cost. While using the max cost helps reduce
overestimating the average idle, the sched_migration_cost can help account
for those additional costs of idle balancing.

Signed-off-by: Jason Low <jason.low2@hp.com>
[peterz: rewrote the logic, but kept the spirit]
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
backported to Linux 3.4
Signed-off-by: Paul Reioux <reioux@gmail.com>
hwrng: add randomness to system from rng sources

When bringing a new RNG source online, it seems like it would make sense
to use some of its bytes to make the system entropy pool more random,
as done with all sorts of other devices that contain per-device or
per-boot differences.

Signed-off-by: Kees Cook <keescook@chromium.org>

Signed-off-by: Paul Reioux <reioux@gmail.com>