This thread did not age well. I spent a week chasing a freeze that my own patch created, so please file most of what I wrote above under "learning experience". Here is what holds up.
Short version: PSR2 works here at stock, and Panel Replay works too once one bit is fixed (patch below). PSR2: the SU_STANDBY park was self-inflicted. My fast wake patch (fast wake 12 lines, above the IO buffer wake of 11) stops every selective update after entry. Jouni was right that io >= fast is required. An unpatched CachyOS 7.3-rc4 kernel with xe.enable_psr=2 works fine here: after each update the sink goes 2 -> 3 -> 2 with last SDP 0x29 (SU_VALID), a damage band at y=600..799 gets per-frame selective updates at ~120 and ~24 fps (one Link CRC flag and one SU per update), the sink test CRC is deterministic per image, and 15 s of desktop use gave 291 captures and no resync. The fast wake series is withdrawn in its own thread. Panel Replay: my early "PR freezes in every variant" came from turning PR on through a psr_debug fastset, which never programs PORT_ALPM_CTL, so the sink was never woken. That was my test method, not the driver. Also retracted: "PR is the same failed-wake resync loop". The Link CRC flag does not mean a failed wake: the sink stays in PR active (0x2022 = 0x02 in every poll) and never resyncs. With the DA16260 quirk removed locally and PR entered by a full modeset, PR SU with Early Transport delivers every update: sink test CRC at ~120/s, CRCs identical to PSR2 for the same 125 images. The desktop stutters though. Not a freeze, just a low-framerate feel much like the original quirk reports, while the source flips at a steady 8.33 ms (1434 of 1437 intervals over 12 s). The cause is one bit that source and sink disagree on. The sink supports async video timing in PR (0xb1 = 0x20), so the driver sets PR_ALPM_CTL[AS SDP Transmission in Active Disable] (PR_ALPM_CTL = 0x11) and stops sending the AS SDP in PR Active. Link training still sets FIXED_VTOTAL_AS_SDP_EN_IN_PR_ACTIVE (DPCD 0x107 = 0xc0; bit 7 is MSA_TIMING_PAR_IGNORE_EN, set because I run an EDID override with a 20-120 Hz range). So the sink is promised AS SDPs that never arrive. As far as I can tell nobody had spotted it: Panel Replay on these machines was quirked off before that bit was ever set (38a7e9bf69bd, v7.2), so the combination never ran here. It also means I can't say it explains the original quirk reports, only that today's symptom looks the same. I tested both ways of making them agree, with a local debug switch and a full modeset each time: - keep the AS SDP on (0x01 / 0xc0): smooth, but 0 DC5 entries in 30 s on a static VT (no compositor, 1 update/s) - stop promising it (0x11 / 0x80): smooth (but see the PR entry issue below), 550 DC5 entries in the same test On the KDE desktop neither mode reached DC5, because the compositor keeps vblank interrupts enabled; that is a separate issue. The patch does the second, rebased on drm-tip including the AS SDP skip frames case: https://lore.kernel.org/r/[email protected] What is left on PTL: with the AS SDP off, the sink can come out of a PR enable locked to a bad phase. Here it showed up after the screen blanked on idle and came back (DPMS off/on, so a fresh PR enable): straight from smooth to stuttery, no gradual drift. A manual 1 s AS SDP burst (PR_ALPM_CTL 0x11 -> 0x01 -> 0x11, written live) made it smooth again right away, and it stayed smooth with the AS SDP off again. My guess (not proven) is that without any AS SDP in PR Active the sink picks its refresh phase at entry and never re-aligns. Xe3p_LPD (display version 35, Nova Lake) has a hardware way to keep a periodic AS SDP going: AS SDP skip frames, PR_ALPM_CTL bits 27:16, one AS SDP then N skipped frames. Upstream added it to reach the panel's minimum refresh, and it is behind a debugfs switch for now. It would also cover this case. My manual burst is a hand-rolled version of the same idea, and it worked. I also checked whether PTL has the field: writing 0x0fff0001 and 0x00050001 to PR_ALPM_CTL both read back 0x00000001, so those bits appear not to be implemented on display version 30. So a question for Intel: how would you like PTL handled? A short software AS SDP burst after each PR enable (and optionally now and then while PR is active), keeping the AS SDP on for such sinks (which costs DC5/DC6), or something else? Locally I'm about to test a burst about 2 s after every PR enable. I'm happy to implement and test whichever you prefer. The DA16260 quirk removal will follow once that is settled and tested. One thing I still can't explain: in PSR2 and PR (never in PSR1), the sink sets the Link CRC error bit once per update (DP_PSR_ERROR_STATUS in PSR2, DP_PANEL_REPLAY_ERROR_STATUS in PR). Under PSR2 it latches even with no AUX traffic from me for 10 s. PSR stays enabled, so the driver evidently gets no IRQ_HPD for it, the sink never resyncs, and nothing is visible on screen. Is that expected for this TCON? The gitlab issue has the same summary: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/9119 Thanks Jouni for the patience and the reference trace. Jake
