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

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

[Alexander Kaplan]

After a DP-alt sink is disconnected with the link still active,
intel_tc_port_link_reset_work() tries to recover the link via a
modeset, flagging the active CRTCs with connectors_changed in
reset_link_commit(). By that point intel_dp_detect() has already
reset the sink capabilities (EDID, dfp.*, DSC DPCD - see the FIXME in
intel_dp_detect()), so the recovery modeset is computed without them.
Depending on which capabilities the connected mode requires, this
either fails the atomic check with -EINVAL, triggering the WARN in
intel_tc_port_link_reset_work():

  i915 0000:00:02.0: [drm] drm_WARN_ON(ret)
  WARNING: ... at drivers/gpu/drm/i915/display/intel_tc.c:1838
           intel_tc_port_link_reset_work+0x38c/0x420

or commits a configuration the disconnected link can't sustain: link
training fails and the output is left enabled on the disconnected
port. Either way the output stays enabled, keeping the TC PHY
ownership held and the TC mode locked. AUX transfers then get
rejected based on intel_digital_port_connected_locked(), so detecting
a newly connected sink keeps failing as well: the port can't be
recovered without disabling the output by some other means (in
practice a reboot).

Disable the affected outputs instead of modesetting them, matching
how commit c598c335da42 ("drm/i915/tc: Reset TypeC PHYs left enabled
in DP-alt mode after the sink disconnects") handles the equivalent
situation during boot/resume sanitization, for the same reason. The
disable also releases the PHY ownership synchronously - via the
encoder's post-PLL-disable hook - avoiding the IOM/TCSS firmware
timeout the above commit worked around, and unblocking the HPD status
updates of other TypeC ports. The output gets re-enabled via the
normal hotplug flow once a sink is connected again.

Preserving the sink capabilities across the disconnect instead (the
direction proposed for the DSC caps in the gitlab reports below)
would avoid the -EINVAL, but not the second failure mode: the
recovery modeset would still be committed against a dead link,
leaving the enabled output behind after a failed link training.
Disabling the output covers both.

Observed on PTL with a DP-alt -> HDMI 2.1 PCON adapter on a TV power
cycle (both failure modes above); reports with the matching WARN on
ADL and MTL in the links below.

Fixes: c598c335da42 ("drm/i915/tc: Reset TypeC PHYs left enabled in DP-alt mode after the sink disconnects")
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14807
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11551
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de>
---
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c b/drivers/gpu/drm/i915/display/intel_tc.c
index a21dd4e3fe4c..ae9da59ca8e3 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -5,6 +5,7 @@

 #include <linux/iopoll.h>

+#include <drm/drm_atomic_uapi.h>
 #include <drm/drm_print.h>

 #include "intel_atomic.h"
@@ -1764,9 +1765,13 @@ static int reset_link_commit(struct intel_tc_port *tc,
 	struct intel_display *display = to_intel_display(tc->dig_port);
 	struct intel_digital_port *dig_port = tc->dig_port;
 	struct intel_dp *intel_dp = enc_to_intel_dp(&dig_port->base);
+	struct drm_connector_state *conn_state;
+	struct drm_connector *connector;
+	struct drm_plane_state *plane_state;
+	struct drm_plane *plane;
 	struct intel_crtc *crtc;
 	u8 pipe_mask;
-	int ret;
+	int i, ret;

 	ret = drm_modeset_lock(&display->drm->mode_config.connection_mutex, ctx);
 	if (ret)
@@ -1779,6 +1784,13 @@ static int reset_link_commit(struct intel_tc_port *tc,
 	if (!pipe_mask)
 		return 0;

+	/*
+	 * The sink is gone, so intel_dp_detect() has already reset the sink
+	 * capabilities, and recomputing the config for the still active mode
+	 * would fail (see the FIXME in intel_dp_detect()). Disable the
+	 * outputs instead; the next sink connect re-enables them via the
+	 * normal hotplug flow.
+	 */
 	for_each_intel_crtc_in_pipe_mask(display, crtc, pipe_mask) {
 		struct intel_crtc_state *crtc_state;

@@ -1786,7 +1798,33 @@ static int reset_link_commit(struct intel_tc_port *tc,
 		if (IS_ERR(crtc_state))
 			return PTR_ERR(crtc_state);

-		crtc_state->uapi.connectors_changed = true;
+		crtc_state->uapi.active = false;
+
+		ret = drm_atomic_set_mode_prop_for_crtc(&crtc_state->uapi, NULL);
+		if (ret)
+			return ret;
+
+		ret = drm_atomic_add_affected_planes(&state->base, &crtc->base);
+		if (ret)
+			return ret;
+
+		ret = drm_atomic_add_affected_connectors(&state->base, &crtc->base);
+		if (ret)
+			return ret;
+	}
+
+	for_each_new_connector_in_state(&state->base, connector, conn_state, i) {
+		ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
+		if (ret)
+			return ret;
+	}
+
+	for_each_new_plane_in_state(&state->base, plane, plane_state, i) {
+		ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
+		if (ret)
+			return ret;
+
+		drm_atomic_set_fb_for_plane(plane_state, NULL);
 	}

 	if (!__intel_tc_port_link_needs_reset(tc))

✗ LGCI.VerificationFailed: failure for drm/i915/tc: Disable outputs instead of modesetting them on link reset

[Patchwork]

== Series Details ==

Series: drm/i915/tc: Disable outputs instead of modesetting them on link reset
URL   : https://patchwork.freedesktop.org/series/167984/
State : failure

== Summary ==

Address 'alexander.kaplan@sms-medipool.de' is not on the allowlist, which prevents CI from being triggered for this patch.
If you want Intel GFX CI to accept this address, please contact the script maintainers at i915-ci-infra@lists.freedesktop.org.
Exception occurred during validation, bailing out!
Build URL: http://gfx-ci.igk.intel.com:8080/job/CI_PW_kernel/178853/ (on built-in)

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

[Imre Deak]

On Fri, Jun 05, 2026 at 11:28:37PM +0200, Alexander Kaplan wrote:
> After a DP-alt sink is disconnected with the link still active,
> intel_tc_port_link_reset_work() tries to recover the link via a
> modeset, flagging the active CRTCs with connectors_changed in
> reset_link_commit(). By that point intel_dp_detect() has already
> reset the sink capabilities (EDID, dfp.*, DSC DPCD - see the FIXME in
> intel_dp_detect()), so the recovery modeset is computed without them.
> Depending on which capabilities the connected mode requires, this
> either fails the atomic check with -EINVAL, triggering the WARN in
> intel_tc_port_link_reset_work():
> 
>   i915 0000:00:02.0: [drm] drm_WARN_ON(ret)
>   WARNING: ... at drivers/gpu/drm/i915/display/intel_tc.c:1838
>            intel_tc_port_link_reset_work+0x38c/0x420
> 
> or commits a configuration the disconnected link can't sustain: link
> training fails and the output is left enabled on the disconnected
> port. Either way the output stays enabled, keeping the TC PHY
> ownership held and the TC mode locked. AUX transfers then get
> rejected based on intel_digital_port_connected_locked(), so detecting
> a newly connected sink keeps failing as well: the port can't be
> recovered without disabling the output by some other means (in
> practice a reboot).
> 
> Disable the affected outputs instead of modesetting them, matching
> how commit c598c335da42 ("drm/i915/tc: Reset TypeC PHYs left enabled
> in DP-alt mode after the sink disconnects") handles the equivalent
> situation during boot/resume sanitization, for the same reason. The
> disable also releases the PHY ownership synchronously - via the
> encoder's post-PLL-disable hook - avoiding the IOM/TCSS firmware
> timeout the above commit worked around, and unblocking the HPD status
> updates of other TypeC ports. The output gets re-enabled via the
> normal hotplug flow once a sink is connected again.
> 
> Preserving the sink capabilities across the disconnect instead (the
> direction proposed for the DSC caps in the gitlab reports below)
> would avoid the -EINVAL, but not the second failure mode: the
> recovery modeset would still be committed against a dead link,
> leaving the enabled output behind after a failed link training.
> Disabling the output covers both.
> 
> Observed on PTL with a DP-alt -> HDMI 2.1 PCON adapter on a TV power
> cycle (both failure modes above); reports with the matching WARN on
> ADL and MTL in the links below.

The driver cannot disable an output that userspace has enabled. The TC
port reset above should also result in a hotplug notification, which
userspace should handle reconfiguring and re-enabling the output as
needed. Could you please provide a dmesg log on the first Link: ticket
below with the rebased

https://gitlab.freedesktop.org/-/project/4519/uploads/326fe332d4e847b29c1f38907be171df/0001-drm-i915-dp-Fix-resetting-DSC-capability-during-dete.patch

applied on the lastest drm-tip kernel, booting with drm.debug=0x15e and
reproducing the problem you still observe (also mentioning the
reproducation steps)?

Thanks.

> Fixes: c598c335da42 ("drm/i915/tc: Reset TypeC PHYs left enabled in DP-alt mode after the sink disconnects")
> Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14807
> Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11551
> Cc: Imre Deak <imre.deak@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de>
> ---
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c b/drivers/gpu/drm/i915/display/intel_tc.c
> index a21dd4e3fe4c..ae9da59ca8e3 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -5,6 +5,7 @@
> 
>  #include <linux/iopoll.h>
> 
> +#include <drm/drm_atomic_uapi.h>
>  #include <drm/drm_print.h>
> 
>  #include "intel_atomic.h"
> @@ -1764,9 +1765,13 @@ static int reset_link_commit(struct intel_tc_port *tc,
>  	struct intel_display *display = to_intel_display(tc->dig_port);
>  	struct intel_digital_port *dig_port = tc->dig_port;
>  	struct intel_dp *intel_dp = enc_to_intel_dp(&dig_port->base);
> +	struct drm_connector_state *conn_state;
> +	struct drm_connector *connector;
> +	struct drm_plane_state *plane_state;
> +	struct drm_plane *plane;
>  	struct intel_crtc *crtc;
>  	u8 pipe_mask;
> -	int ret;
> +	int i, ret;
> 
>  	ret = drm_modeset_lock(&display->drm->mode_config.connection_mutex, ctx);
>  	if (ret)
> @@ -1779,6 +1784,13 @@ static int reset_link_commit(struct intel_tc_port *tc,
>  	if (!pipe_mask)
>  		return 0;
> 
> +	/*
> +	 * The sink is gone, so intel_dp_detect() has already reset the sink
> +	 * capabilities, and recomputing the config for the still active mode
> +	 * would fail (see the FIXME in intel_dp_detect()). Disable the
> +	 * outputs instead; the next sink connect re-enables them via the
> +	 * normal hotplug flow.
> +	 */
>  	for_each_intel_crtc_in_pipe_mask(display, crtc, pipe_mask) {
>  		struct intel_crtc_state *crtc_state;
> 
> @@ -1786,7 +1798,33 @@ static int reset_link_commit(struct intel_tc_port *tc,
>  		if (IS_ERR(crtc_state))
>  			return PTR_ERR(crtc_state);
> 
> -		crtc_state->uapi.connectors_changed = true;
> +		crtc_state->uapi.active = false;
> +
> +		ret = drm_atomic_set_mode_prop_for_crtc(&crtc_state->uapi, NULL);
> +		if (ret)
> +			return ret;
> +
> +		ret = drm_atomic_add_affected_planes(&state->base, &crtc->base);
> +		if (ret)
> +			return ret;
> +
> +		ret = drm_atomic_add_affected_connectors(&state->base, &crtc->base);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	for_each_new_connector_in_state(&state->base, connector, conn_state, i) {
> +		ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	for_each_new_plane_in_state(&state->base, plane, plane_state, i) {
> +		ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
> +		if (ret)
> +			return ret;
> +
> +		drm_atomic_set_fb_for_plane(plane_state, NULL);
>  	}
> 
>  	if (!__intel_tc_port_link_needs_reset(tc))
> 

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

[Alexander Kaplan]

Hi Imre,

first of all, thanks a lot for taking the time to look into this.
I really appreciate it.
This isn't really a niche case, just an early one.
I'm one of the first with Panther Lake, and setups like this will be
common once these machines are out there.

I'm afraid your patch is for a different issue, though.
For some background: this is Panther Lake (NUC 16 Pro) driving an LG OLED
TV through Synaptics VMM7100 based USB-C to HDMI 2.1 PCON adapters.
I have two such dongles and a TB4 dock here, all VMM7100 based, and all
three needed a series of fixes to work at all on this machine (DSC, FRL,
link training quirks).
This wedge is just the nastiest one, because almost every sink disconnect
on these adapters loses the signal until a reboot.
A few more fixes for the same path are on their way.

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.

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.

Same trigger, your patch vs. this one:

  with your patch (wedge):
  link_reset_work: TypeC DP-alt sink disconnected, resetting link
      connectors_changed=1
      disabling pipe A
      [DPRX] Link Training failed at link rate = 810000, lane count = 2
      enabling pipe A
  TV back on:
      DP-1 hotplug event (retry 0..5), detect never succeeds, wedged

  with this patch (recovers):
  link_reset_work: TypeC DP-alt sink disconnected, resetting link
      disabling pipe A
      TC port mode reset (dp-alt -> disconnected), PHY released
  TV back on:
      DP-1 status disconnected -> connected, detect works
      enabling pipe A, output back, no reboot

> The driver cannot disable an output that userspace has enabled. The TC
> port reset above should also result in a hotplug notification, which
> userspace should handle reconfiguring and re-enabling the output as
> needed.

I'd argue that's effectively what this ends up doing.
reset_link_commit() already re-drives the output today (the
connectors_changed modeset above), it isn't only a notification, and that
re-commit is what leaves the zombie behind.
Disabling instead releases the PHY, and as the second snippet shows, the
reconnect HPD then leads to a normal detect and userspace re-enables the
output the usual way.
With the re-commit the zombie keeps connected() false and every detect
fails, so userspace never gets the chance.

That said, if disabling from the reset work is the wrong layer for you,
I'm happy to rework it.
For example not re-enabling the pipe when link training fails in this
path, or whichever direction you prefer.
Just let me know.

Also, the patch you have here isn't quite current anymore.
I've since extended the same approach to also cover the TB4 dock (the
tbt-alt case), so I'd like to send a v2 that's almost identical plus that
small follow-up once we've settled the direction.

One side note: the original submission didn't get CI coverage, my address
isn't on the allowlist yet. I've asked i915-ci-infra@ to add it.

[1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14807

Thanks again,
Alexander

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

[Imre Deak]

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

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

[Alexander Kaplan]

Hi Imre,

You're right, sorry for the noise.
The fix doesn't belong in the kernel here.

I turned on KWin's DRM debug logging and reproduced again on latest drm-tip with your DSC cap patch.
KWin does react to the disconnect, it just never emits the disabling modeset, because DP-1 is its only output:

  [kernel] 19:57:15.58  [CONNECTOR:512:DP-1] status updated from connected to disconnected
  [kernel] 19:57:15.58  [CONNECTOR:512:DP-1] generating connector hotplug event
  [kwin]   19:57:15     Received change event for monitored drm device "/dev/dri/card0"
  [kwin]   19:57:15     Removing output KWin::DrmOutput(...)
           -> no atomic commit from user space, CRTC pipe A stays active
  [kernel] 19:57:17.63  intel_tc_port_link_reset_work Port D/TC#1: TypeC DP-alt sink disconnected, resetting link
  [kernel] 19:57:18.13  [CONNECTOR:512:DP-1] Link Training failed at link rate = 810000, lane count = 2
  [kernel] 19:57:18.32  intel_enable_transcoder enabling pipe A   <- re-enabled on the dead link
  [kernel] 19:57:36+    DP-1 hotplug retry 0..5 -> detect never succeeds -> wedged

So KWin tears down its output object on the hotplug, but for the last output it drops it internally without committing a CRTC off, so the pipe is never disabled.
About 2 s later the TC link reset worker re-enables that still active pipe on the dead link.
Had the CRTC been disabled, the pipe and its TC link ref would be gone before the worker runs, which I think avoids the wedge.
So this one is mine to fix in user space.
I'll check whether current KWin already handles last output removal differently, and otherwise write the fix there.
Thanks for pushing back.

The full boot log up to the wedge and the KWin log are on the ticket [1].

On a separate note, I have a few other small display fixes for this same hardware (Synaptics VMM7100 PCON on Panther Lake), still blocked from submitting by the CI allowlist.
If you have the bandwidth I'd welcome a quick gut check, otherwise I'll post them properly once I'm allowlisted:

  - a DP quirk so the PCON doesn't get stuck at 2 lanes / 6 bpc after a failed RBR link training handshake
  - FRL deep color plus preferring DSC over a 6 bpc uncompressed output, which gets 4K@120 RGB 12 bpc working
  - reading the PCON max FRL bandwidth only for HDMI DFPs in the DP core, it is read unconditionally today
  - a drm_dp_cec fix so CEC tunneling works on these dongles, they do support CEC and it is fully functional to my TV

No worries if you don't have time.
The allowlist route is fine too.

[1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14807

Thanks,
Alexander

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

[Jani Nikula]

On Tue, 09 Jun 2026, Alexander Kaplan <alexander.kaplan@sms-medipool.de> wrote:
> If you have the bandwidth I'd welcome a quick gut check, otherwise
> I'll post them properly once I'm allowlisted:

If you're referring to [1], please just send the patches. We can let the
individual patches through CI.

BR,
Jani.


[1] https://lore.kernel.org/r/178069746256.49942.4174969817609921951@6beec6c84f66


-- 
Jani Nikula, Intel

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

[Alexander Kaplan]

On Wed, 10 Jun 2026, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> If you're referring to [1], please just send the patches. We can let the
> individual patches through CI.

Hi Jani,

thanks for the offer :-)

[1] is solved in the meantime and it turned out not to be a kernel bug
at all, my patch was aiming at the wrong layer.
Imre was right from the beginning and pointed me in the right
direction.
The real bug is in KWin: on a sink disconnect it keeps the output
enabled and never commits the disable, which is what left the TC PHY
wedged (the no-signal state with all the VMM7100 dongles and the TB4
dock).
I have a KWin fix running here that I can confirm resolves the issue
entirely, verified across all the scenarios that used to trigger the
wedge, and I will submit it as a merge request to KWin.
So please consider [1] withdrawn.

The patches you meant are now on the lists:

[2] drm/i915/dp: Fix FRL rate selection and deep color for HDMI sinks
    behind FRL PCONs
    https://lore.kernel.org/r/20260610174413.5881-1-alexander.kaplan@sms-medipool.de
[3] drm/dp: Avoid RBR on Synaptics VMM7100 PCONs failing channel EQ
    https://lore.kernel.org/r/20260610174807.6231-1-alexander.kaplan@sms-medipool.de
[4] drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs
    https://lore.kernel.org/r/20260610174819.6258-1-alexander.kaplan@sms-medipool.de
[5] drm/dp: Service the CEC tunneling IRQ flags without CEC_IRQ in ESI1
    https://lore.kernel.org/r/20260610174833.6284-1-alexander.kaplan@sms-medipool.de

There is also an unrelated ALSA fix from the same machine:

[6] ALSA: hda/hdmi: disable KAE for Intel Panther Lake
    https://lore.kernel.org/r/20260610174834.6301-1-alexander.kaplan@sms-medipool.de

If something in there is not correct to spec, I am glad about a
pointer in the right direction.
Which ones you let through CI I leave to you.

Thanks a lot!

Alexander

[1] https://lore.kernel.org/r/20260605212837.4265-1-alexander.kaplan@sms-medipool.de