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

[Luca Ceresoli]

On Wed Jun 24, 2026 at 5:28 PM CEST, Maxime Ripard wrote:
> 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,

To me, the section title "Special Care with MIPI-DSI bridges" seems to
suggest that.

What about rewording as "Possible driver combinations and their probe
sequences" or the like?

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

I'll try to write that in a fifth bullet in v2.

Luca

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