cpufreq: stats: Don't stop notification call chain

The notification call chain is stopped if error returned. Since
no further steps is needed to handle such error, let's just print
a debug message here so the other registered cpufreq notifier can
be called correctly.

Signed-off-by: Lianwei Wang <a22439@motorola.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpufreq: interactive: reduce chance of zero time delta on load eval

Reschedule load sampling timer after timestamp of sample start taken,
hold spinlock across entire sequence to avoid preemption.  Avoid the
WARN for zero time delta in the load sampling timer function.

Change-Id: Idc10a756f09141decb6df92669521a1ebf0dbc10
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpufreq: interactive: handle errors from cpufreq_frequency_table_target

Add checks for error return from cpufreq_frequency_table_target, and be
less noisy on the existing call with an error check.  CPU hotplug and
system shutdown may cause this call to return -EINVAL.

Bug: 8613560
Change-Id: Id78d8829920462c0db1c7e14e717d91740d6cb44
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
sched: Fix SCHED_HRTICK bug leading to late preemption of tasks

SCHED_HRTICK feature is useful to preempt SCHED_FAIR tasks on-the-dot
(just when they would have exceeded their ideal_runtime). It makes use
of a a per-cpu hrtimer resource and hence alarming that hrtimer should
be based on total SCHED_FAIR tasks a cpu has across its various cfs_rqs,
rather than being based on number of tasks in a particular cfs_rq (as
implemented currently). As a result, with current code, its possible for
a running task (which is the sole task in its cfs_rq) to be preempted
much after its ideal_runtime has elapsed, resulting in increased latency
for tasks in other cfs_rq on same cpu.

Fix this by alarming sched hrtimer based on total number of SCHED_FAIR
tasks a CPU has across its various cfs_rqs.

Change-Id: I1f23680a64872f8ce0f451ac4bcae28e8967918f
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
sched: Reset rq->next_interval before going idle

next_balance, the point in jiffy time scale when a cpu will next load
balance, could have been calculated when the cpu was busy. A busy cpu
will apply its sched domain's busy_factor (usually > 1) in computing
next_balance for that sched domain, which causes the (busy) cpu to load
balance less frequently in its sched domains. However when the same cpu
is going idle, its next_balance needs to be reset without consideration
of busy_factor. Failure to do so would not trigger nohz idle balancer on
that cpu for unnecessarily long time (introducing additional scheduling
latencies for tasks). Fix bug in scheduler which aims to reset
next_balance before a cpu goes idle (as per existing comment) but is
clearly not doing so.

Change-Id: I7e027a51686528c4092d770c7d33c874d38f5df4
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
bcmdhd: tweaked wakelocks a bit
mmc: decrease wakelock timeout
random: remove warning
Revert "Added kernel config option 'BCMDHD_WIFI_PM'."

This reverts commit 42fe1a70f769b910c0120c57bb0f6ac64a7f0876.

Conflicts:
	drivers/net/wireless/bcmdhd/dhd_linux.c
net: wireless: bcmdhd: Update to version 5.90.195.114

- Get AP beacon and DTIM to set proper DTIM skipping

Change-Id: I6bc23f050c144bf8361078ad587bcadbfe3a37fc
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
net: wireless: bcmdhd: Add SUPPORT_PM2_ONLY option

Change-Id: Ieb2569cb7fb2bbc56ff9abbc8728a7741fda0027
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
net: wireless: bcmdhd: Enable SUPPORT_PM2_ONLY mode

Change-Id: I4f8132191454f0a12f7613388229fed9be5216c9
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>

Conflicts:
	drivers/net/wireless/bcmdhd/Makefile
net: wireless: bcmdhd: no need for power mode anymore

Conflicts:
	drivers/net/wireless/bcmdhd/dhd_linux.c
Revert "net: wireless: bcmdhd: Enable full scan on PNO event"

This reverts commit bb4a5720fc872ff7743ba89a9a893cf485300042.
Revert "net: wireless: bcmdhd: Prevent recursive call of cfg80211_sched_scan_stopped()"

This reverts commit 85f63ca7303aa94d5303762e4f2cfde28a1ebd1a.
arch:arm:configs: enable CONFIG_OMAP4_PPA_CPU1_ONLINE_BUG
cpufreq: interactive: resched timer if max freq raised

When the policy max freq is raised, and before the timer is
rescheduled in idle callback, the cpu freq may stuck at a
lower freq.

The target_freq shall be updated too, else on a high load
situation, the new_freq is always equal to target_freq and
which will cause freq stuck at a lower freq too.

Reschedule the timer on gov limits callback.

Change-Id: I6c187001ab43e859731429b64f75a74eebc37a24
Signed-off-by: Lianwei Wang <a22439@motorola.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpufreq: interactive: don't schedule timer on offline cpu

It shall not add timer on an offline CPUs, else it will cause
kernel panic.

And also don't reschedule the timer on an offline cpu in idle
and timer callback. Actually the timer shall be cancelled when
cpu is offline.

Change-Id: Id314f15be3d12ab49e5cdcf6ae89bd88b376308a
Signed-off-by: Lianwei Wang <a22439@motorola.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpufreq: interactive: fix race on cpufreq TRANSITION notifier

The cpufreq TRANSTION notifier callback does not check the
governor_enabled state on affected CPUS, which will case
kernel panic in update_load because the policy object maybe
NULL or invalid when governor_enabled is false.

Change-Id: Ie0f1718124f61e2f9b5da57abc6981ada5b83908
Signed-off-by: Lianwei Wang <a22439@motorola.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
freezer: shorten freezer sleep time using exponential backoff

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