On Tue, 24 Dec 2019 12:31:11 +0100 Sam Ravnborg <sam@xxxxxxxxxxxx> wrote: > 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. I didn't look at Jitao's proposal but it looks like it's addressing a similar issue on the DSI slave/device side: the device probably needs to be powered before the host can interact with it through the DSI+DPHY bus. I'm not entirely sure why we'd need another hook to do that since we already have the ->prepare() one.
