aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/dma-buf
diff options
context:
space:
mode:
authorDaniel Vetter <daniel.vetter@ffwll.ch>2019-11-19 22:08:42 +0100
committerDaniel Vetter <daniel.vetter@ffwll.ch>2019-11-21 11:03:31 +0100
commit2c51419e8c06f6b8b1b91892688b17dd9a7f6e39 (patch)
treee9344a662434885fcd48ae09524fba094e68f36b /drivers/dma-buf
parentMAINTAINERS: Remove myself from drm-misc entry (diff)
downloadlinux-dev-2c51419e8c06f6b8b1b91892688b17dd9a7f6e39.tar.xz
linux-dev-2c51419e8c06f6b8b1b91892688b17dd9a7f6e39.zip
drm/modeset: Prime modeset lock vs dma_resv
It's kinda really hard to get this wrong on a driver with both display and dma_resv locking. But who ever knows, so better to make sure that really all drivers nest these the same way. For actual lock semantics the acquire context nesting doesn't matter. But to teach lockdep what's going on with ww_mutex the acquire ctx is a fake lockdep lock, hence from a lockdep pov it does matter. That's why I figured better to include it. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian König <christian.koenig@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191119210844.16947-2-daniel.vetter@ffwll.ch
Diffstat (limited to 'drivers/dma-buf')
0 files changed, 0 insertions, 0 deletions