[PATCH 9/9 v3] drm/i915: Remove todo and comments about struct_mutex

[Thomas Zimmermann]

Am 15.08.25 um 15:03 schrieb Rodrigo Vivi:
> 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.mello at estudante.ufscar.br>
>> Reviewed-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
>> ---
>>   Documentation/gpu/i915.rst |  7 -------
>>   Documentation/gpu/todo.rst | 25 -------------------------
> drm,drm-misc maintainers, ack to merge this through drm-intel-next?

Sure, ack.

>
>>   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
>>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)