drm/atomic: Add WARN_ON when state->acquire_ctx is not set.

When I was writing an atomic wrapper for rmfb, I ran into the
following backtrace from lockdep:

=============================================
[ INFO: possible recursive locking detected ]
4.5.0-patser+ #4696 Tainted: G     U
---------------------------------------------
kworker/2:2/2608 is trying to acquire lock:
 (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffc00c9ddc>] drm_modeset_lock+0x7c/0x120 [drm]

but task is already holding lock:
 (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffc00c98cd>] modeset_backoff+0x8d/0x220 [drm]

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(crtc_ww_class_mutex);
  lock(crtc_ww_class_mutex);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

4 locks held by kworker/2:2/2608:
 #0:  ("events"){.+.+.+}, at: [<ffffffff810a5eea>] process_one_work+0x15a/0x6c0
 #1:  ((&arg.work)){+.+.+.}, at: [<ffffffff810a5eea>] process_one_work+0x15a/0x6c0
 #2:  (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffffc004532a>] drm_atomic_helper_remove_fb+0x4a/0x1d0 [drm_kms_helper]
 #3:  (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffc00c98cd>] modeset_backoff+0x8d/0x220 [drm]

While lockdep probably catches this bug when it happens, it's better
to explicitly warn when state->acquire_ctx is not set.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1462266751-29123-1-git-send-email-maarten.lankhorst@linux.intel.com

0 files changed, 0 insertions, 0 deletions