All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/3] drm/vblank: Document and fix vblank count barrier semantics
@ 2019-07-19 15:23 Daniel Vetter
  2019-07-19 15:23 ` [PATCH 2/3] drm/vkms: Use wait_for_flip_done Daniel Vetter
                   ` (8 more replies)
  0 siblings, 9 replies; 22+ messages in thread
From: Daniel Vetter @ 2019-07-19 15:23 UTC (permalink / raw)
  To: DRI Development
  Cc: Daniel Vetter, Daniel Vetter, Intel Graphics Development,
	Rodrigo Siqueira

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;
+
+	/*
+	 * 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;
 }
 
 /**
@@ -764,6 +776,14 @@ drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
  * vblank interrupt (since it only reports the software vblank counter), see
  * drm_crtc_accurate_vblank_count() for such use-cases.
  *
+ * Note that for a given vblank counter value drm_crtc_handle_vblank()
+ * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
+ * provide a barrier: Any writes done before calling
+ * drm_crtc_handle_vblank() will be visible to callers of the later
+ * functions, iff the vblank count is the same or a later one.
+ *
+ * See also &drm_vblank_crtc.count.
+ *
  * Returns:
  * The software vblank counter.
  */
@@ -818,6 +838,14 @@ static u64 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
  * vblank events since the system was booted, including lost events due to
  * modesetting activity. Returns corresponding system timestamp of the time
  * of the vblank interval that corresponds to the current vblank counter value.
+ *
+ * Note that for a given vblank counter value drm_crtc_handle_vblank()
+ * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
+ * provide a barrier: Any writes done before calling
+ * drm_crtc_handle_vblank() will be visible to callers of the later
+ * functions, iff the vblank count is the same or a later one.
+ *
+ * See also &drm_vblank_crtc.count.
  */
 u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
 				   ktime_t *vblanktime)
@@ -1791,6 +1819,14 @@ EXPORT_SYMBOL(drm_handle_vblank);
  *
  * This is the native KMS version of drm_handle_vblank().
  *
+ * Note that for a given vblank counter value drm_crtc_handle_vblank()
+ * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
+ * provide a barrier: Any writes done before calling
+ * drm_crtc_handle_vblank() will be visible to callers of the later
+ * functions, iff the vblank count is the same or a later one.
+ *
+ * See also &drm_vblank_crtc.count.
+ *
  * Returns:
  * True if the event was successfully handled, false on failure.
  */
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index e528bb2f659d..5ec623740158 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -110,7 +110,18 @@ struct drm_vblank_crtc {
 	seqlock_t seqlock;
 
 	/**
-	 * @count: Current software vblank counter.
+	 * @count:
+	 *
+	 * Current software vblank counter.
+	 *
+	 * Note that for a given vblank counter value drm_crtc_handle_vblank()
+	 * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
+	 * provide a barrier: Any writes done before calling
+	 * drm_crtc_handle_vblank() will be visible to callers of the later
+	 * functions, iff the vblank count is the same or a later one.
+	 *
+	 * IMPORTANT: This guarantee requires barriers, therefor never access
+	 * this field directly. Use drm_crtc_vblank_count() instead.
 	 */
 	u64 count;
 	/**
-- 
2.22.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH 2/3] drm/vkms: Use wait_for_flip_done
  2019-07-19 15:23 [PATCH 1/3] drm/vblank: Document and fix vblank count barrier semantics Daniel Vetter
@ 2019-07-19 15:23 ` Daniel Vetter
  2019-09-03 12:49   ` Rodrigo Siqueira
  2019-07-19 15:23 ` [PATCH 3/3] drm/vkms: Reduce critical section in vblank_simulate Daniel Vetter
                   ` (7 subsequent siblings)
  8 siblings, 1 reply; 22+ messages in thread
From: Daniel Vetter @ 2019-07-19 15:23 UTC (permalink / raw)
  To: DRI Development
  Cc: Haneen Mohammed, Rodrigo Siqueira, Daniel Vetter,
	Intel Graphics Development, Daniel Vetter

It's the recommended version, wait_for_vblanks is a bit a hacky
interim thing that predates all the flip_done tracking. It's
unfortunately still the default ...

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
---
 drivers/gpu/drm/vkms/vkms_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 44ab9f8ef8be..80524a22412a 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -83,7 +83,7 @@ static void vkms_atomic_commit_tail(struct drm_atomic_state *old_state)
 
 	drm_atomic_helper_commit_hw_done(old_state);
 
-	drm_atomic_helper_wait_for_vblanks(dev, old_state);
+	drm_atomic_helper_wait_for_flip_done(dev, old_state);
 
 	for_each_old_crtc_in_state(old_state, crtc, old_crtc_state, i) {
 		struct vkms_crtc_state *vkms_state =
-- 
2.22.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH 3/3] drm/vkms: Reduce critical section in vblank_simulate
  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-07-19 15:23 ` Daniel Vetter
  2019-09-03 12:50   ` Rodrigo Siqueira
  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
                   ` (6 subsequent siblings)
  8 siblings, 1 reply; 22+ messages in thread
From: Daniel Vetter @ 2019-07-19 15:23 UTC (permalink / raw)
  To: DRI Development
  Cc: Haneen Mohammed, Rodrigo Siqueira, Daniel Vetter,
	Intel Graphics Development, Daniel Vetter

We can reduce the critical section in vkms_vblank_simulate under
output->lock quite a lot:

- hrtimer_forward_now just needs to be ordered correctly wrt
  drm_crtc_handle_vblank. We already access the hrtimer timestamp
  without locks. While auditing that I noticed that we don't correctly
  annotate the read there, so sprinkle a READ_ONCE to make sure the
  compiler doesn't do anything foolish.

- drm_crtc_handle_vblank must stay under the lock to avoid races with
  drm_crtc_arm_vblank_event.

- The access to vkms_ouptut->crc_state also must stay under the lock.

- next problem is making sure the output->state structure doesn't get
  freed too early. First we rely on a given hrtimer being serialized:
  If we call drm_crtc_handle_vblank, then we are guaranteed that the
  previous call to vkms_vblank_simulate has completed. The other side
  of the coin is that the atomic updates waits for the vblank to
  happen before it releases the old state. Both taken together means
  that by the time the atomic update releases the old state, the
  hrtimer won't access it anymore (it might be accessing the new state
  at the same time, but that's ok).

- state is invariant, except the few fields separate protected by
  state->crc_lock. So no need to hold the lock for that.

- finally the queue_work. We need to make sure there's no races with
  the flush_work, i.e. when we call flush_work we need to guarantee
  that the hrtimer can't requeue the work again. This is guaranteed by
  the same vblank/hrtimer ordering guarantees like the reasoning above
  why state won't be freed too early: flush_work on the old state is
  called after wait_for_flip_done in the atomic commit code.

Therefore we can also move everything after the output->crc_state out
of the critical section.

Motivated by suggestions from Rodrigo.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
---
 drivers/gpu/drm/vkms/vkms_crtc.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 927dafaebc76..74f703b8d22a 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -16,17 +16,18 @@ static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
 	u64 ret_overrun;
 	bool ret;
 
-	spin_lock(&output->lock);
-
 	ret_overrun = hrtimer_forward_now(&output->vblank_hrtimer,
 					  output->period_ns);
 	WARN_ON(ret_overrun != 1);
 
+	spin_lock(&output->lock);
 	ret = drm_crtc_handle_vblank(crtc);
 	if (!ret)
 		DRM_ERROR("vkms failure on handling vblank");
 
 	state = output->composer_state;
+	spin_unlock(&output->lock);
+
 	if (state && output->composer_enabled) {
 		u64 frame = drm_crtc_accurate_vblank_count(crtc);
 
@@ -48,8 +49,6 @@ static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
 			DRM_DEBUG_DRIVER("Composer worker already queued\n");
 	}
 
-	spin_unlock(&output->lock);
-
 	return HRTIMER_RESTART;
 }
 
@@ -85,7 +84,7 @@ bool vkms_get_vblank_timestamp(struct drm_device *dev, unsigned int pipe,
 	struct vkms_output *output = &vkmsdev->output;
 	struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
 
-	*vblank_time = output->vblank_hrtimer.node.expires;
+	*vblank_time = READ_ONCE(output->vblank_hrtimer.node.expires);
 
 	if (WARN_ON(*vblank_time == vblank->time))
 		return true;
-- 
2.22.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/vblank: Document and fix vblank count barrier semantics
  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-07-19 15:23 ` [PATCH 3/3] drm/vkms: Reduce critical section in vblank_simulate Daniel Vetter
@ 2019-07-19 15:46 ` Patchwork
  2019-07-19 16:19 ` ✓ Fi.CI.BAT: success " Patchwork
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2019-07-19 15:46 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/3] drm/vblank: Document and fix vblank count barrier semantics
URL   : https://patchwork.freedesktop.org/series/63949/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
f2d502a922df drm/vblank: Document and fix vblank count barrier semantics
-:117: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 85 lines checked
5a7e838c5df6 drm/vkms: Use wait_for_flip_done
-:27: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 8 lines checked
3a795bdbb921 drm/vkms: Reduce critical section in vblank_simulate
-:92: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 36 lines checked

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* ✓ Fi.CI.BAT: success for series starting with [1/3] drm/vblank: Document and fix vblank count barrier semantics
  2019-07-19 15:23 [PATCH 1/3] drm/vblank: Document and fix vblank count barrier semantics Daniel Vetter
                   ` (2 preceding siblings ...)
  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 ` Patchwork
  2019-07-19 17:06 ` [Intel-gfx] [PATCH 1/3] " Ville Syrjälä
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2019-07-19 16:19 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/3] drm/vblank: Document and fix vblank count barrier semantics
URL   : https://patchwork.freedesktop.org/series/63949/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6511 -> Patchwork_13705
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/

Known issues
------------

  Here are the changes found in Patchwork_13705 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@core_auth@basic-auth:
    - fi-icl-u3:          [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/fi-icl-u3/igt@core_auth@basic-auth.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/fi-icl-u3/igt@core_auth@basic-auth.html

  * igt@i915_selftest@live_contexts:
    - fi-icl-dsi:         [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] / [fdo#108569])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/fi-icl-dsi/igt@i915_selftest@live_contexts.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/fi-icl-dsi/igt@i915_selftest@live_contexts.html

  * igt@i915_selftest@live_execlists:
    - fi-skl-gvtdvm:      [PASS][5] -> [DMESG-FAIL][6] ([fdo#111108])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html

  
#### Possible fixes ####

  * igt@gem_basic@bad-close:
    - fi-icl-u3:          [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/fi-icl-u3/igt@gem_basic@bad-close.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/fi-icl-u3/igt@gem_basic@bad-close.html

  * igt@gem_mmap_gtt@basic-copy:
    - fi-glk-dsi:         [INCOMPLETE][9] ([fdo#103359] / [k.org#198133]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/fi-glk-dsi/igt@gem_mmap_gtt@basic-copy.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/fi-glk-dsi/igt@gem_mmap_gtt@basic-copy.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7500u:       [FAIL][11] ([fdo#109485]) -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
    - fi-kbl-7567u:       [FAIL][13] ([fdo#109485]) -> [PASS][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/fi-kbl-7567u/igt@kms_chamelium@hdmi-hpd-fast.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/fi-kbl-7567u/igt@kms_chamelium@hdmi-hpd-fast.html

  
  [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
  [fdo#111108]: https://bugs.freedesktop.org/show_bug.cgi?id=111108
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (52 -> 47)
------------------------------

  Additional (1): fi-cml-u2 
  Missing    (6): fi-kbl-soraka fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * Linux: CI_DRM_6511 -> Patchwork_13705

  CI_DRM_6511: dbedd493118204a194fbc480f86866ddebbc4723 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5103: 45c31e294b9d7874a9a21860f8a89c64bc853df2 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13705: 3a795bdbb9216cc747e03036fe41cec8750ff001 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

3a795bdbb921 drm/vkms: Reduce critical section in vblank_simulate
5a7e838c5df6 drm/vkms: Use wait_for_flip_done
f2d502a922df drm/vblank: Document and fix vblank count barrier semantics

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [Intel-gfx] [PATCH 1/3] drm/vblank: Document and fix vblank count barrier semantics
  2019-07-19 15:23 [PATCH 1/3] drm/vblank: Document and fix vblank count barrier semantics Daniel Vetter
                   ` (3 preceding siblings ...)
  2019-07-19 16:19 ` ✓ Fi.CI.BAT: success " Patchwork
@ 2019-07-19 17:06 ` Ville Syrjälä
  2019-07-19 18:33   ` Daniel Vetter
  2019-07-23 13:13   ` [PATCH] " Daniel Vetter
  2019-07-19 23:02 ` ✓ Fi.CI.IGT: success for series starting with [1/3] " Patchwork
                   ` (3 subsequent siblings)
  8 siblings, 2 replies; 22+ messages in thread
From: Ville Syrjälä @ 2019-07-19 17:06 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Vetter, Intel Graphics Development, Rodrigo Siqueira,
	DRI Development

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/3] drm/vblank: Document and fix vblank count barrier semantics
  2019-07-19 17:06 ` [Intel-gfx] [PATCH 1/3] " Ville Syrjälä
@ 2019-07-19 18:33   ` Daniel Vetter
  2019-07-19 18:56     ` Ville Syrjälä
  2019-07-23 13:13   ` [PATCH] " Daniel Vetter
  1 sibling, 1 reply; 22+ messages in thread
From: Daniel Vetter @ 2019-07-19 18:33 UTC (permalink / raw)
  To: Ville Syrjälä
  Cc: Daniel Vetter, Intel Graphics Development, Rodrigo Siqueira,
	DRI Development

On Fri, Jul 19, 2019 at 7:06 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> 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.

Hm ... so read-side seqno here? At least for 32bit, but not sure
that's worth it, probably simpler to just do it unconditionally. Otoh
... do we care? This matters like once every every year at 120Hz ...
-Daniel

>
> > +
> > +     /*
> > +      * 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



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/3] drm/vblank: Document and fix vblank count barrier semantics
  2019-07-19 18:33   ` Daniel Vetter
@ 2019-07-19 18:56     ` Ville Syrjälä
  0 siblings, 0 replies; 22+ messages in thread
From: Ville Syrjälä @ 2019-07-19 18:56 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Vetter, Intel Graphics Development, Rodrigo Siqueira,
	DRI Development

On Fri, Jul 19, 2019 at 08:33:49PM +0200, Daniel Vetter wrote:
> On Fri, Jul 19, 2019 at 7:06 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > 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.
> 
> Hm ... so read-side seqno here? At least for 32bit, but not sure
> that's worth it, probably simpler to just do it unconditionally.

Or make it atomic64_t perhaps?

> Otoh
> ... do we care? This matters like once every every year at 120Hz ...

Dunno. Might avoid a few odd bug reports maybe.

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* ✓ Fi.CI.IGT: success for series starting with [1/3] drm/vblank: Document and fix vblank count barrier semantics
  2019-07-19 15:23 [PATCH 1/3] drm/vblank: Document and fix vblank count barrier semantics Daniel Vetter
                   ` (4 preceding siblings ...)
  2019-07-19 17:06 ` [Intel-gfx] [PATCH 1/3] " Ville Syrjälä
@ 2019-07-19 23:02 ` 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
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2019-07-19 23:02 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/3] drm/vblank: Document and fix vblank count barrier semantics
URL   : https://patchwork.freedesktop.org/series/63949/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6511_full -> Patchwork_13705_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Known issues
------------

  Here are the changes found in Patchwork_13705_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_isolation@bcs0-s3:
    - shard-apl:          [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +3 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-apl4/igt@gem_ctx_isolation@bcs0-s3.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-apl5/igt@gem_ctx_isolation@bcs0-s3.html

  * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions:
    - shard-hsw:          [PASS][3] -> [FAIL][4] ([fdo#103355])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-hsw1/igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-hsw6/igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-hsw:          [PASS][5] -> [INCOMPLETE][6] ([fdo#103540])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-hsw6/igt@kms_flip@flip-vs-suspend-interruptible.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-hsw7/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite:
    - shard-iclb:         [PASS][7] -> [FAIL][8] ([fdo#103167]) +2 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-iclb4/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-iclb8/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-blt:
    - shard-skl:          [PASS][9] -> [INCOMPLETE][10] ([fdo#106978])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-skl3/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-blt.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-skl8/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-blt.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
    - shard-skl:          [PASS][11] -> [FAIL][12] ([fdo#108145] / [fdo#110403])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-skl4/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-skl9/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
    - shard-skl:          [PASS][13] -> [FAIL][14] ([fdo#108145])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-skl6/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-skl9/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html

  * igt@kms_plane_lowres@pipe-a-tiling-y:
    - shard-iclb:         [PASS][15] -> [FAIL][16] ([fdo#103166])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-iclb8/igt@kms_plane_lowres@pipe-a-tiling-y.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-iclb7/igt@kms_plane_lowres@pipe-a-tiling-y.html

  * igt@kms_psr@psr2_cursor_mmap_cpu:
    - shard-iclb:         [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-iclb6/igt@kms_psr@psr2_cursor_mmap_cpu.html

  
#### Possible fixes ####

  * igt@gem_tiled_swapping@non-threaded:
    - shard-glk:          [DMESG-WARN][19] ([fdo#108686]) -> [PASS][20]
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-glk2/igt@gem_tiled_swapping@non-threaded.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-glk9/igt@gem_tiled_swapping@non-threaded.html

  * igt@i915_suspend@sysfs-reader:
    - shard-apl:          [DMESG-WARN][21] ([fdo#108566]) -> [PASS][22] +3 similar issues
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-apl6/igt@i915_suspend@sysfs-reader.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-apl8/igt@i915_suspend@sysfs-reader.html

  * igt@kms_color@pipe-c-ctm-blue-to-red:
    - shard-skl:          [FAIL][23] ([fdo#107201]) -> [PASS][24]
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-skl9/igt@kms_color@pipe-c-ctm-blue-to-red.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-skl10/igt@kms_color@pipe-c-ctm-blue-to-red.html

  * igt@kms_frontbuffer_tracking@fbc-stridechange:
    - shard-iclb:         [FAIL][25] ([fdo#103167]) -> [PASS][26] +2 similar issues
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-iclb8/igt@kms_frontbuffer_tracking@fbc-stridechange.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-iclb2/igt@kms_frontbuffer_tracking@fbc-stridechange.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [FAIL][27] ([fdo#108145] / [fdo#110403]) -> [PASS][28]
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-skl9/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-skl10/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_psr@psr2_sprite_mmap_gtt:
    - shard-iclb:         [SKIP][29] ([fdo#109441]) -> [PASS][30] +1 similar issue
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-iclb5/igt@kms_psr@psr2_sprite_mmap_gtt.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html

  * igt@kms_setmode@basic:
    - shard-kbl:          [FAIL][31] ([fdo#99912]) -> [PASS][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-kbl1/igt@kms_setmode@basic.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-kbl6/igt@kms_setmode@basic.html

  * igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend:
    - shard-skl:          [INCOMPLETE][33] ([fdo#104108]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-skl6/igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-skl6/igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend.html

  
#### Warnings ####

  * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite:
    - shard-skl:          [FAIL][35] ([fdo#103167]) -> [FAIL][36] ([fdo#108040])
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6511/shard-skl2/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/shard-skl8/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite.html

  
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103355]: https://bugs.freedesktop.org/show_bug.cgi?id=103355
  [fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#106978]: https://bugs.freedesktop.org/show_bug.cgi?id=106978
  [fdo#107201]: https://bugs.freedesktop.org/show_bug.cgi?id=107201
  [fdo#108040]: https://bugs.freedesktop.org/show_bug.cgi?id=108040
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#108686]: https://bugs.freedesktop.org/show_bug.cgi?id=108686
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#110403]: https://bugs.freedesktop.org/show_bug.cgi?id=110403
  [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912


Participating hosts (10 -> 10)
------------------------------

  No changes in participating hosts


Build changes
-------------

  * Linux: CI_DRM_6511 -> Patchwork_13705

  CI_DRM_6511: dbedd493118204a194fbc480f86866ddebbc4723 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5103: 45c31e294b9d7874a9a21860f8a89c64bc853df2 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13705: 3a795bdbb9216cc747e03036fe41cec8750ff001 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13705/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH] drm/vblank: Document and fix vblank count barrier semantics
  2019-07-19 17:06 ` [Intel-gfx] [PATCH 1/3] " Ville Syrjälä
  2019-07-19 18:33   ` Daniel Vetter
@ 2019-07-23 13:13   ` Daniel Vetter
  2019-08-19 16:21     ` Ville Syrjälä
  2019-09-03 12:47     ` Rodrigo Siqueira
  1 sibling, 2 replies; 22+ messages in thread
From: Daniel Vetter @ 2019-07-23 13:13 UTC (permalink / raw)
  To: DRI Development
  Cc: Keith Packard, Rodrigo Siqueira, Daniel Vetter,
	Intel Graphics Development, Daniel Vetter

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.

v3:

Ville noticed that on 32bit we might be breaking up the load/stores,
now that the vblank counter has been switched over to be 64 bit. Fix
that up by switching to atomic64_t. This this happens so rarely in
practice I figured no need to cc: stable ...

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Keith Packard <keithp@keithp.com>
References: 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]")
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 | 45 ++++++++++++++++++++++++++++++++----
 include/drm/drm_vblank.h     | 15 ++++++++++--
 2 files changed, 54 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 603ab105125d..03e37bceac9c 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -107,7 +107,7 @@ static void store_vblank(struct drm_device *dev, unsigned int pipe,
 
 	write_seqlock(&vblank->seqlock);
 	vblank->time = t_vblank;
-	vblank->count += vblank_count_inc;
+	atomic64_add(vblank_count_inc, &vblank->count);
 	write_sequnlock(&vblank->seqlock);
 }
 
@@ -273,7 +273,8 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe,
 
 	DRM_DEBUG_VBL("updating vblank count on crtc %u:"
 		      " current=%llu, diff=%u, hw=%u hw_last=%u\n",
-		      pipe, vblank->count, diff, cur_vblank, vblank->last);
+		      pipe, atomic64_read(&vblank->count), diff,
+		      cur_vblank, vblank->last);
 
 	if (diff == 0) {
 		WARN_ON_ONCE(cur_vblank != vblank->last);
@@ -295,11 +296,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 = atomic64_read(&vblank->count);
+
+	/*
+	 * 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;
 }
 
 /**
@@ -764,6 +777,14 @@ drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
  * vblank interrupt (since it only reports the software vblank counter), see
  * drm_crtc_accurate_vblank_count() for such use-cases.
  *
+ * Note that for a given vblank counter value drm_crtc_handle_vblank()
+ * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
+ * provide a barrier: Any writes done before calling
+ * drm_crtc_handle_vblank() will be visible to callers of the later
+ * functions, iff the vblank count is the same or a later one.
+ *
+ * See also &drm_vblank_crtc.count.
+ *
  * Returns:
  * The software vblank counter.
  */
@@ -801,7 +822,7 @@ static u64 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
 
 	do {
 		seq = read_seqbegin(&vblank->seqlock);
-		vblank_count = vblank->count;
+		vblank_count = atomic64_read(&vblank->count);
 		*vblanktime = vblank->time;
 	} while (read_seqretry(&vblank->seqlock, seq));
 
@@ -818,6 +839,14 @@ static u64 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
  * vblank events since the system was booted, including lost events due to
  * modesetting activity. Returns corresponding system timestamp of the time
  * of the vblank interval that corresponds to the current vblank counter value.
+ *
+ * Note that for a given vblank counter value drm_crtc_handle_vblank()
+ * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
+ * provide a barrier: Any writes done before calling
+ * drm_crtc_handle_vblank() will be visible to callers of the later
+ * functions, iff the vblank count is the same or a later one.
+ *
+ * See also &drm_vblank_crtc.count.
  */
 u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
 				   ktime_t *vblanktime)
@@ -1791,6 +1820,14 @@ EXPORT_SYMBOL(drm_handle_vblank);
  *
  * This is the native KMS version of drm_handle_vblank().
  *
+ * Note that for a given vblank counter value drm_crtc_handle_vblank()
+ * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
+ * provide a barrier: Any writes done before calling
+ * drm_crtc_handle_vblank() will be visible to callers of the later
+ * functions, iff the vblank count is the same or a later one.
+ *
+ * See also &drm_vblank_crtc.count.
+ *
  * Returns:
  * True if the event was successfully handled, false on failure.
  */
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index 9fe4ba8bc622..c16c44052b3d 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -109,9 +109,20 @@ struct drm_vblank_crtc {
 	seqlock_t seqlock;
 
 	/**
-	 * @count: Current software vblank counter.
+	 * @count:
+	 *
+	 * Current software vblank counter.
+	 *
+	 * Note that for a given vblank counter value drm_crtc_handle_vblank()
+	 * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
+	 * provide a barrier: Any writes done before calling
+	 * drm_crtc_handle_vblank() will be visible to callers of the later
+	 * functions, iff the vblank count is the same or a later one.
+	 *
+	 * IMPORTANT: This guarantee requires barriers, therefor never access
+	 * this field directly. Use drm_crtc_vblank_count() instead.
 	 */
-	u64 count;
+	atomic64_t count;
 	/**
 	 * @time: Vblank timestamp corresponding to @count.
 	 */
-- 
2.22.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* ✗ Fi.CI.CHECKPATCH: warning for series starting with drm/vblank: Document and fix vblank count barrier semantics (rev2)
  2019-07-19 15:23 [PATCH 1/3] drm/vblank: Document and fix vblank count barrier semantics Daniel Vetter
                   ` (5 preceding siblings ...)
  2019-07-19 23:02 ` ✓ Fi.CI.IGT: success for series starting with [1/3] " Patchwork
@ 2019-07-23 13:43 ` Patchwork
  2019-07-23 14:34 ` ✓ Fi.CI.BAT: success " Patchwork
  2019-07-23 18:18 ` ✓ Fi.CI.IGT: " Patchwork
  8 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2019-07-23 13:43 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: series starting with drm/vblank: Document and fix vblank count barrier semantics (rev2)
URL   : https://patchwork.freedesktop.org/series/63949/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
371224e762e2 drm/vblank: Document and fix vblank count barrier semantics
-:28: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]")'
#28: 
References: 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]")

-:161: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 1 errors, 1 warnings, 0 checks, 113 lines checked
38190d67a1e7 drm/vkms: Use wait_for_flip_done
-:27: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 8 lines checked
e7001c1e18ea drm/vkms: Reduce critical section in vblank_simulate
-:92: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 0 checks, 36 lines checked

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* ✓ Fi.CI.BAT: success for series starting with drm/vblank: Document and fix vblank count barrier semantics (rev2)
  2019-07-19 15:23 [PATCH 1/3] drm/vblank: Document and fix vblank count barrier semantics Daniel Vetter
                   ` (6 preceding siblings ...)
  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 ` Patchwork
  2019-07-23 18:18 ` ✓ Fi.CI.IGT: " Patchwork
  8 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2019-07-23 14:34 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: series starting with drm/vblank: Document and fix vblank count barrier semantics (rev2)
URL   : https://patchwork.freedesktop.org/series/63949/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6540 -> Patchwork_13725
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/

Known issues
------------

  Here are the changes found in Patchwork_13725 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@i915_module_load@reload:
    - fi-blb-e6850:       [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/fi-blb-e6850/igt@i915_module_load@reload.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/fi-blb-e6850/igt@i915_module_load@reload.html

  * igt@i915_module_load@reload-with-fault-injection:
    - fi-snb-2600:        [PASS][3] -> [INCOMPLETE][4] ([fdo#105411])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/fi-snb-2600/igt@i915_module_load@reload-with-fault-injection.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/fi-snb-2600/igt@i915_module_load@reload-with-fault-injection.html

  * igt@prime_self_import@basic-with_two_bos:
    - fi-icl-dsi:         [PASS][5] -> [INCOMPLETE][6] ([fdo#107713])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/fi-icl-dsi/igt@prime_self_import@basic-with_two_bos.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/fi-icl-dsi/igt@prime_self_import@basic-with_two_bos.html

  
#### Possible fixes ####

  * igt@gem_ctx_create@basic-files:
    - fi-icl-u3:          [INCOMPLETE][7] ([fdo#107713] / [fdo#109100]) -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/fi-icl-u3/igt@gem_ctx_create@basic-files.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/fi-icl-u3/igt@gem_ctx_create@basic-files.html

  * igt@i915_selftest@live_execlists:
    - fi-bwr-2160:        [DMESG-WARN][9] ([fdo#111115]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/fi-bwr-2160/igt@i915_selftest@live_execlists.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/fi-bwr-2160/igt@i915_selftest@live_execlists.html

  * igt@i915_selftest@live_hangcheck:
    - fi-bwr-2160:        [DMESG-FAIL][11] ([fdo#111115]) -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/fi-bwr-2160/igt@i915_selftest@live_hangcheck.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/fi-bwr-2160/igt@i915_selftest@live_hangcheck.html

  * igt@kms_busy@basic-flip-a:
    - fi-kbl-7567u:       [SKIP][13] ([fdo#109271] / [fdo#109278]) -> [PASS][14] +2 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/fi-kbl-7567u/igt@kms_busy@basic-flip-a.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/fi-kbl-7567u/igt@kms_busy@basic-flip-a.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7500u:       [FAIL][15] ([fdo#109485]) -> [PASS][16]
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
    - fi-kbl-7567u:       [FAIL][17] ([fdo#109485]) -> [PASS][18]
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/fi-kbl-7567u/igt@kms_chamelium@hdmi-hpd-fast.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/fi-kbl-7567u/igt@kms_chamelium@hdmi-hpd-fast.html

  * igt@prime_vgem@basic-fence-flip:
    - fi-kbl-7500u:       [SKIP][19] ([fdo#109271]) -> [PASS][20] +23 similar issues
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/fi-kbl-7500u/igt@prime_vgem@basic-fence-flip.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/fi-kbl-7500u/igt@prime_vgem@basic-fence-flip.html

  
  [fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
  [fdo#111115]: https://bugs.freedesktop.org/show_bug.cgi?id=111115


Participating hosts (54 -> 47)
------------------------------

  Additional (2): fi-cfl-8109u fi-pnv-d510 
  Missing    (9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6540 -> Patchwork_13725

  CI-20190529: 20190529
  CI_DRM_6540: 23b909d90e1203a172548f7fc0328baea0e39648 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5107: 1a5b48671e0863cb723e3d0239e54c828360dc99 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13725: e7001c1e18ea37af9b4ed786a0288fe871050386 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

e7001c1e18ea drm/vkms: Reduce critical section in vblank_simulate
38190d67a1e7 drm/vkms: Use wait_for_flip_done
371224e762e2 drm/vblank: Document and fix vblank count barrier semantics

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* ✓ Fi.CI.IGT: success for series starting with drm/vblank: Document and fix vblank count barrier semantics (rev2)
  2019-07-19 15:23 [PATCH 1/3] drm/vblank: Document and fix vblank count barrier semantics Daniel Vetter
                   ` (7 preceding siblings ...)
  2019-07-23 14:34 ` ✓ Fi.CI.BAT: success " Patchwork
@ 2019-07-23 18:18 ` Patchwork
  8 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2019-07-23 18:18 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: series starting with drm/vblank: Document and fix vblank count barrier semantics (rev2)
URL   : https://patchwork.freedesktop.org/series/63949/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6540_full -> Patchwork_13725_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Known issues
------------

  Here are the changes found in Patchwork_13725_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_balancer@smoke:
    - shard-iclb:         [PASS][1] -> [SKIP][2] ([fdo#110854])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-iclb4/igt@gem_exec_balancer@smoke.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-iclb3/igt@gem_exec_balancer@smoke.html

  * igt@gem_persistent_relocs@forked:
    - shard-hsw:          [PASS][3] -> [INCOMPLETE][4] ([fdo#103540])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-hsw7/igt@gem_persistent_relocs@forked.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-hsw4/igt@gem_persistent_relocs@forked.html

  * igt@i915_suspend@debugfs-reader:
    - shard-skl:          [PASS][5] -> [INCOMPLETE][6] ([fdo#104108])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-skl1/igt@i915_suspend@debugfs-reader.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-skl1/igt@i915_suspend@debugfs-reader.html

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
    - shard-glk:          [PASS][7] -> [FAIL][8] ([fdo#102887])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-glk7/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-glk5/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-skl:          [PASS][9] -> [INCOMPLETE][10] ([fdo#109507])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-skl8/igt@kms_flip@flip-vs-suspend-interruptible.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-skl2/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render:
    - shard-iclb:         [PASS][11] -> [FAIL][12] ([fdo#103167]) +8 similar issues
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-iclb7/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-iclb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
    - shard-apl:          [PASS][13] -> [DMESG-WARN][14] ([fdo#108566])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-apl3/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-apl3/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
    - shard-skl:          [PASS][15] -> [FAIL][16] ([fdo#108145])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-skl5/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-skl5/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
    - shard-iclb:         [PASS][17] -> [FAIL][18] ([fdo#103166]) +1 similar issue
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-iclb3/igt@kms_plane_lowres@pipe-a-tiling-x.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-iclb1/igt@kms_plane_lowres@pipe-a-tiling-x.html

  * igt@kms_psr@psr2_primary_mmap_cpu:
    - shard-iclb:         [PASS][19] -> [SKIP][20] ([fdo#109441]) +1 similar issue
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-iclb5/igt@kms_psr@psr2_primary_mmap_cpu.html

  * igt@kms_setmode@basic:
    - shard-apl:          [PASS][21] -> [FAIL][22] ([fdo#99912])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-apl6/igt@kms_setmode@basic.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-apl8/igt@kms_setmode@basic.html

  * igt@kms_vblank@pipe-a-ts-continuation-suspend:
    - shard-kbl:          [PASS][23] -> [DMESG-WARN][24] ([fdo#108566]) +6 similar issues
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-kbl3/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-kbl6/igt@kms_vblank@pipe-a-ts-continuation-suspend.html

  
#### Possible fixes ####

  * igt@gem_eio@reset-stress:
    - shard-snb:          [FAIL][25] ([fdo#109661]) -> [PASS][26]
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-snb6/igt@gem_eio@reset-stress.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-snb7/igt@gem_eio@reset-stress.html

  * igt@gem_tiled_swapping@non-threaded:
    - shard-kbl:          [DMESG-WARN][27] ([fdo#108686]) -> [PASS][28]
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-kbl4/igt@gem_tiled_swapping@non-threaded.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-kbl2/igt@gem_tiled_swapping@non-threaded.html

  * igt@kms_flip@flip-vs-expired-vblank:
    - shard-skl:          [FAIL][29] ([fdo#105363]) -> [PASS][30]
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-skl7/igt@kms_flip@flip-vs-expired-vblank.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-skl4/igt@kms_flip@flip-vs-expired-vblank.html
    - shard-apl:          [FAIL][31] ([fdo#105363]) -> [PASS][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-apl6/igt@kms_flip@flip-vs-expired-vblank.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-apl6/igt@kms_flip@flip-vs-expired-vblank.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-iclb:         [FAIL][33] ([fdo#103167]) -> [PASS][34] +10 similar issues
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-iclb6/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-iclb7/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
    - shard-kbl:          [DMESG-WARN][35] ([fdo#108566]) -> [PASS][36] +6 similar issues
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-kbl6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-kbl4/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
    - shard-skl:          [FAIL][37] ([fdo#108145]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-skl2/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-skl7/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html

  * igt@kms_setmode@basic:
    - shard-kbl:          [FAIL][39] ([fdo#99912]) -> [PASS][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-kbl2/igt@kms_setmode@basic.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-kbl1/igt@kms_setmode@basic.html

  * igt@tools_test@sysfs_l3_parity:
    - shard-hsw:          [SKIP][41] ([fdo#109271]) -> [PASS][42]
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-hsw7/igt@tools_test@sysfs_l3_parity.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-hsw5/igt@tools_test@sysfs_l3_parity.html

  
#### Warnings ####

  * igt@kms_dp_dsc@basic-dsc-enable-edp:
    - shard-iclb:         [SKIP][43] ([fdo#109349]) -> [DMESG-WARN][44] ([fdo#107724])
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-iclb8/igt@kms_dp_dsc@basic-dsc-enable-edp.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-iclb2/igt@kms_dp_dsc@basic-dsc-enable-edp.html

  * igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-mmap-cpu:
    - shard-skl:          [FAIL][45] ([fdo#103167]) -> [FAIL][46] ([fdo#108040])
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6540/shard-skl1/igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-mmap-cpu.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/shard-skl1/igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-mmap-cpu.html

  
  [fdo#102887]: https://bugs.freedesktop.org/show_bug.cgi?id=102887
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#108040]: https://bugs.freedesktop.org/show_bug.cgi?id=108040
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#108686]: https://bugs.freedesktop.org/show_bug.cgi?id=108686
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109349]: https://bugs.freedesktop.org/show_bug.cgi?id=109349
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109507]: https://bugs.freedesktop.org/show_bug.cgi?id=109507
  [fdo#109661]: https://bugs.freedesktop.org/show_bug.cgi?id=109661
  [fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
  [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912


Participating hosts (9 -> 9)
------------------------------

  No changes in participating hosts


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6540 -> Patchwork_13725

  CI-20190529: 20190529
  CI_DRM_6540: 23b909d90e1203a172548f7fc0328baea0e39648 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5107: 1a5b48671e0863cb723e3d0239e54c828360dc99 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13725: e7001c1e18ea37af9b4ed786a0288fe871050386 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13725/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] drm/vblank: Document and fix vblank count barrier semantics
  2019-07-23 13:13   ` [PATCH] " Daniel Vetter
@ 2019-08-19 16:21     ` Ville Syrjälä
  2019-09-03 12:47     ` Rodrigo Siqueira
  1 sibling, 0 replies; 22+ messages in thread
From: Ville Syrjälä @ 2019-08-19 16:21 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Keith Packard, Rodrigo Siqueira, Intel Graphics Development,
	DRI Development, Daniel Vetter

On Tue, Jul 23, 2019 at 03:13:37PM +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.
> 
> v3:
> 
> Ville noticed that on 32bit we might be breaking up the load/stores,
> now that the vblank counter has been switched over to be 64 bit. Fix
> that up by switching to atomic64_t. This this happens so rarely in
> practice I figured no need to cc: stable ...
> 
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Keith Packard <keithp@keithp.com>
> References: 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]")
> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

> ---
>  drivers/gpu/drm/drm_vblank.c | 45 ++++++++++++++++++++++++++++++++----
>  include/drm/drm_vblank.h     | 15 ++++++++++--
>  2 files changed, 54 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 603ab105125d..03e37bceac9c 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -107,7 +107,7 @@ static void store_vblank(struct drm_device *dev, unsigned int pipe,
>  
>  	write_seqlock(&vblank->seqlock);
>  	vblank->time = t_vblank;
> -	vblank->count += vblank_count_inc;
> +	atomic64_add(vblank_count_inc, &vblank->count);
>  	write_sequnlock(&vblank->seqlock);
>  }
>  
> @@ -273,7 +273,8 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe,
>  
>  	DRM_DEBUG_VBL("updating vblank count on crtc %u:"
>  		      " current=%llu, diff=%u, hw=%u hw_last=%u\n",
> -		      pipe, vblank->count, diff, cur_vblank, vblank->last);
> +		      pipe, atomic64_read(&vblank->count), diff,
> +		      cur_vblank, vblank->last);
>  
>  	if (diff == 0) {
>  		WARN_ON_ONCE(cur_vblank != vblank->last);
> @@ -295,11 +296,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 = atomic64_read(&vblank->count);
> +
> +	/*
> +	 * 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;
>  }
>  
>  /**
> @@ -764,6 +777,14 @@ drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
>   * vblank interrupt (since it only reports the software vblank counter), see
>   * drm_crtc_accurate_vblank_count() for such use-cases.
>   *
> + * Note that for a given vblank counter value drm_crtc_handle_vblank()
> + * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> + * provide a barrier: Any writes done before calling
> + * drm_crtc_handle_vblank() will be visible to callers of the later
> + * functions, iff the vblank count is the same or a later one.
> + *
> + * See also &drm_vblank_crtc.count.
> + *
>   * Returns:
>   * The software vblank counter.
>   */
> @@ -801,7 +822,7 @@ static u64 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
>  
>  	do {
>  		seq = read_seqbegin(&vblank->seqlock);
> -		vblank_count = vblank->count;
> +		vblank_count = atomic64_read(&vblank->count);
>  		*vblanktime = vblank->time;
>  	} while (read_seqretry(&vblank->seqlock, seq));
>  
> @@ -818,6 +839,14 @@ static u64 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
>   * vblank events since the system was booted, including lost events due to
>   * modesetting activity. Returns corresponding system timestamp of the time
>   * of the vblank interval that corresponds to the current vblank counter value.
> + *
> + * Note that for a given vblank counter value drm_crtc_handle_vblank()
> + * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> + * provide a barrier: Any writes done before calling
> + * drm_crtc_handle_vblank() will be visible to callers of the later
> + * functions, iff the vblank count is the same or a later one.
> + *
> + * See also &drm_vblank_crtc.count.
>   */
>  u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
>  				   ktime_t *vblanktime)
> @@ -1791,6 +1820,14 @@ EXPORT_SYMBOL(drm_handle_vblank);
>   *
>   * This is the native KMS version of drm_handle_vblank().
>   *
> + * Note that for a given vblank counter value drm_crtc_handle_vblank()
> + * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> + * provide a barrier: Any writes done before calling
> + * drm_crtc_handle_vblank() will be visible to callers of the later
> + * functions, iff the vblank count is the same or a later one.
> + *
> + * See also &drm_vblank_crtc.count.
> + *
>   * Returns:
>   * True if the event was successfully handled, false on failure.
>   */
> diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
> index 9fe4ba8bc622..c16c44052b3d 100644
> --- a/include/drm/drm_vblank.h
> +++ b/include/drm/drm_vblank.h
> @@ -109,9 +109,20 @@ struct drm_vblank_crtc {
>  	seqlock_t seqlock;
>  
>  	/**
> -	 * @count: Current software vblank counter.
> +	 * @count:
> +	 *
> +	 * Current software vblank counter.
> +	 *
> +	 * Note that for a given vblank counter value drm_crtc_handle_vblank()
> +	 * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> +	 * provide a barrier: Any writes done before calling
> +	 * drm_crtc_handle_vblank() will be visible to callers of the later
> +	 * functions, iff the vblank count is the same or a later one.
> +	 *
> +	 * IMPORTANT: This guarantee requires barriers, therefor never access
> +	 * this field directly. Use drm_crtc_vblank_count() instead.
>  	 */
> -	u64 count;
> +	atomic64_t count;
>  	/**
>  	 * @time: Vblank timestamp corresponding to @count.
>  	 */
> -- 
> 2.22.0

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] drm/vblank: Document and fix vblank count barrier semantics
  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
  1 sibling, 1 reply; 22+ messages in thread
From: Rodrigo Siqueira @ 2019-09-03 12:47 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: Intel Graphics Development, DRI Development, Daniel Vetter


[-- Attachment #1.1: Type: text/plain, Size: 7521 bytes --]

Hi Daniel,

All the series look really good for me. I just have some few questions
here.

On 07/23, 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

I have to admit that I'm a little bit confused about the "missed vblank
hilarity we've been seeing". Could you elaborate a little bit more about
this problem in the commit message?

Additionally, how about break this commit in two? One dedicated to the barriers
and the atomic64, and the other related to the documentation?

> 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.
> 
> v3:
> 
> Ville noticed that on 32bit we might be breaking up the load/stores,
> now that the vblank counter has been switched over to be 64 bit. Fix
> that up by switching to atomic64_t. This this happens so rarely in
> practice I figured no need to cc: stable ...
> 
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Keith Packard <keithp@keithp.com>
> References: 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]")
> 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 | 45 ++++++++++++++++++++++++++++++++----
>  include/drm/drm_vblank.h     | 15 ++++++++++--
>  2 files changed, 54 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 603ab105125d..03e37bceac9c 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -107,7 +107,7 @@ static void store_vblank(struct drm_device *dev, unsigned int pipe,
>  
>  	write_seqlock(&vblank->seqlock);
>  	vblank->time = t_vblank;
> -	vblank->count += vblank_count_inc;
> +	atomic64_add(vblank_count_inc, &vblank->count);
>  	write_sequnlock(&vblank->seqlock);
>  }
>  
> @@ -273,7 +273,8 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe,
>  
>  	DRM_DEBUG_VBL("updating vblank count on crtc %u:"
>  		      " current=%llu, diff=%u, hw=%u hw_last=%u\n",
> -		      pipe, vblank->count, diff, cur_vblank, vblank->last);
> +		      pipe, atomic64_read(&vblank->count), diff,
> +		      cur_vblank, vblank->last);
>  
>  	if (diff == 0) {
>  		WARN_ON_ONCE(cur_vblank != vblank->last);
> @@ -295,11 +296,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 = atomic64_read(&vblank->count);
> +
> +	/*
> +	 * 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();

I think I did not get all the idea behind the smp_rmb() in this function. FWIU,
smp_xxx are used for preventing race conditions in a multiprocessor system,
right? In this sense, I can presume that this change can bring benefits for
VKMS or any other virtual driver; on the other hand, this will not bring any
advantage on real drivers like i915 and amdgpu since these devices are not
related with smp stuff, right?

Thanks

> +
> +	return count;
>  }
>  
>  /**
> @@ -764,6 +777,14 @@ drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
>   * vblank interrupt (since it only reports the software vblank counter), see
>   * drm_crtc_accurate_vblank_count() for such use-cases.
>   *
> + * Note that for a given vblank counter value drm_crtc_handle_vblank()
> + * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> + * provide a barrier: Any writes done before calling
> + * drm_crtc_handle_vblank() will be visible to callers of the later
> + * functions, iff the vblank count is the same or a later one.
> + *
> + * See also &drm_vblank_crtc.count.
> + *
>   * Returns:
>   * The software vblank counter.
>   */
> @@ -801,7 +822,7 @@ static u64 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
>  
>  	do {
>  		seq = read_seqbegin(&vblank->seqlock);
> -		vblank_count = vblank->count;
> +		vblank_count = atomic64_read(&vblank->count);
>  		*vblanktime = vblank->time;
>  	} while (read_seqretry(&vblank->seqlock, seq));
>  
> @@ -818,6 +839,14 @@ static u64 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
>   * vblank events since the system was booted, including lost events due to
>   * modesetting activity. Returns corresponding system timestamp of the time
>   * of the vblank interval that corresponds to the current vblank counter value.
> + *
> + * Note that for a given vblank counter value drm_crtc_handle_vblank()
> + * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> + * provide a barrier: Any writes done before calling
> + * drm_crtc_handle_vblank() will be visible to callers of the later
> + * functions, iff the vblank count is the same or a later one.
> + *
> + * See also &drm_vblank_crtc.count.
>   */
>  u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
>  				   ktime_t *vblanktime)
> @@ -1791,6 +1820,14 @@ EXPORT_SYMBOL(drm_handle_vblank);
>   *
>   * This is the native KMS version of drm_handle_vblank().
>   *
> + * Note that for a given vblank counter value drm_crtc_handle_vblank()
> + * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> + * provide a barrier: Any writes done before calling
> + * drm_crtc_handle_vblank() will be visible to callers of the later
> + * functions, iff the vblank count is the same or a later one.
> + *
> + * See also &drm_vblank_crtc.count.
> + *
>   * Returns:
>   * True if the event was successfully handled, false on failure.
>   */
> diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
> index 9fe4ba8bc622..c16c44052b3d 100644
> --- a/include/drm/drm_vblank.h
> +++ b/include/drm/drm_vblank.h
> @@ -109,9 +109,20 @@ struct drm_vblank_crtc {
>  	seqlock_t seqlock;
>  
>  	/**
> -	 * @count: Current software vblank counter.
> +	 * @count:
> +	 *
> +	 * Current software vblank counter.
> +	 *
> +	 * Note that for a given vblank counter value drm_crtc_handle_vblank()
> +	 * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> +	 * provide a barrier: Any writes done before calling
> +	 * drm_crtc_handle_vblank() will be visible to callers of the later
> +	 * functions, iff the vblank count is the same or a later one.
> +	 *
> +	 * IMPORTANT: This guarantee requires barriers, therefor never access
> +	 * this field directly. Use drm_crtc_vblank_count() instead.
>  	 */
> -	u64 count;
> +	atomic64_t count;
>  	/**
>  	 * @time: Vblank timestamp corresponding to @count.
>  	 */
> -- 
> 2.22.0
> 

-- 
Rodrigo Siqueira
Software Engineer, Advanced Micro Devices (AMD)
https://siqueira.tech

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 2/3] drm/vkms: Use wait_for_flip_done
  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
  0 siblings, 1 reply; 22+ messages in thread
From: Rodrigo Siqueira @ 2019-09-03 12:49 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
	Haneen Mohammed


[-- Attachment #1.1: Type: text/plain, Size: 1638 bytes --]

On 07/19, Daniel Vetter wrote:
> It's the recommended version, wait_for_vblanks is a bit a hacky
> interim thing that predates all the flip_done tracking. It's
> unfortunately still the default ...

Just one question, is it safe to replace drm_atomic_helper_wait_for_vblanks by
drm_atomic_helper_wait_for_flip_done? I noticed that only six drivers use these
functions; they are:

* atmel-hlcdc
* mediatek
* msm
* tegra
* tilcdc
* virtio

If we change these drivers, can we drop the helper
drm_atomic_helper_wait_for_vblanks?

Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>

Thanks

> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
> Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> ---
>  drivers/gpu/drm/vkms/vkms_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 44ab9f8ef8be..80524a22412a 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -83,7 +83,7 @@ static void vkms_atomic_commit_tail(struct drm_atomic_state *old_state)
>  
>  	drm_atomic_helper_commit_hw_done(old_state);
>  
> -	drm_atomic_helper_wait_for_vblanks(dev, old_state);
> +	drm_atomic_helper_wait_for_flip_done(dev, old_state);
>  
>  	for_each_old_crtc_in_state(old_state, crtc, old_crtc_state, i) {
>  		struct vkms_crtc_state *vkms_state =
> -- 
> 2.22.0
> 

-- 
Rodrigo Siqueira
Software Engineer, Advanced Micro Devices (AMD)
https://siqueira.tech

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 3/3] drm/vkms: Reduce critical section in vblank_simulate
  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
  0 siblings, 1 reply; 22+ messages in thread
From: Rodrigo Siqueira @ 2019-09-03 12:50 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
	Haneen Mohammed


[-- Attachment #1.1: Type: text/plain, Size: 4015 bytes --]

Thanks for this patch! It looks good for me.

Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>

On 07/19, Daniel Vetter wrote:
> We can reduce the critical section in vkms_vblank_simulate under
> output->lock quite a lot:
> 
> - hrtimer_forward_now just needs to be ordered correctly wrt
>   drm_crtc_handle_vblank. We already access the hrtimer timestamp
>   without locks. While auditing that I noticed that we don't correctly
>   annotate the read there, so sprinkle a READ_ONCE to make sure the
>   compiler doesn't do anything foolish.
> 
> - drm_crtc_handle_vblank must stay under the lock to avoid races with
>   drm_crtc_arm_vblank_event.
> 
> - The access to vkms_ouptut->crc_state also must stay under the lock.
> 
> - next problem is making sure the output->state structure doesn't get
>   freed too early. First we rely on a given hrtimer being serialized:
>   If we call drm_crtc_handle_vblank, then we are guaranteed that the
>   previous call to vkms_vblank_simulate has completed. The other side
>   of the coin is that the atomic updates waits for the vblank to
>   happen before it releases the old state. Both taken together means
>   that by the time the atomic update releases the old state, the
>   hrtimer won't access it anymore (it might be accessing the new state
>   at the same time, but that's ok).
> 
> - state is invariant, except the few fields separate protected by
>   state->crc_lock. So no need to hold the lock for that.
> 
> - finally the queue_work. We need to make sure there's no races with
>   the flush_work, i.e. when we call flush_work we need to guarantee
>   that the hrtimer can't requeue the work again. This is guaranteed by
>   the same vblank/hrtimer ordering guarantees like the reasoning above
>   why state won't be freed too early: flush_work on the old state is
>   called after wait_for_flip_done in the atomic commit code.
> 
> Therefore we can also move everything after the output->crc_state out
> of the critical section.
> 
> Motivated by suggestions from Rodrigo.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
> Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> ---
>  drivers/gpu/drm/vkms/vkms_crtc.c | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 927dafaebc76..74f703b8d22a 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -16,17 +16,18 @@ static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
>  	u64 ret_overrun;
>  	bool ret;
>  
> -	spin_lock(&output->lock);
> -
>  	ret_overrun = hrtimer_forward_now(&output->vblank_hrtimer,
>  					  output->period_ns);
>  	WARN_ON(ret_overrun != 1);
>  
> +	spin_lock(&output->lock);
>  	ret = drm_crtc_handle_vblank(crtc);
>  	if (!ret)
>  		DRM_ERROR("vkms failure on handling vblank");
>  
>  	state = output->composer_state;
> +	spin_unlock(&output->lock);
> +
>  	if (state && output->composer_enabled) {
>  		u64 frame = drm_crtc_accurate_vblank_count(crtc);
>  
> @@ -48,8 +49,6 @@ static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
>  			DRM_DEBUG_DRIVER("Composer worker already queued\n");
>  	}
>  
> -	spin_unlock(&output->lock);
> -
>  	return HRTIMER_RESTART;
>  }
>  
> @@ -85,7 +84,7 @@ bool vkms_get_vblank_timestamp(struct drm_device *dev, unsigned int pipe,
>  	struct vkms_output *output = &vkmsdev->output;
>  	struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
>  
> -	*vblank_time = output->vblank_hrtimer.node.expires;
> +	*vblank_time = READ_ONCE(output->vblank_hrtimer.node.expires);
>  
>  	if (WARN_ON(*vblank_time == vblank->time))
>  		return true;
> -- 
> 2.22.0
> 

-- 
Rodrigo Siqueira
Software Engineer, Advanced Micro Devices (AMD)
https://siqueira.tech

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/vblank: Document and fix vblank count barrier semantics
  2019-09-03 12:47     ` Rodrigo Siqueira
@ 2019-09-03 15:09       ` Daniel Vetter
  2019-09-03 15:17         ` Rodrigo Siqueira
  0 siblings, 1 reply; 22+ messages in thread
From: Daniel Vetter @ 2019-09-03 15:09 UTC (permalink / raw)
  To: Rodrigo Siqueira
  Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
	Daniel Vetter

On Tue, Sep 03, 2019 at 08:47:03AM -0400, Rodrigo Siqueira wrote:
> Hi Daniel,
> 
> All the series look really good for me. I just have some few questions
> here.
> 
> On 07/23, 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
> 
> I have to admit that I'm a little bit confused about the "missed vblank
> hilarity we've been seeing". Could you elaborate a little bit more about
> this problem in the commit message?

We've had various reports on various drivers that hw vblanks seem to get
lost and the driver stuck on vblank waits. I think most of those where
just driver bugs, but could be also that there's some issues in the vblank
core.

> Additionally, how about break this commit in two? One dedicated to the barriers
> and the atomic64, and the other related to the documentation?
> 
> > 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.
> > 
> > v3:
> > 
> > Ville noticed that on 32bit we might be breaking up the load/stores,
> > now that the vblank counter has been switched over to be 64 bit. Fix
> > that up by switching to atomic64_t. This this happens so rarely in
> > practice I figured no need to cc: stable ...
> > 
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Cc: Keith Packard <keithp@keithp.com>
> > References: 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]")
> > 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 | 45 ++++++++++++++++++++++++++++++++----
> >  include/drm/drm_vblank.h     | 15 ++++++++++--
> >  2 files changed, 54 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > index 603ab105125d..03e37bceac9c 100644
> > --- a/drivers/gpu/drm/drm_vblank.c
> > +++ b/drivers/gpu/drm/drm_vblank.c
> > @@ -107,7 +107,7 @@ static void store_vblank(struct drm_device *dev, unsigned int pipe,
> >  
> >  	write_seqlock(&vblank->seqlock);
> >  	vblank->time = t_vblank;
> > -	vblank->count += vblank_count_inc;
> > +	atomic64_add(vblank_count_inc, &vblank->count);
> >  	write_sequnlock(&vblank->seqlock);
> >  }
> >  
> > @@ -273,7 +273,8 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe,
> >  
> >  	DRM_DEBUG_VBL("updating vblank count on crtc %u:"
> >  		      " current=%llu, diff=%u, hw=%u hw_last=%u\n",
> > -		      pipe, vblank->count, diff, cur_vblank, vblank->last);
> > +		      pipe, atomic64_read(&vblank->count), diff,
> > +		      cur_vblank, vblank->last);
> >  
> >  	if (diff == 0) {
> >  		WARN_ON_ONCE(cur_vblank != vblank->last);
> > @@ -295,11 +296,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 = atomic64_read(&vblank->count);
> > +
> > +	/*
> > +	 * 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();
> 
> I think I did not get all the idea behind the smp_rmb() in this function. FWIU,
> smp_xxx are used for preventing race conditions in a multiprocessor system,
> right? In this sense, I can presume that this change can bring benefits for
> VKMS or any other virtual driver; on the other hand, this will not bring any
> advantage on real drivers like i915 and amdgpu since these devices are not
> related with smp stuff, right?

smp or not smp is about the cpu your driver is running on, not anything to
do with the device hardware itself. And nowadays there's simply no
single-threaded processors anymore, everything has at least 2 cores (even
the tiniest soc). So yeah, this matters for everyone.

smp_* functions only get compiled out to nothing if you have CONFIG_UP
(which means only 1 cpu core with only 1 SMT thread is supported).

And yeah correctly placing smp barriers is Real Hard Stuff (tm).
-Daniel

 
> Thanks
> 
> > +
> > +	return count;
> >  }
> >  
> >  /**
> > @@ -764,6 +777,14 @@ drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
> >   * vblank interrupt (since it only reports the software vblank counter), see
> >   * drm_crtc_accurate_vblank_count() for such use-cases.
> >   *
> > + * Note that for a given vblank counter value drm_crtc_handle_vblank()
> > + * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> > + * provide a barrier: Any writes done before calling
> > + * drm_crtc_handle_vblank() will be visible to callers of the later
> > + * functions, iff the vblank count is the same or a later one.
> > + *
> > + * See also &drm_vblank_crtc.count.
> > + *
> >   * Returns:
> >   * The software vblank counter.
> >   */
> > @@ -801,7 +822,7 @@ static u64 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
> >  
> >  	do {
> >  		seq = read_seqbegin(&vblank->seqlock);
> > -		vblank_count = vblank->count;
> > +		vblank_count = atomic64_read(&vblank->count);
> >  		*vblanktime = vblank->time;
> >  	} while (read_seqretry(&vblank->seqlock, seq));
> >  
> > @@ -818,6 +839,14 @@ static u64 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
> >   * vblank events since the system was booted, including lost events due to
> >   * modesetting activity. Returns corresponding system timestamp of the time
> >   * of the vblank interval that corresponds to the current vblank counter value.
> > + *
> > + * Note that for a given vblank counter value drm_crtc_handle_vblank()
> > + * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> > + * provide a barrier: Any writes done before calling
> > + * drm_crtc_handle_vblank() will be visible to callers of the later
> > + * functions, iff the vblank count is the same or a later one.
> > + *
> > + * See also &drm_vblank_crtc.count.
> >   */
> >  u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
> >  				   ktime_t *vblanktime)
> > @@ -1791,6 +1820,14 @@ EXPORT_SYMBOL(drm_handle_vblank);
> >   *
> >   * This is the native KMS version of drm_handle_vblank().
> >   *
> > + * Note that for a given vblank counter value drm_crtc_handle_vblank()
> > + * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> > + * provide a barrier: Any writes done before calling
> > + * drm_crtc_handle_vblank() will be visible to callers of the later
> > + * functions, iff the vblank count is the same or a later one.
> > + *
> > + * See also &drm_vblank_crtc.count.
> > + *
> >   * Returns:
> >   * True if the event was successfully handled, false on failure.
> >   */
> > diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
> > index 9fe4ba8bc622..c16c44052b3d 100644
> > --- a/include/drm/drm_vblank.h
> > +++ b/include/drm/drm_vblank.h
> > @@ -109,9 +109,20 @@ struct drm_vblank_crtc {
> >  	seqlock_t seqlock;
> >  
> >  	/**
> > -	 * @count: Current software vblank counter.
> > +	 * @count:
> > +	 *
> > +	 * Current software vblank counter.
> > +	 *
> > +	 * Note that for a given vblank counter value drm_crtc_handle_vblank()
> > +	 * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> > +	 * provide a barrier: Any writes done before calling
> > +	 * drm_crtc_handle_vblank() will be visible to callers of the later
> > +	 * functions, iff the vblank count is the same or a later one.
> > +	 *
> > +	 * IMPORTANT: This guarantee requires barriers, therefor never access
> > +	 * this field directly. Use drm_crtc_vblank_count() instead.
> >  	 */
> > -	u64 count;
> > +	atomic64_t count;
> >  	/**
> >  	 * @time: Vblank timestamp corresponding to @count.
> >  	 */
> > -- 
> > 2.22.0
> > 
> 
> -- 
> Rodrigo Siqueira
> Software Engineer, Advanced Micro Devices (AMD)
> https://siqueira.tech



> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 2/3] drm/vkms: Use wait_for_flip_done
  2019-09-03 12:49   ` Rodrigo Siqueira
@ 2019-09-03 15:12     ` Daniel Vetter
  0 siblings, 0 replies; 22+ messages in thread
From: Daniel Vetter @ 2019-09-03 15:12 UTC (permalink / raw)
  To: Rodrigo Siqueira
  Cc: Haneen Mohammed, Daniel Vetter, Intel Graphics Development,
	DRI Development, Daniel Vetter

On Tue, Sep 03, 2019 at 08:49:06AM -0400, Rodrigo Siqueira wrote:
> On 07/19, Daniel Vetter wrote:
> > It's the recommended version, wait_for_vblanks is a bit a hacky
> > interim thing that predates all the flip_done tracking. It's
> > unfortunately still the default ...
> 
> Just one question, is it safe to replace drm_atomic_helper_wait_for_vblanks by
> drm_atomic_helper_wait_for_flip_done? I noticed that only six drivers use these
> functions; they are:
> 
> * atmel-hlcdc
> * mediatek
> * msm
> * tegra
> * tilcdc
> * virtio
> 
> If we change these drivers, can we drop the helper
> drm_atomic_helper_wait_for_vblanks?

Yes, but there might be a tiny behaviour change, that's why I haven't just
made it the default.

Also note that wait_for_vblanks is still the default in the
atomic_commit_tail (seee drm_atomic_helper_commit_tail), so there's a pile
more drivers using this implicitly.

But yeah would be really great to fix that all up, since I think
wait_for_flip_done is the better function. Maybe a todo.rst? Or perhaps we
should at least do it for atomic helpers, and just see what breaks? As a
start for this conversion.

> Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>

Thanks, Daniel

> 
> Thanks
> 
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
> > Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > ---
> >  drivers/gpu/drm/vkms/vkms_drv.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> > index 44ab9f8ef8be..80524a22412a 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > @@ -83,7 +83,7 @@ static void vkms_atomic_commit_tail(struct drm_atomic_state *old_state)
> >  
> >  	drm_atomic_helper_commit_hw_done(old_state);
> >  
> > -	drm_atomic_helper_wait_for_vblanks(dev, old_state);
> > +	drm_atomic_helper_wait_for_flip_done(dev, old_state);
> >  
> >  	for_each_old_crtc_in_state(old_state, crtc, old_crtc_state, i) {
> >  		struct vkms_crtc_state *vkms_state =
> > -- 
> > 2.22.0
> > 
> 
> -- 
> Rodrigo Siqueira
> Software Engineer, Advanced Micro Devices (AMD)
> https://siqueira.tech



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 3/3] drm/vkms: Reduce critical section in vblank_simulate
  2019-09-03 12:50   ` Rodrigo Siqueira
@ 2019-09-03 15:16     ` Daniel Vetter
  0 siblings, 0 replies; 22+ messages in thread
From: Daniel Vetter @ 2019-09-03 15:16 UTC (permalink / raw)
  To: Rodrigo Siqueira
  Cc: Haneen Mohammed, Daniel Vetter, Intel Graphics Development,
	DRI Development, Daniel Vetter

On Tue, Sep 03, 2019 at 08:50:29AM -0400, Rodrigo Siqueira wrote:
> Thanks for this patch! It looks good for me.
> 
> Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>

Thanks for taking a look at all this, entire series merged. With the r-b
from Ville on patch 1, but I'm happy to further discuss your questions.
Plus I augmented the commit message a bit for patch 1 to explain the
missed vblank story better.
-Daniel

> 
> On 07/19, Daniel Vetter wrote:
> > We can reduce the critical section in vkms_vblank_simulate under
> > output->lock quite a lot:
> > 
> > - hrtimer_forward_now just needs to be ordered correctly wrt
> >   drm_crtc_handle_vblank. We already access the hrtimer timestamp
> >   without locks. While auditing that I noticed that we don't correctly
> >   annotate the read there, so sprinkle a READ_ONCE to make sure the
> >   compiler doesn't do anything foolish.
> > 
> > - drm_crtc_handle_vblank must stay under the lock to avoid races with
> >   drm_crtc_arm_vblank_event.
> > 
> > - The access to vkms_ouptut->crc_state also must stay under the lock.
> > 
> > - next problem is making sure the output->state structure doesn't get
> >   freed too early. First we rely on a given hrtimer being serialized:
> >   If we call drm_crtc_handle_vblank, then we are guaranteed that the
> >   previous call to vkms_vblank_simulate has completed. The other side
> >   of the coin is that the atomic updates waits for the vblank to
> >   happen before it releases the old state. Both taken together means
> >   that by the time the atomic update releases the old state, the
> >   hrtimer won't access it anymore (it might be accessing the new state
> >   at the same time, but that's ok).
> > 
> > - state is invariant, except the few fields separate protected by
> >   state->crc_lock. So no need to hold the lock for that.
> > 
> > - finally the queue_work. We need to make sure there's no races with
> >   the flush_work, i.e. when we call flush_work we need to guarantee
> >   that the hrtimer can't requeue the work again. This is guaranteed by
> >   the same vblank/hrtimer ordering guarantees like the reasoning above
> >   why state won't be freed too early: flush_work on the old state is
> >   called after wait_for_flip_done in the atomic commit code.
> > 
> > Therefore we can also move everything after the output->crc_state out
> > of the critical section.
> > 
> > Motivated by suggestions from Rodrigo.
> > 
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
> > Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > ---
> >  drivers/gpu/drm/vkms/vkms_crtc.c | 9 ++++-----
> >  1 file changed, 4 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
> > index 927dafaebc76..74f703b8d22a 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -16,17 +16,18 @@ static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
> >  	u64 ret_overrun;
> >  	bool ret;
> >  
> > -	spin_lock(&output->lock);
> > -
> >  	ret_overrun = hrtimer_forward_now(&output->vblank_hrtimer,
> >  					  output->period_ns);
> >  	WARN_ON(ret_overrun != 1);
> >  
> > +	spin_lock(&output->lock);
> >  	ret = drm_crtc_handle_vblank(crtc);
> >  	if (!ret)
> >  		DRM_ERROR("vkms failure on handling vblank");
> >  
> >  	state = output->composer_state;
> > +	spin_unlock(&output->lock);
> > +
> >  	if (state && output->composer_enabled) {
> >  		u64 frame = drm_crtc_accurate_vblank_count(crtc);
> >  
> > @@ -48,8 +49,6 @@ static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
> >  			DRM_DEBUG_DRIVER("Composer worker already queued\n");
> >  	}
> >  
> > -	spin_unlock(&output->lock);
> > -
> >  	return HRTIMER_RESTART;
> >  }
> >  
> > @@ -85,7 +84,7 @@ bool vkms_get_vblank_timestamp(struct drm_device *dev, unsigned int pipe,
> >  	struct vkms_output *output = &vkmsdev->output;
> >  	struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
> >  
> > -	*vblank_time = output->vblank_hrtimer.node.expires;
> > +	*vblank_time = READ_ONCE(output->vblank_hrtimer.node.expires);
> >  
> >  	if (WARN_ON(*vblank_time == vblank->time))
> >  		return true;
> > -- 
> > 2.22.0
> > 
> 
> -- 
> Rodrigo Siqueira
> Software Engineer, Advanced Micro Devices (AMD)
> https://siqueira.tech



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] drm/vblank: Document and fix vblank count barrier semantics
  2019-09-03 15:09       ` [Intel-gfx] " Daniel Vetter
@ 2019-09-03 15:17         ` Rodrigo Siqueira
  2019-09-03 15:46           ` Daniel Vetter
  0 siblings, 1 reply; 22+ messages in thread
From: Rodrigo Siqueira @ 2019-09-03 15:17 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
	Daniel Vetter


[-- Attachment #1.1: Type: text/plain, Size: 9664 bytes --]

Hi, thanks for the explanation.

I noticed that I forgot to add my r-b.

Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>

On 09/03, Daniel Vetter wrote:
> On Tue, Sep 03, 2019 at 08:47:03AM -0400, Rodrigo Siqueira wrote:
> > Hi Daniel,
> > 
> > All the series look really good for me. I just have some few questions
> > here.
> > 
> > On 07/23, 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
> > 
> > I have to admit that I'm a little bit confused about the "missed vblank
> > hilarity we've been seeing". Could you elaborate a little bit more about
> > this problem in the commit message?
> 
> We've had various reports on various drivers that hw vblanks seem to get
> lost and the driver stuck on vblank waits. I think most of those where
> just driver bugs, but could be also that there's some issues in the vblank
> core.
> 
> > Additionally, how about break this commit in two? One dedicated to the barriers
> > and the atomic64, and the other related to the documentation?
> > 
> > > 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.
> > > 
> > > v3:
> > > 
> > > Ville noticed that on 32bit we might be breaking up the load/stores,
> > > now that the vblank counter has been switched over to be 64 bit. Fix
> > > that up by switching to atomic64_t. This this happens so rarely in
> > > practice I figured no need to cc: stable ...
> > > 
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Cc: Keith Packard <keithp@keithp.com>
> > > References: 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]")
> > > 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 | 45 ++++++++++++++++++++++++++++++++----
> > >  include/drm/drm_vblank.h     | 15 ++++++++++--
> > >  2 files changed, 54 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > > index 603ab105125d..03e37bceac9c 100644
> > > --- a/drivers/gpu/drm/drm_vblank.c
> > > +++ b/drivers/gpu/drm/drm_vblank.c
> > > @@ -107,7 +107,7 @@ static void store_vblank(struct drm_device *dev, unsigned int pipe,
> > >  
> > >  	write_seqlock(&vblank->seqlock);
> > >  	vblank->time = t_vblank;
> > > -	vblank->count += vblank_count_inc;
> > > +	atomic64_add(vblank_count_inc, &vblank->count);
> > >  	write_sequnlock(&vblank->seqlock);
> > >  }
> > >  
> > > @@ -273,7 +273,8 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe,
> > >  
> > >  	DRM_DEBUG_VBL("updating vblank count on crtc %u:"
> > >  		      " current=%llu, diff=%u, hw=%u hw_last=%u\n",
> > > -		      pipe, vblank->count, diff, cur_vblank, vblank->last);
> > > +		      pipe, atomic64_read(&vblank->count), diff,
> > > +		      cur_vblank, vblank->last);
> > >  
> > >  	if (diff == 0) {
> > >  		WARN_ON_ONCE(cur_vblank != vblank->last);
> > > @@ -295,11 +296,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 = atomic64_read(&vblank->count);
> > > +
> > > +	/*
> > > +	 * 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();
> > 
> > I think I did not get all the idea behind the smp_rmb() in this function. FWIU,
> > smp_xxx are used for preventing race conditions in a multiprocessor system,
> > right? In this sense, I can presume that this change can bring benefits for
> > VKMS or any other virtual driver; on the other hand, this will not bring any
> > advantage on real drivers like i915 and amdgpu since these devices are not
> > related with smp stuff, right?
> 
> smp or not smp is about the cpu your driver is running on, not anything to
> do with the device hardware itself. And nowadays there's simply no
> single-threaded processors anymore, everything has at least 2 cores (even
> the tiniest soc). So yeah, this matters for everyone.
> 
> smp_* functions only get compiled out to nothing if you have CONFIG_UP
> (which means only 1 cpu core with only 1 SMT thread is supported).
> 
> And yeah correctly placing smp barriers is Real Hard Stuff (tm).
> -Daniel
> 
>  
> > Thanks
> > 
> > > +
> > > +	return count;
> > >  }
> > >  
> > >  /**
> > > @@ -764,6 +777,14 @@ drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
> > >   * vblank interrupt (since it only reports the software vblank counter), see
> > >   * drm_crtc_accurate_vblank_count() for such use-cases.
> > >   *
> > > + * Note that for a given vblank counter value drm_crtc_handle_vblank()
> > > + * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> > > + * provide a barrier: Any writes done before calling
> > > + * drm_crtc_handle_vblank() will be visible to callers of the later
> > > + * functions, iff the vblank count is the same or a later one.
> > > + *
> > > + * See also &drm_vblank_crtc.count.
> > > + *
> > >   * Returns:
> > >   * The software vblank counter.
> > >   */
> > > @@ -801,7 +822,7 @@ static u64 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
> > >  
> > >  	do {
> > >  		seq = read_seqbegin(&vblank->seqlock);
> > > -		vblank_count = vblank->count;
> > > +		vblank_count = atomic64_read(&vblank->count);
> > >  		*vblanktime = vblank->time;
> > >  	} while (read_seqretry(&vblank->seqlock, seq));
> > >  
> > > @@ -818,6 +839,14 @@ static u64 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
> > >   * vblank events since the system was booted, including lost events due to
> > >   * modesetting activity. Returns corresponding system timestamp of the time
> > >   * of the vblank interval that corresponds to the current vblank counter value.
> > > + *
> > > + * Note that for a given vblank counter value drm_crtc_handle_vblank()
> > > + * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> > > + * provide a barrier: Any writes done before calling
> > > + * drm_crtc_handle_vblank() will be visible to callers of the later
> > > + * functions, iff the vblank count is the same or a later one.
> > > + *
> > > + * See also &drm_vblank_crtc.count.
> > >   */
> > >  u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
> > >  				   ktime_t *vblanktime)
> > > @@ -1791,6 +1820,14 @@ EXPORT_SYMBOL(drm_handle_vblank);
> > >   *
> > >   * This is the native KMS version of drm_handle_vblank().
> > >   *
> > > + * Note that for a given vblank counter value drm_crtc_handle_vblank()
> > > + * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> > > + * provide a barrier: Any writes done before calling
> > > + * drm_crtc_handle_vblank() will be visible to callers of the later
> > > + * functions, iff the vblank count is the same or a later one.
> > > + *
> > > + * See also &drm_vblank_crtc.count.
> > > + *
> > >   * Returns:
> > >   * True if the event was successfully handled, false on failure.
> > >   */
> > > diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
> > > index 9fe4ba8bc622..c16c44052b3d 100644
> > > --- a/include/drm/drm_vblank.h
> > > +++ b/include/drm/drm_vblank.h
> > > @@ -109,9 +109,20 @@ struct drm_vblank_crtc {
> > >  	seqlock_t seqlock;
> > >  
> > >  	/**
> > > -	 * @count: Current software vblank counter.
> > > +	 * @count:
> > > +	 *
> > > +	 * Current software vblank counter.
> > > +	 *
> > > +	 * Note that for a given vblank counter value drm_crtc_handle_vblank()
> > > +	 * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> > > +	 * provide a barrier: Any writes done before calling
> > > +	 * drm_crtc_handle_vblank() will be visible to callers of the later
> > > +	 * functions, iff the vblank count is the same or a later one.
> > > +	 *
> > > +	 * IMPORTANT: This guarantee requires barriers, therefor never access
> > > +	 * this field directly. Use drm_crtc_vblank_count() instead.
> > >  	 */
> > > -	u64 count;
> > > +	atomic64_t count;
> > >  	/**
> > >  	 * @time: Vblank timestamp corresponding to @count.
> > >  	 */
> > > -- 
> > > 2.22.0
> > > 
> > 
> > -- 
> > Rodrigo Siqueira
> > Software Engineer, Advanced Micro Devices (AMD)
> > https://siqueira.tech
> 
> 
> 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Rodrigo Siqueira
Software Engineer, Advanced Micro Devices (AMD)
https://siqueira.tech

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] drm/vblank: Document and fix vblank count barrier semantics
  2019-09-03 15:17         ` Rodrigo Siqueira
@ 2019-09-03 15:46           ` Daniel Vetter
  0 siblings, 0 replies; 22+ messages in thread
From: Daniel Vetter @ 2019-09-03 15:46 UTC (permalink / raw)
  To: Rodrigo Siqueira
  Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
	Daniel Vetter

On Tue, Sep 03, 2019 at 11:17:12AM -0400, Rodrigo Siqueira wrote:
> Hi, thanks for the explanation.
> 
> I noticed that I forgot to add my r-b.
> 
> Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>

Uh I just pushed, so can't add your r-b now :-/

Sry.
-Daniel

> 
> On 09/03, Daniel Vetter wrote:
> > On Tue, Sep 03, 2019 at 08:47:03AM -0400, Rodrigo Siqueira wrote:
> > > Hi Daniel,
> > > 
> > > All the series look really good for me. I just have some few questions
> > > here.
> > > 
> > > On 07/23, 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
> > > 
> > > I have to admit that I'm a little bit confused about the "missed vblank
> > > hilarity we've been seeing". Could you elaborate a little bit more about
> > > this problem in the commit message?
> > 
> > We've had various reports on various drivers that hw vblanks seem to get
> > lost and the driver stuck on vblank waits. I think most of those where
> > just driver bugs, but could be also that there's some issues in the vblank
> > core.
> > 
> > > Additionally, how about break this commit in two? One dedicated to the barriers
> > > and the atomic64, and the other related to the documentation?
> > > 
> > > > 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.
> > > > 
> > > > v3:
> > > > 
> > > > Ville noticed that on 32bit we might be breaking up the load/stores,
> > > > now that the vblank counter has been switched over to be 64 bit. Fix
> > > > that up by switching to atomic64_t. This this happens so rarely in
> > > > practice I figured no need to cc: stable ...
> > > > 
> > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > Cc: Keith Packard <keithp@keithp.com>
> > > > References: 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]")
> > > > 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 | 45 ++++++++++++++++++++++++++++++++----
> > > >  include/drm/drm_vblank.h     | 15 ++++++++++--
> > > >  2 files changed, 54 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > > > index 603ab105125d..03e37bceac9c 100644
> > > > --- a/drivers/gpu/drm/drm_vblank.c
> > > > +++ b/drivers/gpu/drm/drm_vblank.c
> > > > @@ -107,7 +107,7 @@ static void store_vblank(struct drm_device *dev, unsigned int pipe,
> > > >  
> > > >  	write_seqlock(&vblank->seqlock);
> > > >  	vblank->time = t_vblank;
> > > > -	vblank->count += vblank_count_inc;
> > > > +	atomic64_add(vblank_count_inc, &vblank->count);
> > > >  	write_sequnlock(&vblank->seqlock);
> > > >  }
> > > >  
> > > > @@ -273,7 +273,8 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe,
> > > >  
> > > >  	DRM_DEBUG_VBL("updating vblank count on crtc %u:"
> > > >  		      " current=%llu, diff=%u, hw=%u hw_last=%u\n",
> > > > -		      pipe, vblank->count, diff, cur_vblank, vblank->last);
> > > > +		      pipe, atomic64_read(&vblank->count), diff,
> > > > +		      cur_vblank, vblank->last);
> > > >  
> > > >  	if (diff == 0) {
> > > >  		WARN_ON_ONCE(cur_vblank != vblank->last);
> > > > @@ -295,11 +296,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 = atomic64_read(&vblank->count);
> > > > +
> > > > +	/*
> > > > +	 * 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();
> > > 
> > > I think I did not get all the idea behind the smp_rmb() in this function. FWIU,
> > > smp_xxx are used for preventing race conditions in a multiprocessor system,
> > > right? In this sense, I can presume that this change can bring benefits for
> > > VKMS or any other virtual driver; on the other hand, this will not bring any
> > > advantage on real drivers like i915 and amdgpu since these devices are not
> > > related with smp stuff, right?
> > 
> > smp or not smp is about the cpu your driver is running on, not anything to
> > do with the device hardware itself. And nowadays there's simply no
> > single-threaded processors anymore, everything has at least 2 cores (even
> > the tiniest soc). So yeah, this matters for everyone.
> > 
> > smp_* functions only get compiled out to nothing if you have CONFIG_UP
> > (which means only 1 cpu core with only 1 SMT thread is supported).
> > 
> > And yeah correctly placing smp barriers is Real Hard Stuff (tm).
> > -Daniel
> > 
> >  
> > > Thanks
> > > 
> > > > +
> > > > +	return count;
> > > >  }
> > > >  
> > > >  /**
> > > > @@ -764,6 +777,14 @@ drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
> > > >   * vblank interrupt (since it only reports the software vblank counter), see
> > > >   * drm_crtc_accurate_vblank_count() for such use-cases.
> > > >   *
> > > > + * Note that for a given vblank counter value drm_crtc_handle_vblank()
> > > > + * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> > > > + * provide a barrier: Any writes done before calling
> > > > + * drm_crtc_handle_vblank() will be visible to callers of the later
> > > > + * functions, iff the vblank count is the same or a later one.
> > > > + *
> > > > + * See also &drm_vblank_crtc.count.
> > > > + *
> > > >   * Returns:
> > > >   * The software vblank counter.
> > > >   */
> > > > @@ -801,7 +822,7 @@ static u64 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
> > > >  
> > > >  	do {
> > > >  		seq = read_seqbegin(&vblank->seqlock);
> > > > -		vblank_count = vblank->count;
> > > > +		vblank_count = atomic64_read(&vblank->count);
> > > >  		*vblanktime = vblank->time;
> > > >  	} while (read_seqretry(&vblank->seqlock, seq));
> > > >  
> > > > @@ -818,6 +839,14 @@ static u64 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
> > > >   * vblank events since the system was booted, including lost events due to
> > > >   * modesetting activity. Returns corresponding system timestamp of the time
> > > >   * of the vblank interval that corresponds to the current vblank counter value.
> > > > + *
> > > > + * Note that for a given vblank counter value drm_crtc_handle_vblank()
> > > > + * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> > > > + * provide a barrier: Any writes done before calling
> > > > + * drm_crtc_handle_vblank() will be visible to callers of the later
> > > > + * functions, iff the vblank count is the same or a later one.
> > > > + *
> > > > + * See also &drm_vblank_crtc.count.
> > > >   */
> > > >  u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
> > > >  				   ktime_t *vblanktime)
> > > > @@ -1791,6 +1820,14 @@ EXPORT_SYMBOL(drm_handle_vblank);
> > > >   *
> > > >   * This is the native KMS version of drm_handle_vblank().
> > > >   *
> > > > + * Note that for a given vblank counter value drm_crtc_handle_vblank()
> > > > + * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> > > > + * provide a barrier: Any writes done before calling
> > > > + * drm_crtc_handle_vblank() will be visible to callers of the later
> > > > + * functions, iff the vblank count is the same or a later one.
> > > > + *
> > > > + * See also &drm_vblank_crtc.count.
> > > > + *
> > > >   * Returns:
> > > >   * True if the event was successfully handled, false on failure.
> > > >   */
> > > > diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
> > > > index 9fe4ba8bc622..c16c44052b3d 100644
> > > > --- a/include/drm/drm_vblank.h
> > > > +++ b/include/drm/drm_vblank.h
> > > > @@ -109,9 +109,20 @@ struct drm_vblank_crtc {
> > > >  	seqlock_t seqlock;
> > > >  
> > > >  	/**
> > > > -	 * @count: Current software vblank counter.
> > > > +	 * @count:
> > > > +	 *
> > > > +	 * Current software vblank counter.
> > > > +	 *
> > > > +	 * Note that for a given vblank counter value drm_crtc_handle_vblank()
> > > > +	 * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> > > > +	 * provide a barrier: Any writes done before calling
> > > > +	 * drm_crtc_handle_vblank() will be visible to callers of the later
> > > > +	 * functions, iff the vblank count is the same or a later one.
> > > > +	 *
> > > > +	 * IMPORTANT: This guarantee requires barriers, therefor never access
> > > > +	 * this field directly. Use drm_crtc_vblank_count() instead.
> > > >  	 */
> > > > -	u64 count;
> > > > +	atomic64_t count;
> > > >  	/**
> > > >  	 * @time: Vblank timestamp corresponding to @count.
> > > >  	 */
> > > > -- 
> > > > 2.22.0
> > > > 
> > > 
> > > -- 
> > > Rodrigo Siqueira
> > > Software Engineer, Advanced Micro Devices (AMD)
> > > https://siqueira.tech
> > 
> > 
> > 
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> 
> -- 
> Rodrigo Siqueira
> Software Engineer, Advanced Micro Devices (AMD)
> https://siqueira.tech



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2019-09-03 15:46 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 ` [Intel-gfx] [PATCH 1/3] " Ville Syrjälä
2019-07-19 18:33   ` 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

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.