]> git.baikalelectronics.ru Git - kernel.git/commit
drm: Drop modeset locking from crtc init function
authorDaniel Vetter <daniel.vetter@ffwll.ch>
Mon, 8 Sep 2014 07:02:49 +0000 (09:02 +0200)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Mon, 15 Sep 2014 06:56:30 +0000 (08:56 +0200)
commitc755aee4f3c0cb058b8be5256031ae4cca750f2f
tree982718b5a303801f405af3a36aa74d9e7f025c31
parente52e969c20590fa705445232c38b60a88ae7dadd
drm: Drop modeset locking from crtc init function

At driver init no one can access modeset objects and we're
single-threaded. So locking is just cargo-culting here. Worse, with
the new ww mutexes and ww mutex slowpath debugging the mutex_lock
might actually fail, and we don't have the full-blown ww recovery
dance.

Which then leads to fireworks when we try to unlock the not-locked
crtc lock.

An audit of all the functions called from here shows that none of them
contain locking checks, so there's also no reason to keep the locking
around just for consistency of caller contexts. Besides that I have
the rule (at least in i915) that such places where we take locks just
to simplify locking checks and not for correctness always require a
comment.

This regression was introduced in

commit dbe8066b1e2e11645d1eb41269d8e4322280cb1c
Author: Rob Clark <robdclark@gmail.com>
Date:   Tue Nov 19 12:10:12 2013 -0500

    drm: convert crtc and connection_mutex to ww_mutex (v5)

v2: Don't drop the lock_init call, spotted by the 0day builder.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=83341
Cc: Rob Clark <robdclark@gmail.com>
Cc: thellstrom@vmware.com
Cc: maarten.lankhorst@canonical.com
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
drivers/gpu/drm/drm_crtc.c