Message-ID: <20250122171230.30cf9b97@booty>
Date: Wed, 22 Jan 2025 17:12:30 +0100
From: Luca Ceresoli <luca.ceresoli@...tlin.com>
To: Maxime Ripard <mripard@...nel.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>, Simona Vetter
 <simona@...ll.ch>, Inki Dae <inki.dae@...sung.com>, Jagan Teki
 <jagan@...rulasolutions.com>, Marek Szyprowski <m.szyprowski@...sung.com>,
 Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
 Shawn Guo <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>,
 Pengutronix Kernel Team <kernel@...gutronix.de>, Fabio Estevam
 <festevam@...il.com>, Daniel Thompson <danielt@...nel.org>, Andrzej Hajda
 <andrzej.hajda@...el.com>, Jonathan Corbet <corbet@....net>, Paul
 Kocialkowski <contact@...lk.fr>, Neil Armstrong
 <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>, Laurent
 Pinchart <Laurent.pinchart@...asonboard.com>, Jonas Karlman
 <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>, Maarten
 Lankhorst <maarten.lankhorst@...ux.intel.com>, Thomas Zimmermann
 <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Hervé Codina <herve.codina@...tlin.com>, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>, linux-kernel@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, linux-doc@...r.kernel.org, Paul
 Kocialkowski <paul.kocialkowski@...tlin.com>
Subject: Re: [PATCH v5 04/10] drm/bridge: add documentation of refcounted
 bridges

Hi Maxime,

On Wed, 8 Jan 2025 17:02:04 +0100
Maxime Ripard <mripard@...nel.org> wrote:

[...]

> > > > And we'll also need some flag in drm_bridge to indicate that the device
> > > > is gone, similar to what drm_dev_enter()/drm_dev_exit() provides,
> > > > because now your bridge driver sticks around for much longer than your
> > > > device so the expectation that your device managed resources (clocks,
> > > > registers, etc.) are always going to be around.    
> > 
> > Yes, makes sense too. That should be a drm_bridge_enter/exit(), and
> > drm_bridge.c will need to be sprinkled with them I guess.  
> 
> The users would be the drivers, most likely. There's not much we can do
> at the framework level, unfortunately.

Back to the idea of a "gone" flag, or perhaps an "unplugged" flag to
be consistent with the struct drm_device naming, and
drm_bridge_enter()/drm_bridge_exit(), I did a few experiments and have
a question.

In case:

  a) there is a notification callback to inform about bridges
     being removed, and
  b) all entities owning a struct drm_bridge pointer stop using
     that pointer when notified


With the above, there should be no need for
drm_bridge_enter()/drm_bridge_exit(). Nobody will be using a pointer to
a bridge that is being removed.

Now, about a), patch 1 in this series implements such a mechanism to
inform all bridges when a bridge is being removed. Note that the
"unplugged" flag would be set immediately after the notifier callback
is currently called: "unplugged == true" will never happen before the
callback, and after the callback there will be no pointer at all.

Patch 1 however is only notifying bridges, so other entities (e.g.
encoders) cannot be notified with this implementation. However a
different notification mechanism can be implemented. E.g. until v3 this
series was using a generic struct notifier_block for this goal [0], so
any part of the kernel can be notified.

About b), the notification appears simpler to implement in the various
drivers as it needs to be added in one place per driver. Also adding
drm_bridge_enter()/exit() can be trickier to get right for non-trivial
functions.

Do you see any drawback in using a notification mechanism instead of
drm_bridge_enter()/exit() + unplugged flag?

[0] https://lore.kernel.org/all/20240510-hotplug-drm-bridge-v2-2-ec32f2c66d56@bootlin.com/

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists