Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Perform full wedge on display reset
Date: Fri, 04 Sep 2026 12:20:13 +0300	[thread overview]
Message-ID: <ad75b3c6b3c41aaeea11c7b452e2bf9ad451fd18@intel.com> (raw)
In-Reply-To: <20260903130116.19089-1-ville.syrjala@linux.intel.com>

On Thu, 03 Sep 2026, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> We lost the proper display reset deadlock handling in
> commit d59cf7bb73f3 ("drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence").
> Currently the only thing that eventually breaks the deadlock is the
> 10 second fence timeout, which is very slow.
>
> I tried to essentially restore the previous mechanism via a custom
> dma_fence in
> https://lore.kernel.org/intel-gfx/20260408233458.22666-6-ville.syrjala@linux.intel.com/
> but Christian didn't want it.
>
> The ideal solution would be to allow the reset time modesets to proceed
> ahead of any already queued atomic commits, but that is quite involved
> since we need to be able to track the already committed (to the
> hardware) atomic states in addition to the userspace queued atomic states.
> Years ago I did implement something like that in
> https://lore.kernel.org/intel-gfx/20170629134948.5614-1-ville.syrjala@linux.intel.com/
> but Sima didn't want it.
>
> In order to get rid of the dependency on the timeout, and make things
> faster, let's just effectively revert the remainders of
> commit 9db529aac938 ("drm/i915: More surgically unbreak the modeset vs reset deadlock").
> The upside is that the reset is fast again, but the downside is that
> we now do a full wedge on all display resets, which will also kill
> innocent batches. But perhaps no one really cares since this is
> currently only needed for old pre-g4x hardware. But if anyone has plans on
> using eg. FLR as a backup GPU reset on new hardware then we probably need
> to come up with something better...
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Acked-by: Jani Nikula <jani.nikula@intel.com>

> ---
>  drivers/gpu/drm/i915/gt/intel_reset.c | 8 +-------
>  drivers/gpu/drm/i915/i915_dpt.c       | 2 --
>  drivers/gpu/drm/i915/i915_drv.h       | 2 --
>  drivers/gpu/drm/i915/i915_fb_pin.c    | 6 ------
>  drivers/gpu/drm/i915/i915_overlay.c   | 5 -----
>  5 files changed, 1 insertion(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c
> index 6053f3e8aa27..bd1f26336ac4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> @@ -1433,13 +1433,7 @@ static void intel_gt_reset_global(struct intel_gt *gt,
>  			need_display_reset;
>  
>  		if (reset_display) {
> -			if (atomic_read(&i915->pending_fb_pin)) {
> -				drm_dbg_kms(&i915->drm,
> -					    "Modeset potentially stuck, unbreaking through wedging\n");
> -
> -				intel_gt_set_wedged(gt);
> -			}
> -
> +			intel_gt_set_wedged(gt);
>  			intel_display_reset_prepare(display);
>  		}
>  
> diff --git a/drivers/gpu/drm/i915/i915_dpt.c b/drivers/gpu/drm/i915/i915_dpt.c
> index e01dc4de1788..85d872c0f387 100644
> --- a/drivers/gpu/drm/i915/i915_dpt.c
> +++ b/drivers/gpu/drm/i915/i915_dpt.c
> @@ -139,7 +139,6 @@ struct i915_vma *i915_dpt_pin_to_ggtt(struct intel_dpt *dpt, unsigned int alignm
>  		pin_flags |= PIN_MAPPABLE;
>  
>  	wakeref = intel_runtime_pm_get(&i915->runtime_pm);
> -	atomic_inc(&i915->pending_fb_pin);
>  
>  	for_i915_gem_ww(&ww, err, true) {
>  		err = i915_gem_object_lock(dpt->obj, &ww);
> @@ -169,7 +168,6 @@ struct i915_vma *i915_dpt_pin_to_ggtt(struct intel_dpt *dpt, unsigned int alignm
>  
>  	dpt->obj->mm.dirty = true;
>  
> -	atomic_dec(&i915->pending_fb_pin);
>  	intel_runtime_pm_put(&i915->runtime_pm, wakeref);
>  
>  	return err ? ERR_PTR(err) : vma;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 844ed79e7211..dafee3dcd1c5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -315,8 +315,6 @@ struct drm_i915_private {
>  	/* The TTM device structure. */
>  	struct ttm_device bdev;
>  
> -	atomic_t pending_fb_pin;
> -
>  	I915_SELFTEST_DECLARE(struct i915_selftest_stash selftest;)
>  
>  	/*
> diff --git a/drivers/gpu/drm/i915/i915_fb_pin.c b/drivers/gpu/drm/i915/i915_fb_pin.c
> index 1034cb767e9f..63be136f1a05 100644
> --- a/drivers/gpu/drm/i915/i915_fb_pin.c
> +++ b/drivers/gpu/drm/i915/i915_fb_pin.c
> @@ -35,8 +35,6 @@ intel_fb_pin_to_dpt(struct drm_gem_object *_obj, struct intel_dpt *dpt,
>  	if (WARN_ON(!i915_gem_object_is_framebuffer(obj)))
>  		return ERR_PTR(-EINVAL);
>  
> -	atomic_inc(&i915->pending_fb_pin);
> -
>  	for_i915_gem_ww(&ww, ret, true) {
>  		ret = i915_gem_object_lock(obj, &ww);
>  		if (ret)
> @@ -98,7 +96,6 @@ intel_fb_pin_to_dpt(struct drm_gem_object *_obj, struct intel_dpt *dpt,
>  	 */
>  	drm_WARN_ON(&i915->drm, i915_dpt_offset(vma));
>  err:
> -	atomic_dec(&i915->pending_fb_pin);
>  
>  	return vma;
>  }
> @@ -132,8 +129,6 @@ intel_fb_pin_to_ggtt(struct drm_gem_object *_obj,
>  	 */
>  	wakeref = intel_runtime_pm_get(&i915->runtime_pm);
>  
> -	atomic_inc(&i915->pending_fb_pin);
> -
>  	pinctl = 0;
>  	/* PIN_MAPPABLE limits the address to GMADR size */
>  	if (pin_params->needs_low_address)
> @@ -206,7 +201,6 @@ intel_fb_pin_to_ggtt(struct drm_gem_object *_obj,
>  	if (ret)
>  		vma = ERR_PTR(ret);
>  
> -	atomic_dec(&i915->pending_fb_pin);
>  	intel_runtime_pm_put(&i915->runtime_pm, wakeref);
>  	return vma;
>  }
> diff --git a/drivers/gpu/drm/i915/i915_overlay.c b/drivers/gpu/drm/i915/i915_overlay.c
> index 6de550a17756..c1a7920c6324 100644
> --- a/drivers/gpu/drm/i915/i915_overlay.c
> +++ b/drivers/gpu/drm/i915/i915_overlay.c
> @@ -354,14 +354,11 @@ static struct i915_vma *i915_overlay_pin_fb(struct drm_device *drm,
>  					    struct drm_gem_object *obj,
>  					    u32 *offset)
>  {
> -	struct drm_i915_private *i915 = to_i915(drm);
>  	struct drm_i915_gem_object *new_bo = to_intel_bo(obj);
>  	struct i915_gem_ww_ctx ww;
>  	struct i915_vma *vma;
>  	int ret;
>  
> -	atomic_inc(&i915->pending_fb_pin);
> -
>  	i915_gem_ww_ctx_init(&ww, true);
>  retry:
>  	ret = i915_gem_object_lock(new_bo, &ww);
> @@ -377,8 +374,6 @@ static struct i915_vma *i915_overlay_pin_fb(struct drm_device *drm,
>  	}
>  	i915_gem_ww_ctx_fini(&ww);
>  
> -	atomic_dec(&i915->pending_fb_pin);
> -
>  	if (ret)
>  		return ERR_PTR(ret);

-- 
Jani Nikula, Intel

      parent reply	other threads:[~2026-09-04  9:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-03 13:01 [PATCH] drm/i915: Perform full wedge on display reset Ville Syrjala
2026-09-03 15:00 ` ✓ i915.CI.BAT: success for " Patchwork
2026-09-04  4:32 ` ✗ i915.CI.Full: failure " Patchwork
2026-09-04  9:20 ` Jani Nikula [this message]

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=ad75b3c6b3c41aaeea11c7b452e2bf9ad451fd18@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.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