bam_dmux: Add d2usc workaround for modem crash.

Effectively reverts "msm: bam_dmux: Add locking around platform device
calls" (3688ab952920247bc79a1dd89293bd6449fb1127) for d2usc only, as this
commit is responsible for its modem crash and boot loop.

TODO: Determine exactly why this commit is related to the modem crash, and
why other d2 devices are unaffected.

Change-Id: Iafb7092f448f31c0b5a08c20d9d1921f356014a1
msm_fb: display: remove dmae wait in spinlock

This is a merge error that caused the crash when hdmi cable is
plugged. mdp4_dtv_wait4dmae is not included in spinlock in mainline
patch.

Change-Id: I3e95d281f19aef423bbc42f7e628ea94335a0843
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
msm_fb: display: add mutex on overlay_play to fix iommu page
 fault

An iommu page fault may heppen When a pipe_commit is executed
in between of frame dropped and pipe_queue during overlay play.
An mutex is necessary to mutual exclusive between pipe_commit
and overlay_play.

Change-Id: I736e821c6c648a6ebd435303a1906a40e9b75791
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
msm_fb: display: add wait for overlay0 done

Dcs command mode BLT involves both overlay0 done interrupt
and dmap done interrupt. A transaction is start at kickoff and
end with done interrupt.  At some cornor cases both overlay0 and
dmap transaction need to be completed before kickoff new transaction.

Change-Id: I5a3cc6e8255acf2c61fc627d35f990182d226f63
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
(cherry picked from commit 521230e19ad81077bf0ad51ee2989e058e129837)
PM: Limit race conditions between runtime PM and system
 sleep (v2)

One of the roles of the PM core is to prevent different PM callbacks
executed for the same device object from racing with each other.
Unfortunately, after commit e8665002477f0278f84f898145b1f141ba26ee26
(PM: Allow pm_runtime_suspend() to succeed during system suspend)
runtime PM callbacks may be executed concurrently with system
suspend/resume callbacks for the same device.

The main reason for commit e8665002477f0278f84f898145b1f141ba26ee26
was that some subsystems and device drivers wanted to use runtime PM
helpers, pm_runtime_suspend() and pm_runtime_put_sync() in
particular, for carrying out the suspend of devices in their
.suspend() callbacks.  However, as it's been determined recently,
there are multiple reasons not to do so, inlcuding:

 * The caller really doesn't control the runtime PM usage counters,
   because user space can access them through sysfs and effectively
   block runtime PM.  That means using pm_runtime_suspend() or
   pm_runtime_get_sync() to suspend devices during system suspend
   may or may not work.

 * If a driver calls pm_runtime_suspend() from its .suspend()
   callback, it causes the subsystem's .runtime_suspend() callback to
   be executed, which leads to the call sequence:

   subsys->suspend(dev)
      driver->suspend(dev)
         pm_runtime_suspend(dev)
            subsys->runtime_suspend(dev)

   recursive from the subsystem's point of view.  For some subsystems
   that may actually work (e.g. the platform bus type), but for some
   it will fail in a rather spectacular fashion (e.g. PCI).  In each
   case it means a layering violation.

 * Both the subsystem and the driver can provide .suspend_noirq()
   callbacks for system suspend that can do whatever the
   .runtime_suspend() callbacks do just fine, so it really isn't
   necessary to call pm_runtime_suspend() during system suspend.

 * The runtime PM's handling of wakeup devices is usually different
   from the system suspend's one, so .runtime_suspend() may simply be
   inappropriate for system suspend.

 * System suspend is supposed to work even if CONFIG_PM_RUNTIME is
   unset.

 * The runtime PM workqueue is frozen before system suspend, so if
   whatever the driver is going to do during system suspend depends
   on it, that simply won't work.

Still, there is a good reason to allow pm_runtime_resume() to
succeed during system suspend and resume (for instance, some
subsystems and device drivers may legitimately use it to ensure that
their devices are in full-power states before suspending them).
Moreover, there is no reason to prevent runtime PM callbacks from
being executed in parallel with the system suspend/resume .prepare()
and .complete() callbacks and the code removed by commit
e8665002477f0278f84f898145b1f141ba26ee26 went too far in this
respect.  On the other hand, runtime PM callbacks, including
.runtime_resume(), must not be executed during system suspend's
"late" stage of suspending devices and during system resume's "early"
device resume stage.

Taking all of the above into consideration, make the PM core
acquire a runtime PM reference to every device and resume it if
there's a runtime PM resume request pending right before executing
the subsystem-level .suspend() callback for it.  Make the PM core
drop references to all devices right after executing the
subsystem-level .resume() callbacks for them.  Additionally,
make the PM core disable the runtime PM framework for all devices
during system suspend, after executing the subsystem-level .suspend()
callbacks for them, and enable the runtime PM framework for all
devices during system resume, right before executing the
subsystem-level .resume() callbacks for them.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
[jackp@codeaurora.org: resolved trivial merge conflicts]
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Change-Id: I408fbfe1544457ca65fc8b04d3a116cd7098fdfa
PM / Runtime: don't forget to wake up waitqueue on failure

commit f2791d733a2f06997b573d1a3cfde21e6f529826 upstream.

This patch (as1535) fixes a bug in the runtime PM core.  When a
runtime suspend attempt completes, whether successfully or not, the
device's power.wait_queue is supposed to be signalled.  But this
doesn't happen in the failure pathway of rpm_suspend() when another
autosuspend attempt is rescheduled.  As a result, a task can get stuck
indefinitely on the wait queue (I have seen this happen in testing).

The patch fixes the problem by moving the wake_up_all() call up near
the start of the failure code.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
[jackp@codeaurora.org: backported to msm-3.0: insert in correct context]
Signed-off-by: Jack Pham <jackp@codeaurora.org>
CRs-fixed: 375498
Change-Id: Idfcb87373e9ed1c62b922164ed780b22de3f9718