[PATCH 1/3] drm: Add callbacks for late registering

Ville Syrjälä ville.syrjala at linux.intel.com
Mon Jun 20 15:54:23 UTC 2016


On Mon, Jun 20, 2016 at 04:30:36PM +0100, Chris Wilson wrote:
> On Mon, Jun 20, 2016 at 05:22:55PM +0200, Benjamin Gaignard wrote:
> > Like what has been done for connectors add callbacks on encoder,
> > crtc and plane to let driver do actions after drm device registration.
> > 
> > Correspondingly, add callbacks called before unregister drm device.
> > 
> > Signed-off-by: Benjamin Gaignard <benjamin.gaignard at linaro.org>
> > ---
> >  drivers/gpu/drm/drm_drv.c | 42 ++++++++++++++++++++++++++
> >  include/drm/drm_crtc.h    | 77 +++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 119 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index c7101c0..b4f7f62 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -666,6 +666,9 @@ EXPORT_SYMBOL(drm_dev_unref);
> >  int drm_dev_register(struct drm_device *dev, unsigned long flags)
> >  {
> >  	int ret;
> > +	struct drm_crtc *crtc;
> > +	struct drm_plane *plane;
> > +	struct drm_encoder *encoder;
> >  
> >  	mutex_lock(&drm_global_mutex);
> >  
> > @@ -690,6 +693,27 @@ int drm_dev_register(struct drm_device *dev, unsigned long flags)
> >  	if (drm_core_check_feature(dev, DRIVER_MODESET))
> >  		drm_connector_register_all(dev);
> 
> Look above for the ouch.
> 
> >  
> > +	drm_for_each_crtc(crtc, dev) {
> > +		if (crtc->funcs->late_register)
> > +			ret = crtc->funcs->late_register(crtc);
> > +		if (ret)
> > +			goto err_minors;
> > +	}
> 
> For the sake of conformity, is it worth adding drm_crtc_register_all()
> et all?
> 
> Then a drm_modeset_register_all ? (i.e.
> if (drm_core_check_feature(dev, DRIVER_MODESET))
> 	drm_modeset_register_all(dev);
> 	  -> { connector, encoder, plane, crtc )
> 
> Also, is the logical order 
> 
> drm_connector_register_all();
> drm_encoder_register_all();
> drm_plane_register_all();
> drm_crtc_register_all();
> 
> or the other way around (basically working from output back to input, or
> input to output)?

input to output would make sense to me. Once the output appears
everything upstream of it would then be in place already.

-- 
Ville Syrjälä
Intel OTC


More information about the dri-devel mailing list