[Intel-gfx] [PATCH i-g-t 1/6] tests/kms_flip: Print timestamps in a consistent form

[Chris Wilson]

On Wed, Jun 22, 2016 at 04:26:01PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 22, 2016 at 02:11:51PM +0100, Chris Wilson wrote:
> > On Wed, Jun 22, 2016 at 04:01:12PM +0300, Ville Syrjälä wrote:
> > > On Wed, Jun 22, 2016 at 01:34:16PM +0100, Chris Wilson wrote:
> > > > On Tue, Jun 21, 2016 at 08:25:27PM +0300, ville.syrjala at linux.intel.com wrote:
> > > > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > 
> > > > Would it be possible for writing timing requirement tests for individual
> > > > updates of planes on the same CRTC? E.g. making sure that legacy cursor
> > > > doesn't block pageflips and vice versa. Also extending that to
> > > > independent updates of primary vs sprite planes?
> > > 
> > > I guess all that should be doable.
> > > 
> > > I was also thinking we should at least have some kind of basic
> > > performance benchmark for atomic ioctls. Eg. do TEST_ONLY ioctls
> > > with different sets of properties and make sure we don't totally
> > > suck.
> > 
> > Would it fit into kms_flip?
> 
> Possibly, but I wouldn't. Maybe if we would try to split up the main
> test function into different functions for different tests instead of
> continuing with the flag galore. But still I'd probably prefer a
> separate test so the the entire thing easier to read.
> 
> > 
> > For starters, I'm going to try and replicate the current cursor bogosity
> > inside ./kms_cursor_legacy. Biggest challenge is defining pass/fail
> > criteria. :|
> 
> What do we need?
> - make sure >1 cursor updates can be performed per frame w/o errors/blocking.
> - issue >1 one cursor updates, followed by a flip that should not error/block
> - issue flip, followed by >1 cursor updates that should not error/block

I've put together an initial sketch to try and load as many cursor
updates before the the pageflip as possible to try and detect if (a) the
cursor updates are then synchronous with each other and (b) if the
pageflip serialises with the cursor updates. That's enough to catch the
current bug (and I think the previous cursor bug).
 
> Maybe crc check at the end to make sure it's really the last submitted
> thing that got latched. And maybe we should change the crc frame counter
> to use the sw counter so we could check that update happens on the frame
> we expected?

In theory, that should be caught by kms_cursor_crc, right? Probably
worth a look to see why we don't have a representative test case in BAT
(or if we do, why it was ineffective).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre