I would like to use the IPU "DS3" data stream

[sidebranch]

Hello,

On i.MX53, I would like to use the IPU "DS3" data stream, which is directly from framebuffer memory to display for 32-bit generic data. It bypasses the DP (display port).

Is there any documentation on this, an app note, or Linux driver, or test code?

The Reference Manual barely touches this topic.

Regards,

Leon Woestenberg

[Philip_FSL]

I think I see the source of some of the confusion.  The 32-bit generic data mode mentioned in connection with JPEG data is for the CSI (sensor interface).  The registers and buses inside the IPU are 32-bits wide.  However the external parallel bus to the synchronous display is only 24bits wide.  The "Interface" subsection of section 45.3.1.2 Display Ports on page 2636 is probably the best source of information about the possibilities for data formats and signal interfaces from the IPU to an external display.  There is also the asynchronous 32-bit access display support.  I don't know if this is what you are considering when mentioning Intel/Motorola bus reads and writes.  However this is quite a different interface.

[sidebranch]

Philip,

thank you. The reference manual mentions that there is a generic 32 bit data mode (also some defined for this format are in the Linux fb drivers. The reference manual mentions this could be used for JPEG data or any other data if an external accelerator is attached to the IPU display interface. Also, the IPU display interface is capable of performing Intel or Motorola style bus reads and writes. These two topics (generic data and read/writes) are very sparsely mentioned without explanation, but they could be useful for many applications.

The bus would be used with command cycles and data cycles.

Philip Hatcher said:

DS3 is used for the second display in Linux.  Since the DP can only be connected to a single DI, the second DI is driven by data directly read from memory via the iDMAC.  The same limitation still applies in that the DI has a maximum 24-bit data bus.  So, 32bpp pixel data cannot be transferred in a single pixel clock cycle.

[Philip_FSL]

DS3 is used for the second display in Linux.  Since the DP can only be connected to a single DI, the second DI is driven by data directly read from memory via the iDMAC.  The same limitation still applies in that the DI has a maximum 24-bit data bus.  So, 32bpp pixel data cannot be transferred in a single pixel clock cycle.

[sidebranch]

Run the IPU in 16-bit 565 mode but use a double wide screen stride, thus allowing for 32-bit RGBA. It halves the pixel refresh rate and has issues with the internal layer compositing. An external device should merge the pixel components back into a single pixel if you require one pixel per clock. This is suboptimal and we are looking if the IPU can be fooled in another way. I am still considering DS3 but the RM is really to sparse with info there.

[exoson]

Hi Leon,  
I think DS3 is outside what I need.  My "simple" problem is to init a TFT LCD to 32 bit RGBA mode.  The sample code I am using is from the OBDS for the imx536.  It uses 16 bit 565 format which I believe is standard for Android.  This is a non-Linux application.  The iMX53RM provides far too little useful information.  Been that way for the entire project.

Can you share your solution?

Scott

Leon Woestenberg said:

We did not get anything useful from Freescale so far on the DS3 approach, or the 32-bit generic data approach mentioned in the reference manual.

You mean have sample code for using DS3?

What are you trying to accomplish?

We have a 32-bit RGBA solution for our next FPGA/Linux software release in the works for i.MX53 on our Trisendo board.

http://www.trisendo.eu/

[sidebranch]

We did not get anything useful from Freescale so far on the DS3 approach, or the 32-bit generic data approach mentioned in the reference manual.

You mean have sample code for using DS3?

What are you trying to accomplish?

We have a 32-bit RGBA solution for our next FPGA/Linux software release in the works for i.MX53 on our Trisendo board.

http://www.trisendo.eu/

[exoson]

Has you resolved this?  I have the same basic issue.  The sample code I have is for 16 bit 565 mode.  I am looking for 32 bit RGBA.

Scott Nowell