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 12:58:40PM +0300, 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.

Oh, and skipping the controlled shutdown could violate panel power
sequencing requirements, which is not good for the panel's health.

-- 
Ville Syrjälä
Intel