Re: [PATCH 19/37] drm/bridge: samsung-dsim: move drm_bridge_add() call to probe

[Maxime Ripard]

On Thu, Jun 11, 2026 at 10:54:14AM +0200, Luca Ceresoli wrote:
> On Mon Jun 8, 2026 at 1:58 PM CEST, Maxime Ripard wrote:
> > On Tue, May 19, 2026 at 12:37:36PM +0200, Luca Ceresoli wrote:
> >> This bridge driver calls drm_bridge_add() in the DSI host .attach callback
> >> instead of in the probe function.
> >>
> >> This works for current use cases but is problematic for supporting hotplug
> >> of DRM bridges. The problematic case is when this DSI host is always
> >> present while its DSI device is hot-pluggable. In such case with the
> >> current code the DRM card will not be populated until after the DSI device
> >> attaches to the host, which could happen a very long time after booting, or
> >> even not happen at all.
> >>
> >> The reason is that the previous pipeline component (the encoder in this
> >> case) when probing cannot find the samsung-dsim bridge. What happens is:
> >>
> >>  [1 and 2 can happen in any order, same result]
> >>  1) samsung-dsim probes (does not drm_bridge_add() itself)
> >>  2) The lcdif starts probing multiple times, but
> >>     lcdif_probe
> >>     -> lcdif_load
> >>        -> lcdif_attach_bridge
> >>           -> devm_drm_of_get_bridge() returns -EPROBE_DEFER because
> >>              the samsung-dsim is not in the global bridge_list
> >>              (deferred probe pending: imx-lcdif: Cannot connect bridge)
> >>
> >> The samsung-dsim will not drm_bridge_add() itself until a DSI device will
> >> try to mipi_dsi_attach() to the DSI Host, which can happen arbitratily late
> >> on hot-pluggable hardware.
> >>
> >> As a preliminary step to supporting hotplug move drm_bridge_add() at probe
> >> time, so that the samsung-dsim DSI host bridge is available during boot,
> >> even without a connected DSI device. This results in:
> >>
> >>  1) samsung-dsim probes (and adds to drm_bridge_add() itself)
> >>  2) The lcdif starts probing multiple times, but
> >>     lcdif_probe
> >>     -> lcdif_load
> >>        -> lcdif_attach_bridge
> >>           -> devm_drm_of_get_bridge() --> OK, returns samsung-dsim ptr
> >>
> >> Signed-off-by: Luca Ceresoli <luca.ceresoli@xxxxxxxxxxx>
> >
> > We should probably amend
> > https://www.kernel.org/doc/html/latest/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges
> >
> > To mention this use case here
> 
> Right. I haven't updated the docs for this v1 because I was not sure the
> overall approach would be acked. Now Dmitry acked it overall, and I kind of
> infer you are not against, so I'll look into updating the docs in v2.
> 
> However I find that section of the docs a bit hard to read especially from
> a newcomer perspective.

It's a complex problem, so I don't think we should expect the target
audience to be newcomers. But maybe we can indeed improve it.

> A better understanding on my side would help in doing the right change as
> far as this patch is concerned, and as a bonus in improving the section
> overall (that would probably be a separate series).
> 
> So I have a couple questions to start from:
> 
>  * Do I understand correctly that using the component framework is legacy,
>    not recommended for new DRM development, and that converting existing
>    code to stop using it is welcome?

No. It's not legacy or deprecated. And about the conversion, I guess
it's on a case-by-case basis? It's not encouraged or discouraged anyway.

>  * The first bullet quotes "The upstream driver [...] isn’t a MIPI-DSI
>    host". If the upstream driver of a MIPI DSI link isn't a MIPI DSI host,
>    what else could it be? What are the use cases here?

Nowhere is it said that we're considering a MIPI-DSI link here, so the
use case is any bridge that isn't using MIPI-DSI at all.

>  * If read literally, none of the 4 bullets after "Indeed, there’s multiple
>    cases that needs to be considered" covers this driver (it does not use
>    the component framework, it does not use DCS, and the upstream device is
>    a DSI host). However the 3 bullets after "The ideal pattern to cover the
>    last item" appear to cover what this driver does.  Do we need a fifth
>    bullet for drivers like this one? Or...?

You tell me :)

How does hotplugging, say, a MIPI-DSI device bridge controlled over I2C,
or a MIPI-DSI host bridge, affect the probing sequence, and can we end
up in endless probe deferrals?

>  * To me it looks like the "bridge" word in this section is always used to
>    refer to the DSI device. Would it make sense to replace "bridge" ->
>    "[DSI ]device" in this section?

Not necessarily, and from a KMS point of view, MIPI-DSI doesn't exist,
only bridge do.

> (especially as the DSI host is also a DRM bridge)

It doesn't have to be.

Maxime

Attachment: signature.asc
Description: PGP signature