Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Luca Coelho <luciano.coelho@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	rodrigo.vivi@intel.com
Subject: Re: [Intel-xe] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank
Date: Fri, 17 Nov 2023 09:19:59 +0200	[thread overview]
Message-ID: <ZVcUH7G40NQ4Q-R7@intel.com> (raw)
In-Reply-To: <20231116112700.648963-1-luciano.coelho@intel.com>

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

  parent reply	other threads:[~2023-11-17  7:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-16 11:27 [Intel-xe] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank Luca Coelho
2023-11-16 11:30 ` [Intel-xe] ✗ CI.Patch_applied: failure for " Patchwork
2023-11-17  7:19 ` Ville Syrjälä [this message]
2023-11-17  8:05   ` [Intel-xe] [Intel-gfx] [PATCH] " 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
2023-11-18  0:50 ` [Intel-xe] ✗ CI.Patch_applied: failure for " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZVcUH7G40NQ4Q-R7@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=luciano.coelho@intel.com \
    --cc=rodrigo.vivi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox