The only thing that omap_gem_free_object does that might need the magic protection of struct_mutex (of keeping all objects alive if that lock is held, even if the last reference is gone) is the mm_list manipulation.
But that is already protected by the separate omapdrm->list_lock, which means struct_mutex is an entirely internal lock for omapdrm. Everything else is just releasing resources, which is all protected already by the various subsystems and allocators.
To make this even more obvious we could do an s/dev->struct_mutex/omapdrm->gem_lock/ like I've done for udl. But since omapdrm is a lot bigger and a lot more active I'll refrain from that - this is better done by omapdrm developers at some suitable time in the future.
Signed-off-by: Daniel Vetter daniel.vetter@intel.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com --- drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c index 3f40f7af3285..6d52877ed25a 100644 --- a/drivers/gpu/drm/omapdrm/omap_drv.c +++ b/drivers/gpu/drm/omapdrm/omap_drv.c @@ -490,7 +490,7 @@ static struct drm_driver omap_drm_driver = { .prime_fd_to_handle = drm_gem_prime_fd_to_handle, .gem_prime_export = omap_gem_prime_export, .gem_prime_import = omap_gem_prime_import, - .gem_free_object = omap_gem_free_object, + .gem_free_object_unlocked = omap_gem_free_object, .gem_vm_ops = &omap_gem_vm_ops, .dumb_create = omap_gem_dumb_create, .dumb_map_offset = omap_gem_dumb_map_offset,