On Wed, Jun 24, 2026 at 05:47:10PM +0200, Luca Ceresoli wrote: > On Wed Jun 24, 2026 at 1:41 PM CEST, Maxime Ripard wrote: > > Hi,x > > > > On Fri, Jun 12, 2026 at 02:56:24PM +0200, Luca Ceresoli wrote: > >> On Mon Jun 8, 2026 at 1:40 PM CEST, Maxime Ripard wrote: > >> > On Tue, May 19, 2026 at 12:37:22PM +0200, Luca Ceresoli wrote: > >> >> In preparation to introduce bridge hotplug, split out from > >> >> drm_bridge_connector_init() the code adding the drm_connector into a > >> >> dedicated function. This will be needed to be able to add (and re-add) > >> >> the > >> >> connector from different code paths. > >> > > >> > Same story here, explaining what you need later on that calls for that > >> > change would be nice. > >> > >> Here's a more verbose version: > >> > >> Currently drm_bridge_connector_init() does two things: > >> > >> * allocate and initialize the drm_bridge_connector > >> (which embeds a drm_connector) > >> * initialize and register the embedded drm_connector > >> > >> For bridge hotplug we need to separate these two actions: > >> > >> * the drm_connector needs to be added and removed at any time based on > >> hotplug events > >> * the drm_bridge_connector is designated to create and remove the > >> drm_connector, so it must be persistent for the card lifetime > >> > >> As the lifetimes of drm_bridge_connector and drm_connector become > >> different, we need to create them in different moments. > >> > >> In preparation to support that, split out from > >> drm_bridge_connector_init() the code adding the drm_connector into a > >> dedicated function. No functional changes, just moving code around for > >> now. A future commit will make the drm_connector be created based on > >> hotplug events. > >> > >> Looks good? > > > > The message itself, yes, thanks. > > > > However, I have questions now :) > > > > Do we really expect drm_bridge_connector to stick around when a bridge > > gets unplugged? If so, how does it cope with having, say, an HDMI > > connector, and then swapping out the hotplugged part for an LVDS one? > > Does the HDMI connector sticks around indefinitely? > > In your example, the HDMI drm_connector would be unregistered and put on > hotunplug. Its allocation will stick around until the last put but that's > quite irrelevant. Then, on plugging the LVDS addon, a new LVDS > drm_connector will be created and registered. > > > *Especially* if we're using overlays for this, I'd expect everything > > after the first hotplugged bridge to be destroyed, no? > > As said, it would be unregistered immediately but might be freed later on > if still refcounted. > > This is visible in patches 36+15, the path to follow is: > > drm_bridge_connector_handle_event(event = DRM_BRIDGE_DETACHED) [patch 36] > -> drm_bridge_connector_dynconn_release() [patch 15] > > Does this solve your concern?
Not really, I'm talking about drm_bridge_connector. The fact that bridges are destroyed make sense to me. The fact that drm_bridge_connector sticks around doesn't. It's supposed to be a connector for bridges. If you don't have bridges because they got destroyed, and connector, drm_bridge_connector doesn't have a reason to exist anymore, unless it's drm_bridge_hotplug in a trench coat :) Maxime
signature.asc
Description: PGP signature
