Re: ✗ i915.CI.Full: failure for drm/i915/display: stop using the configurable fence timeout (rev2)

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

On Wed, Apr 08, 2026 at 05:49:58PM +0200, Maarten Lankhorst wrote:
> Hey,
> 
> Den 2026-04-08 kl. 17:14, skrev Jani Nikula:
> > On Thu, 02 Apr 2026, Maarten Lankhorst <maarten.lankhorst@intel.com> wrote:
> >> Den 2026-04-02 kl. 11:40, skrev Jani Nikula:
> >>> On Wed, 03 Dec 2025, Maarten Lankhorst <maarten.lankhorst@intel.com> wrote:
> >>>> Hey,
> >>>>
> >>>> Den 2025-11-25 kl. 18:24, skrev Ville Syrjälä:
> >>>>> On Tue, Nov 25, 2025 at 03:55:02PM +0200, Jani Nikula wrote:
> >>>>>> Maarten, Ville, any ideas what to do about these?
> >>>>> Looks like we need the timeout to unbreak the modeset vs. reset
> >>>>> deadlock in a timely fashion.
> >>>>>
> >>>>> I'm not where we signal/error the fences the modeset is waiting
> >>>>> for, but I guess that must be happening after the whole reset
> >>>>> sequence is done. Doing that earlier would seem like another
> >>>>> solution, but dunno what other fallout it would have.
> >>>> intel_prepare_plane_fb() adds all dma-resv fences for old_obj on
> >>>> intel_crtc_needs_modeset(), does it change anything if we remove that,
> >>>> at least for the GPU reset commit?
> >>> We dropped the ball here a bit, and I'm a bit clueless as to what to
> >>> do. Except we'll need to unify i915 and xe here somehow.
> >>>
> >>> Alternatives:
> >>>
> >>> - Remove the timeout from i915 (the patch at hand), and fix the fallout
> >>>   somehow.
> >>>
> >>> - Add the timeout to xe, and fix the fallout, if any.
> >>>
> >>> - Add the timeout to display parent interface, which is a bit meh.
> >>>
> >>>
> >> The mention in the commit is old_obj needs to be wait for flip_done, I do not believe this
> >> is the case that it was ever used in hardware supported by xe, so for xe the wait can be dropped entirely.
> >>
> >> Is this required for i915 still? In that case you can just eliminate
> >> the wait only for xe.
> > Trouble is, doing things differently basically means using the parent
> > interface no matter what.
> >
> The specific wait mentioned in intel_plane_prepare_plane_fb is only
> used in pre-universal plane overlay support, and in xf86-video-intel
> driver on < gen9. (source:
> intel_skylake_info specifies gen = 0110,
> and sna_wait_for_scanline() returns false for gen >= 0110 on sna.)
> 
> Adding a < GEN9 check would be sufficient, and not driver specific.

How does skipping the wait for the old obj fence help if we're stuck
waiting on the new obj fence?

-- 
Ville Syrjälä
Intel