On Fri, 2026-09-04 Jouni Högander wrote:
> I think PSR2 was working on that setup at the point when I introduced
> that quirk
> ...
> Maybe this is actually matter of bisection?
Checked that today with a probe that only polls the sink (0x2006,
0x2008, 0x200a every 200 ms, error bit cleared after each read), so it
runs the same on any kernel:
stock 7.2.2, io/fast 11/11: CRC error re-latched on every poll,
0x2008 = 3 throughout,
0x200a shows SU_VALID in 2 of 94 polls
7.3-rc1, io/fast 11/11: same, SU_VALID in 7 of 90 polls
7.3-rc1, io/fast 11/12: no CRC errors, 0x2008 = 2,
SU_VALID never
So what looks like PSR2 working is the link failing on every wake and
the engine re-entering over and over. Each re-entry does its two entry
captures, those carry SU_VALID, then the engine parks in SU_STANDBY
until the next failed wake resets it. Screen updates come from the
resyncs, not from selective updates. With the wake clean there are no
resyncs and the panel stays on the stale frame.
I doubt bisecting finds anything for PSR2: it was in this state in
April too unless the wake formulas were different then, and
intel_alpm.c has four commits since March, none touching them. Panel
Replay uses the aux-less wake, which does not fail, so it froze
outright from the start. That is the quirk.
Probe script and logs are on 9119.
Jake
