On Mon, Jan 20, 2025 at 04:39:24PM +0200, Ville Syrjälä wrote: > On Mon, Jan 20, 2025 at 07:28:52AM +0000, Hogander, Jouni wrote: > > On Sat, 2025-01-18 at 01:07 +0200, Ville Syrjälä wrote: > > > On Fri, Jan 17, 2025 at 10:20:17PM +0200, Ville Syrjälä wrote: > > > > On Thu, Jan 09, 2025 at 09:31:37AM +0200, Jouni Högander wrote: > > > > > Now as we have correct PSR2_MAN_TRK_CTL handling in place we can > > > > > allow DSB > > > > > usage also when PSR is enabled for LunarLake onwards. > > > > > > > > We seem to still lack an answer as to when the PSR wakes, when it > > > > latches the update, and how does all that guarantee that the DSB > > > > interrupt fires after the update has been latched? > > > > > > > > Some thoughts as to how to figure this out: > > > > 1. make sure we're in PSR > > > > 2. sample TIMESTAMP_CTR > > > > 3. start DSB in which > > > > write PLANE_SURF with a new value > > > > send push > > > > wait for vblank > > > > poll PLANE_SURFLIVE == new value > > > > fire interrupt > > > > > > > > in the interrupt handler: > > > > sample TIMESTAMP_CTR again > > > > > > > > And then compare flip timestmap vs. frame timestamp vs. the > > > > manually sampled timestamps. And then repeat without the SURFLIVE > > > > poll to make sure nothing has changed. You'll need to be careful > > > > to make sure it will actually poll for long enough to make a real > > > > difference (if the poll actuall is needed), but tweaking the poll > > > > interval+count suitably. I don't remeber what the max poll > > > > count was, but IIRC it wasn't too high so the duration will have > > > > to get bumped for long polls. > > > > > > > > I guess one could also try to poll for the actual PSR status, > > > > but dunno how well that'll work. > > > > > > > > And we could also try to come up with different ideas on where > > > > to sample timestamps. Unfortunately we only have the single > > > > pipe flip timestamp register so we can only sample one timestamp > > > > from the DSB itself per frame. If we had more we could much more > > > > easily figure things out :/ > > > > > > > > I pushed my latest DSB selftest stuff to > > > > https://github.com/vsyrjala/linux.git dsb_selftests_7 > > > > which has a bunch of stuff for this kind of experimentation. > > > > It's in a somewhat sorry state at the moment since I last used > > > > to hunt for various DSB bugs, but at least it still builds :) > > > > > > > > The way I use that is that I run igt 'testdisplay -o ...' > > > > to make sure nothing else is actively poking the hardware > > > > and then I trigger the DSB tests via debugfs. > > > > > > I poked around a bit, though only on a TGL+PSR1 system (what I had > > > at hand), so some of this might not apply to PSR2 and/or more > > > modern platforms. > > > > > > General notes: > > > - PSR1 exit is triggered by any pipe/plane register write (even the > > > non-arming ones) > > > > This is same for PSR2 as well. > > > > > > > > We basically have three cases to consider here: > > > 1. PSR1 is currently inactive > > > Obviously everything should be with the current code, > > > vblank evasion works, wait for vblank+interrupt scheme > > > for flip completion works > > > > > > 2. PSR1 is active, but DC states are not > > > The wakeup latency here is super quick (it's < 1 scanline, how > > > much below? I've not yet measured), and arming registers do latch > > > nearly immediately. > > Actually it's only ~1usec (based on the timestamps). I also used the > following DSB batch to test how many registers we can write there: > > for (i = 0; ...; i++) > dsb_write(PLANE_SURF, i << 12) > dsb_interrupt() > > and then in the interrupt handler I read PLANE_SURFLIVE, and it always > shows 0xa000, meaning we only have time to write ten registers. So > definitely not enough to guarantee that all arming registers get > written. Oh, and I also checked whether increasing the vblank delay would give us more time here, but unfortunately it does not. So looks like the timing of this "fake vblank" doesn't take that into account :/ > > So, for PSR1 at least I think we'd have two options: > 1) do a manual PSR wake around the whole commit, which doesn't > sound very nice > 2) evade hw_scaline==0 so that we wait until we've woken up > from the DC state, and then proceed with the normal vblank > evasion and arming register writes. And obviously all that > only works in DSB_SKIP_WAITS_EN is disabled. Also if all > the pipes are doing the full update using the DSB then we > could perhaps also remove the explicit DC_OFF dance around > the whole commit. > > > The scanline counter starts counting > > > accordingly > > > from vblank_start-1. However the hardware still considers PSR to be > > > active for that short duration so DSB_SKIP_WAITS_EN _will_ skip the > > > waits. > > > > > > Unfortunately being this quick I'm not convinced we have enough > > > time > > > to write all the registers atomically before the hardware latches > > > something. So I'm thinking we may need to remove DSB_SKIP_WAITS_EN, > > > in which case the vblank evasion will push the arming register > > > writes into the next frame. This will mean the wakeup will take > > > one full frame. > > > > To my understanding DSB_SKIP_WAITS_EN have impact only when in SRD > > (PSR)/DEEP_SLEEP(PSR2). I.e. In this scenario we still do have all > > waits as in commit without PSR. > > The PSR state machine is already in link off mode in this case, > meaning the pipe has been halted, and the display has been > signalled to scan out from its RFB (confirmed by checking the > PSR status register in DPCD), and DSB_SKIP_WAITS_EN is already > active. But the link is still actually up (I'm guessing it might > be transmitting the idle pattern, but I've not confirmed that. > Can't remeber if we even have any kind of status register that > could show this...). So looks like the link only gets actually > turned off by the DMC when entering the DC state. DP_TP_STATUS to the rescue. Monitoring that while in PSR (with DC states still disabled) I see: when active: DP_TP_STATUS: 0x00700000 DP Stream Status: 1 DP Init Status: Active SST when in PSR: DP_TP_STATUS: 0x00000000 DP Stream Status: 0 DP Init Status: Pattern1 when transitioning between the two: DP_TP_STATUS: 0x00200000 DP Stream Status: 0 DP Init Status: Idle SST DP_TP_STATUS: 0x00100000 DP Stream Status: 0 DP Init Status: Pattern3 So looks like it's sort of doing link training always. But since the link doesn't get turned off when DC states aren't enabled the it's just practically immediate. And I now also confirmed that the 5ms wakeup time I was seeing with DC states enabled corresponds to the TP1/TP3 times configured in SRD_CTL. Reducing those also reduces the wakeup time accordingly. -- Ville Syrjälä Intel
