Quoting Andy Lutomirski (2018-02-09 17:55:38)
> On Fri, Feb 9, 2018 at 7:39 AM, Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> wrote:
> > Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> writes:
> > So, I move the hacked scheduled to 10s and forced psr_activate 10ms
> > after that and the result is this:
> >
> >
> > [ 11.757909] [drm:intel_psr_enable [i915]] *ERROR* I915-DEBUG:
> > Scheduling 10s
> > [ 11.778586] [drm:intel_psr_flush [i915]] *ERROR* I915-DEBUG: Work busy!
> > ...
> > a bunch more of Work busy
> > ...
> > [ 21.980643] [drm:intel_psr_flush [i915]] *ERROR* I915-DEBUG: Work busy!
>
> This like ("Work busy!") is intel_psr_flush() noticing that
> work_busy() returns true (which it does indeed do when the work is
> scheduled for the future). But this means that intel_psr_flush()
> wants to keep PSR off for a little bit (10s with your patch applied)
> because the screen isn't idle.
>
> > [ 21.983060] [drm:intel_psr_work [i915]] *ERROR* I915-DEBUG: Work running
>
> And here's intel_psr_work() turning PSR back on 3ms later.
>
> So I think you're seeing exactly the bug I described.
It's also evident in the tests that PSR isn't being disabled as
often/quick as we need for frontbuffer updates to be seen.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
