On Wed, Aug 13, 2025 at 10:50:33AM -0300, Luiz Otavio Mello wrote: > This patch completes the removal of struct_mutex from the driver. > > Remove the related TODO item, as the transition away from struct_mutex > is now complete. > > Also clean up references to struct_mutex in i915.rst to avoid outdated > documentation. > > Signed-off-by: Luiz Otavio Mello <luiz.me...@estudante.ufscar.br> > Reviewed-by: Rodrigo Vivi <rodrigo.v...@intel.com> > --- > Documentation/gpu/i915.rst | 7 ------- > Documentation/gpu/todo.rst | 25 -------------------------
drm,drm-misc maintainers, ack to merge this through drm-intel-next? > 2 files changed, 32 deletions(-) > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > index 72932fa31b8d..eba09c3ddce4 100644 > --- a/Documentation/gpu/i915.rst > +++ b/Documentation/gpu/i915.rst > @@ -358,8 +358,6 @@ Locking Guidelines > #. All locking rules and interface contracts with cross-driver interfaces > (dma-buf, dma_fence) need to be followed. > > -#. No struct_mutex anywhere in the code > - > #. dma_resv will be the outermost lock (when needed) and ww_acquire_ctx > is to be hoisted at highest level and passed down within i915_gem_ctx > in the call chain > @@ -367,11 +365,6 @@ Locking Guidelines > #. While holding lru/memory manager (buddy, drm_mm, whatever) locks > system memory allocations are not allowed > > - * Enforce this by priming lockdep (with fs_reclaim). If we > - allocate memory while holding these looks we get a rehash > - of the shrinker vs. struct_mutex saga, and that would be > - real bad. > - > #. Do not nest different lru/memory manager locks within each other. > Take them in turn to update memory allocations, relying on the object’s > dma_resv ww_mutex to serialize against other operations. > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 92db80793bba..b5f58b4274b1 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -173,31 +173,6 @@ Contact: Simona Vetter > > Level: Intermediate > > -Get rid of dev->struct_mutex from GEM drivers > ---------------------------------------------- > - > -``dev->struct_mutex`` is the Big DRM Lock from legacy days and infested > -everything. Nowadays in modern drivers the only bit where it's mandatory is > -serializing GEM buffer object destruction. Which unfortunately means drivers > -have to keep track of that lock and either call ``unreference`` or > -``unreference_locked`` depending upon context. > - > -Core GEM doesn't have a need for ``struct_mutex`` any more since kernel 4.8, > -and there's a GEM object ``free`` callback for any drivers which are > -entirely ``struct_mutex`` free. > - > -For drivers that need ``struct_mutex`` it should be replaced with a driver- > -private lock. The tricky part is the BO free functions, since those can't > -reliably take that lock any more. Instead state needs to be protected with > -suitable subordinate locks or some cleanup work pushed to a worker thread. > For > -performance-critical drivers it might also be better to go with a more > -fine-grained per-buffer object and per-context lockings scheme. Currently > only > -the ``msm`` and `i915` drivers use ``struct_mutex``. > - > -Contact: Simona Vetter, respective driver maintainers > - > -Level: Advanced > - > Move Buffer Object Locking to dma_resv_lock() > --------------------------------------------- > > -- > 2.50.1 >
