MIPI DSI panel bringup in Linaro


I am trying to bring-up a panel which has a lot of register settings in its initialization sequence. I followed the ‘truly’ panel driver for writing my driver. Since it is a Video mode panel, I am setting MIPI_DSI_MODE_VIDEO mode while probing the panel. This is causing the initialization to take a lot of time. It takes around 30 seconds to send around 400 commands to the panel. I figured out that the delay is being caused by the function: dsi_wait4video_eng_busy. This function simply returns if the MIPI_DSI_MODE_VIDEO is not set. But since its set in my case, it takes around 7-8ms for each command write. I tried to bring up the panel by sending init commands without enabling VIDEO mode and later setting the VIDEO mode, I am able to send init commands in short time but the panel does not come up (Only backlight comes). The panel works fine if I enable the VIDEO mode initially. Can you suggest a way to send init commands quickly and get the panel up.


hello Kiranecjc,

You said you are enabling VIDEO mode. Where are you doing this? In dtsi or elsewhere. The question is not clear.

Can you please elaborate?



Thanks for the reply.
I am enabling video mode in the driver probe:


If I dont set VIDEO_MODE in probe(), my probe gets executed quickly, not otherwise.
But if I do not set VIDEO mode, the panel wont come up.

If your panel is a video mode panel you should set mode_flags, as you are doing.

Performing 400 operations, taking 8ms should take 3.2 seconds (also too long), do you have any particular operation that consumes the remaining 27 seconds?

The thing in the code that sticks out is that the timeout for dsi_wait4video_done() is 70ms, which would land you at 28 seconds for those 400 operations. In that case I would recommend that you verify that the panel is properly powered and that your reset sequence is accurate.

But just to clarify, does the panel work after those 30 seconds?


Yes it works after 30 seconds, the display comes up. In dsi_wait4video_eng_busy() it waits for video frame to end before sending each command byte. But since our panel is still not on, there is no video frames actually, which the kernel does not know. We have to either add a check in dsi_wait4video_eng_busy to not wait for video frame during init time or set video mode after sending the commands. The second option did not work though.

It almost sounds like the display controller is in reset, and the initialization commands are all failing and timing out. Have you checked the reset line to your display controller?

Full Disclosure: I am an employee of Qualcomm Canada, any opinions expressed in this or any other post may not reflect the opinions of my employer.

1 Like