[Intel-gfx] [PATCH 3/3] drm/i915/skl: Support for 90/270 rotation

[Daniel Vetter]

On Thu, Mar 05, 2015 at 03:08:17PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 05, 2015 at 01:56:53PM +0100, Daniel Vetter wrote:
> > On Thu, Mar 05, 2015 at 02:51:28PM +0530, Sonika Jindal wrote:
> > > @@ -1519,16 +1550,7 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane)
> > >  		goto out;
> > >  	}
> > >  
> > > -	if (!dev->mode_config.rotation_property)
> > > -		dev->mode_config.rotation_property =
> > > -			drm_mode_create_rotation_property(dev,
> > > -							  BIT(DRM_ROTATE_0) |
> > > -							  BIT(DRM_ROTATE_180));
> > > -
> > > -	if (dev->mode_config.rotation_property)
> > > -		drm_object_attach_property(&intel_plane->base.base,
> > > -					   dev->mode_config.rotation_property,
> > > -					   state->base.rotation);
> > > +	intel_create_rotation_property(dev, intel_plane);
> > 
> > I think back from the original rotation work we've had the leftover task
> > to move this into common code so that we do create the property just once
> > without this check.
> > 
> > I think this should be done now.
> 
> Someone should also make it so we can again have different supported
> rotation bits on different planes. I'll have need for it on CHV I think.

plane->atomic_check just needs to reject them. Tbh I'm not sold on the
value of trying to tell userspace which rotation works and which doesnt -
generic userspace won't learn about y-tiling requirements either so this
feels a bit pointless tbh. And rejecting stuff in atomic_check is what
it's for.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch