On Mon, May 30, 2016 at 11:10:49AM +0200, Daniel Vetter wrote:

Signed-off-by: Daniel Vetter daniel.vetter@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-&lt;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