The gnome-shell wayland compositor triggers a setcrtc with an fb that is
still being rendered, triggering the call to _wait_fence_interruptable().
But a NULL timeout means "don't wait, return -EBUSY if not ready", which
in turn causes the setcrtc to fail.
Signed-off-by: NRob Clark <robdclark@gmail.com>

As a result of atomic DPMS support, the various prepare/commit hooks get
called in a way that msm dislikes.  We were expecting prepare/commit to
bracket a modeset, which is no longer the case.  This was needed to hold
various extra clk's (such as interface clks) on while we are touching
registers, and in the case of mdp4 holding vblank enabled.

The most straightforward way to deal with this, since we already have
our own atomic_commit(), is to just handle prepare/commit internally to
the driver (with some additional vfuncs for mdp4 vs mdp5), and switch
everything over to instead use the new enable/disable hooks.  It doesn't
really change too much, despite the code motion.  What used to be in the
encoder/crtc dpms() fxns is split out into enable/disable.

We should be able to drop our own enable-state tracking, as the atomic
helpers should do this for us.  But keeping that for the short term for
extra debugging as atomic stablizes.
Signed-off-by: NRob Clark <robdclark@gmail.com>

We can't have multiple updates pending on a given CRTC, and we don't
want a sync update to race w/ an async update that preceeded it.  So
keep track of which CRTCs have updates in flight, and block later
updates that would conflict.
Signed-off-by: NRob Clark <robdclark@gmail.com>

This essentially reverts

commit 934ce1c2
Author: Rob Clark <robdclark@gmail.com>
Date:   Wed Nov 19 16:41:33 2014 -0500

    drm/atomic: check mode_changed *after* atomic_check

Depending upon the driver both orders (or maybe even interleaving) is
required:
- If ->atomic_check updates ->mode_changed then helper_check_modeset
  must be run afters.
- If ->atomic_check depends upon accurate adjusted dotclock values for
  e.g. watermarks, then helper_check_modeset must be run first.

The failure mode in the first case is usually a totally angry hw
because the pixel format switching doesn't happen. The failure mode in
the later case is usually nothing, since in most cases the old
adjusted mode from the previous modeset wont be too far off to be a
problem. So just underruns and perhaps even just suboptimal (from a
power consumption) watermarks.

Furthermore in the transitional helpers we only call ->atomic_check
after the new modeset state has been fully set up (and hence
computed).

Given that asymmetry in expected failure modes I think it's safer to
go back to the older order. So do that and give msm a special check
function to compensate.

Also update kerneldoc to explain this a bit.

v2: Actually add the missing hunk Rob spotted.

v3: Move msm_atomic_check into msm_atomic.c, requested by Rob.

Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Tested-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Fixes for a couple little issues found in testing.
Signed-off-by: NRob Clark <robdclark@gmail.com>

The core parts for async commit.
Signed-off-by: NRob Clark <robdclark@gmail.com>