[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1528453446.26356.12.camel@pengutronix.de>
Date: Fri, 08 Jun 2018 12:24:06 +0200
From: Lucas Stach <l.stach@...gutronix.de>
To: Eric Anholt <eric@...olt.net>, dri-devel@...ts.freedesktop.org
Cc: linux-kernel@...r.kernel.org, amd-gfx@...ts.freedesktop.org
Subject: Re: [PATCH 3/3] drm/v3d: Add a note about locking of
v3d_fence_create().
Am Dienstag, den 05.06.2018, 12:03 -0700 schrieb Eric Anholt:
> This isn't the first time I've had to argue to myself why the '++' was
> safe.
And now you need to do the same thing with me...
> Signed-off-by: Eric Anholt <eric@...olt.net>
> ---
> drivers/gpu/drm/v3d/v3d_fence.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_fence.c b/drivers/gpu/drm/v3d/v3d_fence.c
> index bfe31a89668b..6265e9ab4a13 100644
> --- a/drivers/gpu/drm/v3d/v3d_fence.c
> +++ b/drivers/gpu/drm/v3d/v3d_fence.c
> @@ -3,6 +3,9 @@
>
> #include "v3d_drv.h"
>
> +/* Note that V3D fences are created during v3d_job_run(), so we're
> + * already implictly locked.
> + */
I don't see where you would be locked in the job_run path. I think what
you mean is that this path needs no locks, as it is driven by a single
scheduler thread, right?
Regards,
Lucas
Powered by blists - more mailing lists