On 2/27/26 09:53, Michele Palazzi wrote:
On 2/23/26 16:27, Leo Li wrote:
Really nice debuging work, thanks for catching this!
Ideally, the cursor event should be delivered when hardware latches
onto the new
cursor info and starts scanning it out. The latching event fires an
interrupt
that should be handled by dm_crtc_high_irq().
dm_pflip_high_irq() handles an interrupt specifically for when
hardware latches
onto a new fb address; I don't think it actually fires when there's a
cursor-only update. I think if we really want to do it right, we can have
another "acrtc_attach->cursor_event" just for cusror-only updates, and
deliver
the event in crtc_high_irq().
In any case, I don't foresee any major issues with delivering the
event early.
And since it fixes an ongoing issue:
Reviewed-by: Leo Li <[email protected]>
Thanks!
Leo
Thanks for the review. Further testing confirms that both this patch and
increasing the dGPU vblank offdelay (from 2 frames to ~50 frames)
independently eliminate the flip timeouts in my testing. Both work by
reducing the frequency of vblank disable/re-enable cycles, basically
either could be an interim fix.
Your deferred vblank enable/disable series https://lore.kernel.org/amd-
gfx/[email protected]/T/#t looks like it could
be the proper solution going forward instead (haven't tested it).
fixed [email protected] cc
