Thanks for the information, Igor. I suspected that that was the case.
I have a detailed follow-up question for you -- please let me know if you wish to create a separate issue for this:
As I suggested in my original post, I have been able to get the display working in MIPI DSI command mode by writing MIPI DSI packets directly from the ARM platform. However, as I also wrote, this is a bit slow. I have researched the reasons for this slow performance, and they are
derived from the fact that the generic FIFO (accessed by writing MIPI_DSI_GEN_PLD_DATA) has a maximum of 64 bytes. I learned this limit via experimentation. Our 240x432 display (103680 pixels) therefore requires 3240 fills of this FIFO, which, because the MIPI_DSI_CMD_PKT_STATUS register shows that after such a 64-byte fill of the FIFO, it is "full" for about 200 microseconds, means that a full write of the display takes about ¾ of a second. That's a bit slow.
Thus, I wonder if there is a way to improve this performance, by increasing the size of this FIFO, or otherwise. Is this FIFO’s size fixed at 64 bytes?
More generally, I wonder if you know of another method for improving performance of MIPI DSI Asynchronous Mode when writing via the ARM platform. We’ve looked into using the MIPI DBI interface, but the documentation is sparse regarding that module. Is the DBI supported on the i.MX6?
Also, I see references to microcode in the IPU, and I wonder if we can have the capability of altering this to assist with our performance goals, given the discussed parameters.
Thank you.
