Tested-by: Marco Nenciarini <[email protected]>
Tested v3 on a Dell Pro Max 16 (Arrow Lake-P) with a Dell WD19DC dock
(Synaptics VMM5331 MST hub), one monitor on DP and one on HDMI behind
it, i915 driving the dock over TBT-alt, drm.debug=0x10e. Kernel is
Debian 7.2.9 with v3 applied on top.
The only change needed for 7.2.9 was the context of the last hunk in
intel_dp_mst.c, which still uses drm_dp_dpcd_readb(). The new helpers
use drm_dp_dpcd_read_byte(), which exists in 7.2.9, so verify_ctrl()
needed no change.
Results for the points you asked about, 120 s DPMS off with a connector
probe forced on the trunk 30 s into the off period:
1. No "MST mode got reset" message, no MSTM_CTRL mismatch message and
no connector was unregistered. DPMS off wrote MSTM_CTRL as 0x04
and the probe read it back as 04.
2. After the wake, one LINK_ADDRESS was sent and the connectors kept
their names and ids.
3. The wake was normal: link training passed at 810000 x4 on the sink
and both LTTPRs, payloads were allocated and both monitors came
back.
I also probed the two MST connectors while paused (90 s off, probes
at 30 s). Modes and EDID were identical before, during and after
(28 and 32 modes, 256 byte EDID). The first probe (DP-6) took about
5 s: its REMOTE_I2C_READ got a NAK (LINK_FAILURE) after 4 s and the
retry worked. The DP-7 probe took under a second with no NAK. The
probe of the trunk read MSTM_CTRL as 04 again.
Unplug and replug during DPMS off: four runs, one cable at a time
(HDMI and DP, 90 s off, cable moved 4 to 7 s into the off period). In
all four the dock raised a long HPD on the trunk and AUX failed for
about a second, so i915 took the normal disconnect path ("MST device
may have disappeared"): the MSTM_CTRL write failed with -6 and the
three MST connectors were unregistered. One second later MST was
enabled again (0x111 <- 07), LINK_ADDRESS was sent and the topology
was rebuilt with new connectors (DP-5, DP-10, DP-11), so the names
were not kept in these runs. There was no "MST mode got reset"
message. The wake that followed was normal, with link training at
810000 x4 and payloads only for the monitors that were connected.
There was no LINK_ADDRESS after the wake. As I read the code,
set_mst() clears the paused state and nothing paused it again after
the rebuild, so unpause() returned false and no re-probe followed.
The only noise was the usual REMOTE_DPCD_READ NAKs, 4 to 10 per run,
the same as the 4 at boot when the topology is first probed.
So on this dock a sink change while paused did not reach the re-probe
at unpause: the dock raised a long HPD and the disconnect path rebuilt
the topology first. The unpause re-probe was only exercised by the
normal wakes above (one LINK_ADDRESS, no topology change).
The logs are available if you want them.
