On Tue, Oct 28, 2025 at 11:32 AM Tomi Valkeinen <[email protected]> wrote:
> > As the CRTC is no longer online at bridge_pre_enable() > > and gone at brige_post_disable() which maps to the panel > > bridge .prepare()/.unprepare() callbacks, any CRTC that > > enable/disable the DSI transmitter in it's enable/disable > > callbacks will be unable to send any DSI commands in the > > .prepare() and .unprepare() callbacks. > > Well, that wasn't the intention... > > We also have this pre_enable_prev_first hack in the drm_bridge, but I > guess that doesn't help in this case? I don't know what that's for, the panel bridge isn't using it so it doesn't help any panel driver? > More generally speaking, I think the core issue is that we have the DSI > video stream as a dependency for DSI commands. That's right, I think. > It would be better if the > DSI hosts dealt with DSI commands independent of the video stream, in > other words, one could send a DSI command at any time. > > Unfortunately in some cases that might be impossible, if the DSI host > depends on the incoming pixel clock to function... This is the case with the MCDE driver. It even cannot use the existing .enable/.disable callbacks in it's bridge because it really needs to bring the DSI transmission block up at the right time in the initialization sequence. I'm not making it up: I really, really tried hard to just initialized it independently. It just won't, it's too tightly coupled with the DSI video/command stream generator. > In this particular case, if the same driver is dealing with the crtc and > the dsi host, wouldn't it be possible to make the > mipi_dsi_host_ops.transfer() work regardless of the enable/disable status? Sadly no. FWIW I think it is fine to require the DSI panels to only send DSI commands in .enable/.disable and not in .prepare/.unprepare, it's intuitive in a way, if we go for this semantic I can send a doc update after the fixes and try to look over the panel drivers a bit and see if there are more offenders. Yours, Linus Walleij
