summaryrefslogtreecommitdiffstats
path: root/drivers/misc/sram-exec.c
diff options
context:
space:
mode:
authorDaniel Vetter <daniel.vetter@ffwll.ch>2017-07-15 11:53:28 +0200
committerDaniel Vetter <daniel.vetter@ffwll.ch>2017-07-18 09:17:22 +0200
commit3379c04cfa11043e26953c784a7202709b19658e (patch)
tree3a4e1323112a7aef8db37c00ac69fe54ef593e39 /drivers/misc/sram-exec.c
parent98755a51fbfd12a9eb3379bc51941375934545b4 (diff)
downloadlinux-stable-3379c04cfa11043e26953c784a7202709b19658e.tar.gz
linux-stable-3379c04cfa11043e26953c784a7202709b19658e.tar.bz2
linux-stable-3379c04cfa11043e26953c784a7202709b19658e.zip
drm: Don't complain too much about struct_mutex.
For modern drivers the DRM core doesn't use struct_mutex at all, which means it's defacto a driver-private lock. But since we still need it for legacy drivers we can't initialize it in drivers, which means all the different instances share one lockdep key. Despite that they might be placed in totally different places in the locking hierarchy. This results in a lot of bogus lockdep splats when running stuff on systems with multiple gpus. Partially remedy the situation by only doing might_lock checks on drivers that do use struct_mutex still for gem locking. A more complete solution would be to do the mutex_init in the drm core only for legacy drivers, plus add it to each modern driver that still needs it, which would also give each its own lockdep key. Trying to do that dynamically doesn't work, because lockdep requires it's keys to be statically allocated. v2: {} everywhere (Chris) Cc: Hans de Goede <hdegoede@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Jiri Slaby <jirislaby@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@redhat.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170715095328.25671-1-daniel.vetter@ffwll.ch
Diffstat (limited to 'drivers/misc/sram-exec.c')
0 files changed, 0 insertions, 0 deletions