>-----Original Message----- >From: dri-devel <dri-devel-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Emil >Velikov >Sent: Thursday, May 7, 2020 11:08 AM >To: dri-devel@xxxxxxxxxxxxxxxxxxxxx >Cc: emil.l.velikov@xxxxxxxxx >Subject: [PATCH 03/36] drm/todo: mention i915 in the struct_mutex section > >From: Emil Velikov <emil.velikov@xxxxxxxxxxxxx> > >Signed-off-by: Emil Velikov <emil.velikov@xxxxxxxxxxxxx> >--- >i915 uses the _unlocked version of the grm_gem_object API. Yet makes an >extensive use of the struct_mutex. s/grm_/drm_/ ? M > >Did not check how exactly it all work though. >--- > Documentation/gpu/todo.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst >index 658b52f7ffc6..2ce52c5917f8 100644 >--- a/Documentation/gpu/todo.rst >+++ b/Documentation/gpu/todo.rst >@@ -157,8 +157,8 @@ 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`` driver still use ``struct_mutex``. >+fine-grained per-buffer object and per-context lockings scheme. Currently >only >+the ``msm`` and `i915` drivers use ``struct_mutex``. > > Contact: Daniel Vetter, respective driver maintainers > >-- >2.25.1 > >_______________________________________________ >dri-devel mailing list >dri-devel@xxxxxxxxxxxxxxxxxxxxx >https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
