drm/i915: Remove todo and comments about struct_mutex
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:
parent
34ac58ded8
commit
b69f8c496e
|
@ -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.
|
||||
|
|
|
@ -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()
|
||||
---------------------------------------------
|
||||
|
||||
|
|
Loading…
Reference in New Issue