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: http://nv-tegra.nvidia.com/gitweb/?p=linux-display.git;a=blob;f=drivers/video/tegra/dc/dsi.c;h=5b07fea74fb5c2665c5b243e0b5d49232e5a4230;hb=l4t/l4t-r28.2#l4222
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: http://nv-tegra.nvidia.com/gitweb/?p=linux-display.git;a=blob;f=drivers/video/tegra/dc/dsi.c;h=5b07fea74fb5c2665c5b243e0b5d49232e5a4230;hb=l4t/l4t-r28.2#l4265
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?