kswapd: Introduce congestion_wait_kswapd

congestion_wait for kswapd is similar to congestion_wait, the vital
difference is that congestion_wait_kswapd uses schedule_timeout
instead of io_schedule_timeout (which can cause IO wait conditions,
due to nr_iowait usage).

Derived from: https://github.com/oppo-source/Find5-Kernel-Source-4.2/commit/c7b44a43a970b699ecd68655bd6f83a8fbb3d74d
Original author: huanggd @oppo-source

Change-Id: I08bbbdd49c8764a3180c0d7a9197d2b9c8112d81
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>
sched: Limit setaffinity with CPU_HOTPLUG

Some applications do not count CPU's correctly and make bad
decisions on systems with hotplugged CPU's.

Limit app's ability to use setaffinity based on CONFIG_CPU_HOTPLUG.

Change-Id: I133cff0c0c71553ca1febfb044dba59bda38cb33
Signed-off-by: Chris Fries <C.Fries@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/528092
SLT-Approved: Gerrit Code Review <gerrit-blurdev@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Christopher Fries <qcf001@motorola.com>
Reviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Igor Kovalenko <cik009@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>
CHROMIUM: clocksource: allow clocksources to be selected earlier during boot

Global and per-CPU timers ought to be initialized once SMP initialization
is complete.  Although the clocksources associated with these timers may
not be registered until later in the boot process, they should be ready
to go once registered.  We'd like to stop using the super low-resolution
boot clocksource (jiffies) as soon as possible since devices may rely on
accurate timekeeping while being brought up during boot, so move
clocksource_done_booting() to arch_initcall time so that we can switch
to a higher-resolution clocksrouce earlier in the boot process.

BUG=chrome-os-partner:20458
TEST=Pit and Lumpy both still boot reliably.  Boot time on Pit improves
considerably:
Before: [    3.032967] VFS: Mounted root ...
After:  [    1.855936] VFS: Mounted root ...
Lumpy boot time improves very slightly:
Before: [    1.786347] VFS: Mounted root ...
After:  [    1.754297] VFS: Mounted root ...

Change-Id: I951fee2e7e4697ccfe7f845a2c1c6bd80669a8d5
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170102
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>
BUILD: v078

Signed-off-by: poondog <markj338@gmail.com>
power: quickwakeup: initial driver

This driver allows clients to register code to be called upon wakeup
so that clients can perform specific checks and vote to drop the system
back into suspend without fully resuming if the wake reason was a special
quick wakeup event.

Propagation of (CR)

Change-Id: I791ff02f34b616e6da2b68efc2d4eb4449e5bbe7
Signed-off-by: James Wylder <jwylder1@motorola.com>
Signed-off-by: Jared Suttles <jsuttles@motorola.com>
Signed-off-by: Joe Swantek <w98568@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/611835
SLTApproved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Joseph Swantek <jswantek@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Signed-off-by: poondog <markj338@gmail.com>
DEFCONFIG: enable WQUICK WAKEUP

Signed-off-by: poondog <markj338@gmail.com>
msm: pm-8x60: add suspend_again handler

Call quickwakeup clients to enable us to perform very small amounts of
processing and then to drop quickly back into suspend.

Change-Id: I17d43d6670a7fd9f94b3270d2e0c659f3be93ee1
Signed-off-by: James Wylder <jwylder1@motorola.com>
Signed-off-by: Jared Suttles <jsuttles@motorola.com>
Signed-off-by: Joe Swantek <w98568@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/584478
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Joseph Swantek <jswantek@motorola.com>
Reviewed-by: Patrick Auchter <auchter@motorola.com>
Reviewed-by: Lian-Wei Wang <lian-wei.wang@motorola.com>
Reviewed-by: Stephen Rossbach <rossbach@motorola.com>
SLTApproved: Stephen Rossbach <rossbach@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
(cherry picked from commit ca2fd43830dfed227f94bbae65d9cbc7c2abe631)
[ljc: Adapt patch to newer quickwakeup driver]
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
Signed-off-by: poondog <markj338@gmail.com>
BUILD: v079

Signed-off-by: poondog <markj338@gmail.com>
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>
DEFCONFIG: Enable RCU_FAST_NO_HZ

Derived from
https://github.com/MotorolaMobilityLLC/kernel-msm/commit/822e84f17b0a5290c8ad350f9800983df534cdb6
https://github.com/SyNtheticNightmar3/kernel_asus_flo/commit/c6e961987efc8df15730f776cab43cfaaa2e1cd6

Signed-off-by: poondog <markj338@gmail.com>
BOARD: a bit cooler

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

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

Signed-off-by: poondog <markj338@gmail.com>
cpufreq: conservative: Fix typos in comments

Fix a couple of typos in comments.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: poondog <markj338@gmail.com>
cpufreq: conservative: Fix sampling_down_factor functionality

sampling_down_factor tunable is unused since commit
8e677ce83bf41ba9c74e5b6d9ee60b07d4e5ed93 (4 years ago).

This patch restores the original functionality and documents the
tunable.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: poondog <markj338@gmail.com>
cpufreq: conservative: Fix the logic in frequency decrease checking

When we evaluate the CPU load for frequency decrease we have to compare
the load against down_threshold. There is no need to subtract 10 points
from down_threshold.

Instead, we have to use the default down_threshold or user's selection
unmodified.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: poondog <markj338@gmail.com>
cpufreq: conservative: Use an inline function to evaluate freq_target

Use an inline function to evaluate freq_target to avoid duplicate code.

Also, define a macro for the default frequency step.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: poondog <markj338@gmail.com>
cpufreq: conservative: Update CPU utilization

Update CPU utilization for use in dynamic hotplug driver

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Signed-off-by: poondog <markj338@gmail.com>
cpufreq: conservative: First check if we can further reduce the freq

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Signed-off-by: poondog <markj338@gmail.com>
cpufreq: conservative: fix requested_freq reduction issue

When decreasing frequency, requested_freq may be less than
freq_target, So requested_freq minus freq_target may be negative,
But reqested_freq's unit is unsigned int, then the negative result
will be one larger interger which may be even higher than
requested_freq.

This patch is to fix such issue. when result becomes negative,
set requested_freq as the min value of policy.

Signed-off-by: Xiaoguang Chen <chenxg@marvell.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Signed-off-by: poondog <markj338@gmail.com>