msm_fb: hdmi: Proper HPD state update

On switching off the HPD, we need to update the HPD state
after the polarity has been done to set the HPD state in
hardware properly.

CRs-Fixed: 465476
Change-Id: Ic0ba7fac72b8188c86a034ba9a45107689809028
Signed-off-by: Ajay Singh Parmar <aparmar@codeaurora.org>
Revert "Bluetooth: Initiate dedicated bonding if pin/key missing on remote device"

Change has to be reverted to address one user interaction case,
in the process of addressing one issue it made mandate to have
user interactions in some BT scenarios, the issue is fixed via
f8fffe8423933433c30dda4f9a92afc71e8def21 and it addressees all
the user scenarios properly.

More details on this issue is provided in CR: 413132 analysis
section in the prism.

This reverts commit 45df0f99094aefc2564951495ab0005a18d62de3.

Change-Id: I56611cb2646789c71f4012e906a7bbada1236c00
Signed-off-by: Bhasker Neti <bneti@codeaurora.org>
Bluetooth:Show bonding dialog if neither side requires no bonding

If the bonded remote device is removed from the list of paired
devices in the DUT, it is still possible to connect to the DUT
from the remote device without any user confirmation.

CRs-fixed: 413132
Change-Id: Iea3e4cf41e5403c3e304ca5f82cf42266be35b79
Signed-off-by: Bhasker Neti <bneti@codeaurora.org>
msm_fb: display: skip one vsync event after enabling mdp and vsync clk

Both mdp and mdp_vsync clks are disabled for command mode panel when
no new frames are being played. When they are re-enabled if new
requests come in, the first vsync event which is signaled by read
pointer interrupt arrives in a random time due to the sync between mdp
and panel, so skip it to maintain correct vsync timing.

Change-Id: I683b765e4a16d3d152b9270f5982234b94921f1e
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
msm_fb: display: wake up system before vsync for cmd panel

Add this feature for cmd mode panel. The feature is to avoid frame
drops due to power collapse and it is already present for other
display interfaces.

Change-Id: Ic68f41cd59931294b592577475ed7480459f2cf8
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
hrtimer: Prevent hrtimer_enqueue_reprogram race

hrtimer_enqueue_reprogram contains a race which could result in
timer.base switch during unlock/lock sequence.

hrtimer_enqueue_reprogram is releasing the lock protecting the timer
base for calling raise_softirq_irqsoff() due to a lock ordering issue
versus rq->lock.

If during that time another CPU calls __hrtimer_start_range_ns() on
the same hrtimer, the timer base might switch, before the current CPU
can lock base->lock again and therefor the unlock_timer_base() call
will unlock the wrong lock.

[ tglx: Added comment and massaged changelog ]

Change-Id: I327d862c28f24b77a62861764393c4bf660a7318
Signed-off-by: Leonid Shatz <leonid.shatz@ravellosystems.com>
Signed-off-by: Izik Eidus <izik.eidus@ravellosystems.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1359981217-389-1-git-send-email-izik.eidus@ravellosystems.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Git-commit: b22affe0aef429d657bc6505aacb1c569340ddd2
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Taniya Das <tdas@codeaurora.org>
hrtimer: Don't reinitialize a cpu_base's lock on CPU_UP

The current code makes the assumption that a cpu_base lock cannot
be held if a CPU is offline, which is tragically wrong.

If a hrtimer is not queued, then it will not be migrated by
migrate_hrtimers() when a CPU is offlined. Therefore, the
hrtimer's cpu_base may still point to a CPU which has
subsequently gone offline if the timer wasn't enqueued at the
time the CPU went down.

Normally this wouldn't be a problem, but a cpu_base's lock is
blindly reinitialized each time a CPU is brought up. If a CPU is
brought online during the period that another thread is
performing a hrtimer operation on a stale hrtimer, then the lock
will be reinitialized under its feet, and a SPIN_BUG() like the
following will be observed:

 [  448.212369] BUG: spinlock already unlocked on CPU#3,
 swapper/3/0
[  448.217368]  lock: 0xc47b1a40, .magic: dead4ead, .owner:
swapper/3/0, .owner_cpu: -1
[  448.217398] [<c0014398>] (unwind_backtrace+0x0/0x120) from
[<c0269ab0>] (do_raw_spin_unlock+0x44/0xdc)
[  448.217419] [<c0269ab0>] (do_raw_spin_unlock+0x44/0xdc) from
[<c071bbb0>] (_raw_spin_unlock_irqrestore+0xc/0x38)
[  448.217438] [<c071bbb0>]
(_raw_spin_unlock_irqrestore+0xc/0x38) from [<c00aa498>]
(hrtimer_try_to_cancel+0xf8/0x10c)
[  448.217455] [<c00aa498>] (hrtimer_try_to_cancel+0xf8/0x10c)
from [<c00aa4bc>] (hrtimer_cancel+0x10/0x20)
[  448.217475] [<c00aa4bc>] (hrtimer_cancel+0x10/0x20) from
[<c00e6934>] (rcu_idle_exit_common+0x5c/0xe0)
[  448.217494] [<c00e6934>] (rcu_idle_exit_common+0x5c/0xe0) from
[<c00e6ae8>] (rcu_idle_exit+0x9c/0xb4)
[  448.217514] [<c00e6ae8>] (rcu_idle_exit+0x9c/0xb4) from
[<c000f2dc>] (cpu_idle+0x98/0xf0)
[  448.217529] [<c000f2dc>] (cpu_idle+0x98/0xf0) from
[<000081ac>] (0x81ac)

CRs-Fixed: 460670
Change-Id: I588f6a864054abe6d4c249aad815c6d2f5a54077
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
msm: timer: Use 32768Hz GPT and SCLK on 8064 family

On 8064 SOC family, a dedicated XO is derived to support
sleep clock at 32768Hz unlike 8960 SOC family where TCXO
divider was used with effective freq. of 32765Hz.

CRs-fixed: 462079
CRs-Fixed: 453095
Change-Id: I79142703c4ffac209f4dedeefebc235eeb8b140d
Signed-off-by: Jay Chokshi <jchokshi@codeaurora.org>
Signed-off-by: Taniya Das <tdas@codeaurora.org>
ASoC: wcd9xxx: Fix MBHC irq handler deadlock scenario.

There is a chance to encounter deadlock when either electrical mbhc irq
or mechanical mbhc irq releases resource lock to let polling thread finish
its job.  This is due to the possibility of one irq handler can preempt
already running the other type of irq handler.
Introduce a new mutex to avoid this preemption.

CRs-fixed: 428653
Change-Id: Idf24c62224026c9c061de12c31e248c05b47de9d
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>

Conflicts:

	drivers/mfd/wcd9xxx-irq.c

Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
Bluetooth: Avoiding a case, sleep is getting called from invalid context.

While performing SSR, when BT is turned on & connected with BT
headset. Sometimes sleep is getting called in process context
from work queue, which is queued from a code section guarded
under the bh lock. Using  normal lock instead of bh lock to
resolve the issue.

CRs-Fixed: 464823
Change-Id: I28d5a3df7c624231b40ee0dd1a60d257aab5864f
Signed-off-by: Nitin Shivpure <nshivpur@codeaurora.org>
use clamp_t in UNAME26 fix

The min/max call needed to have explicit types on some architectures
(e.g. mn10300). Use clamp_t instead to avoid the warning:

  kernel/sys.c: In function 'override_release':
  kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a cast [enabled by default]

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge "hrtimer: Prevent hrtimer_enqueue_reprogram race"
Merge "hrtimer: Don't reinitialize a cpu_base's lock on CPU_UP"
Merge "msm: timer: Use 32768Hz GPT and SCLK on 8064 family"
Merge "ASoC: wcd9xxx: Fix MBHC irq handler deadlock scenario."
Merge "Bluetooth: Avoiding a case, sleep is getting called from invalid context."
Merge "use clamp_t in UNAME26 fix"
Merge "Bluetooth:Show bonding dialog if neither side requires no bonding"
Merge "Revert "Bluetooth: Initiate dedicated bonding if pin/key missing on remote device""
Merge "msm_fb: hdmi: Proper HPD state update"