[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87vaatxl3h.fsf@anholt.net>
Date: Fri, 08 Jun 2018 10:08:02 -0700
From: Eric Anholt <eric@...olt.net>
To: Lucas Stach <l.stach@...gutronix.de>,
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().
Lucas Stach <l.stach@...gutronix.de> writes:
> 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?
Yeah, it's only called from run_job, and run_job can't reenter.
Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
Powered by blists - more mailing lists