[Intel-gfx] [PATCH] drm/i915: Fix SKL+ 90/270 degree rotated plane coordinate computation

[Ville Syrjälä]

On Tue, Oct 25, 2016 at 10:55:35AM +0100, Chris Wilson wrote:
> On Tue, Oct 25, 2016 at 12:39:43PM +0300, Ville Syrjälä wrote:
> > On Tue, Oct 25, 2016 at 08:20:46AM +0100, Chris Wilson wrote:
> > > On Mon, Oct 24, 2016 at 07:13:04PM +0300, ville.syrjala at linux.intel.com wrote:
> > > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > 
> > > > Pass the framebuffer size in .16 fixed point coordinates to
> > > > drm_rect_rotate() since that's what the source coordinates are as well
> > > > at this stage. We used to do this part of the computation in integer
> > > > coordinates, but that got changed when moving the computation to
> > > > happen in the check phase of the operation. Unfortunately I forgot
> > > > to shift up the fb width and height appropriately.
> > > > 
> > > > With the bogus size we ended up with some negative fb offset, which when
> > > > added to the vma offset caused out scanout to start at an offset earlier
> > > > than we inteded. Eg. when testing on my SKL I saw a row of incorrect
> > > > tiles at the top of my screen.
> > > > 
> > > > Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> > > > Cc: Sivakumar Thulasimani <sivakumar.thulasimani at intel.com>
> > > > Cc: drm-intel-fixes at lists.freedesktop.org
> > > > Fixes: b63a16f6cd89 ("drm/i915: Compute display surface offset in the plane check hook for SKL+")
> > > > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_display.c | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > > > index 5a036999487b..c783f884f85d 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -2985,7 +2985,8 @@ int skl_check_plane_surface(struct intel_plane_state *plane_state)
> > > >  	/* Rotate src coordinates to match rotated GTT view */
> > > >  	if (drm_rotation_90_or_270(rotation))
> > > >  		drm_rect_rotate(&plane_state->base.src,
> > > > -				fb->width, fb->height, DRM_ROTATE_270);
> > > > +				fb->width << 16, fb->height << 16,
> > > > +				DRM_ROTATE_270);
> > > 
> > > Line 2576 (intel_fill_fb_info()) also looks wrong.
> > > 
> > > drm_rect_rotate(&r,
> > > 		rot_info->plane[i].width * tile_width,
> > > 		rot_info->plane[i].height * tile_height,
> > > 		DRM_ROTATE_270);
> > 
> > That should be fine. No sub-pixel stuff going on in that
> > function.
> 
> Ah, yes r is not scaled.
> 
> Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
> 
> drm_plane_subpixel_scale(fb->width) ?
> drm_plane_scale_pixels_to_subpixels(fb->width) ?

I guess we could have something like that. Can't gurarantee it wouldn't
confuse me though. As I replied to Paulo, my brain has a hard time
understanding abstracted fixed point stuff.

> 
> Not sure what terminology you are already using for the plane_state->src
> coordinates.

Me neither. Sometimes I refer to sub-pixel coordinates, sometimes
fractional coordinates, and sometimes perhaps even something else
that I can't recall right now.

-- 
Ville Syrjälä
Intel OTC