Running MIPI DSI commands *after* the video transfer starts?

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

I’m using a TX2 (in this case, on a custom carrier) with MIPI DSI panels in ganged mode. It’s working reasonably well right now - I have the panel init commands in the DTS file with the other parameters, and I have a panel driver .c file being used by Linux_for_Tegra/sources/kernel/t18x/drivers/video/tegra/dc/nvdisp/nvdisp_stub.c

However, the panel behavior suggests to me that (at least some of) the DSI commands are not taking effect. One potential problem/theory is that, when I’ve used the panels before in a standalone display, there are DSI init commands that get sent to the panel on reset, then a different set of commands that are sent after the MIPI video stream starts being transmitted.

Based on some added debug printouts, it appears like the startup commands are sent to the panel before video transmission starts, and I can’t find a good hook or way to send DSI commands after the video transmission starts.

Is there some way to send some MIPI DSI commands after video transmission starts (as a part of panel init), either through one of command constants in the DTS file, or through a driver source?

(Mods: Please don’t move this out of the public forum - I am testing this with L4T)

2

Those command sequence we support is listed in

kernel-4.4/Documentation/devicetree/bindings/video/nvidia,tegra210-dsi.txt

3

Yes, I’ve read that document (and the t186 version which I haven’t bothered to diff but might be identical), and I’ve also traced through the code that actually loads those command sequences from device tree as well as the code that sends the command sequences out the DSI interface. What I’ve seen is that in the execution path that is taken in our case, only “nvidia,dsi-init-cmd” is executed on initial startup - other execution paths involving the other command properties are conditional and not executed.

Specifically, here’s the call that actually uses the dsi-init-cmd data parsed from the device tree: nv-tegra.nvidia Code Review - linux-display.git/blob - drivers/video/tegra/dc/dsi.c

It wasn’t clear to me if the tegra_dsi_start_dc_stream() call was being made in our use case, the code was a little hard to follow from configuration to invocation.

Additionally, the dsi->out_ops->postpoweron(dsi) call looks promising, but looking below it, we can see where it’s populated: nv-tegra.nvidia Code Review - linux-display.git/blob - drivers/video/tegra/dc/dsi.c

It’s only non-null if a DSI-to-something bridge is configured. However, only one public driver actually populates the postpoweron function pointer, and it doesn’t do any DSI operations there.

This seems to suggest this is probably a driver limitation, but I don’t see any examples of DSI commands being sent after video start in the source (except the debugfs interface which I couldn’t figure out) so I’m unsure if it’s hardware or software. I’m rather confused, since every modern high-res panel I’ve worked with has these two sets of initialization commands: some that are sequenced after reset is released, and some that occur once the display is receiving video data. (Typically associated with the display-on sleep-out sequence, which in some panels triggers a re-load of the “MTP” panel controller data.) So, I imagine there must be a way to do this.

Does what I’m saying make sense? Is this actually just a driver limitation that I might be able to work around by, for instance, modifying the dsi->out_ops population sequence to add in my own postpoweron code to send another set of DSI commands? Or is this a fundamental hardware limitation, and if so, what is the approach for setting up panels that have such a two-part init sequence?

4

Hi Ryan,
ive also some problems to get the dsi init commands accepted by our display.
i can see them transmitted by the tegra with our scope - but the display dont react…

but perhaps the command TEGRA_DSI_SEND_FRAME

nvidia,dsi-init-cmd =
<TEGRA_DSI_SEND_FRAME 100>,
<TEGRA_DSI_PACKET_CMD DSI_DCS_LONG_WRITE 0x06 0x00 0x00 0xFF 0xFF 0x98 0x06 0x04 0x01 0x00 0x00>,.....

is suitable for you? it should active some dummy video output before sending the init commands.
regards