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@xxxxxxxxxxx/#t
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
