Questions over DSI within DRM.

[Andrzej Hajda]

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@samsung.com/#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