Re: [PATCH 3/3] drm/i915/skl: Support for 90/270 rotation

[Daniel Vetter <daniel@ffwll.ch>]

On Fri, Mar 06, 2015 at 07:22:46PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 06, 2015 at 06:03:31PM +0100, Daniel Vetter wrote:
> > On Thu, Mar 05, 2015 at 05:56:23PM +0200, Ville Syrjälä wrote:
> > > 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.
> > 
> > Well to be able to fix this we need to restrict the value-set of
> > properties per-attachment. Since I very much want core atomic to decodd
> > standardized properties, and if we create rotation per-plane then that's
> > going to be fairly painful.
> 
> AFAICS it should be a simple matter of
> s/config->rotation_property/plane->rotation_property/
> Well, unless you want to go optimize things so that we don't create multiple
> properties with the same supported bitmask.

Hm yeah that'd work too. I guess I've been a bit dense today, time for w/e
;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx