[PATCH v3 04/13] drm: bridge: Detach bridge from encoder at encoder cleanup time

[Daniel Vetter]

On Tue, Nov 29, 2016 at 08:56:44PM +0200, Laurent Pinchart wrote:
> Hi Archit,
> 
> On Tuesday 29 Nov 2016 16:04:08 Archit Taneja wrote:
> > On 11/29/2016 02:34 PM, Laurent Pinchart wrote:
> > > Most drivers that use bridges forgot to detach them at cleanup time.
> > > Instead of fixing them one by one, detach the bridge in the core
> > > drm_encoder_cleanup() function.
> > > 
> > > Signed-off-by: Laurent Pinchart
> > > <laurent.pinchart+renesas at ideasonboard.com>
> > > ---
> > > 
> > >  drivers/gpu/drm/drm_encoder.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> > > index 5c067719164d..9c1f99646e0d 100644
> > > --- a/drivers/gpu/drm/drm_encoder.c
> > > +++ b/drivers/gpu/drm/drm_encoder.c
> > > @@ -164,6 +164,9 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
> > >  	 * the indices on the drm_encoder after us in the encoder_list.
> > >  	 */
> > > +	if (encoder->bridge)
> > > +		drm_bridge_detach(encoder->bridge);
> > 
> > This would require the kms driver to still detach the remaining
> > n - 1 bridges in a possible chain. We could probably detach all of
> > them here, or maybe leave detaching of all to the kms driver, and just
> > report a warning here.
> 
> I'd prefer detaching them all here, but that's a bit intrusive and should be 
> tested correctly. The patch series is already growing big, could we do that in 
> a separate patch ?

I think you're bridge-for-panels driver is the first one that's actually
getting chained. I guess you do have to fix this here ;-) And if you go
through with making drm_bridge_detach be a purely drm.ko internal thing,
we can make it recursive like all the other functions. Problem solved.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch