Hi Boris.
> Just a reminder of my 2 proposals:
>
> 1/ implement the bridge_ops->pre_enable/post_disable() hooks so you can
> split your enable/disable logic in 2 parts and make sure things are
> ready when the panel/next bridge tries to send DSI commands
> 2/ move everything that's needed to send DSI commands out of the
> ->enable() path (maybe in runtime PM resume/suspend hooks) so you
> can call that in the DSI transfer path too
>
> As pointed out by Laurent, #1 doesn't work because some panel drivers
> send DSI commands in their ->prepare() hook, and ->pre_enable() methods
> are called in reverse order, meaning that the DRM panel bridge driver
> would try to issue DSI commands before the DSI host controllers is ready
> to send them. I still thing #2 is a good option.
Jitao Shi suggested to extend panels so we had a sequence of:
prepare_power() <= new callback,
here one should NOT be allowed to send
DSI commands
prepare()
enable()
#
# panel is now ready to show your favourite christmas movie
#
disable()
unprepare()
unprepare_power() <= new callback
Would this help implement what you suggest above?
Relevant panels would then have to be updated - but this
is doable.
Sam
