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@xxxxxxxxxxxxxxxxxx> > > > > 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@xxxxxxxx> -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
