DLPC3433: Clarifying MIPI DSI input requirements

Hi Lucas,

Please give me some time to look into this and get back to you. 

best,

Maximus

Hi Lucas, 

During Vertical blanking and Vsync we actually recommend being in LP11 mode. Please see the screenshot and document attached below for more information.

Best,

Maximus 

0523.DSI Setup and Debugging Guide v1.0.pdf

What about the sync packets, which require data transmission? My understanding was that LP11 implies the state in which all data wires are driven high, whereas it's also possible to do low-power data transmission (LPDT) by entering escape mode; therefore, it would be possible to send VSYNC and HSYNC packets without entering HS mode on the data lanes.

In our design, we were planning to send all VSYNC and HSYNC packets in HS mode, which would mean periodically entering HS mode on the data lanes even during inactive lines. I'm trying to confirm that that is acceptable for the DLPC3433, since the wording of the LP requirement was a bit ambiguous to me.

Hi Lucas,

This is intended that your Vsync goes high and stays high throughout your vertical blanking. Below is a scope shot of DSI beginning transmission, as you can see the purple data lane goes high for each Vsync and stays high for all of the blanking. 

We do not recommend sending all Vsync and Hsync packets in HS mode, Hsync is okay however Vsync needs to be done in LP11 for best reliability. 

Best,
Maximus

"This is intended that your Vsync goes high and stays high throughout your vertical blanking."

I'm not sure I follow; we have no dedicated vsync wire in this interface, all sync signals are sent as MIPI packets.

"Vsync needs to be done in LP11 for best reliability"

To clarify, are you saying that the vsync start/end packets (MIPI datatypes 0x01 and 0x11, respectively) need to be sent using LPDT? That would be distinct from LP11 (which implies no data being sent at all), and would also be different from the HS signaling otherwise used for data transfer. If we indeed need to use LPDT, it requires different implementation choices for the MIPI DSI host in our design.

Hi Lucas,

The Vsync is sent over the Data pins i.e. DD0n and DD0P as shown in the previous picture I attached. 

As for your second question, your DSI Host should be configured to send the vertical sync and blanking in LP11 mode where all data lines are driven high. This is a requirement from the DLPC3433 and can be seen in our example timings shown below from the document I previously sent. 

This answer does not make sense to me, nor does it answer my core question. MIPI video signaling involves sending data packets that indicate VSYNC and HSYNC events; it's possible to be in LP11 mode between these events, but not during them, because it's not possible to send data on a lane while in the LP11 state. My question is as to whether it's permissible to go into HS mode to send those packets, and I'm unable to glean that detail from the documents and scope traces you've shared (since HS and LPDT are not easily distinguished without zooming in on one of the sync events in question).

If it's in fact the case that _no_ sync event packets should be sent during inactive lines, then I think that would be fairly non-standard for MIPI, and is not communicated in any documentation I've come across (including that which you've linked).

Hi Lucas, 

We will put together a more complete answer to your previous question and get back to you by the end of the week. Thank you for your patience, in the mean time could you help us understand what issues you are facing in setting up the DSI signal to your DLPC? What DSI front end are you using? We also have a TI DLP Pico Hardware Diagnostic Tool which has some DSI debugging functions you can use to help debug DSI from the DLPC side of things if you think that would be helpful to you (link). 

Best,

Maximus

We're actually implementing much of the DSI host logic ourselves in an FPGA, which is why I'm trying to nail down the exact particulars of the traffic that the DLPC expects. We are also still in the process of creating a hardware testbench for all this, so it will be a bit before we're able to prove anything out in hardware, and I'd like to nail down as much as possible before then.

Thanks for linking that diagnostic tool; I was not aware of it, and it may prove helpful.

Hi Lucas,

Thanks for sharing that, it will help us with making sure to provide information needed. I will get back to you soon.

Best,

Maximus