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, 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
signature.asc
Description: PGP signature
