[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y2p8QzOMH/nm4IM3@phenom.ffwll.local>
Date: Tue, 8 Nov 2022 16:56:51 +0100
From: Daniel Vetter <daniel@...ll.ch>
To: Maíra Canal <mcanal@...lia.com>
Cc: Melissa Wen <mwen@...lia.com>, Emma Anholt <emma@...olt.net>,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
André Almeida <andrealmeid@...lia.com>,
"Juan A . Suarez" <jasuarez@...lia.com>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] drm/v3d: switch to drmm_mutex_init
On Mon, Nov 07, 2022 at 07:46:55PM -0300, Maíra Canal wrote:
> mutex_init() is supposed to be balanced by a call to mutex_destroy(), but
> this is not currently happening on the v3d driver.
>
> Considering the introduction of a DRM-managed mutex_init variant, switch
> to drmm_mutex_init.
>
> Signed-off-by: Maíra Canal <mcanal@...lia.com>
Reviewed-by: Daniel Vetter <daniel.vetter@...ll.ch>
> ---
> drivers/gpu/drm/v3d/v3d_gem.c | 17 +++++++++++++----
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
> index b8980440d137..96af1cb5202a 100644
> --- a/drivers/gpu/drm/v3d/v3d_gem.c
> +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> @@ -10,6 +10,7 @@
> #include <linux/sched/signal.h>
> #include <linux/uaccess.h>
>
> +#include <drm/drm_managed.h>
> #include <drm/drm_syncobj.h>
> #include <uapi/drm/v3d_drm.h>
>
> @@ -1075,10 +1076,18 @@ v3d_gem_init(struct drm_device *dev)
>
> spin_lock_init(&v3d->mm_lock);
> spin_lock_init(&v3d->job_lock);
> - mutex_init(&v3d->bo_lock);
> - mutex_init(&v3d->reset_lock);
> - mutex_init(&v3d->sched_lock);
> - mutex_init(&v3d->cache_clean_lock);
> + ret = drmm_mutex_init(dev, &v3d->bo_lock);
> + if (ret)
> + return ret;
> + ret = drmm_mutex_init(dev, &v3d->reset_lock);
> + if (ret)
> + return ret;
> + ret = drmm_mutex_init(dev, &v3d->sched_lock);
> + if (ret)
> + return ret;
> + ret = drmm_mutex_init(dev, &v3d->cache_clean_lock);
> + if (ret)
> + return ret;
>
> /* Note: We don't allocate address 0. Various bits of HW
> * treat 0 as special, such as the occlusion query counters
> --
> 2.38.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Powered by blists - more mailing lists