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
