From 0645de5a4c22638170f6e0bb31a0b1c9f52daf93 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Mon, 30 May 2016 11:10:49 +0200 Subject: [PATCH] drm/doc: Unify KMS Locking docs Signed-off-by: Daniel Vetter Acked-by: Jani Nikula Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1464599449-12509-1-git-send-email-daniel.vetter@ffwll.ch --- Documentation/DocBook/gpu.tmpl | 16 ---------------- drivers/gpu/drm/drm_modeset_lock.c | 11 +++++++++-- 2 files changed, 9 insertions(+), 18 deletions(-) diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index 90dbdb5087c4..221a4929ca59 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -1092,22 +1092,6 @@ int max_width, max_height; operation. - - Locking - - Beside some lookup structures with their own locking (which is hidden - behind the interface functions) most of the modeset state is protected - by the dev-<mode_config.lock mutex and additionally - per-crtc locks to allow cursor updates, pageflips and similar operations - to occur concurrently with background tasks like output detection. - Operations which cross domains like a full modeset always grab all - locks. Drivers there need to protect resources shared between crtcs with - additional locking. They also need to be careful to always grab the - relevant crtc locks if a modset functions touches crtc state, e.g. for - load detection (which does only grab the mode_config.lock - to allow concurrent screen updates on live crtcs). - - diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c index e3a4adf03e7b..f33ebe638a28 100644 --- a/drivers/gpu/drm/drm_modeset_lock.c +++ b/drivers/gpu/drm/drm_modeset_lock.c @@ -30,12 +30,12 @@ * * As KMS moves toward more fine grained locking, and atomic ioctl where * userspace can indirectly control locking order, it becomes necessary - * to use ww_mutex and acquire-contexts to avoid deadlocks. But because + * to use &ww_mutex and acquire-contexts to avoid deadlocks. But because * the locking is more distributed around the driver code, we want a bit * of extra utility/tracking out of our acquire-ctx. This is provided * by drm_modeset_lock / drm_modeset_acquire_ctx. * - * For basic principles of ww_mutex, see: Documentation/locking/ww-mutex-design.txt + * For basic principles of &ww_mutex, see: Documentation/locking/ww-mutex-design.txt * * The basic usage pattern is to: * @@ -51,6 +51,13 @@ * ... do stuff ... * drm_modeset_drop_locks(&ctx); * drm_modeset_acquire_fini(&ctx); + * + * On top of of these per-object locks using &ww_mutex there's also an overall + * dev->mode_config.lock, for protecting everything else. Mostly this means + * probe state of connectors, and preventing hotplug add/removal of connectors. + * + * Finally there's a bunch of dedicated locks to protect drm core internal + * lists and lookup data structures. */ /** -- 2.20.1