Re: [PATCH] drm/i915/tc: Disable outputs instead of modesetting them on link reset

[Imre Deak <imre.deak@intel.com>]

On Tue, Jun 09, 2026 at 12:35:48AM +0200, Alexander Kaplan wrote:
> Hi Imre,
>
> [...]
>
> I did the test you asked for. I rebooted latest drm-tip with your
> patch applied and drm.debug=0x15e, and reproduced the problem by
> power-cycling the TV while the output was active.  The full boot log
> up to the wedge is on the first ticket [1], with the reproduction
> steps.

Thanks for the log.

> On PTL this never reaches the -EINVAL / WARN you get on the ADL/MTL
> reports. The recovery modeset computes a valid (degraded) config and
> commits it against the dead link, link training fails, and the pipe is
> re-enabled regardless, leaving the output enabled on a disconnected
> port.  After that the TC PHY ownership stays held,
> intel_tc_port_connected() returns false and AUX is rejected, so the
> reconnect HPD never produces a successful detect.  Keeping the DSC
> caps doesn't help here. The caps we lose are dfp.*/EDID (the PCON FRL
> bandwidth) via intel_dp_unset_edid(), not dsc_dpcd, and the second
> failure mode above is independent of the sink caps anyway.

The actual problem is that userspace does not follow up with a disabling
modeset, as it should after it received a hotplug event and did a
connector probing on the connector where the sink got disconnected. The
connector state is disconnected in this case and userspace must disable
the output accordingly. However it doesn't do this, not sure why. I
provided the corresponding events from the log on [1], the best course
forward would be to find out why userspace (something based on Wayland)
on your host doesn't do disabling modesets.

--Imre

> ...
>
> [1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14807
> 
> Thanks again,
> Alexander