lib: spinlock_debug: Avoid livelock in do_raw_spin_lock

The logic in do_raw_spin_lock attempts to acquire a spinlock
by invoking arch_spin_trylock in a loop with a delay between
each attempt. Now consider the following situation in a 2
CPU system:

1. Cpu 0 continually acquires and releases a spinlock in a
   tight loop; it stays in this loop until some condition X
   is satisfied. X can only be satisfied by another CPU.

2. Cpu 1 tries to acquire the same spinlock, in an attempt
   to satisfy the aforementioned condition X. However, it
   never sees the unlocked value of the lock because the
   debug spinlock code uses trylock instead of just lock;
   it checks at all the wrong moments - whenever Cpu 0 has
   locked the lock.

Now in the absence of debug spinlocks, the architecture specific
spinlock code can correctly allow Cpu1 to wait in a "queue"
(e.g., ticket spinlocks), ensuring that it acquires the lock at
some point. However, with the debug spinlock code, livelock
can easily occur due to the use of try_lock, which obviously
cannot put the CPU in that "queue".

Address this by actually attempting arch_spin_lock once it is
suspected that there is a spinlock lockup. If we're in a
situation that is described above, the arch_spin_lock should
succeed; otherwise other timeout mechanisms (e.g., watchdog)
should alert the system of a lockup.

Additionally, the delay between each trylock attempt adds up
to a total delay of 1 second. On some embedded architectures,
this is an unacceptably large value. Reduce this to a ~62 ms
delay.

CRs-Fixed: 393351
Change-Id: I56f0d8f5e483cd7e8167fc7a363b9de7777a0830
Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
USB: ci13xxx_udc: Reduce busywait time from 100msec to 25msec

Commit 037476 "lib: spinlock_debug: Avoid livelock in
do_raw_spin_lock" reduced timeout value in spin_try_lock from
1sec to 62msec. Once this timeout happens, system would then
crash detecting spinlock lockup.
USB driver is currently using 100msec as timeout during busywait
loops with spinlock acquired. It may result in above spin lockup
crash whenever timeout happens due to some hardware issue.
Fix this by reducing timeout to 25msec as confirmed by h/w team.

CRs-Fixed: 487591
Change-Id: Idadcbe4b21fea456256586657ef07dfcb578f5c1
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
msm_thermal: add the work to a dedicated WQ. We need the driver to be notified of temp changes as fast as possible, and during high system load the latency might be big and delay the response of the throttling.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
mako_hotplug: if the cores go online one by one we still want the performance tunables if we hit the second level threshold with all the cores online for at least 5 seconds.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpufreq: interactive: improve governor routines, clean up old crap and remove tracing. Also add 3 tunables.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
mako_hotplug: adapt according to the new interactive code.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpufreq: interactive: fix a bug and remove some, in my opinion, useless code.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
mako_hotplug: increase first_level to 90.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
msm: cpufreq: Break out early if target frequency is the same as the current

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Revert "cpufreq: interactive: fix a bug and remove some, in my opinion, useless code."

This reverts commit 2b193a2a9a54228d576debc195a1da8d4b13df3f.
cpufreq: interactive: reverted last patch to fix a 3-4fps loss, but still need this commit to fix a bug where the freq could be stuck at 1GHz depending on the input_boost_freq.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Decrease timer_rate to 35ms, inincrease above_hispeed_delay to 20ms and decrease first_level threshold to 80, again.

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

Every 0.1 second it polls for load. if the load is higher than the "threshold"
(configurable via first_level), it scores 1 point. If the load is lower than
the "threshold", it takes away 1 point. On the scoreboard, if the points reach
10 --> 4 cores -> polls every 0.25 second from now on. Whenever the points
on the scoreboard drops below 10 --> 1 core operation --> polling
(frequency of calculating scores) back to 0.1 second.

So basically the hotplug driver has either 1 core or 4 cores. And 2 cores are
up by touch boosts.

"lighter games" will have 4 cores too because the load is not calculated from
all the cores. Instead the new driver only takes the load from cpu0
(most games, esp light ones focus on stressing cpu0) so there will be a higher
chance to reach 10 points on the scoreboard --> 4 cores --> points dont drop
because of constant gaming --> constant 4 cores ->> ultimate fps while gaming.

My theory is that whenever you game, you dont care about battery and so the
kernel gives best fps. Out of gaming? The prevention of unnecessary cores
jumping will save more juice!

Also for anyone worrying about the scoreboard having too many points, the
maximum points for the cpus to score is 50.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
mako_hotplug: wrongly deleted a line on latest commit. Also move the touch boost call up in the work function.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpufreq: interactive: remove input_boost, its obsolete now.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
mako_hotplug: re-implement cores_on_touch and freq boost to the onlined core(s) as well.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Change int to long to prevent overflow.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Merge remote-tracking branch 'franco/nightlies' into nightlies

Conflicts:
	arch/arm/kernel/mako_hotplug.c
	drivers/cpufreq/cpufreq_interactive.c