From: Lucas Stach <l.stach@pengutronix.de> To: Eric Anholt <eric@anholt.net>, dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 3/3] drm/v3d: Add a note about locking of v3d_fence_create(). Date: Fri, 08 Jun 2018 12:24:06 +0200 [thread overview] Message-ID: <1528453446.26356.12.camel@pengutronix.de> (raw) In-Reply-To: <20180605190302.18279-3-eric@anholt.net> 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@anholt.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
WARNING: multiple messages have this Message-ID (diff)
From: Lucas Stach <l.stach@pengutronix.de> To: Eric Anholt <eric@anholt.net>, dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 3/3] drm/v3d: Add a note about locking of v3d_fence_create(). Date: Fri, 08 Jun 2018 12:24:06 +0200 [thread overview] Message-ID: <1528453446.26356.12.camel@pengutronix.de> (raw) In-Reply-To: <20180605190302.18279-3-eric@anholt.net> 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@anholt.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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-06-08 10:24 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-06-05 19:03 [PATCH 1/3] drm/v3d: Take a lock across GPU scheduler job creation and queuing Eric Anholt 2018-06-05 19:03 ` Eric Anholt 2018-06-05 19:03 ` [PATCH 2/3] drm/v3d: Remove the bad signaled() implementation Eric Anholt 2018-06-05 19:03 ` Eric Anholt 2018-06-08 10:21 ` Lucas Stach 2018-06-08 10:21 ` Lucas Stach 2018-06-05 19:03 ` [PATCH 3/3] drm/v3d: Add a note about locking of v3d_fence_create() Eric Anholt 2018-06-05 19:03 ` Eric Anholt 2018-06-08 10:24 ` Lucas Stach [this message] 2018-06-08 10:24 ` Lucas Stach 2018-06-08 17:08 ` Eric Anholt 2018-06-08 17:08 ` Eric Anholt 2018-06-06 8:46 ` [PATCH 1/3] drm/v3d: Take a lock across GPU scheduler job creation and queuing Lucas Stach 2018-06-06 8:46 ` Lucas Stach 2018-06-06 8:52 ` Christian König 2018-06-06 17:48 ` [PATCH 1/3 v2] " Eric Anholt 2018-06-06 17:48 ` Eric Anholt 2018-06-07 8:37 ` Lucas Stach 2018-06-07 8:37 ` Lucas Stach
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1528453446.26356.12.camel@pengutronix.de \ --to=l.stach@pengutronix.de \ --cc=amd-gfx@lists.freedesktop.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=eric@anholt.net \ --cc=linux-kernel@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.