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 hiddenbehind 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