On Fri, May 08, 2020 at 12:00:40PM +0100, Emil Velikov wrote:
On Fri, 8 May 2020 at 07:40, Daniel Vetter daniel@ffwll.ch wrote:
On Thu, May 07, 2020 at 04:07:56PM +0100, Emil Velikov wrote:
From: Emil Velikov emil.velikov@collabora.com
Vast majority of DRM (core and drivers) are struct_mutex free.
As such we have only a handful of cases where the locked helper should be used. Make that stand out a little bit better.
Done via the following script:
__from=drm_gem_object_put __to=drm_gem_object_put_locked
for __file in $(git grep --name-only --word-regexp $__from); do sed -i "s/<$__from>/$__to/g" $__file; done
Cc: Rob Clark robdclark@gmail.com Cc: Sean Paul sean@poorly.run Cc: linux-arm-msm@vger.kernel.org Signed-off-by: Emil Velikov emil.velikov@collabora.com
Since
commit 48e7f18392c66f9b69ebac11c54f1a2e033ced54 Author: Kristian H. Kristensen hoegsberg@gmail.com Date: Wed Mar 20 10:09:08 2019 -0700
drm/msm: Implement .gem_free_object_unlockedmsm doesn't need the struct_mutex in the bo_put anymore, the only reason we had to use the _locked version here is historical accidents I think.
I think you could convert these all to the _unlocked variant and then entirely drop the _locked version.
Did not check the msm driver closely, but it makes sense. Let's keep that as follow-up series? We're already at 36 patches, plus mixing mostly mechanical and locking changes doesn't sound wise.
My idea was to simply throw this patch out, and replace it by an msm patch to switch over to the unlocked variant.
Well maybe then needs 2nd patch to throw the locked version out.
So feels a bit a detour to touch msm twice, which is why I suggested to do the more direct route. But if you feel strongly I guess we can go this way and then follow up with converting msm to unlocked and throwing the _locked variant out for good too. -Daniel
Once we have that we could move struct_mutex into each driver (at least for msm and i915) since it's purely internal, and then wrap it in an #ifdef CONFIG_DRM_LEGACY to gloriously sunset it all :-)
Indeed, we're nearly there.
-Emil