Merge pull request #6 from Tommy-Geenexus/cm-11.0

Code cleanup, backported rwsem from Linux 3.11 + some other goodies
Enable msm thermal + small fixup warning

Change-Id: I4c14d5552caa8bfc76b776f9603de45a2aeadee6
Update from .96 to .97

Change-Id: Ib3719cb40370d956dc47877cf3b263802a0b08a7
Update defconfig

Change-Id: I451ff5819421858723cbc030716aad29be29aed4
rcu: Precompute RCU_FAST_NO_HZ timer offsets

Ported from OSS commit:
    aa9b16306e3243229580ff889cc59fd66bf77973

    When a CPU is entering dyntick-idle mode, tick_nohz_stop_sched_tick()
    calls rcu_needs_cpu() see if RCU needs that CPU, and, if not, computes the
    next wakeup time based on the timer wheels.  Only later, when actually
    entering the idle loop, rcu_prepare_for_idle() will be invoked.  In some
    cases, rcu_prepare_for_idle() will post timers to wake the CPU back up.
    But all for naught: The next wakeup time for the CPU has already been
    computed, and posting a timer afterwards does not force that wakeup
    time to be recomputed.  This means that rcu_prepare_for_idle()'s have
    no effect.

    This is not a problem on a busy system because something else will wake
    up the CPU soon enough.  However, on lightly loaded systems, the CPU
    might stay asleep for a considerable length of time.  If that CPU has
    a callback that the rest of the system is waiting on, the system might
    run very slowly or (in theory) even hang.

    This commit avoids this problem by having rcu_needs_cpu() give
    tick_nohz_stop_sched_tick() an estimate of when RCU will need the CPU
    to wake back up, which tick_nohz_stop_sched_tick() takes into account
    when programming the CPU's wakeup time.  An alternative approach is
    for rcu_prepare_for_idle() to use hrtimers instead of normal timers,
    but timers are much more efficient than are hrtimers for frequently
    and repeatedly posting and cancelling a given timer, which is exactly
    what RCU_FAST_NO_HZ does.

Change-Id: I072ab911800c388d4252ea112a5b1346f24753a4
Signed-off-by: Hong-Mei Li <a21834@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/618361
SLTApproved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Signed-off-by: poondog <markj338@gmail.com>

Conflicts:
	kernel/rcutree_plugin.h
PM: enable all sleep states. Tests have shown that this will increase battery life particularly with screen off. Tests conducted with users. Thanks to those who contributed

Signed-off-by: poondog <markj338@gmail.com>

Conflicts:
	arch/arm/mach-msm/pm-data.c

Change-Id: I0632f1f62adbda48bae63f3a4acac27c4fd3a4eb
lz4: ensure length does not wrap

Given some pathologically compressed data, lz4 could possibly decide to
wrap a few internal variables, causing unknown things to happen.  Catch
this before the wrapping happens and abort the decompression.

Reported-by: "Don A. Bailey" <donb@securitymouse.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
lz4: fix another possible overrun

There is one other possible overrun in the lz4 code as implemented by
Linux at this point in time (which differs from the upstream lz4
codebase, but will get synced at in a future kernel release.)  As
pointed out by Don, we also need to check the overflow in the data
itself.

While we are at it, replace the odd error return value with just a
"simple" -1 value as the return value is never used for anything other
than a basic "did this work or not" check.

Reported-by: "Don A. Bailey" <donb@securitymouse.com>
Reported-by: Willy Tarreau <w@1wt.eu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: Introduce new relation for freq selection

Introduce CPUFREQ_RELATION_C for frequency selection.
It selects the frequency with the minimum euclidean distance
to target. In case of equal distance between 2 frequencies,
it will select the greater freq.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: this governor is fundamentally different from Ondemand and by norm its a bit more sensitive to load changes in terms of which freqs are chosen, but even though sometimes it can be a little stupid and non react to load changes that linearly as one could hope for (even though it's better than Ondemand) so for that reason let's try to use this new formula by @stratosk found in this commit: https://github.com/stratosk/kernel_msm/commit/9df03b662b9c213c75ac082138f5ab8afadb9d94 make sure you read his commit message for better understanding of this.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c

Change-Id: I3f84feb71a9ae91591a1f7fc9090b66b8ae4eb0c
choose_freq & freq_to_targetload are not used anymore in cpufreq_interactive

Change-Id: I7ab37751491998cf27ed6368c910dce68ac3a848
intelli_plug: only apply suspend/resume logic if active

Signed-off-by: Paul Reioux <reioux@gmail.com>
intellidemand: cumulative updateis to version 5.5 + adapt frequencies for Z

also remove unused legacy stuff

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

Conflicts:
	drivers/cpufreq/Kconfig
	drivers/cpufreq/cpufreq_intellidemand.c

Change-Id: Iad86d5b124eba6de065d1bbfbd42b69e3a2ffa8f
intelliplug: hack for screen_off_max

Change-Id: Ib52bd2e680681ebfa6d8a817906b8e1f1d87403a
Simplify max_screen_off fix provided by @aidfarh

Change-Id: I2213cb068d3187383b403fd93a1b1d6ac342c3ce
Patch 3.4.97 > 3.4.98

Change-Id: Icee9442239c7453676c21d5aed0282a0f45f99c7
Patch 3.4.98 > 3.4.99

Change-Id: I39db698027f896714cc1093aab3a30c2af3f9c94
Update prima wlan to 3.2.7.47

Change-Id: I8636b16936d184adf65412120a638b117269ae62
Revert "Simplify max_screen_off fix provided by @aidfarh"

This reverts commit affe26530e8e6946439549e73f19635a5d417894.
Revert "intelliplug: hack for screen_off_max"

This reverts commit f82df32dcf514c83b352797ded27bd476b2dcc4c.