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

[Jani Nikula <jani.nikula@intel.com>]

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.

BR,
Jani.


-- 
Jani Nikula, Intel