Re: [PATCH 15/37] drm/display: bridge-connector: allocate the connector dynamically

[Maxime Ripard]

On Thu, Jun 25, 2026 at 11:32:32AM +0200, Luca Ceresoli wrote:
> On Wed Jun 24, 2026 at 5:34 PM CEST, Luca Ceresoli wrote:
> > Hi Maxime,
> >
> > thanks for the feedback.
> >
> > On Wed Jun 24, 2026 at 1:48 PM CEST, Maxime Ripard wrote:
> >> On Fri, Jun 12, 2026 at 02:44:43PM +0200, Luca Ceresoli wrote:
> >>> On Mon Jun 8, 2026 at 1:46 PM CEST, Maxime Ripard wrote:
> >>> > On Tue, May 19, 2026 at 12:37:32PM +0200, Luca Ceresoli wrote:
> >>> >> Currently the drm_bridge_connector has an embedded drm_connector, so their
> >>> >> allocation lifetimes are tied to each other. This is insufficient to
> >>> >> support DRM bridge hotplugging, which requires the connector to be added
> >>> >> and removed dynamically at runtime multiple times based on hotplug/unplug
> >>> >> events while the drm_bridge_connector is persistent.
> >>> >>
> >>> >> Moreover the drm_connector is exposed to user space and thus an ongoing
> >>> >> operation (e.g. an ioctl) might last for an arbitrarily long time even
> >>> >> after the hardware gets removed. This means a new connector might have to
> >>> >> be added when the previous one is still referenced by user space.
> >>> >>
> >>> >> In preparation to handle hotplug, allocate the drm-connector dynamically,
> >>> >> to allow:
> >>> >>
> >>> >>  * creating and destroying a connector multiple times during a single
> >>> >>    drm_bridge_connector lifetime
> >>> >>  * creating a new connector even though the previous one is still in use
> >>> >>    and thus still refcounted and not yet freed
> >>> >>
> >>> >> This commit does not introduce the actions in the two bullets (it will
> >>> >> happen in a later commit), it only moves to dynamic APIs for connector
> >>> >> allocation and init.
> >>> >>
> >>> >> Signed-off-by: Luca Ceresoli <luca.ceresoli@xxxxxxxxxxx>
> >>> >
> >>> > I think this patch should be split in half, with the switch to using
> >>> > destroy first, and then the actual move to the dynamically allocated
> >>> > connector API.
> >>>
> >>> Is it doable? drm_connector_dynamic_init() mandates a .destroy callback,
> >>> drm_connector_init() forbids it.
> >>
> >> drmm_connector_init forbids it. drm_connector_init mandates it.
> >
> > Something bogus in my reply, sorry. :)
> >
> > So you mean splitting in:
> >
> >  * first patch: move from drmm_connector[_hdmi]_init() to
> >    drm_connector[_hdmi]_init() and add a .destroy
> >  * second patch: move from drm_connector[_hdmi]_init() to
> >    drm_connector[_hdmi]_dynamic_init() +
> >    drm_connector_dynamic_register/unregister()
> 
> Ah, no, there's an annoyance here. drm_connector_hdmi_init() does not
> exist, so it'd have to be created just for the sake of splitting this
> patch, sitting unused after the second patch.
> 
> I don't think it's worth implementing (and maybe deleting) it just for
> that, so I'm leaving this patch as is unless you have counteraguments.

If it's just to ease the transition, you can have two different set of
drm_connector_funcs for HDMI vs !HDMI, one with destroy and the other
using drmm while you rework the init function

Maxime

Attachment: signature.asc
Description: PGP signature