sched/nohz: Fix logic in trigger_load_balance

Whether we need to kick nohz doesn't depend on current rq->next_balance,
meaning it doesn't depend on the check of previous if condition.

Change-Id: I566011d6341fa7a9a700c834f77e129043eaba11
Signed-off-by: Xin Qi <xqi@codeaurora.org>
sched/nohz: Fix logic in run_rebalance_domains

If triggered by nohz_balancer_kick, idle_at_tick is not updated
accordingly.  Update myself at this moment right before it is used

Change-Id: I20dd4314159e70f955ffe482160c8867c65c261e
Signed-off-by: Xin Qi <xqi@codeaurora.org>
sched/nohz: Fix logic in nohz_kick_needed

Update the logic so that as long as rq->nr_running is greater than 1,
nohz_kick will be needed, regardless of whether the current CPU has
successfully competed for the first or second cpu spot

Previous logic has the corner case that if current CPU has r_running more than
1, and two other CPUs alreay hold first and econd cpu spot, but they don't
meeting kicking criterial (first cpu has nr_running 1, and second cpu doesn't
have any load), then nohz_kick will not be set correctly.

Change-Id: I30790f22df0a2e90899daa44c67757284dcca25d
Signed-off-by: Xin Qi <xqi@codeaurora.org>
sched/nohz: Correctly initialize 'next_balance' in 'nohz' idle balancer

The 'next_balance' field of 'nohz' idle balancer must be initialized
to jiffies. Since jiffies is initialized to negative 300 seconds the
'nohz' idle balancer does not run for the first 300s (5mins) after
bootup. If no new processes are spawed or no idle cycles happen, the
load on the cpus will remain unbalanced for that duration.

Signed-off-by: Diwakar Tundlam <dtundlam@nvidia.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1DD7BFEDD3147247B1355BEFEFE4665237994F30EF@HQMAIL04.nvidia.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>

[xqi@codeaurora.org merge into different file location in 3.0]
Change-Id: I42c41210babb0881150d28d11c2d3fce24fe3a9f
Signed-off-by: Xin Qi <xqi@codeaurora.org>
sched: Fix select_fallback_rq() vs cpu_active/cpu_online

Commit 5fbd036b55 ("sched: Cleanup cpu_active madness"), which was
supposed to finally sort the cpu_active mess, instead uncovered more.

Since CPU_STARTING is ran before setting the cpu online, there's a
(small) window where the cpu has active,!online.

If during this time there's a wakeup of a task that used to reside on
that cpu select_task_rq() will use select_fallback_rq() to compute an
alternative cpu to run on since we find !online.

select_fallback_rq() however will compute the new cpu against
cpu_active, this means that it can return the same cpu it started out
with, the !online one, since that cpu is in fact marked active.

This results in us trying to scheduling a task on an offline cpu and
triggering a WARN in the IPI code.

The solution proposed by Chuansheng Liu of setting cpu_active in
set_cpu_online() is buggy, firstly not all archs actually use
set_cpu_online(), secondly, not all archs call set_cpu_online() with
IRQs disabled, this means we would introduce either the same race or
the race from fd8a7de17 ("x86: cpu-hotplug: Prevent softirq wakeup on
wrong CPU") -- albeit much narrower.

[ By setting online first and active later we have a window of
  online,!active, fresh and bound kthreads have task_cpu() of 0 and
  since cpu0 isn't in tsk_cpus_allowed() we end up in
  select_fallback_rq() which excludes !active, resulting in a reset
  of ->cpus_allowed and the thread running all over the place. ]

The solution is to re-work select_fallback_rq() to require active
_and_ online. This makes the active,!online case work as expected,
OTOH archs running CPU_STARTING after setting online are now
vulnerable to the issue from fd8a7de17 -- these are alpha and
blackfin.

Reported-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: linux-alpha@vger.kernel.org
Link: http://lkml.kernel.org/n/tip-hubqk1i10o4dpvlm06gq7v6j@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Conflicts:

	kernel/sched/core.c

Change-Id: Ib22f61c28494bcccc40f9f7fa3812c72e5528203
sched: Cleanup cpu_active madness

Stepan found:

CPU0		CPUn

_cpu_up()
  __cpu_up()

		boostrap()
		  notify_cpu_starting()
		  set_cpu_online()
		  while (!cpu_active())
		    cpu_relax()

<PREEMPT-out>

smp_call_function(.wait=1)
  /* we find cpu_online() is true */
  arch_send_call_function_ipi_mask()

  /* wait-forever-more */

<PREEMPT-in>
		  local_irq_enable()

  cpu_notify(CPU_ONLINE)
    sched_cpu_active()
      set_cpu_active()

Now the purpose of cpu_active is mostly with bringing down a cpu, where
we mark it !active to avoid the load-balancer from moving tasks to it
while we tear down the cpu. This is required because we only update the
sched_domain tree after we brought the cpu-down. And this is needed so
that some tasks can still run while we bring it down, we just don't want
new tasks to appear.

On cpu-up however the sched_domain tree doesn't yet include the new cpu,
so its invisible to the load-balancer, regardless of the active state.
So instead of setting the active state after we boot the new cpu (and
consequently having to wait for it before enabling interrupts) set the
cpu active before we set it online and avoid the whole mess.

Change-Id: Id564d0a195de2b700db29c264ed2f926c4f0ca09
Reported-by: Stepan Moskovchenko <stepanm@codeaurora.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1323965362.18942.71.camel@twins
Signed-off-by: Ingo Molnar <mingo@elte.hu>
thermal: Don't limit CPU frequency after msm_thermal is disabled

There may be an outstanding task to check for threshold crossing
when msm_thermal is disabled and CPU is restored to maximum
frequency. This task can get scheduled after the maximum frequency
is restored, and result in another mitigation that pins CPU
frequencies to 918mHz. This happens in the case that the final
temperature was still above the max temperature threshold.
This patch ensures any outstanding tasks are cancelled and flushed
before finally restoring the CPU frequencies.

CRs-fixed: 351614
Change-Id: Ifce00b379989b78856803ac09c7403207f5c998b
Signed-off-by: Eugene Seah <eseah@codeaurora.org>
(cherry picked from commit cbc0753ecc3a4f80105e99e5698da0b3363866ea)
input: Disable DVFS and finger up/down logs

Change-Id: Ieb3bb8ec052cb6ddf8d5408a9b673ab46281b827

Conflicts:
	drivers/input/touchscreen/mxt224e.c
CONFIG: Version 0.7
Add SIO I/O scheduler

Change-Id: I3c4edf24c3747b488b8b6e457668a4b01edb727d
CONFIG: Version 0.8
Revert "By default, the wifi chip disabled packet filters when phone is out of"

This reverts commit 289e02b30f83e963f67f772b6e0f30ba945104eb.
Revert "Make the unicast filter work with IPv6: from madmack"

This reverts commit d3746ab708d1d33ab40be71c0f7c16852e79e863.
Revert "Disable mDNS completely due to excessive wakelock: from madmack"

This reverts commit 175bb4a524867cd6bef819550bdf57c8421c40bd.
Revert "Only allow unicast and multicastDNS to wake the device when the screen"

This reverts commit dd5664cdca8ed0a60eac744f67cdd5068d24e977.
BUILD: Script update to automatically tag last commit with build timestamp