[Intel-gfx] [PATCH 08/22] drm/i915: Pass 90/270 vs. 0/180 rotation info for intel_gen4_compute_page_offset()

[Daniel Vetter]

On Wed, Oct 21, 2015 at 02:36:34PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 21, 2015 at 12:53:34PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 14, 2015 at 07:29:00PM +0300, ville.syrjala at linux.intel.com wrote:
> > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > 
> > > The page aligned surface address calculation needs to know which way
> > > things are rotated. The contract now says that the caller must pass the
> > > rotate x/y coordinates, as well as the tile_height aligned stride in
> > > the tile_height direction. This will make it fairly simple to deal with
> > > 90/270 degree rotation on SKL+ where we have to deal with the rotated
> > > view into the GTT.
> > > 
> > > v2: Pass rotation instead of bool even thoughwe only care about 0/180 vs. 90/270
> > > 
> > > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 62 ++++++++++++++++++++++++++++++------
> > >  drivers/gpu/drm/i915/intel_drv.h     |  3 +-
> > >  drivers/gpu/drm/i915/intel_sprite.c  | 15 +++++----
> > >  3 files changed, 64 insertions(+), 16 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > > index 75be66b..bd55d06 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -2451,13 +2451,50 @@ static void intel_unpin_fb_obj(struct drm_framebuffer *fb,
> > >  	i915_gem_object_unpin_from_display_plane(obj, &view);
> > >  }
> > >  
> > > -/* Computes the linear offset to the base tile and adjusts x, y. bytes per pixel
> > > - * is assumed to be a power-of-two. */
> > > +/*
> > > + * Return the tile dimensions in pixel units matching
> > > + * the specified rotation angle.
> > > + */
> > > +static void intel_rotate_tile_dims(unsigned int *tile_width,
> > > +				   unsigned int *tile_height,
> > > +				   unsigned int *pitch,
> > > +				   unsigned int cpp,
> > > +				   unsigned int rotation)
> > 
> > A rotation enum would be nice, so that we can employ sparse to check it.
> > That'd work since sparse treats enums as bitfields, but we'd need to
> > add names for the BIT(DRM_ROTATION_*) variants. Just an aside.
> 
> I was thinking of including the '1<<x' in the define already since the
> current thing just invites bugs all over. I guess making it an enum at
> the same time should be easy.
> 
> > 
> > > +{
> > > +	if (intel_rotation_90_or_270(rotation)) {
> > > +		WARN_ON(*pitch % *tile_height);
> > > +
> > > +		/* pixel units please */
> > > +		*tile_width /= cpp;
> > 
> > Ok, something dawns on me now about tile_width ... it's in bytes, I
> > somehow thought it's pixels. And this function doing a behind-the-scenes
> > conversions from bytes to pixels is a bit tricky.
> > 
> > Should we have separate tile_pitch and tile_width to unconfuse this?
> > Generally foo_width in the modeset code is mostly pixels ...
> 
> Yeah, things are a bit unclear with bytes vs. pixels sometimes. I
> usually think of tile width as bytes because then you don't have to
> consider the pixel format (well, except for Yf/Ys tiling), but here
> we want it in pixels instead.
> 
> I'm not sure tile_pitch is a good name becuse then it might get
> confused with the pitch for the fb or fence. But I don't really have
> a better name in mind either.

Yeah, redefining tile_width to be in pixel would break with existing code.
But silently converting from bytes to pixels is worse, and I don't have
any better idea than tile_width and tile_pitch for these two. We'd need to
update i915_gem_tiling too though for consistency.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch