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

[Ville Syrjälä]

On Thu, Mar 05, 2015 at 04:29:30PM +0100, Daniel Vetter wrote:
> 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.

By that logic we shouldn't expose pixel formats or any other useful
infromation either then.

-- 
Ville Syrjälä
Intel OTC