msm_fb: Use an exclusive semaphore for Vsync IOCTL

Vsync IOCTL runs in a separate thread context and is independent of the
other display IOCTLs. Right now, we have the same semaphore shared
for Vsync IOCTL along with other IOCTLs. This will cause performance
drop if a Vsync enable/disable IOCTL thread waits to acquire the
semaphore since composition might be happening through Overlay/Blit
IOCTL. Hence, use a different semaphore for the Vsync IOCTL.

Change-Id: I190505740b289b01812b2a46d237854a31d047e8
Signed-off-by: Padmanabhan Komanduru <pkomandu@codeaurora.org>
video: msm: Call unblank for DTV too

Change-Id: I73345a1b096812eafd03a2da84933fd7bb3ead12
msm_fb: display: Assign proper destination rectangles to mdp blit

Add check for (90 + Flip Horizontal) and Flip Vertical cases to assign
proper destination rectangle parameters to avoid corrupted frame
buffer content.

CRs-Fixed: 344807
Change-Id: I7e7b0b8d26f08f63a6f9c55eedd37f31cf0348d7
Signed-off-by: Jeevan Shriram <jshriram@codeaurora.org>
msm_fb: Check for panel power on after Unblank.

In Overlay_play , panel power on check was at wrong place
it has to be after Unblank.

Change-Id: If910f83ef57499b5f771bc7d3d1bdfa814d5c019
Signed-off-by: Kalyan Thota <kalyant@codeaurora.org>
msm: display: update non-double-buffered register

Update non-double-buffered register to avoid flickering
or mdp hang in engine done interrupt.

Change-Id: I71e8c6e587bcf2f5eca504d884e20dd224776311
Signed-off-by: Ken Zhang <kenz@codeaurora.org>
Signed-off-by: Sakshi Sharma <sakshis@codeaurora.org>
qt602240_ts: clear unused slots in the framework after calibration

It is possible for the state of the framework and the driver to get out
of sync resulting in "stuck" touch points from the framework's perspective.
This seems to happen only if there are touches during the device's
calibration.  The result is a locked up touchscreen for the user.

After error cases and after calibration, send an "unused" message
(-1 for ABS_MT_TRACKING_ID) for all unused slots. This fixes the
phantom stuck points.

Change-Id: I1fc22175dde9deb68ac69c322e305fc174fdba78
qt602240_ts: fix incorrect #if !defined(CONFIG_*_MODEL) usage

  * When trying to avoid compiling some code for a specified set of models,
    #if !defined() was used with ||'s instead of &&'s. This ends up enabling the
    code on all models, which is not the intended purpose.
  * #demorganfail

Change-Id: If42c933ae144f8c3b7c64cd5a8da36ac418a6efc
qt602240_ts: add additional mutex protection

Change-Id: I174920431e0eaba2b59dda78e478af228affb9d7
msm_fb: hdmi: update data on resolution change

On changing resolution, all information related to display
needs to be updated which helps in calculating the right mdp
clock for each resolution.

CRs-Fixed: 436151
Change-Id: I1ab6e5859491936a7fa8c62247da9ef5a0ff45ef
Signed-off-by: Ajay Singh Parmar <aparmar@codeaurora.org>
msm_fb: hdmi: Do not turn on HDMI if not ready

At bootup, if HPD is not configured, HDMI is not in
the state of getting turned on. This change makes sure
HDMI is not turned on/off unnecessarily which turns on
clocks as well.

CRs-Fixed: 447511
Change-Id: I074d9c463943770775b060c4a93b9120dfe9bcf0
Signed-off-by: Ajay Singh Parmar <aparmar@codeaurora.org>
msm_fb: Optimize the resolution change on hdmi interface

HDMI resolution is changed twice on cable connect.
This will optimize resolution change by turning on
HDMI core only once, with best possible resolution.

Change-Id: I7f636b0c2c64eb3c661fda2a709b5480db05bd27
Signed-off-by: Nagamalleswararao Ganji <nganji@codeaurora.org>
Signed-off-by: Abhishek Kharbanda <akharban@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/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: 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 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>
panic: Fix a possible deadlock in panic()

panic_lock is meant to ensure that panic processing takes
place only on one cpu; if any of the other cpus encounter
a panic, they will spin waiting to be shut down.

However, this causes a regression in this scenario:

1. Cpu 0 encounters a panic and acquires the panic_lock
   and proceeds with the panic processing.
2. There is an interrupt on cpu 0 that also encounters
   an error condition and invokes panic.
3. This second invocation fails to acquire the panic_lock
   and enters the infinite while loop in panic_smp_self_stop.

Thus all panic processing is stopped, and the cpu is stuck
for eternity in the while(1) inside panic_smp_self_stop.

To address this, disable local interrupts with
local_irq_disable before acquiring the panic_lock. This will
prevent interrupt handlers from executing during the panic
processing, thus avoiding this particular problem.

Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
(cherry picked from commit dd58afef43357f265e803c317bbaa91f8c440663)

Change-Id: I5f7ebcf2a028df265a57922b6c959e686a82026a
Signed-off-by: Swetha Basineni <sbasin@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
bdi: use deferable timer for sync_supers task

sync_supers task currently wakes up periodically for superblock
writeback. This hurts power on battery driven devices. This patch
turns this housekeeping timer into a deferable timer so that it
does not fire when system is really idle.

CRs-Fixed: 353700
Signed-off-by: Yong Wang <yong.y.wang@intel.com>
Signed-off-by: Xia Wu <xia.wu@intel.com>
Signed-off-by: Krishna Vanka <kvanka@codeaurora.org>
(cherry picked from commit f398f30d1f34632d3c96758b5b19e65b056af072)

Change-Id: I6ec6310d66c0d014adf0f41e75cd4c48c233f83d
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
video: msm: Call complete_all if vsync times out for LCDC

 * If vsync times out, we need to call complete_all otherwise the wait
   count goes to zero and we are stuck forever.
 * Should hopefully fix the hangs and crashes.

Change-Id: Ia6673b3307251ab3ca1750d65e8c721c5c2dce5f
powerpc: fix numa distance for form0 device tree

commit 7122beeee7bc1757682049780179d7c216dd1c83 upstream.

The following commit breaks numa distance setup for old powerpc
systems that use form0 encoding in device tree.

commit 41eab6f88f24124df89e38067b3766b7bef06ddb
powerpc/numa: Use form 1 affinity to setup node distance

Device tree node /rtas/ibm,associativity-reference-points would
index into /cpus/PowerPCxxxx/ibm,associativity based on form0 or
form1 encoding detected by ibm,architecture-vec-5 property.

All modern systems use form1 and current kernel code is correct.
However, on older systems with form0 encoding, the numa distance
will get hard coded as LOCAL_DISTANCE for all nodes.  This causes
task scheduling anomaly since scheduler will skip building numa
level domain (topmost domain with all cpus) if all numa distances
are same.  (value of 'level' in sched_init_numa() will remain 0)

Prior to the above commit:
((from) == (to) ? LOCAL_DISTANCE : REMOTE_DISTANCE)

Restoring compatible behavior with this patch for old powerpc systems
with device tree where numa distance are encoded as form0.

Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>