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

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

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@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx