intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
* [Intel-gfx] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank
@ 2023-11-16 11:27 Luca Coelho
  2023-11-16 16:03 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for " Patchwork
  2023-11-17  7:19 ` [Intel-gfx] [Intel-xe] [PATCH] " Ville Syrjälä
  0 siblings, 2 replies; 13+ messages in thread
From: Luca Coelho @ 2023-11-16 11:27 UTC (permalink / raw)
  To: intel-gfx; +Cc: intel-xe, rodrigo.vivi

Since we're abstracting the display code from the underlying driver
(i.e. i915 vs xe), we can't use the uncore's spinlock to protect
critical sections of our code.

After further inspection, it seems that the spinlock is not needed at
all and this can be handled by disabling preemption and interrupts
instead.

Change the vblank code so that we don't use uncore's spinlock anymore
and update the comments accordingly.  While at it, also remove
comments pointing out where to insert RT-specific calls, since we're
now explicitly calling preempt_disable/enable() anywyay.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---

Note: this replaces my previous patch discussed here:
https://patchwork.freedesktop.org/patch/563857/


 drivers/gpu/drm/i915/display/intel_vblank.c | 32 ++++++++++-----------
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c b/drivers/gpu/drm/i915/display/intel_vblank.c
index 2cec2abf9746..28e38960806e 100644
--- a/drivers/gpu/drm/i915/display/intel_vblank.c
+++ b/drivers/gpu/drm/i915/display/intel_vblank.c
@@ -302,13 +302,12 @@ static bool i915_get_crtc_scanoutpos(struct drm_crtc *_crtc,
 	}
 
 	/*
-	 * Lock uncore.lock, as we will do multiple timing critical raw
-	 * register reads, potentially with preemption disabled, so the
-	 * following code must not block on uncore.lock.
+	 * We will do multiple timing critical raw register reads, so
+	 * disable interrupts and preemption to make sure this code
+	 * doesn't get blocked.
 	 */
-	spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
-
-	/* preempt_disable_rt() should go right here in PREEMPT_RT patchset. */
+	local_irq_save(irqflags);
+	preempt_disable();
 
 	/* Get optional system timestamp before query. */
 	if (stime)
@@ -372,9 +371,8 @@ static bool i915_get_crtc_scanoutpos(struct drm_crtc *_crtc,
 	if (etime)
 		*etime = ktime_get();
 
-	/* preempt_enable_rt() should go right here in PREEMPT_RT patchset. */
-
-	spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
+	preempt_enable();
+	local_irq_restore(irqflags);
 
 	/*
 	 * While in vblank, position will be negative
@@ -408,13 +406,14 @@ bool intel_crtc_get_vblank_timestamp(struct drm_crtc *crtc, int *max_error,
 
 int intel_get_crtc_scanline(struct intel_crtc *crtc)
 {
-	struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
 	unsigned long irqflags;
 	int position;
 
-	spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
+	local_irq_save(irqflags);
+	preempt_disable();
 	position = __intel_get_crtc_scanline(crtc);
-	spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
+	preempt_enable();
+	local_irq_restore(irqflags);
 
 	return position;
 }
@@ -528,16 +527,16 @@ void intel_crtc_update_active_timings(const struct intel_crtc_state *crtc_state,
 	 * Belts and suspenders locking to guarantee everyone sees 100%
 	 * consistent state during fastset seamless refresh rate changes.
 	 *
-	 * vblank_time_lock takes care of all drm_vblank.c stuff, and
-	 * uncore.lock takes care of __intel_get_crtc_scanline() which
-	 * may get called elsewhere as well.
+	 * vblank_time_lock takes care of all drm_vblank.c stuff.  For
+	 * __intel_get_crtc_scanline() we don't need locking or
+	 * disabling preemption and irqs, since this is already done
+	 * by the vblank_time_lock spinlock calls.
 	 *
 	 * TODO maybe just protect everything (including
 	 * __intel_get_crtc_scanline()) with vblank_time_lock?
 	 * Need to audit everything to make sure it's safe.
 	 */
 	spin_lock_irqsave(&i915->drm.vblank_time_lock, irqflags);
-	spin_lock(&i915->uncore.lock);
 
 	drm_calc_timestamping_constants(&crtc->base, &adjusted_mode);
 
@@ -547,6 +546,5 @@ void intel_crtc_update_active_timings(const struct intel_crtc_state *crtc_state,
 
 	crtc->scanline_offset = intel_crtc_scanline_offset(crtc_state);
 
-	spin_unlock(&i915->uncore.lock);
 	spin_unlock_irqrestore(&i915->drm.vblank_time_lock, irqflags);
 }
-- 
2.39.2


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

* [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: don't use uncore spinlock to protect critical section in vblank
  2023-11-16 11:27 [Intel-gfx] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank Luca Coelho
@ 2023-11-16 16:03 ` Patchwork
  2023-11-17  7:19 ` [Intel-gfx] [Intel-xe] [PATCH] " Ville Syrjälä
  1 sibling, 0 replies; 13+ messages in thread
From: Patchwork @ 2023-11-16 16:03 UTC (permalink / raw)
  To: Luca Coelho; +Cc: intel-gfx

[-- Attachment #1: Type: text/plain, Size: 10168 bytes --]

== Series Details ==

Series: drm/i915: don't use uncore spinlock to protect critical section in vblank
URL   : https://patchwork.freedesktop.org/series/126518/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13884 -> Patchwork_126518v1
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_126518v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_126518v1, please notify your bug team (lgci.bug.filing@intel.com) to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/index.html

Participating hosts (39 -> 37)
------------------------------

  Additional (1): bat-dg2-9 
  Missing    (3): bat-dg2-8 fi-snb-2520m bat-dg1-5 

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_126518v1:

### IGT changes ###

#### Possible regressions ####

  * igt@i915_selftest@live@workarounds:
    - bat-dg2-11:         [PASS][1] -> [DMESG-FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13884/bat-dg2-11/igt@i915_selftest@live@workarounds.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-dg2-11/igt@i915_selftest@live@workarounds.html

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_suspend@basic-s0@smem:
    - bat-jsl-1:          [PASS][3] -> [INCOMPLETE][4] ([i915#9275])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13884/bat-jsl-1/igt@gem_exec_suspend@basic-s0@smem.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-jsl-1/igt@gem_exec_suspend@basic-s0@smem.html

  * igt@gem_mmap@basic:
    - bat-dg2-9:          NOTRUN -> [SKIP][5] ([i915#4083])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-dg2-9/igt@gem_mmap@basic.html

  * igt@gem_mmap_gtt@basic:
    - bat-dg2-9:          NOTRUN -> [SKIP][6] ([i915#4077]) +2 other tests skip
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-dg2-9/igt@gem_mmap_gtt@basic.html

  * igt@gem_render_tiled_blits@basic:
    - bat-dg2-9:          NOTRUN -> [SKIP][7] ([i915#4079]) +1 other test skip
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-dg2-9/igt@gem_render_tiled_blits@basic.html

  * igt@i915_pm_rps@basic-api:
    - bat-dg2-9:          NOTRUN -> [SKIP][8] ([i915#6621])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-dg2-9/igt@i915_pm_rps@basic-api.html

  * igt@i915_selftest@live@gt_tlb:
    - bat-rpls-1:         [PASS][9] -> [INCOMPLETE][10] ([i915#9674])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13884/bat-rpls-1/igt@i915_selftest@live@gt_tlb.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-rpls-1/igt@i915_selftest@live@gt_tlb.html

  * igt@i915_selftest@live@workarounds:
    - bat-adlp-9:         [PASS][11] -> [INCOMPLETE][12] ([i915#9413])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13884/bat-adlp-9/igt@i915_selftest@live@workarounds.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-adlp-9/igt@i915_selftest@live@workarounds.html

  * igt@i915_suspend@basic-s3-without-i915:
    - bat-jsl-1:          [PASS][13] -> [FAIL][14] ([fdo#103375])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13884/bat-jsl-1/igt@i915_suspend@basic-s3-without-i915.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-jsl-1/igt@i915_suspend@basic-s3-without-i915.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
    - bat-dg2-9:          NOTRUN -> [SKIP][15] ([i915#5190])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-dg2-9/igt@kms_addfb_basic@addfb25-y-tiled-small-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
    - bat-dg2-9:          NOTRUN -> [SKIP][16] ([i915#4215] / [i915#5190])
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-dg2-9/igt@kms_addfb_basic@basic-y-tiled-legacy.html

  * igt@kms_addfb_basic@framebuffer-vs-set-tiling:
    - bat-dg2-9:          NOTRUN -> [SKIP][17] ([i915#4212]) +6 other tests skip
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-dg2-9/igt@kms_addfb_basic@framebuffer-vs-set-tiling.html

  * igt@kms_addfb_basic@tile-pitch-mismatch:
    - bat-dg2-9:          NOTRUN -> [SKIP][18] ([i915#4212] / [i915#5608])
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-dg2-9/igt@kms_addfb_basic@tile-pitch-mismatch.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
    - bat-dg2-9:          NOTRUN -> [SKIP][19] ([i915#4103] / [i915#4213] / [i915#5608]) +1 other test skip
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-dg2-9/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
    - bat-dg2-9:          NOTRUN -> [SKIP][20] ([fdo#109285])
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-dg2-9/igt@kms_force_connector_basic@force-load-detect.html

  * igt@kms_force_connector_basic@prune-stale-modes:
    - bat-dg2-9:          NOTRUN -> [SKIP][21] ([i915#5274])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-dg2-9/igt@kms_force_connector_basic@prune-stale-modes.html

  * igt@kms_setmode@basic-clone-single-crtc:
    - bat-dg2-9:          NOTRUN -> [SKIP][22] ([i915#3555] / [i915#4098])
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-dg2-9/igt@kms_setmode@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-fence-flip:
    - bat-dg2-9:          NOTRUN -> [SKIP][23] ([i915#3708])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-dg2-9/igt@prime_vgem@basic-fence-flip.html

  * igt@prime_vgem@basic-fence-mmap:
    - bat-dg2-9:          NOTRUN -> [SKIP][24] ([i915#3708] / [i915#4077]) +1 other test skip
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-dg2-9/igt@prime_vgem@basic-fence-mmap.html

  * igt@prime_vgem@basic-write:
    - bat-dg2-9:          NOTRUN -> [SKIP][25] ([i915#3291] / [i915#3708]) +2 other tests skip
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-dg2-9/igt@prime_vgem@basic-write.html

  
#### Possible fixes ####

  * igt@i915_selftest@live@coherency:
    - fi-hsw-4770:        [INCOMPLETE][26] -> [PASS][27]
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13884/fi-hsw-4770/igt@i915_selftest@live@coherency.html
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/fi-hsw-4770/igt@i915_selftest@live@coherency.html

  * igt@i915_selftest@live@gt_heartbeat:
    - fi-apl-guc:         [DMESG-FAIL][28] ([i915#5334]) -> [PASS][29]
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13884/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
    - bat-rplp-1:         [ABORT][30] ([i915#8668]) -> [PASS][31]
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13884/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1.html
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
  [i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
  [i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
  [i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
  [i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
  [i915#5608]: https://gitlab.freedesktop.org/drm/intel/issues/5608
  [i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
  [i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
  [i915#9275]: https://gitlab.freedesktop.org/drm/intel/issues/9275
  [i915#9413]: https://gitlab.freedesktop.org/drm/intel/issues/9413
  [i915#9648]: https://gitlab.freedesktop.org/drm/intel/issues/9648
  [i915#9673]: https://gitlab.freedesktop.org/drm/intel/issues/9673
  [i915#9674]: https://gitlab.freedesktop.org/drm/intel/issues/9674


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

  * Linux: CI_DRM_13884 -> Patchwork_126518v1

  CI-20190529: 20190529
  CI_DRM_13884: 9739fd04dfe62f6b46eb8f6af604decabb45a87b @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7590: c484e1422184a3183d11f1595e53a6715574520f @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_126518v1: 9739fd04dfe62f6b46eb8f6af604decabb45a87b @ git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

b221395de673 drm/i915: don't use uncore spinlock to protect critical section in vblank

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126518v1/index.html

[-- Attachment #2: Type: text/html, Size: 11573 bytes --]

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

* Re: [Intel-gfx] [Intel-xe] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank
  2023-11-16 11:27 [Intel-gfx] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank Luca Coelho
  2023-11-16 16:03 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for " Patchwork
@ 2023-11-17  7:19 ` Ville Syrjälä
  2023-11-17  8:05   ` Coelho, Luciano
  1 sibling, 1 reply; 13+ messages in thread
From: Ville Syrjälä @ 2023-11-17  7:19 UTC (permalink / raw)
  To: Luca Coelho; +Cc: intel-gfx, intel-xe, rodrigo.vivi

On Thu, Nov 16, 2023 at 01:27:00PM +0200, Luca Coelho wrote:
> Since we're abstracting the display code from the underlying driver
> (i.e. i915 vs xe), we can't use the uncore's spinlock to protect
> critical sections of our code.
> 
> After further inspection, it seems that the spinlock is not needed at
> all and this can be handled by disabling preemption and interrupts
> instead.

uncore.lock has multiple purposes:
1. serialize all register accesses to the same cacheline as on
   certain platforms that can hang the machine
2. protect the forcewake/etc. state

1 is relevant here, 2 is not.

> 
> Change the vblank code so that we don't use uncore's spinlock anymore
> and update the comments accordingly.  While at it, also remove
> comments pointing out where to insert RT-specific calls, since we're
> now explicitly calling preempt_disable/enable() anywyay.
> 
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> ---
> 
> Note: this replaces my previous patch discussed here:
> https://patchwork.freedesktop.org/patch/563857/
> 
> 
>  drivers/gpu/drm/i915/display/intel_vblank.c | 32 ++++++++++-----------
>  1 file changed, 15 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c b/drivers/gpu/drm/i915/display/intel_vblank.c
> index 2cec2abf9746..28e38960806e 100644
> --- a/drivers/gpu/drm/i915/display/intel_vblank.c
> +++ b/drivers/gpu/drm/i915/display/intel_vblank.c
> @@ -302,13 +302,12 @@ static bool i915_get_crtc_scanoutpos(struct drm_crtc *_crtc,
>  	}
>  
>  	/*
> -	 * Lock uncore.lock, as we will do multiple timing critical raw
> -	 * register reads, potentially with preemption disabled, so the
> -	 * following code must not block on uncore.lock.
> +	 * We will do multiple timing critical raw register reads, so
> +	 * disable interrupts and preemption to make sure this code
> +	 * doesn't get blocked.
>  	 */
> -	spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
> -
> -	/* preempt_disable_rt() should go right here in PREEMPT_RT patchset. */
> +	local_irq_save(irqflags);
> +	preempt_disable();
>  
>  	/* Get optional system timestamp before query. */
>  	if (stime)
> @@ -372,9 +371,8 @@ static bool i915_get_crtc_scanoutpos(struct drm_crtc *_crtc,
>  	if (etime)
>  		*etime = ktime_get();
>  
> -	/* preempt_enable_rt() should go right here in PREEMPT_RT patchset. */
> -
> -	spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
> +	preempt_enable();
> +	local_irq_restore(irqflags);
>  
>  	/*
>  	 * While in vblank, position will be negative
> @@ -408,13 +406,14 @@ bool intel_crtc_get_vblank_timestamp(struct drm_crtc *crtc, int *max_error,
>  
>  int intel_get_crtc_scanline(struct intel_crtc *crtc)
>  {
> -	struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>  	unsigned long irqflags;
>  	int position;
>  
> -	spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
> +	local_irq_save(irqflags);
> +	preempt_disable();
>  	position = __intel_get_crtc_scanline(crtc);
> -	spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
> +	preempt_enable();
> +	local_irq_restore(irqflags);
>  
>  	return position;
>  }
> @@ -528,16 +527,16 @@ void intel_crtc_update_active_timings(const struct intel_crtc_state *crtc_state,
>  	 * Belts and suspenders locking to guarantee everyone sees 100%
>  	 * consistent state during fastset seamless refresh rate changes.
>  	 *
> -	 * vblank_time_lock takes care of all drm_vblank.c stuff, and
> -	 * uncore.lock takes care of __intel_get_crtc_scanline() which
> -	 * may get called elsewhere as well.
> +	 * vblank_time_lock takes care of all drm_vblank.c stuff.  For
> +	 * __intel_get_crtc_scanline() we don't need locking or
> +	 * disabling preemption and irqs, since this is already done
> +	 * by the vblank_time_lock spinlock calls.
>  	 *
>  	 * TODO maybe just protect everything (including
>  	 * __intel_get_crtc_scanline()) with vblank_time_lock?
>  	 * Need to audit everything to make sure it's safe.
>  	 */
>  	spin_lock_irqsave(&i915->drm.vblank_time_lock, irqflags);
> -	spin_lock(&i915->uncore.lock);
>  
>  	drm_calc_timestamping_constants(&crtc->base, &adjusted_mode);
>  
> @@ -547,6 +546,5 @@ void intel_crtc_update_active_timings(const struct intel_crtc_state *crtc_state,
>  
>  	crtc->scanline_offset = intel_crtc_scanline_offset(crtc_state);
>  
> -	spin_unlock(&i915->uncore.lock);
>  	spin_unlock_irqrestore(&i915->drm.vblank_time_lock, irqflags);
>  }
> -- 
> 2.39.2

-- 
Ville Syrjälä
Intel

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

* Re: [Intel-gfx] [Intel-xe] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank
  2023-11-17  7:19 ` [Intel-gfx] [Intel-xe] [PATCH] " Ville Syrjälä
@ 2023-11-17  8:05   ` Coelho, Luciano
  2023-11-17  8:41     ` Ville Syrjälä
  0 siblings, 1 reply; 13+ messages in thread
From: Coelho, Luciano @ 2023-11-17  8:05 UTC (permalink / raw)
  To: ville.syrjala; +Cc: intel-gfx, intel-xe, Vivi,  Rodrigo

Thanks for your comments, Ville!

On Fri, 2023-11-17 at 09:19 +0200, Ville Syrjälä wrote:
> On Thu, Nov 16, 2023 at 01:27:00PM +0200, Luca Coelho wrote:
> > Since we're abstracting the display code from the underlying driver
> > (i.e. i915 vs xe), we can't use the uncore's spinlock to protect
> > critical sections of our code.
> > 
> > After further inspection, it seems that the spinlock is not needed at
> > all and this can be handled by disabling preemption and interrupts
> > instead.
> 
> uncore.lock has multiple purposes:
> 1. serialize all register accesses to the same cacheline as on
>    certain platforms that can hang the machine

Okay, do you remember which platforms? I couldn't find any reference to
this reason.  Also, the only place where where we take the uncore.lock
is in this vblank code I changed, where the only explanation I found
was about timing, specifically when using RT-kernels and in very old
and slow platforms... (this was added 10 years ago).


> 2. protect the forcewake/etc. state
> 
> 1 is relevant here, 2 is not.

Okay, good that we have only one known problem. :)

--
Cheers,
Luca.

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

* Re: [Intel-gfx] [Intel-xe] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank
  2023-11-17  8:05   ` Coelho, Luciano
@ 2023-11-17  8:41     ` Ville Syrjälä
  2023-11-17  8:46       ` Coelho, Luciano
  2023-11-17  9:26       ` Ville Syrjälä
  0 siblings, 2 replies; 13+ messages in thread
From: Ville Syrjälä @ 2023-11-17  8:41 UTC (permalink / raw)
  To: Coelho, Luciano; +Cc: intel-gfx, intel-xe, Vivi, Rodrigo

On Fri, Nov 17, 2023 at 08:05:21AM +0000, Coelho, Luciano wrote:
> Thanks for your comments, Ville!
> 
> On Fri, 2023-11-17 at 09:19 +0200, Ville Syrjälä wrote:
> > On Thu, Nov 16, 2023 at 01:27:00PM +0200, Luca Coelho wrote:
> > > Since we're abstracting the display code from the underlying driver
> > > (i.e. i915 vs xe), we can't use the uncore's spinlock to protect
> > > critical sections of our code.
> > > 
> > > After further inspection, it seems that the spinlock is not needed at
> > > all and this can be handled by disabling preemption and interrupts
> > > instead.
> > 
> > uncore.lock has multiple purposes:
> > 1. serialize all register accesses to the same cacheline as on
> >    certain platforms that can hang the machine
> 
> Okay, do you remember which platforms?

HSW is the one I remember for sure being affected.
Althoguh I don't recall if I ever managed to hang it
using display registers specifically. intel_gpu_top
certainly was very good at reproducing the problem.

> I couldn't find any reference to
> this reason. 

If all else fails git log is your friend.

> Also, the only place where where we take the uncore.lock
> is in this vblank code I changed, where the only explanation I found
> was about timing, specifically when using RT-kernels and in very old
> and slow platforms... (this was added 10 years ago).
> 
> 
> > 2. protect the forcewake/etc. state
> > 
> > 1 is relevant here, 2 is not.
> 
> Okay, good that we have only one known problem. :)
> 
> --
> Cheers,
> Luca.

-- 
Ville Syrjälä
Intel

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

* Re: [Intel-gfx] [Intel-xe] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank
  2023-11-17  8:41     ` Ville Syrjälä
@ 2023-11-17  8:46       ` Coelho, Luciano
  2023-11-17  9:26       ` Ville Syrjälä
  1 sibling, 0 replies; 13+ messages in thread
From: Coelho, Luciano @ 2023-11-17  8:46 UTC (permalink / raw)
  To: ville.syrjala; +Cc: intel-gfx, intel-xe, Vivi,  Rodrigo

On Fri, 2023-11-17 at 10:41 +0200, Ville Syrjälä wrote:
> On Fri, Nov 17, 2023 at 08:05:21AM +0000, Coelho, Luciano wrote:
> > Thanks for your comments, Ville!
> > 
> > On Fri, 2023-11-17 at 09:19 +0200, Ville Syrjälä wrote:
> > > On Thu, Nov 16, 2023 at 01:27:00PM +0200, Luca Coelho wrote:
> > > > Since we're abstracting the display code from the underlying driver
> > > > (i.e. i915 vs xe), we can't use the uncore's spinlock to protect
> > > > critical sections of our code.
> > > > 
> > > > After further inspection, it seems that the spinlock is not needed at
> > > > all and this can be handled by disabling preemption and interrupts
> > > > instead.
> > > 
> > > uncore.lock has multiple purposes:
> > > 1. serialize all register accesses to the same cacheline as on
> > >    certain platforms that can hang the machine
> > 
> > Okay, do you remember which platforms?
> 
> HSW is the one I remember for sure being affected.
> Althoguh I don't recall if I ever managed to hang it
> using display registers specifically. intel_gpu_top
> certainly was very good at reproducing the problem.

So do we know if the display registers are affected at all?


> > I couldn't find any reference to
> > this reason. 
> 
> If all else fails git log is your friend.

Of course! That's where I found the info about the RT stuff.  But I
didn't find anything else regarding this.  Maybe I should just look
harder, if you don't have a reference at hand. ;)

--
Cheers,
Luca.

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

* Re: [Intel-gfx] [Intel-xe] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank
  2023-11-17  8:41     ` Ville Syrjälä
  2023-11-17  8:46       ` Coelho, Luciano
@ 2023-11-17  9:26       ` Ville Syrjälä
  2023-11-17 12:21         ` Coelho, Luciano
  2023-11-17 16:50         ` Rodrigo Vivi
  1 sibling, 2 replies; 13+ messages in thread
From: Ville Syrjälä @ 2023-11-17  9:26 UTC (permalink / raw)
  To: Coelho, Luciano; +Cc: intel-gfx, intel-xe, Vivi, Rodrigo

On Fri, Nov 17, 2023 at 10:41:43AM +0200, Ville Syrjälä wrote:
> On Fri, Nov 17, 2023 at 08:05:21AM +0000, Coelho, Luciano wrote:
> > Thanks for your comments, Ville!
> > 
> > On Fri, 2023-11-17 at 09:19 +0200, Ville Syrjälä wrote:
> > > On Thu, Nov 16, 2023 at 01:27:00PM +0200, Luca Coelho wrote:
> > > > Since we're abstracting the display code from the underlying driver
> > > > (i.e. i915 vs xe), we can't use the uncore's spinlock to protect
> > > > critical sections of our code.
> > > > 
> > > > After further inspection, it seems that the spinlock is not needed at
> > > > all and this can be handled by disabling preemption and interrupts
> > > > instead.
> > > 
> > > uncore.lock has multiple purposes:
> > > 1. serialize all register accesses to the same cacheline as on
> > >    certain platforms that can hang the machine
> > 
> > Okay, do you remember which platforms?
> 
> HSW is the one I remember for sure being affected.
> Althoguh I don't recall if I ever managed to hang it
> using display registers specifically. intel_gpu_top
> certainly was very good at reproducing the problem.
> 
> > I couldn't find any reference to
> > this reason. 
> 
> If all else fails git log is your friend.

It seems to be documented in intel_uncore.h. Though that one
mentions IVB instead of HSW for some reason. I don't recall
seeing it on IVB myself, but I suppose it might have been an
issue there as well. How long the problem remained after HSW
I have no idea.

> 
> > Also, the only place where where we take the uncore.lock
> > is in this vblank code I changed, where the only explanation I found
> > was about timing, specifically when using RT-kernels and in very old
> > and slow platforms... (this was added 10 years ago).
> > 
> > 
> > > 2. protect the forcewake/etc. state
> > > 
> > > 1 is relevant here, 2 is not.
> > 
> > Okay, good that we have only one known problem. :)
> > 
> > --
> > Cheers,
> > Luca.
> 
> -- 
> Ville Syrjälä
> Intel

-- 
Ville Syrjälä
Intel

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

* Re: [Intel-gfx] [Intel-xe] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank
  2023-11-17  9:26       ` Ville Syrjälä
@ 2023-11-17 12:21         ` Coelho, Luciano
  2023-11-17 12:46           ` Tvrtko Ursulin
  2023-11-17 16:50         ` Rodrigo Vivi
  1 sibling, 1 reply; 13+ messages in thread
From: Coelho, Luciano @ 2023-11-17 12:21 UTC (permalink / raw)
  To: ville.syrjala; +Cc: intel-gfx, Ursulin, Tvrtko, intel-xe, Vivi,  Rodrigo

Adding Tvrtko, for some reason he didn't get CCed before.


On Fri, 2023-11-17 at 11:26 +0200, Ville Syrjälä wrote:
> On Fri, Nov 17, 2023 at 10:41:43AM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 17, 2023 at 08:05:21AM +0000, Coelho, Luciano wrote:
> > > Thanks for your comments, Ville!
> > > 
> > > On Fri, 2023-11-17 at 09:19 +0200, Ville Syrjälä wrote:
> > > > On Thu, Nov 16, 2023 at 01:27:00PM +0200, Luca Coelho wrote:
> > > > > Since we're abstracting the display code from the underlying driver
> > > > > (i.e. i915 vs xe), we can't use the uncore's spinlock to protect
> > > > > critical sections of our code.
> > > > > 
> > > > > After further inspection, it seems that the spinlock is not needed at
> > > > > all and this can be handled by disabling preemption and interrupts
> > > > > instead.
> > > > 
> > > > uncore.lock has multiple purposes:
> > > > 1. serialize all register accesses to the same cacheline as on
> > > >    certain platforms that can hang the machine
> > > 
> > > Okay, do you remember which platforms?
> > 
> > HSW is the one I remember for sure being affected.
> > Althoguh I don't recall if I ever managed to hang it
> > using display registers specifically. intel_gpu_top
> > certainly was very good at reproducing the problem.
> > 
> > > I couldn't find any reference to
> > > this reason. 
> > 
> > If all else fails git log is your friend.
> 
> It seems to be documented in intel_uncore.h. Though that one
> mentions IVB instead of HSW for some reason. I don't recall
> seeing it on IVB myself, but I suppose it might have been an
> issue there as well. How long the problem remained after HSW
> I have no idea.

Oh, somehow I missed that.  Thanks.

So, it seems that the locking is indeed needed.  I think there are two
options, then:

1. Go back to my previous version of the patch, where I had the wrapper
that didn't lock anything on Xe and implement the display part when we
get a similar implementation of the uncore.lock on Xe (if ever needed).

2. Implement a display-local lock for this, as suggested at some point,
including the other intel_de*() accesses.  But can we be sure that it's
enough to protect only the registers accessed by the display? I.e.
won't accessing display registers non-serially in relation to non-
display registers?


Preferences?

--
Cheers,
Luca.

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

* Re: [Intel-gfx] [Intel-xe] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank
  2023-11-17 12:21         ` Coelho, Luciano
@ 2023-11-17 12:46           ` Tvrtko Ursulin
  2023-11-29  8:20             ` Coelho, Luciano
  0 siblings, 1 reply; 13+ messages in thread
From: Tvrtko Ursulin @ 2023-11-17 12:46 UTC (permalink / raw)
  To: Coelho, Luciano, ville.syrjala
  Cc: intel-gfx, Vivi, Rodrigo, intel-xe, Ursulin, Tvrtko


On 17/11/2023 12:21, Coelho, Luciano wrote:
> Adding Tvrtko, for some reason he didn't get CCed before.
> 
> 
> On Fri, 2023-11-17 at 11:26 +0200, Ville Syrjälä wrote:
>> On Fri, Nov 17, 2023 at 10:41:43AM +0200, Ville Syrjälä wrote:
>>> On Fri, Nov 17, 2023 at 08:05:21AM +0000, Coelho, Luciano wrote:
>>>> Thanks for your comments, Ville!
>>>>
>>>> On Fri, 2023-11-17 at 09:19 +0200, Ville Syrjälä wrote:
>>>>> On Thu, Nov 16, 2023 at 01:27:00PM +0200, Luca Coelho wrote:
>>>>>> Since we're abstracting the display code from the underlying driver
>>>>>> (i.e. i915 vs xe), we can't use the uncore's spinlock to protect
>>>>>> critical sections of our code.
>>>>>>
>>>>>> After further inspection, it seems that the spinlock is not needed at
>>>>>> all and this can be handled by disabling preemption and interrupts
>>>>>> instead.
>>>>>
>>>>> uncore.lock has multiple purposes:
>>>>> 1. serialize all register accesses to the same cacheline as on
>>>>>     certain platforms that can hang the machine
>>>>
>>>> Okay, do you remember which platforms?
>>>
>>> HSW is the one I remember for sure being affected.
>>> Althoguh I don't recall if I ever managed to hang it
>>> using display registers specifically. intel_gpu_top
>>> certainly was very good at reproducing the problem.
>>>
>>>> I couldn't find any reference to
>>>> this reason.
>>>
>>> If all else fails git log is your friend.
>>
>> It seems to be documented in intel_uncore.h. Though that one
>> mentions IVB instead of HSW for some reason. I don't recall
>> seeing it on IVB myself, but I suppose it might have been an
>> issue there as well. How long the problem remained after HSW
>> I have no idea.
> 
> Oh, somehow I missed that.  Thanks.
> 
> So, it seems that the locking is indeed needed.  I think there are two
> options, then:
> 
> 1. Go back to my previous version of the patch, where I had the wrapper
> that didn't lock anything on Xe and implement the display part when we
> get a similar implementation of the uncore.lock on Xe (if ever needed).
> 
> 2. Implement a display-local lock for this, as suggested at some point,
> including the other intel_de*() accesses.  But can we be sure that it's
> enough to protect only the registers accessed by the display? I.e.
> won't accessing display registers non-serially in relation to non-
> display registers?
> 
> 
> Preferences?

AFAIR my initial complaint was the naming which was along the lines of 
intel_spin_lock(uncore). How to come up with a clean and logical name is 
the question...

On Xe you don't need a lock since HSW/IVB/cacheline angle does not exist 
but you need a name which does not clash with either.

Assuming you still need the preempt off (or irq off) on Xe for better 
timings, maybe along the lines of intel_vblank_section_enter/exit(i915)? 
Although I am not up to speed with what object instead of i915 would you 
be passing in from Xe ie. how exactly polymorphism is implemented in 
shared code.

Regards,

Tvrtko

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

* Re: [Intel-gfx] [Intel-xe] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank
  2023-11-17  9:26       ` Ville Syrjälä
  2023-11-17 12:21         ` Coelho, Luciano
@ 2023-11-17 16:50         ` Rodrigo Vivi
  2023-11-17 17:15           ` Zanoni, Paulo R
  1 sibling, 1 reply; 13+ messages in thread
From: Rodrigo Vivi @ 2023-11-17 16:50 UTC (permalink / raw)
  To: Ville Syrjälä, Paulo Zanoni
  Cc: intel-gfx, Coelho, Luciano, intel-xe

On Fri, Nov 17, 2023 at 11:26:44AM +0200, Ville Syrjälä wrote:
> On Fri, Nov 17, 2023 at 10:41:43AM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 17, 2023 at 08:05:21AM +0000, Coelho, Luciano wrote:
> > > Thanks for your comments, Ville!
> > > 
> > > On Fri, 2023-11-17 at 09:19 +0200, Ville Syrjälä wrote:
> > > > On Thu, Nov 16, 2023 at 01:27:00PM +0200, Luca Coelho wrote:
> > > > > Since we're abstracting the display code from the underlying driver
> > > > > (i.e. i915 vs xe), we can't use the uncore's spinlock to protect
> > > > > critical sections of our code.
> > > > > 
> > > > > After further inspection, it seems that the spinlock is not needed at
> > > > > all and this can be handled by disabling preemption and interrupts
> > > > > instead.
> > > > 
> > > > uncore.lock has multiple purposes:
> > > > 1. serialize all register accesses to the same cacheline as on
> > > >    certain platforms that can hang the machine
> > > 
> > > Okay, do you remember which platforms?
> > 
> > HSW is the one I remember for sure being affected.
> > Althoguh I don't recall if I ever managed to hang it
> > using display registers specifically. intel_gpu_top
> > certainly was very good at reproducing the problem.
> > 
> > > I couldn't find any reference to
> > > this reason. 
> > 
> > If all else fails git log is your friend.
> 
> It seems to be documented in intel_uncore.h. Though that one
> mentions IVB instead of HSW for some reason. I don't recall
> seeing it on IVB myself, but I suppose it might have been an
> issue there as well. How long the problem remained after HSW
> I have no idea.

Paulo very recently told me that he could easily reproduce the issue
on IVB, simply by running 2 glxgears at the same time.

> 
> > 
> > > Also, the only place where where we take the uncore.lock
> > > is in this vblank code I changed, where the only explanation I found
> > > was about timing, specifically when using RT-kernels and in very old
> > > and slow platforms... (this was added 10 years ago).
> > > 
> > > 
> > > > 2. protect the forcewake/etc. state
> > > > 
> > > > 1 is relevant here, 2 is not.
> > > 
> > > Okay, good that we have only one known problem. :)

and good it is an old one! :)

> > > 
> > > --
> > > Cheers,
> > > Luca.
> > 
> > -- 
> > Ville Syrjälä
> > Intel
> 
> -- 
> Ville Syrjälä
> Intel

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

* Re: [Intel-gfx] [Intel-xe] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank
  2023-11-17 16:50         ` Rodrigo Vivi
@ 2023-11-17 17:15           ` Zanoni, Paulo R
  2023-11-29  8:22             ` Coelho, Luciano
  0 siblings, 1 reply; 13+ messages in thread
From: Zanoni, Paulo R @ 2023-11-17 17:15 UTC (permalink / raw)
  To: ville.syrjala, Vivi, Rodrigo; +Cc: intel-gfx, Coelho, Luciano, intel-xe

On Fri, 2023-11-17 at 11:50 -0500, Rodrigo Vivi wrote:
> On Fri, Nov 17, 2023 at 11:26:44AM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 17, 2023 at 10:41:43AM +0200, Ville Syrjälä wrote:
> > > On Fri, Nov 17, 2023 at 08:05:21AM +0000, Coelho, Luciano wrote:
> > > > Thanks for your comments, Ville!
> > > > 
> > > > On Fri, 2023-11-17 at 09:19 +0200, Ville Syrjälä wrote:
> > > > > On Thu, Nov 16, 2023 at 01:27:00PM +0200, Luca Coelho wrote:
> > > > > > Since we're abstracting the display code from the underlying driver
> > > > > > (i.e. i915 vs xe), we can't use the uncore's spinlock to protect
> > > > > > critical sections of our code.
> > > > > > 
> > > > > > After further inspection, it seems that the spinlock is not needed at
> > > > > > all and this can be handled by disabling preemption and interrupts
> > > > > > instead.
> > > > > 
> > > > > uncore.lock has multiple purposes:
> > > > > 1. serialize all register accesses to the same cacheline as on
> > > > >    certain platforms that can hang the machine
> > > > 
> > > > Okay, do you remember which platforms?
> > > 
> > > HSW is the one I remember for sure being affected.
> > > Althoguh I don't recall if I ever managed to hang it
> > > using display registers specifically. intel_gpu_top
> > > certainly was very good at reproducing the problem.
> > > 
> > > > I couldn't find any reference to
> > > > this reason. 
> > > 
> > > If all else fails git log is your friend.
> > 
> > It seems to be documented in intel_uncore.h. Though that one
> > mentions IVB instead of HSW for some reason. I don't recall
> > seeing it on IVB myself, but I suppose it might have been an
> > issue there as well. How long the problem remained after HSW
> > I have no idea.
> 
> Paulo very recently told me that he could easily reproduce the issue
> on IVB, simply by running 2 glxgears at the same time.

Just a minor correction: I didn't give the degree of confidence in my
answer that the sentence above suggests :). It's all "as far as I
remember". This is all from like 10 years ago and I can't remember what
I had for lunch yesterday. Maybe it was some other similar bug that I
could reproduce with glxgears. Also, the way we used registers was
different back then, maybe today glxgears is not enough to do it
anymore. And I think it required vblank_mode=0.

> 
> > 
> > > 
> > > > Also, the only place where where we take the uncore.lock
> > > > is in this vblank code I changed, where the only explanation I found
> > > > was about timing, specifically when using RT-kernels and in very old
> > > > and slow platforms... (this was added 10 years ago).
> > > > 
> > > > 
> > > > > 2. protect the forcewake/etc. state
> > > > > 
> > > > > 1 is relevant here, 2 is not.
> > > > 
> > > > Okay, good that we have only one known problem. :)
> 
> and good it is an old one! :)
> 
> > > > 
> > > > --
> > > > Cheers,
> > > > Luca.
> > > 
> > > -- 
> > > Ville Syrjälä
> > > Intel
> > 
> > -- 
> > Ville Syrjälä
> > Intel


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

* Re: [Intel-gfx] [Intel-xe] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank
  2023-11-17 12:46           ` Tvrtko Ursulin
@ 2023-11-29  8:20             ` Coelho, Luciano
  0 siblings, 0 replies; 13+ messages in thread
From: Coelho, Luciano @ 2023-11-29  8:20 UTC (permalink / raw)
  To: ville.syrjala, tvrtko.ursulin
  Cc: intel-gfx, Ursulin, Tvrtko, intel-xe, Vivi,  Rodrigo

On Fri, 2023-11-17 at 12:46 +0000, Tvrtko Ursulin wrote:
> On 17/11/2023 12:21, Coelho, Luciano wrote:
> > Adding Tvrtko, for some reason he didn't get CCed before.
> > 
> > 
> > On Fri, 2023-11-17 at 11:26 +0200, Ville Syrjälä wrote:
> > > On Fri, Nov 17, 2023 at 10:41:43AM +0200, Ville Syrjälä wrote:
> > > > On Fri, Nov 17, 2023 at 08:05:21AM +0000, Coelho, Luciano wrote:
> > > > > Thanks for your comments, Ville!
> > > > > 
> > > > > On Fri, 2023-11-17 at 09:19 +0200, Ville Syrjälä wrote:
> > > > > > On Thu, Nov 16, 2023 at 01:27:00PM +0200, Luca Coelho wrote:
> > > > > > > Since we're abstracting the display code from the underlying driver
> > > > > > > (i.e. i915 vs xe), we can't use the uncore's spinlock to protect
> > > > > > > critical sections of our code.
> > > > > > > 
> > > > > > > After further inspection, it seems that the spinlock is not needed at
> > > > > > > all and this can be handled by disabling preemption and interrupts
> > > > > > > instead.
> > > > > > 
> > > > > > uncore.lock has multiple purposes:
> > > > > > 1. serialize all register accesses to the same cacheline as on
> > > > > >     certain platforms that can hang the machine
> > > > > 
> > > > > Okay, do you remember which platforms?
> > > > 
> > > > HSW is the one I remember for sure being affected.
> > > > Althoguh I don't recall if I ever managed to hang it
> > > > using display registers specifically. intel_gpu_top
> > > > certainly was very good at reproducing the problem.
> > > > 
> > > > > I couldn't find any reference to
> > > > > this reason.
> > > > 
> > > > If all else fails git log is your friend.
> > > 
> > > It seems to be documented in intel_uncore.h. Though that one
> > > mentions IVB instead of HSW for some reason. I don't recall
> > > seeing it on IVB myself, but I suppose it might have been an
> > > issue there as well. How long the problem remained after HSW
> > > I have no idea.
> > 
> > Oh, somehow I missed that.  Thanks.
> > 
> > So, it seems that the locking is indeed needed.  I think there are two
> > options, then:
> > 
> > 1. Go back to my previous version of the patch, where I had the wrapper
> > that didn't lock anything on Xe and implement the display part when we
> > get a similar implementation of the uncore.lock on Xe (if ever needed).
> > 
> > 2. Implement a display-local lock for this, as suggested at some point,
> > including the other intel_de*() accesses.  But can we be sure that it's
> > enough to protect only the registers accessed by the display? I.e.
> > won't accessing display registers non-serially in relation to non-
> > display registers?
> > 
> > 
> > Preferences?
> 
> AFAIR my initial complaint was the naming which was along the lines of 
> intel_spin_lock(uncore). How to come up with a clean and logical name is 
> the question...

You're right, that was your first comment, and now we're back to it. :)


> On Xe you don't need a lock since HSW/IVB/cacheline angle does not exist 
> but you need a name which does not clash with either.
> 
> Assuming you still need the preempt off (or irq off) on Xe for better 
> timings, maybe along the lines of intel_vblank_section_enter/exit(i915)?

I like this name, because it's indeed this vblank section we're trying
to protect here, and this is not used anywhere else.

 
> Although I am not up to speed with what object instead of i915 would you 
> be passing in from Xe ie. how exactly polymorphism is implemented in 
> shared code.

AFAICT we are still using the i915 structure for most things inside the
display code, so I guess we should use that for now.

I'll send a new version of my original patch in a bit.

--
Cheers,
Luca.

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

* Re: [Intel-gfx] [Intel-xe] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank
  2023-11-17 17:15           ` Zanoni, Paulo R
@ 2023-11-29  8:22             ` Coelho, Luciano
  0 siblings, 0 replies; 13+ messages in thread
From: Coelho, Luciano @ 2023-11-29  8:22 UTC (permalink / raw)
  To: ville.syrjala, Vivi, Rodrigo, Zanoni, Paulo R; +Cc: intel-gfx, intel-xe

On Fri, 2023-11-17 at 17:15 +0000, Zanoni, Paulo R wrote:
> On Fri, 2023-11-17 at 11:50 -0500, Rodrigo Vivi wrote:
> > On Fri, Nov 17, 2023 at 11:26:44AM +0200, Ville Syrjälä wrote:
> > > On Fri, Nov 17, 2023 at 10:41:43AM +0200, Ville Syrjälä wrote:
> > > > On Fri, Nov 17, 2023 at 08:05:21AM +0000, Coelho, Luciano wrote:
> > > > > Thanks for your comments, Ville!
> > > > > 
> > > > > On Fri, 2023-11-17 at 09:19 +0200, Ville Syrjälä wrote:
> > > > > > On Thu, Nov 16, 2023 at 01:27:00PM +0200, Luca Coelho wrote:
> > > > > > > Since we're abstracting the display code from the underlying driver
> > > > > > > (i.e. i915 vs xe), we can't use the uncore's spinlock to protect
> > > > > > > critical sections of our code.
> > > > > > > 
> > > > > > > After further inspection, it seems that the spinlock is not needed at
> > > > > > > all and this can be handled by disabling preemption and interrupts
> > > > > > > instead.
> > > > > > 
> > > > > > uncore.lock has multiple purposes:
> > > > > > 1. serialize all register accesses to the same cacheline as on
> > > > > >    certain platforms that can hang the machine
> > > > > 
> > > > > Okay, do you remember which platforms?
> > > > 
> > > > HSW is the one I remember for sure being affected.
> > > > Althoguh I don't recall if I ever managed to hang it
> > > > using display registers specifically. intel_gpu_top
> > > > certainly was very good at reproducing the problem.
> > > > 
> > > > > I couldn't find any reference to
> > > > > this reason. 
> > > > 
> > > > If all else fails git log is your friend.
> > > 
> > > It seems to be documented in intel_uncore.h. Though that one
> > > mentions IVB instead of HSW for some reason. I don't recall
> > > seeing it on IVB myself, but I suppose it might have been an
> > > issue there as well. How long the problem remained after HSW
> > > I have no idea.
> > 
> > Paulo very recently told me that he could easily reproduce the issue
> > on IVB, simply by running 2 glxgears at the same time.
> 
> Just a minor correction: I didn't give the degree of confidence in my
> answer that the sentence above suggests :). It's all "as far as I
> remember". This is all from like 10 years ago and I can't remember what
> I had for lunch yesterday. Maybe it was some other similar bug that I
> could reproduce with glxgears. Also, the way we used registers was
> different back then, maybe today glxgears is not enough to do it
> anymore. And I think it required vblank_mode=0.

Great, thanks for this information! It's good to know the actual facts
for this implementation.  So, we'll keep things mostly as they are,
without removing any locking and go back to my original version of this
implementation, which keeps the locking with i915.

--
Cheers,
Luca.

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

end of thread, other threads:[~2023-11-29  8:23 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-16 11:27 [Intel-gfx] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank Luca Coelho
2023-11-16 16:03 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for " Patchwork
2023-11-17  7:19 ` [Intel-gfx] [Intel-xe] [PATCH] " Ville Syrjälä
2023-11-17  8:05   ` Coelho, Luciano
2023-11-17  8:41     ` Ville Syrjälä
2023-11-17  8:46       ` Coelho, Luciano
2023-11-17  9:26       ` Ville Syrjälä
2023-11-17 12:21         ` Coelho, Luciano
2023-11-17 12:46           ` Tvrtko Ursulin
2023-11-29  8:20             ` Coelho, Luciano
2023-11-17 16:50         ` Rodrigo Vivi
2023-11-17 17:15           ` Zanoni, Paulo R
2023-11-29  8:22             ` Coelho, Luciano

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).