Re: [PATCH 05/37] drm/display: bridge-connector: split code creating the connector to a subfunction

[Maxime Ripard]

On Thu, Jul 16, 2026 at 10:37:24AM +0200, Luca Ceresoli wrote:
> >> > Now if the bridges start doing it themselves we should go back to
> >> > those encoder drivers and ditch all the drm_bridge_connector from
> >> > there?
> >> >
> >> > I must be missing something. Can you elaborate on this?
> >>
> >> drm_bridge_connectors bring together a (complete) bridge chain and a
> >> connector. If you don't have either anymore, then we shouldn't keep it
> >> around.
> >>
> >> What I was suggesting before was only a suggestion. I guess we could
> >> also make the encoder own the hotplug handling code and create the
> >> drm_bridge_connector when the chain is complete, and remove it when it's
> >> no longer the case.
> >
> > That's an interesting option. We don't have to keep drm_bridge_connector
> > in its current form, but I don't think we should go back to individual
> > bridge driver creating connectors, especially now that we have bridge
> > chains where the connector ops are implemented collectively by multiple
> > bridges.
> 
> I definitely agree we don't want to add burden back on the encoder.

I don't think Laurent mentioned the encoder anywhere.

> >> We can discuss alternatives too. But either way, we shouldn't have it
> >> stick around.
> 
> Bottom line, I roughly see three ideas mentioned:
> 
>  1. (this series) extend the drm_bridge_connector to create the
>     drm_connector based on bridge hotplug events [+rename it]
>  2. - keep the drm_bridge_connector (mostly) as is
>     - let each encoder driver add/remove it based on bridge hotplug events
>     => more burden on encoder drivers -> no

Can you motivate that with *any* reason? Because I really feel like it's
the best solution going forward.

Maxime

Attachment: signature.asc
Description: PGP signature