From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>,
DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 1/3] drm/vblank: Document and fix vblank count barrier semantics
Date: Fri, 19 Jul 2019 20:06:54 +0300 [thread overview]
Message-ID: <20190719170654.GQ5942@intel.com> (raw)
In-Reply-To: <20190719152314.7706-1-daniel.vetter@ffwll.ch>
On Fri, Jul 19, 2019 at 05:23:12PM +0200, Daniel Vetter wrote:
> Noticed while reviewing code. I'm not sure whether this might or might
> not explain some of the missed vblank hilarity we've been seeing. I
> think those all go through the vblank completion event, which has
> unconditional barriers - it always takes the spinlock. Therefore no
> cc stable.
>
> v2:
> - Barrriers are hard, put them in in the right order (Chris).
> - Improve the comments a bit.
>
> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> drivers/gpu/drm/drm_vblank.c | 38 +++++++++++++++++++++++++++++++++++-
> include/drm/drm_vblank.h | 13 +++++++++++-
> 2 files changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 603ab105125d..eb2a8304536c 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -295,11 +295,23 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe,
> static u64 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
> {
> struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
> + u64 count;
>
> if (WARN_ON(pipe >= dev->num_crtcs))
> return 0;
>
> - return vblank->count;
> + count = vblank->count;
Hmm. This is now a 64bit quantity, which means on 32bit the load/store
won't be atomic. That doesn't seem particularly great.
> +
> + /*
> + * This read barrier corresponds to the implicit write barrier of the
> + * write seqlock in store_vblank(). Note that this is the only place
> + * where we need an explicit barrier, since all other access goes
> + * through drm_vblank_count_and_time(), which already has the required
> + * read barrier curtesy of the read seqlock.
> + */
> + smp_rmb();
> +
> + return count;
> }
>
> /**
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-07-19 17:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-19 15:23 [PATCH 1/3] drm/vblank: Document and fix vblank count barrier semantics Daniel Vetter
2019-07-19 15:23 ` [PATCH 2/3] drm/vkms: Use wait_for_flip_done Daniel Vetter
2019-09-03 12:49 ` Rodrigo Siqueira
2019-09-03 15:12 ` Daniel Vetter
2019-07-19 15:23 ` [PATCH 3/3] drm/vkms: Reduce critical section in vblank_simulate Daniel Vetter
2019-09-03 12:50 ` Rodrigo Siqueira
2019-09-03 15:16 ` Daniel Vetter
2019-07-19 15:46 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/vblank: Document and fix vblank count barrier semantics Patchwork
2019-07-19 16:19 ` ✓ Fi.CI.BAT: success " Patchwork
2019-07-19 17:06 ` Ville Syrjälä [this message]
2019-07-19 18:33 ` [PATCH 1/3] " Daniel Vetter
2019-07-19 18:56 ` Ville Syrjälä
2019-07-23 13:13 ` [PATCH] " Daniel Vetter
2019-08-19 16:21 ` Ville Syrjälä
2019-09-03 12:47 ` Rodrigo Siqueira
2019-09-03 15:09 ` [Intel-gfx] " Daniel Vetter
2019-09-03 15:17 ` Rodrigo Siqueira
2019-09-03 15:46 ` Daniel Vetter
2019-07-19 23:02 ` ✓ Fi.CI.IGT: success for series starting with [1/3] " Patchwork
2019-07-23 13:43 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with drm/vblank: Document and fix vblank count barrier semantics (rev2) Patchwork
2019-07-23 14:34 ` ✓ Fi.CI.BAT: success " Patchwork
2019-07-23 18:18 ` ✓ Fi.CI.IGT: " Patchwork
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=20190719170654.GQ5942@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=rodrigosiqueiramelo@gmail.com \
/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: link
Be 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.