On Thu, Sep 16, 2021 at 11:15:52PM +0200, Fernando Ramos wrote: > The previous commits do exactly what this entry in the TODO file asks > for, thus we can remove it now as it is no longer applicable. Thanks for doing this work! Can we remove drm_modeset_lock_all[_ctx] now? If so, let's queue that up as part of the set. Reviewed-by: Sean Paul <sean@xxxxxxxxxx> > > Signed-off-by: Fernando Ramos <greenfoo@xxxxxx> > --- > Documentation/gpu/todo.rst | 17 ----------------- > Documentation/locking/ww-mutex-design.rst | 2 +- > 2 files changed, 1 insertion(+), 18 deletions(-) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 12e61869939e..6613543955e9 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -353,23 +353,6 @@ converted, except for struct drm_driver.gem_prime_mmap. > > Level: Intermediate > > -Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate > ---------------------------------------------------------- > - > -For cases where drivers are attempting to grab the modeset locks with a local > -acquire context. Replace the boilerplate code surrounding > -drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN() and > -DRM_MODESET_LOCK_ALL_END() instead. > - > -This should also be done for all places where drm_modeset_lock_all() is still > -used. > - > -As a reference, take a look at the conversions already completed in drm core. > - > -Contact: Sean Paul, respective driver maintainers > - > -Level: Starter > - > Rename CMA helpers to DMA helpers > --------------------------------- > > diff --git a/Documentation/locking/ww-mutex-design.rst b/Documentation/locking/ww-mutex-design.rst > index 6a4d7319f8f0..6a8f8beb9ec4 100644 > --- a/Documentation/locking/ww-mutex-design.rst > +++ b/Documentation/locking/ww-mutex-design.rst > @@ -60,7 +60,7 @@ Concepts > Compared to normal mutexes two additional concepts/objects show up in the lock > interface for w/w mutexes: > > -Acquire context: To ensure eventual forward progress it is important the a task > +Acquire context: To ensure eventual forward progress it is important that a task > trying to acquire locks doesn't grab a new reservation id, but keeps the one it > acquired when starting the lock acquisition. This ticket is stored in the > acquire context. Furthermore the acquire context keeps track of debugging state > -- > 2.33.0 > -- Sean Paul, Software Engineer, Google / Chromium OS
