LTDC in video mode

[FiorixF1]

Hi,
I'm happy to have found this repository, because I'm also writing the configuration code for the LCD display of this board. It is working fine in command mode, but now I'm trying to make it work also in video mode (it seems that in command mode the maximum frame rate is quite low). However I can not find the right timings for the display (I found NOWHERE any datasheet of the equipped display). With some trial-and-error, the best I obtained is a working display with the right side still black and a strange black line on top of the display. Since you have already worked on this driver, do you have any idea on how to make it work properly also in video mode?

[ChuckM]

You want to display video on the display? Note that in my code I have the display hold its last frame and I update it as needed. For video you want to tell the LTDC to auto-trigger the transfer from the LTDC output to the MIPI side. Per the data sheet your resolution is limited to the bandwidth of the MIPI interface.

[FiorixF1]

Yeah I know that you have to set explicitly the bit DSI_WCR_LTDCEN to update the display, and this is what happens in command mode.
There is another mode called "video mode" where the DSI continously sends a stream of pixels, and I'm trying to configure the display this way. The problem is that in command mode, timing values (hsync, vsync, hbp, hfp, vbp, vfp) are not important: you can put whatever you want and it works fine, but in video mode they are very important and you have to set them right to show the frames correctly. This is what I'm trying to do: I don't know which are the correct timing values and I didn't find them yet. For this reason I'm asking which timing values I should insert (or how to calculate them) for 480*800 resolution at 16 bpp and 60 Hz.

[ChuckM]

Ah got it. It is just math.

Starting with 16 bits per pixel that is 2 bytes.
480 * 800 display resolution is 384,000 pixels
384,000 pixels of 2 bytes each is 768,000 bytes. 
60 frames per second, is one frame every 16 mS
768,000 bytes (one frame) in 16 mS is 46.08 Megabytes per second or 460.8 Megabits per second.
The MIPI clock rate (500 MBs) - 460.8 MBs gives you 3.92MBs of "wait time"
16 bits per pixel, means 3.92/16.0 or 245,000 pixel clocks.

Assuming you're running the MIPI bus at 500MBs you would need to delay 245000 pixel clocks betwen "frames" to get an even 60Hz. Or you tell it to wait 245000 clocks between vertical syncs if you're sending all your data each frame starting on the vertical sync.

Does that help?
so to send that in 1/60th of second you have 16 mS to send all the pixels

[ChuckM]

Ah got it. It is just math.

Starting with 16 bits per pixel that is 2 bytes.
480 * 800 display resolution is 384,000 pixels
384,000 pixels of 2 bytes each is 768,000 bytes. 
60 frames per second, is one frame every 16 mS
768,000 bytes (one frame) in 16 mS is 46.08 Megabytes per second or 460.8 Megabits per second.
The MIPI clock rate (500 MBs) - 460.8 MBs gives you 3.92MBs of "wait time"
16 bits per pixel, means 3.92/16.0 or 245,000 pixel clocks.

Assuming you're running the MIPI bus at 500MBs you would need to delay 245000 pixel clocks betwen "frames" to get an even 60Hz. Or you tell it to wait 245000 clocks between vertical syncs if you're sending all your data each frame starting on the vertical sync.

Does that help?

[FiorixF1]

Interesting. So, doing some calculation, basically the timings should be chosen such that
(vsync + vbp + height + vfp)*(hsync + hbp + weight + hbp)*rate = pixel_clock, is this right?

[ChuckM]

Yes sort of. Reading the documentation is seems that in video mode the screen update is triggered by the Vsync pulse, it doesn't have to meet any "timing" parameter exactly, rather when it pulses that is when the display switches to the current frame for its display. The horizontal sync pulses tell the display to start storing on the next line. It looks like you need at least 1 clock of hfp to allow the display to get its address adjusted before the next pixel comes in. Then if you count up the number of pixel clocks between the leading edge of vsyncs, that will be your equivalent refresh rate. I would not be surprised if you also needed a few clocks of vfp to allow the display to switch, and the address counters to reset to the start of the memory buffer.