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 <[email protected]> >> > >> > 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
