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 <[email protected]> > >>> > > >>> > 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
signature.asc
Description: PGP signature
