On Fri, 2026-09-04 at 09:32 -0400, Jake Steinman wrote: > 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.
Is PSR2 working on your setup with this quirk? BR, Jouni Högander > > Jake
