[PATCH] drm/doc: Unify KMS Locking docs
Daniel Vetter
daniel at ffwll.ch
Mon May 30 09:19:10 UTC 2016
On Mon, May 30, 2016 at 11:10:49AM +0200, Daniel Vetter wrote:
> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
Merged with Jani's irc-ack - we want to get all things docbook merged
before the big sphinx conversion happens.
-Daniel
> ---
> 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 d755d53615d7..cb130514cedf 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -1092,22 +1092,6 @@ int max_width, max_height;</synopsis>
> operation.
> </para>
> </sect2>
> - <sect2>
> - <title>Locking</title>
> - <para>
> - Beside some lookup structures with their own locking (which is hidden
> - behind the interface functions) most of the modeset state is protected
> - by the <code>dev-<mode_config.lock</code> 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 <code>mode_config.lock</code>
> - to allow concurrent screen updates on live crtcs).
> - </para>
> - </sect2>
> </sect1>
>
> <!-- Internals: kms initialization and cleanup -->
> 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.8.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the dri-devel
mailing list