Re: [PATCH 5/6] drm/i915/reset: Handle the display vs. GPU reset deadlock using a custom dma-fence

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Mon, Apr 13, 2026 at 01:24:04PM +0200, Christian König wrote:
> On 4/13/26 11:58, Ville Syrjälä wrote:
> > On Mon, Apr 13, 2026 at 11:35:23AM +0200, Christian König wrote:
> >> On 4/13/26 11:11, Ville Syrjälä wrote:
> >>>>>> I think something is missing in my picture how that is supposed to work.
> >>>>>
> >>>>> The problem stems from the fact that on old platforms a GPU reset
> >>>>> also resets the display hardware,
> >>>>
> >>>> Which is true for at least AMD GPUs and I think pretty much everybody else as well, but that wasn't so much of a problem so far.
> >>>>
> >>>>> and to do that safely we need:
> >>>>> 1. shut down display
> >>>>> 2. perform the GPU reset
> >>>>> 3. restore the display hardware to its orignal state
> >>>>
> >>>> Mhm, I've recently talked with Michel about it and we confirmed that this is perfectly possible without issues. Adding Michel as well.
> >>>>
> >>>>> We just do that with essentially with a normal atomic commit.
> >>>>
> >>>> I think that is the source of the problem.
> >>>>
> >>>> I'm not an expert on that topic but amdgpu and tons of other drivers seem to just use drm_atomic_helper_shutdown() for that.
> >>>
> >>> drm_atomic_helper_shutdown() is definitely not the thing to use
> >>> for this as it would clobber the stored kms state, leaving everything
> >>> permanently disabled. The drm_atomic_helper_commit_duplicated_state()
> >>> stuff i915 uses is the correct thing here.
> >>>
> >>> But for this problem it doesn't even matter which gets used. Either
> >>> would get equally stuck behind a previous atomic commit waiting for
> >>> its fences.
> >>>
> >>>>
> >>>> What is i915 doing differently?
> >>>
> >>> I see zero code for any display reset stuff in any other driver. If
> >>> amdgpu does anything it must be something completely custom, hidden
> >>> somewhere deep.
> >>
> >> The display is just fully reset by any MODE1 reset, you don't need to do anything special for that.
> > 
> > You can't just ignore the fact that there may be a display hardware
> > reprogramming already happening in parallel. Failing to follow the
> > correct programming sequence is a recipe for even hard system hangs.
> 
> Of course not. We have a RW lock to prevent concurrent HW access while a GPU reset is ongoing to prevent that.

Now that you mention it, I remember that long ago I did something
very similar for i915, but it required quite a bit of surgery to
the atomic core code and Sima didn't want it so it never went in.

Our modeset state is much more complex these days, so attempting
to resurrect it now (and actually getting people to accept it)
just for old hardware doesn't seem worth the effort.

I think apart from the reset fence, the only other *practical* solution
is to effectively revert Sima's commit 9db529aac938 ("drm/i915: More
surgically unbreak the modeset vs reset deadlock") and go back to the
full wedge (== cancel all in flight requests). It's a bit rude since
it will also penalize completely innocent contexts. But meh.

> > There is zero support in the atomic design for reordering commits,
> > which is pretty much what would be needed. A generic solution would
> > more or less involve a full redesign/rewrite of atomic.
> 
> Mhm, I need to ask our DC team and other contacts how that is handled at the moment for amdgpu.
> 
> But we clearly have the same problem and it doesn't require any hacks like that one here. So there must be a solution for it already.

The hacks must be on the modeset side, since as mentioned atomic has
zero support for this at the moment.

-- 
Ville Syrjälä
Intel