watchdog: Fix warning caused by use of smp_processor_id()

watchdog driver creates per-cpu kernel threads that are bound to
separate cpus. Use of smp_processor_id() by such threads in
__touch_watchdog() is perfectly fine, as they are generally pinned to
the cpu on which they are running.

During cpu offline event, however, affinity for the watchdog thread
bound to dying cpu is broken before it is killed. There is a small
time window between affinity broken and thread dying in which thread
can run on a cpu with its affinity not set to that cpu exclusively.
This will trigger a warning from use of smp_processor_id(), which is
harmless in this case as it will provide the required heartbeat on cpu
where it is running and moreover that thread will be shortly killed.

Mute the harmless warning by use of raw_smp_processor_id() in
__touch_watchdog(). This seems less intrusive fix than killing threads
in CPU_DOWN_PREPARE event handler.

Change-Id: I7fa22ff529aeea0ec3d5610cfec87aea92cf95a0
CRs-Fixed: 517188
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
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>

Conflicts:

	lib/spinlock_debug.c
lib: spinlock_debug: increase spin dump timeout

On certain targets the worst case console buffer draining time can
exceed the aggressive spin dump timeout value. Relax the timeout value
to cater to these scenarios.

Change-Id: I7312ffe06bafd2dc7adf0f4e8b73a53fc5839235
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
video: lm3530_bl: Introduce new tunables to control LED driver

- min_br: sets the mininum brightness level (2-114)
- max_br: sets the maximum brightness level (2-114)
- br_mode: sets the linear (default 1) or exponential (0) brightness
mapping mode.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>

Conflicts:
	drivers/video/backlight/lm3530_bl.c
video: lm3530_bl: Fix a couple of checkpatch warnings

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
video: lm3530_bl: Fix backlight issue when suspend

Revert the min brightness check that prevents the driver
to turn off backlight when suspend.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
sched: Implement smarter wake-affine logic

The wake-affine scheduler feature is currently always trying to pull
the wakee close to the waker. In theory this should be beneficial if
the waker's CPU caches hot data for the wakee, and it's also beneficial
in the extreme ping-pong high context switch rate case.

Testing shows it can benefit hackbench up to 15%.

However, the feature is somewhat blind, from which some workloads
such as pgbench suffer. It's also time-consuming algorithmically.

Testing shows it can damage pgbench up to 50% - far more than the
benefit it brings in the best case.

So wake-affine should be smarter and it should realize when to
stop its thankless effort at trying to find a suitable CPU to wake on.

This patch introduces 'wakee_flips', which will be increased each
time the task flips (switches) its wakee target.

So a high 'wakee_flips' value means the task has more than one
wakee, and the bigger the number, the higher the wakeup frequency.

Now when making the decision on whether to pull or not, pay attention to
the wakee with a high 'wakee_flips', pulling such a task may benefit
the wakee. Also imply that the waker will face cruel competition later,
it could be very cruel or very fast depends on the story behind
'wakee_flips', waker therefore suffers.

Furthermore, if waker also has a high 'wakee_flips', that implies that
multiple tasks rely on it, then waker's higher latency will damage all
of them, so pulling wakee seems to be a bad deal.

Thus, when 'waker->wakee_flips / wakee->wakee_flips' becomes
higher and higher, the cost of pulling seems to be worse and worse.

The patch therefore helps the wake-affine feature to stop its pulling
work when:

	wakee->wakee_flips > factor &&
	waker->wakee_flips > (factor * wakee->wakee_flips)
The 'factor' here is the number of CPUs in the current CPU's NUMA node,
so a bigger node will lead to more pulling since the trial becomes more
severe.

After applying the patch, pgbench shows up to 40% improvements and no regressions.

Tested with 12 cpu x86 server and tip 3.10.0-rc7.

The percentages in the final column highlight the areas with the biggest wins,
all other areas improved as well:

	pgbench		    base	smart

	| db_size | clients |  tps  |	|  tps  |
	+---------+---------+-------+   +-------+
	| 22 MB   |       1 | 10598 |   | 10796 |
	| 22 MB   |       2 | 21257 |   | 21336 |
	| 22 MB   |       4 | 41386 |   | 41622 |
	| 22 MB   |       8 | 51253 |   | 57932 |
	| 22 MB   |      12 | 48570 |   | 54000 |
	| 22 MB   |      16 | 46748 |   | 55982 | +19.75%
	| 22 MB   |      24 | 44346 |   | 55847 | +25.93%
	| 22 MB   |      32 | 43460 |   | 54614 | +25.66%
	| 7484 MB |       1 |  8951 |   |  9193 |
	| 7484 MB |       2 | 19233 |   | 19240 |
	| 7484 MB |       4 | 37239 |   | 37302 |
	| 7484 MB |       8 | 46087 |   | 50018 |
	| 7484 MB |      12 | 42054 |   | 48763 |
	| 7484 MB |      16 | 40765 |   | 51633 | +26.66%
	| 7484 MB |      24 | 37651 |   | 52377 | +39.11%
	| 7484 MB |      32 | 37056 |   | 51108 | +37.92%
	| 15 GB   |       1 |  8845 |   |  9104 |
	| 15 GB   |       2 | 19094 |   | 19162 |
	| 15 GB   |       4 | 36979 |   | 36983 |
	| 15 GB   |       8 | 46087 |   | 49977 |
	| 15 GB   |      12 | 41901 |   | 48591 |
	| 15 GB   |      16 | 40147 |   | 50651 | +26.16%
	| 15 GB   |      24 | 37250 |   | 52365 | +40.58%
	| 15 GB   |      32 | 36470 |   | 50015 | +37.14%
Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
Cc: Mike Galbraith <efault@gmx.de>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/51D50057.9000809@linux.vnet.ibm.com
[ Improved the changelog. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Signed-off-by: Paul Reioux <reioux@gmail.com>
sched: Micro-optimize the smart wake-affine logic

Smart wake-affine is using node-size as the factor currently, but the overhead
of the mask operation is high.

Thus, this patch introduce the 'sd_llc_size' percpu variable, which will record
the highest cache-share domain size, and make it to be the new factor, in order
to reduce the overhead and make it more reasonable.

Tested-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Tested-by: Michael Wang <wangyun@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Michael Wang <wangyun@linux.vnet.ibm.com>
Cc: Mike Galbraith <efault@gmx.de>
Link: http://lkml.kernel.org/r/51D5008E.6030102@linux.vnet.ibm.com
[ Tidied up the changelog. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Signed-off-by: Paul Reioux <reioux@gmail.com>
msm: mdm2: Decrease leakage before QSC power-up

Cleanup of IPC gpios for driver strength and toggle
AP2MDM_STATUS only after AP2MDM_KPD_PWR is toggled, this
will decrease the leakage from MSM to QSC before QSC
powering up.

CRs-Fixed: 460500
Change-Id: Iabfa34331b613dd66577e485572a809440cf5272
Signed-off-by: Taniya Das <tdas@codeaurora.org>

modified for Mako use

Signed-off-by: Paul Reioux <reioux@gmail.com>

Conflicts:

	arch/arm/mach-msm/lge/mako/board-mako.c
	arch/arm/mach-msm/mdm_common.c