On Mon, May 30, 2016 at 11:10:49AM +0200, Daniel Vetter wrote: > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
