[Intel-gfx] [PATCH] drm/i915: Wait for vblank after register read
Dhinakaran Pandiyan
dhinakaran.pandiyan at intel.com
Fri Apr 20 20:56:21 UTC 2018
On Fri, 2018-04-20 at 11:15 -0700, Rodrigo Vivi wrote:
> On Thu, Apr 19, 2018 at 10:03:05AM +0300, Mika Kahola wrote:
> > On Thu, 2018-04-19 at 09:11 +0300, Lofstedt, Marta wrote:
> > > For the PW results:
> > > https://patchwork.freedesktop.org/series/41877/
> > >
> > > it didn't fix the CRC mismatch on:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8731/shard-
> > > snb6/igt at kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html
> > This was expected that removing one vblank doesn't fix have an effect
> > on crc mismatches. Theres something more in this issue.
> >
> > >
> > > but that test has always failed on SNB:
> > > http://gfx-ci.fi.intel.com/cibuglog/?action_failures_history=-1&failu
> > > res_test=igt at kms_frontbuffer_tracking@fbc-1p-pri-indfb-
> > > multidraw&failures_machine=shard-snb
> > >
> > > so I don't think you brake anything with this patch.
> > >
> > > Mika, do you know if waiting for the extra vblank was done with some
> > > purpose?
> > That I don't know if it was intentional. I'll try to find out why it
> > was needed.
>
> sink CRC calculation starts on the next active frame and takes a full
> frame to finish the calculation. So 2 vblanks before the result is ready.
>
> I don't believe we should move it for after reading it.
>
> But it is a fact that this sink crc was always only a headache.
> If we manage to move PSR tests to use the interrupts and status bits only
> than we will be able to kill this sink crc code entirely....
Yup.
Patch has nothing to do with the bug that it is trying to fix. The test
doesn't read sink-crc's, so I don't think even a References tag is
appropriate here.
More information about the Intel-gfx
mailing list