Re: [PATCH 00/32] drm/mipi-dsi: avoid DSI host drivers to have pointers to DSI devices

[Luca Ceresoli <luca.ceresoli@bootlin.com>]

Hi Maxime,

On Mon, 7 Jul 2025 12:13:19 +0200
Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:

...

> > Post scriptum. The very initial issue that led to all this discussion
> > when writing the hotplug-bridge driver is that the samsung-dsim driver
> > will not drm_bridge_add() until a DSI device does .attach to it. Again,
> > see the comments before hotplug_bridge_dsi_attach() in [0] for details.
> > However by re-examining the driver for the N-th time now from a new
> > POV, I _think_ this is not correct and potentially easy to solve. But this leads to one fundamental question:  
> 
> The question is: should a DSI host bridge driver:
> 
>  A) wait for a DSI device to .attach before drm_bridge_add()ing itself,
>     or
>  B) drm_bridge_add() itself unconditionally, and let the DSI device
>     .attach whenever it happens?
> 
> A) is what many drivers (IIRC the majority) does. It implies the card
> will not be populated until .attach, which in the hotplug case could
> happen very late
> 
> B) is done by a few drivers and allows the card to appear in the
> hotplug case without the device, which is needed for hotplug.

I haven't received any reply to this e-mail. Should this be due to the
fuzzyness of what I wrote, you're perfectly understood. :-)

Let me try to start cleaner, and focus only on the question quoted here
above. It is very relevant to the hotplug work, so I'd like any informed
opinions about it in the first place. Many other things depend on it.

The samsung-dsim driver, which is in the hardware I'm working on, falls
in the A) case, and this is problematic.

> I had tried simply moving drm_bridge_add() from .attach to probe in
> the samsung-dsim driver in the pase but that would not work. Now I did
> yet another check at the code and I suspect it can be done with a small
> additional change, but cannot access the hardware to test it currently.

I managed to try today and test on hardware, and I can confirm that the
samsung-dsim driver can be moved from A) to B). In other words the
drm_bridge_add() call to add the samsung-dsim bridge can be moved from
the mipi_dsi_host_ops.attach op to the probe function, but this
requires an additional change, at least when using the imx8mp LCDIF:

@@ -1645,6 +1645,9 @@ static int samsung_dsim_attach(struct drm_bridge *bridge,
 {
        struct samsung_dsim *dsi = bridge_to_dsi(bridge);
 
+       if (!dsi->out_bridge)
+               return -EPROBE_DEFER;
+
        return drm_bridge_attach(encoder, dsi->out_bridge, bridge,
                                 flags);
 }

Without the above change, the mxsfb driver will hard-fail because
mxsfb_attach_bridge() [0] finds the next bridge (the samsung-dsim
bridge, which is now added earlier, in probe) but cannot attach it to
the encoder chain (the samsung-dsim bridge still hasn't got an
out_bridge).

I have a working draft of the above samsung-dsim changes working with
the hotplug-bridge, and it makes the hotplug code one relevant step
simpler.

Your opinion would be appreciated before I proceed to cleaning up and
sending such change.

[0] https://elixir.bootlin.com/linux/v6.16-rc5/source/drivers/gpu/drm/mxsfb/mxsfb_drv.c#L128-L145

Luca

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