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

[Luca Ceresoli]

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.

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?

 * 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?

 * 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...?

 * 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? (especially as the DSI host is also a
   DRM bridge)

Luca

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