msm: hotplug: Add control for max_cpus_online while suspend

* Recent findings hints that all sibling cores going offline
  while suspend introduces glitch in music playback with
  DSP Manager.
* This patch allows user to select no. of possible CPUs
  that can be allowed to go online when device is suspended.
* If max_online_cpus_susp is set to 1, there is no need to
  keep hotplug function working, so we simply flush
  workqueue and bring down sibling cores when device is
  suspended after suspend_defer_time.
* For other values of max_online_cpus_susp, hotplug will be
  functional with max_online_cpus = max_online_cpus_susp
  when device is suspended after suspend_defer_time.
* We set default value of max_online_cpus_susp to 2 to help
  with issue of audio glitch while using DSP Manager.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>

Conflicts:
	arch/arm/mach-msm/msm_hotplug.c
intelli_plug: Add max_cpus_online_susp and remove wakeboost

* max_cpus_online_susp is added for same reason and in same
  way as that in MSM Hotplug.
* wakeboost is removed. It was just placebo, never worked
  actually. Also, if we are gonna implement it, we will
  implement it via MSM Limiter driver since our max_freq
  is controlled by that driver.
* Rewrite bits for resume and suspend to make more sense.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
 intelli_plug: Rewrite suspend architecture

* Add support for multiple suspend architectures.
* Add suspend_defer_time attribute.
* Improve driver initialization.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>

Dorimanx Note:
Cleaned file from 80 chars lines + white space.

Conflicts:
	arch/arm/mach-msm/intelli_plug.c
MSM HOTPLUG: Cleanups. Thanks NEO :)
rtmutex: Handle deadlock detection smarter

Even in the case when deadlock detection is not requested by the
caller, we can detect deadlocks. Right now the code stops the lock
chain walk and keeps the waiter enqueued, even on itself. Silly not to
yell when such a scenario is detected and to keep the waiter enqueued.

Return -EDEADLK unconditionally and handle it at the call sites.

The futex calls return -EDEADLK. The non futex ones dequeue the
waiter, throw a warning and put the task into a schedule loop.

Tagged for stable as it makes the code more robust.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Brad Mouring <bmouring@ni.com>
Link: http://lkml.kernel.org/r/20140605152801.836501969@linutronix.de
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
rtmutex: Detect changes in the pi lock chain

When we walk the lock chain, we drop all locks after each step. So the
lock chain can change under us before we reacquire the locks. That's
harmless in principle as we just follow the wrong lock path. But it
can lead to a false positive in the dead lock detection logic:

T0 holds L0
T0 blocks on L1 held by T1
T1 blocks on L2 held by T2
T2 blocks on L3 held by T3
T4 blocks on L4 held by T4

Now we walk the chain

lock T1 -> lock L2 -> adjust L2 -> unlock T1 ->
     lock T2 ->  adjust T2 ->  drop locks

T2 times out and blocks on L0

Now we continue:

lock T2 -> lock L0 -> deadlock detected, but it's not a deadlock at all.

Brad tried to work around that in the deadlock detection logic itself,
but the more I looked at it the less I liked it, because it's crystal
ball magic after the fact.

We actually can detect a chain change very simple:

lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 ->

     next_lock = T2->pi_blocked_on->lock;

drop locks

T2 times out and blocks on L0

Now we continue:

lock T2 ->

     if (next_lock != T2->pi_blocked_on->lock)
     	   return;

So if we detect that T2 is now blocked on a different lock we stop the
chain walk. That's also correct in the following scenario:

lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 ->

     next_lock = T2->pi_blocked_on->lock;

drop locks

T3 times out and drops L3
T2 acquires L3 and blocks on L4 now

Now we continue:

lock T2 ->

     if (next_lock != T2->pi_blocked_on->lock)
     	   return;

We don't have to follow up the chain at that point, because T2
propagated our priority up to T4 already.

[ Folded a cleanup patch from peterz ]

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reported-by: Brad Mouring <bmouring@ni.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140605152801.930031935@linutronix.de
Cc: stable@vger.kernel.org
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
rtmutex: Plug slow unlock race

When the rtmutex fast path is enabled the slow unlock function can
create the following situation:

spin_lock(foo->m->wait_lock);
foo->m->owner = NULL;
	    			rt_mutex_lock(foo->m); <-- fast path
				free = atomic_dec_and_test(foo->refcnt);
				rt_mutex_unlock(foo->m); <-- fast path
				if (free)
				   kfree(foo);

spin_unlock(foo->m->wait_lock); <--- Use after free.

Plug the race by changing the slow unlock to the following scheme:

     while (!rt_mutex_has_waiters(m)) {
     	    /* Clear the waiters bit in m->owner */
	    clear_rt_mutex_waiters(m);
      	    owner = rt_mutex_owner(m);
      	    spin_unlock(m->wait_lock);
      	    if (cmpxchg(m->owner, owner, 0) == owner)
      	       return;
      	    spin_lock(m->wait_lock);
     }

So in case of a new waiter incoming while the owner tries the slow
path unlock we have two situations:

 unlock(wait_lock);
					lock(wait_lock);
 cmpxchg(p, owner, 0) == owner
 	    	   			mark_rt_mutex_waiters(lock);
	 				acquire(lock);

Or:

 unlock(wait_lock);
					lock(wait_lock);
	 				mark_rt_mutex_waiters(lock);
 cmpxchg(p, owner, 0) != owner
					enqueue_waiter();
					unlock(wait_lock);
 lock(wait_lock);
 wakeup_next waiter();
 unlock(wait_lock);
					lock(wait_lock);
					acquire(lock);

If the fast path is disabled, then the simple

   m->owner = NULL;
   unlock(m->wait_lock);

is sufficient as all access to m->owner is serialized via
m->wait_lock;

Also document and clarify the wakeup_next_waiter function as suggested
by Oleg Nesterov.

Reported-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140611183852.937945560@linutronix.de
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
sched/dl: Fix race in dl_task_timer()

Throttled task is still on rq, and it may be moved to other cpu
if user is playing with sched_setaffinity(). Therefore, unlocked
task_rq() access makes the race.

Juri Lelli reports he got this race when dl_bandwidth_enabled()
was not set.

Other thing, pointed by Peter Zijlstra:

   "Now I suppose the problem can still actually happen when
    you change the root domain and trigger a effective affinity
    change that way".

To fix that we do the same as made in __task_rq_lock(). We do not
use __task_rq_lock() itself, because it has a useful lockdep check,
which is not correct in case of dl_task_timer(). We do not need
pi_lock locked here. This case is an exception (PeterZ):

   "The only reason we don't strictly need ->pi_lock now is because
    we're guaranteed to have p->state == TASK_RUNNING here and are
    thus free of ttwu races".

Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: <stable@vger.kernel.org> # v3.14+
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/3056991400578422@web14g.yandex.ru
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
sched/deadline: Delete extraneous extern for to_ratio()

There was a prototype for it added to kernel/sched/sched.h
at the same time the extern was added, so the extern in
the C file was never really ever needed.

See commit 332ac17ef5bfcff4766dfdfd3b4cdf10b8f8f155
("sched/deadline: Add bandwidth management for SCHED_DEADLINE
tasks") for details.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Dario Faggioli <raistlin@linux.it>
Link: http://lkml.kernel.org/r/1400013605-18717-1-git-send-email-paul.gortmaker@windriver.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Linux 3.4.95

Conflicts:
	kernel/time/tick-sched.c
	lib/lzo/lzo1x_decompress.c
	lib/lzo/lzodefs.h
Fixed Linux 3.4.95 commit.
alucard governor: percpu pump_inc_step_at_min_freq, pump_inc_step, pump_dec_step
Add Boost MAX Freq on wakeup to Ondemand and helper to cpu-boost for LGE.

Conflicts:
	drivers/cpufreq/cpufreq_ondemand.c
Revert "sched: Consider pi boosting in setscheduler()"

* Seems to me we are not ready for this. It caused stutterings
  in music playback. Thanks to user community for active
  participation in test builds!

* This reverts commit fd27b2b1ea411a5c5664cb3d628cee3d66f49da6

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: cpuboost: Make cpu boost driver aware of LCD events

* We previously removed "placebo" wake boost from intelli
  hotplug driver and stated we may add same to MSM Limiter
  driver.
* However, we already have good boost driver in place.
  So we use same to apply CPU boost whenever screen is
  turned on!
* Tested and worked well.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
 After i have found that all kernel build error were disabled!!! -w

I have fixed many bugs that i had in my code and didnt know!

*For now switched to NEON from neon-vfp4 for tests.
*Cleaned Makefile flags order.
*Relocated functions to correct headers.
*Added missing heders and headers functions.
*Cleaned not used code.
*For some files i have added NO warnings as the warning is not important.
in time i will fix all.
 Config change. testing with CONFIG_SCHED_AUTOGROUP

*I know that we should config this, but maybe it's really auto!

need to read some more about this CONFIG_SCHED_AUTOGROUP
sched/cpuidle: reduce IPI store. Backport upstream 3.16 scheduler updates

Signed-off-by: Paul Reioux <reioux@gmail.com>
Revert "scheduler: Re-compute time-average nr_running on read"

This reverts commit cc713f0f701c38dfd3512655e5237e6330112ca0.
Revert "proc: enhance time-average nr_running stats"

This reverts commit e95a97db5678052ba67b5ae4e50fbd8459186bdc.