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