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@xxxxxxxxxxxxxxxx> > > > --- > > > > > > 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
