[PATCH] drm/doc: Unify KMS Locking docs

2016-05-30 Thread Daniel Vetter
On Mon, May 30, 2016 at 11:10:49AM +0200, Daniel Vetter wrote:
> Signed-off-by: Daniel Vetter 

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;
>  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 _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 _mutex, see: 
> Documentation/locking/ww-mutex-design.txt
>   *
>   * The basic usage pattern is to:
>   *
> @@ -51,6 +51,13 @@
>   * ... do stuff ...
>   * drm_modeset_drop_locks();
>   * drm_modeset_acquire_fini();
> + *
> + *  On top of of these per-object locks using _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


[PATCH] drm/doc: Unify KMS Locking docs

2016-05-30 Thread Daniel Vetter
Signed-off-by: Daniel Vetter 
---
 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;
 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 _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 _mutex, see: 
Documentation/locking/ww-mutex-design.txt
  *
  * The basic usage pattern is to:
  *
@@ -51,6 +51,13 @@
  * ... do stuff ...
  * drm_modeset_drop_locks();
  * drm_modeset_acquire_fini();
+ *
+ *  On top of of these per-object locks using _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