[Intel-gfx] [PATCH igt] igt/kms_frontbuffer_tracking: Wait for PSR to be disabled

Daniel Vetter daniel at ffwll.ch
Tue Mar 6 14:46:42 UTC 2018


On Tue, Feb 20, 2018 at 04:31:40PM +0000, Chris Wilson wrote:
> Quoting Daniel Vetter (2018-02-20 15:44:38)
> > On Tue, Feb 20, 2018 at 02:33:08PM +0000, Chris Wilson wrote:
> > > PSR may not exit instantaneously, so while asserting that PSR is
> > > disabled after an action, we may have to wait a short while. Currently
> > > that wait is waiting for PSR to enabled and expecting to timeout; this
> > > fails when we start the assertion with PSR already enabled. Fix the wait
> > > to wait until PSR is disabled rather than timeout.
> > > 
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > 
> > I guess that's the reply to my question about the earlier
> > kms_frontbuffer_tracking patch?
> 
> Which, the -ENODEV? I thought I explained that was purely to cope with
> the i915_fbc_info API for !HAS_FBC machines, as we are running
> kms_frontbuffer_tracking across farm1 in idle time.
> https://intel-gfx-ci.01.org/tree/drm-tip/kasan2.html

I got confused. In my defense, too much vacations recently :-P

> > Makes a bunch more sense to me.
> 
> There's the question of whether to apply this to
> fbc_wait_until_disabled() as well, but I guess fbc behaves slightly
> differently as we don't see the assert failure there.

Afaiui fbc exit is instantly, psr exit might take some idle frames until
the link is up again (at least for the super deep PSR variants, not so
much for the PSR2 partial uploads magic).

I think this makes sense now to me.

Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list