Am Dienstag, 3. Juli 2018, 14:42:49 CEST schrieb Andrzej Hajda: > On 18.06.2018 12:28, Heiko Stuebner wrote: > > When the panel-driver is build as a module it currently fails hard as the > > panel cannot be probed directly: > > > > dw_mipi_dsi_bind() > > __dw_mipi_dsi_probe() > > creates dsi bus > > creates panel device > > triggers panel module load > > panel not probed (module not loaded or panel probe slow) > > drm_bridge_attach > > fails with -EINVAL due to empty panel_bridge > > > > So emit a -EPROBE_DEFER in that case to give the driver another > > chance at getting the display later. > > Thats odd (at least for me), if the resource (panel in this case) is not > present, bridge should not be attached (drm_bridge_attach should not be > called). Ie __dw_mipi_dsi_probe should rather look for the panel and > defer if not found. Resource gathering is the task of probe. > drm_bridge_attach can be called after probe and it would be difficult > for the caller to react properly for -EPROBE_DEFER error. I think one of the problems comes from the fact that the panel only gets probed (and even the panel-device created) after the dsi host bus gets created in __dw_mipi_dsi_probe. In hindsight, I think this is more of a concurrency issue between the panel probing and calling dsi-attach and the dsi-controller looking for the panel vs. panel-bridge. So when I'm using drm_of_find_panel_or_bridge() as indicator of the panel being, it probably makes things racy. I'll try to find a better solution for the issue. Heiko -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
