mirrors/linux
1
0
Fork 1
mirror of https://github.com/torvalds/linux.git synced 2025-11-04 02:30:34 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

drm/i915: Remove todo and comments about struct_mutex

Browse source 
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.mello@estudante.ufscar.br>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250908131518.36625-10-luiz.mello@estudante.ufscar.br
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
This commit is contained in:
Luiz Otavio Mello 2025-09-08 09:15:17 -04:00 committed by Rodrigo Vivi
parent 34ac58ded8
commit b69f8c496e
No known key found for this signature in database
GPG key ID: FA625F640EEB13CA
2 changed files with 0 additions and 32 deletions
repo.diff.show_diff_stats Download patch file Download diff file Expand all files Collapse all files

7
Documentation/gpu/i915.rst
View file

@ -358,8 +358,6 @@ Locking Guidelines
#. All locking rules and interface contracts with cross-driver interfaces #. All locking rules and interface contracts with cross-driver interfaces
(dma-buf, dma_fence) need to be followed. (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 #. 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 is to be hoisted at highest level and passed down within i915_gem_ctx
in the call chain in the call chain
@ -367,11 +365,6 @@ Locking Guidelines
#. While holding lru/memory manager (buddy, drm_mm, whatever) locks #. While holding lru/memory manager (buddy, drm_mm, whatever) locks
system memory allocations are not allowed 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. #. Do not nest different lru/memory manager locks within each other.
Take them in turn to update memory allocations, relying on the object’s Take them in turn to update memory allocations, relying on the object’s
dma_resv ww_mutex to serialize against other operations. dma_resv ww_mutex to serialize against other operations.

25
Documentation/gpu/todo.rst
View file

@ -173,31 +173,6 @@ Contact: Simona Vetter
Level: Intermediate 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() Move Buffer Object Locking to dma_resv_lock()
--------------------------------------------- ---------------------------------------------