[Intel-gfx] [PATCH v2 05/15] drm/atmel-hlcdc: Use per-plane rotation property

Daniel Vetter daniel at ffwll.ch
Thu Aug 11 08:50:03 UTC 2016


On Wed, Aug 10, 2016 at 06:38:39PM +0200, Boris Brezillon wrote:
> On Wed, 10 Aug 2016 16:04:37 +0200
> Daniel Vetter <daniel at ffwll.ch> wrote:
> 
> > On Wed, Aug 10, 2016 at 01:52:45PM +0200, Boris Brezillon wrote:
> > > On Wed, 10 Aug 2016 14:41:52 +0300
> > > Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> > >   
> > > > On Wed, Aug 10, 2016 at 11:25:03AM +0200, Boris Brezillon wrote:  
> > > > > On Wed, 10 Aug 2016 12:09:41 +0300
> > > > > Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> > > > >     
> > > > > > On Wed, Aug 10, 2016 at 10:35:22AM +0200, Boris Brezillon wrote:    
> > > > > > > Hi Ville,
> > > > > > > 
> > > > > > > On Fri, 22 Jul 2016 18:47:01 +0300
> > > > > > > ville.syrjala at linux.intel.com wrote:
> > > > > > >       
> > > > > > > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > > > > > 
> > > > > > > > The global mode_config.rotation_property is going away, switch over to
> > > > > > > > per-plane rotation_property.
> > > > > > > > 
> > > > > > > > v2: Propagate error upwards (Boris)
> > > > > > > > 
> > > > > > > > Cc: Boris Brezillon <boris.brezillon at free-electrons.com>
> > > > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > > > > > ---
> > > > > > > >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 37 +++++++++++++------------
> > > > > > > >  1 file changed, 20 insertions(+), 17 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > > > > > > > index f3350c80704d..ee9bd7a938c3 100644
> > > > > > > > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > > > > > > > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > > > > > > > @@ -883,9 +883,9 @@ static int atmel_hlcdc_plane_atomic_get_property(struct drm_plane *p,
> > > > > > > >  	return 0;
> > > > > > > >  }
> > > > > > > >  
> > > > > > > > -static void atmel_hlcdc_plane_init_properties(struct atmel_hlcdc_plane *plane,
> > > > > > > > -				const struct atmel_hlcdc_layer_desc *desc,
> > > > > > > > -				struct atmel_hlcdc_plane_properties *props)
> > > > > > > > +static int atmel_hlcdc_plane_init_properties(struct atmel_hlcdc_plane *plane,
> > > > > > > > +					     const struct atmel_hlcdc_layer_desc *desc,
> > > > > > > > +					     struct atmel_hlcdc_plane_properties *props)
> > > > > > > >  {
> > > > > > > >  	struct regmap *regmap = plane->layer.hlcdc->regmap;
> > > > > > > >  
> > > > > > > > @@ -902,10 +902,18 @@ static void atmel_hlcdc_plane_init_properties(struct atmel_hlcdc_plane *plane,
> > > > > > > >  				ATMEL_HLCDC_LAYER_GA_MASK);
> > > > > > > >  	}
> > > > > > > >  
> > > > > > > > -	if (desc->layout.xstride && desc->layout.pstride)
> > > > > > > > -		drm_object_attach_property(&plane->base.base,
> > > > > > > > -				plane->base.dev->mode_config.rotation_property,
> > > > > > > > -				BIT(DRM_ROTATE_0));
> > > > > > > > +	if (desc->layout.xstride && desc->layout.pstride) {
> > > > > > > > +		int ret;
> > > > > > > > +
> > > > > > > > +		ret = drm_plane_create_rotation_property(&plane->base,
> > > > > > > > +							 BIT(DRM_ROTATE_0),
> > > > > > > > +							 BIT(DRM_ROTATE_0) |
> > > > > > > > +							 BIT(DRM_ROTATE_90) |
> > > > > > > > +							 BIT(DRM_ROTATE_180) |
> > > > > > > > +							 BIT(DRM_ROTATE_270));
> > > > > > > > +		if (ret)
> > > > > > > > +			return ret;
> > > > > > > > +	}
> > > > > > > >  
> > > > > > > >  	if (desc->layout.csc) {
> > > > > > > >  		/*
> > > > > > > > @@ -925,6 +933,8 @@ static void atmel_hlcdc_plane_init_properties(struct atmel_hlcdc_plane *plane,
> > > > > > > >  			     ATMEL_HLCDC_LAYER_CSC_CFG(&plane->layer, 2),
> > > > > > > >  			     0x40040890);
> > > > > > > >  	}
> > > > > > > > +
> > > > > > > > +	return 0;
> > > > > > > >  }
> > > > > > > >  
> > > > > > > >  static struct drm_plane_helper_funcs atmel_hlcdc_layer_plane_helper_funcs = {
> > > > > > > > @@ -1036,7 +1046,9 @@ atmel_hlcdc_plane_create(struct drm_device *dev,
> > > > > > > >  			     &atmel_hlcdc_layer_plane_helper_funcs);
> > > > > > > >  
> > > > > > > >  	/* Set default property values*/
> > > > > > > > -	atmel_hlcdc_plane_init_properties(plane, desc, props);
> > > > > > > > +	ret = atmel_hlcdc_plane_init_properties(plane, desc, props);
> > > > > > > > +	if (ret)
> > > > > > > > +		return ERR_PTR(ret);      
> > > > > > > 
> > > > > > > Shouldn't we call drm_plane_cleanup() here?      
> > > > > > 
> > > > > > The other error path doesn't call it either, so I figured no really
> > > > > > cares anyway.    
> > > > > 
> > > > > Because the other error path is before plane initialization.    
> > > > 
> > > > There's some stuff being done earlier already, so either that part
> > > > doesn't need cleaning, or the init/cleanup is somehow asymmetric, or
> > > > it's just broken.  
> > > 
> > > devm_ resources are automatically released by the device-model, hence
> > > the absence of devm_kfree(). atmel_hlcdc_layer_cleanup() should be
> > > called if drm_universal_plane_init() fails though.  
> > 
> > Aside: drm objects are independently refcounting, mostly likely using
> > devm_ on the underlying physical device for drm objects is a bug.
> 
> AFAICT it's not buggy: I'm not freeing the plane object in ->destroy()
> (this is done when the underlying device is destroyed), but I release
> other resources.

Well, drm_device is also refcounted, so you can't allocate anything in
there using devm_ on some other hw device. At least not if you really want
hotplug to work. I guess we could switch the refcounting for drm_device to
struct device (instead of our own) and then you could use the devm_
functions on that virtual object. But since no one yet figured out how to
exactly do drm_device hot-unplugging it's all a bit unclear. Unfortunately
udl doesn't support current generation of usb display chips since years,
so there's not really much of a user left :(

Anyway all rather academic with soc gpus, and for driver module unload the
two actions happen in the right order so it's all fine.
-Daniel

> 
> > At least all this stuff looks extremely fishy.
> 
> But that's true, using devm_ here is probably not the best solution.
> 
> I'll try to change that along with the memory leak fixes.

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list