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.syrj...@linux.intel.com > > > wrote: > > > > From: Ville Syrjälä <ville.syrj...@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.ursu...@intel.com> > > > > Cc: Sivakumar Thulasimani <sivakumar.thulasim...@intel.com> > > > > Cc: drm-intel-fi...@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.syrj...@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 <ch...@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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx