[Bug 104931] New: PSR reactivation logic seems a bit dubious

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=104931

            Bug ID: 104931
           Summary: PSR reactivation logic seems a bit dubious
           Product: DRI
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: luto at kernel.org
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org

I'm running Fedora 27 with a gnome-shell Wayland session.  I think I'm using a
software cursor, but I'm not at all confident about that.  I seem to have small
amounts of cursor lag when I move the cursor after a bit of idle time.

On inspection of the code, I see nothing that keeps PSR off for any particular
amount of time or number of vblanks after intel_psr_flush() gets called. 
Adding some tracing confirms that intel_psr_work() can reactivate PSR almost
immediately after intel_psr_flush().  In fact, it seems that PSR gets
reactivated about every 100ms even when the display contents never stop
changing at all.

The attached hackish patch at least improves the trace, and it might be
improving the cursor lag too, but the latter could be the placebo effect. 
Nonetheless, I think the code could be improved.

My patch is a big gross.  I think a better solution would be to use mod_timer()
and/or to track whatever condition, if any, is needed to ensure that the panel
is up to date before reactivating PSR.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180203/e486125c/attachment-0001.html>