Hi,
Thanks Laurent for reviving the thread, I have missed it entirely.
On 03.10.2021 16:16, Laurent Pinchart wrote:
Hello,
Reviving a bit of an old thread.
On Thu, Jul 15, 2021 at 11:50:22AM +0200, Maxime Ripard wrote:
On Tue, Jul 06, 2021 at 05:44:58PM +0100, Dave Stevenson wrote:
On Tue, 6 Jul 2021 at 16:13, Maxime Ripard wrote:
> On a similar theme, some devices want the clock lane in HS mode early > so they can use it in place of an external oscillator, but the data > lanes still in LP-11. There appears to be no way for the > display/bridge to signal this requirement or it be achieved.
You're right. A loooong time ago, the omapdrm driver had an internal infrastructure that didn't use drm_bridge or drm_panel and instead required omapdrm-specific drivers for those components. It used to model the display pipeline in a different way than drm_bridge, with the sync explicitly setting the source state. A DSI sink could thus control its enable sequence, interleaving programming of the sink with control of the source.
Migrating omapdrm to the drm_bridge model took a really large effort, which makes me believe that transitioning the whole subsystem to sink-controlled sources would be close to impossible. We could add DSI-specific operations, or add another enable bridge operation (post_pre_enable ? :-D). Neither would scale, but it may be enough.
I haven't thought it through for all generic cases, but I suspect it's more a pre_pre_enable that is needed to initialise the PHY etc, probably from source to sink.
I believe it could be implemented as a pre-pre-enable indeed. It feels like a bit of a hack, as the next time we need more fine-grained control over the startup sequence, we'll have to add a pre-pre-pre-enable. Given that the startup sequence requirements come from the sink device, it would make sense to let it explicitly control the initialization, instead of driving it from the source. I don't think we'll be able to rework the bridge API in that direction though, so I'm fine with a hack.
As I remember I have suggested in similar discussion [1] adding to mipi_dsi_host_ops requested operations: power_on - power on DSI bus (do we really need it?) init - enter LP11 (or HS-stop state if I remember correctly) and then call them from the right place in DSI device, probably pre_enable callback.
This way we could avoid polluting drm_bridge_ops, with DSI specific stuff.
[1]: https://lore.kernel.org/dri-devel/6700c90f-d0e0-5cbf-1616-0c1d158441b1@samsu...
Sorry for addressing only this issue, but I need to read whole thread, to re-read whole thread, and today it is too late for me :)
Regards Andrzej