Commit 0645de5a authored by Daniel Vetter's avatar Daniel Vetter
parent f55f1701
...@@ -1092,22 +1092,6 @@ int max_width, max_height;</synopsis> ...@@ -1092,22 +1092,6 @@ int max_width, max_height;</synopsis>
operation. operation.
</para> </para>
</sect2> </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> </sect1>
<!-- Internals: kms initialization and cleanup --> <!-- Internals: kms initialization and cleanup -->
......
...@@ -30,12 +30,12 @@ ...@@ -30,12 +30,12 @@
* *
* As KMS moves toward more fine grained locking, and atomic ioctl where * As KMS moves toward more fine grained locking, and atomic ioctl where
* userspace can indirectly control locking order, it becomes necessary * 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 * 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 * of extra utility/tracking out of our acquire-ctx. This is provided
* by drm_modeset_lock / drm_modeset_acquire_ctx. * 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: * The basic usage pattern is to:
* *
...@@ -51,6 +51,13 @@ ...@@ -51,6 +51,13 @@
* ... do stuff ... * ... do stuff ...
* drm_modeset_drop_locks(&ctx); * drm_modeset_drop_locks(&ctx);
* drm_modeset_acquire_fini(&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.
*/ */
/** /**
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment