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

[Maarten Lankhorst <maarten.lankhorst@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2189 bytes --]

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.

Kind regards,
~Maarten Lankhorst

[-- Attachment #2: Type: text/html, Size: 3526 bytes --]