[Intel-gfx] [PATCH i-g-t] igt/kms_rotation_crc : Remove flip tests for sprite plane

[Lofstedt, Marta]

When I have some time I will try to fix the test instead of deleting it.

/Marta 

> -----Original Message-----
> From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> Sent: Tuesday, September 19, 2017 5:30 PM
> To: Tvrtko Ursulin <tvrtko.ursulin at linux.intel.com>
> Cc: Lofstedt, Marta <marta.lofstedt at intel.com>; intel-
> gfx at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH i-g-t] igt/kms_rotation_crc : Remove flip tests
> for sprite plane
> 
> On Tue, Sep 19, 2017 at 02:52:12PM +0100, Tvrtko Ursulin wrote:
> >
> > On 19/09/2017 14:13, Ville Syrjälä wrote:
> > > On Tue, Sep 19, 2017 at 04:01:42PM +0300, Ville Syrjälä wrote:
> > >> On Tue, Sep 19, 2017 at 03:31:21PM +0300, Marta Lofstedt wrote:
> > >>> The kms_rotation_crc at sprite-rotation-*-flip subtests, would need
> > >>> display engine blending to be setup inorder to work in the same
> > >>> manner as the respective tests for the primary plane.
> > >>
> > >> Hmm. I don't see anything really blending related in there. It's
> > >> just using regular old XRGB framebuffers which means blending will
> > >> be off.
> > >
> > > OK. So the actual problem is that the test calls drmModePageFlip()
> > > expecting it to magically do something for the sprite plane.
> > > drmModePageFlip() by definition only operates on the primary plane
> > > of the crtc. So the fix looks correct (ie. get rid of the "flip"
> > > tests for the sprite planes) but the commit message is incorrect.
> > > This also explains why you only had to remove the tests with flip==1
> > > and didn't have to remove the flip==0 tests.
> >
> > Is it possible to flip on the sprite planes? If so would there be
> > value with keeping the tests? Just replacing the flip with some other
> > magic ioctl so those code paths are checked as well.
> 
> Setplane is the "legacy" ioctl to flip planes. In the past that took a totally
> different path through the driver so testing the pageflip ioctl separately
> made a ton of sense. These days both the pageflip and setplane ioctl both
> get converted into an atomic update internally, so from a pure driver code
> perspective they're pretty much identical.
> 
> So I supposse converting it over to setplane would be OKish. That would
> mean ripping out the flip event handling from the code as well.
> 
> >
> > Also, important thing to note is that with 90/270 the test fails
> > before the CRC check with a failure from
> > drm_framebuffer_check_src_coords. Not sure if that is something to
> investigate or another test code failure?
> 
> That is potentially due to not using atomic and having a framebuffer that
> can't accomodate both orientations. So either the plane would have to
> disabled before changing the rotation and re-enabled with the new fb
> afterwards, or the fb would have to be allocated to have
> max(w,h) x max(w,h) dimensions to accomodate both orientations.
> 
> With atomic we can do the rotation change and the fb change at the same
> time, so there is no problematic intermediate state that could exceed the fb
> dimensions.
> 
> --
> Ville Syrjälä
> Intel OTC