[igt-dev] [PATCH i-g-t] [i-g-t] tests/kms_plane_scaling: modify fb height for yuv planar

[Srinivas, Vidya]

> -----Original Message-----
> From: Maarten Lankhorst [mailto:maarten.lankhorst at linux.intel.com]
> Sent: Wednesday, March 21, 2018 5:08 PM
> To: Srinivas, Vidya <vidya.srinivas at intel.com>; igt-dev at lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kamath at intel.com>; Shankar, Uma
> <uma.shankar at intel.com>
> Subject: Re: [PATCH i-g-t] [i-g-t] tests/kms_plane_scaling: modify fb height
> for yuv planar
> 
> Op 21-03-18 om 06:06 schreef Vidya Srinivas:
> > fb src height to be more than minimum scanlines for planar formats
> > like NV12. Changing the fb height to 19 so that the height is more
> > than min value after KMD adjustments
> >
> > Credits-to: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> > Signed-off-by: Uma Shankar <uma.shankar at intel.com>
> > Signed-off-by: Vidya Srinivas <vidya.srinivas at intel.com>
> > ---
> >  tests/kms_plane_scaling.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/tests/kms_plane_scaling.c b/tests/kms_plane_scaling.c
> > index 36fcfc0..027b42e 100644
> > --- a/tests/kms_plane_scaling.c
> > +++ b/tests/kms_plane_scaling.c
> > @@ -130,9 +130,11 @@ static void check_scaling_pipe_plane_rot(data_t
> *d, igt_plane_t *plane,
> >  	mode = igt_output_get_mode(output);
> >
> >  	/* create buffer in the range of  min and max source side limit.*/
> > -	width = height = 9;
> >  	if (pixel_format == DRM_FORMAT_NV12)
> > -		width = height = 17;
> > +		width = height = 19;
> > +	else
> > +		width = height = 9;
> > +
> >  	igt_create_color_fb(display->drm_fd, width, height,
> >  		       pixel_format, tiling, 0.0, 1.0, 0.0, &d->fb[0]);
> >  	igt_plane_set_fb(plane, &d->fb[0]);
> 
> But in all seriousness, if we create underruns should we simply refuse to
> show NV12 with -EINVAL if it's not correctly aligned?
> 
> I can understand that we don't do it for legacy formats, but don't see why
> we can't do it for NV12. Especially since it's a corner case that
> 
> could be understandable if you know the hw format as well.
> 

True. We could. But the results are inconsistent as per observation currently.
As in: even when the final calculated width and height (just before writing to 
Plane size) is multiplier of 4 (like 28x28), we saw underrun.

But as per your suggestion, when we use 19x19 and add checks for primary plane
and adjustments which were being done for sprite, no underruns are seen.
Can we go ahead with this and KMD changes submitted on trybot? Could you please have a check?
https://patchwork.freedesktop.org/series/38919/ - please check rev 16 of the series.
Thanks much.

Regards
Vidya


> ~Maarten