When the framebuffers are in 32-bit ARGB mode, can the i.MX53 bring out the alpha channel to the external display interface carry an alpha channel?
I.e. ARGB instead of RGB?
For example, at 30 Hz, is it possible to use the external display interface in 16-bit mode,
and send "AR" (16-bit) then "BG" (16-bit)?
The Display interface implicitly drops the alpha component as this is not something used by an LCD. If you would like to get the alpha information out of the IPU, it might be possible to fool the IPU into sending the data as 16bpp data in two clock cycles per pixel. This does imply some restrictions as you would not be able to use the DP to manipulate the image (color space conversion, alpha blending) on the way to the DI since the IPU "thinks" it is handling 16bpp pixel data.
thanks, I will certainly look into this, as we have something connected that is a bit smarter than an LCD, we use an external FPGA that allows an additional overlay. Would be nice to support per-pixel alpha in real-time.
See here: http://imxcommunity.org/photo/trisendo-2d-3d-video-board
Hello Philip, Freescalers,
I have read the IPU section of the i.MX53 datasheet and reference manual. Two things look like a possible solution to export ARGB to an external "smart display" or better "external graphics accelerator".
1) Synchronous mode, fooling the IPI into sending ARGB32 as two 16-bit
2) Asynchronous mode.
page 2635 of the i.MX53 Reference Manual Rev 2
Asynchronous Access:This is the main mode used for communicating with an external display controller(possibly in a smart display or a graphics accelerator). In this mode, the IPU performsrandom access - read/write - to the memory and registers of the controller.Two types of addressing methods are supported• Generic linear addressing of pixels and generic data• 2-dimensional (X/Y) addressing of pixelsThe following access types are provided:• Data transfer to the external device, after on-the-fly processing in the• Data transfer (DMA) - read/write - between the host's system memory and theexternal device, through the IPU's memory port (controlled by the IDMAC), such asthe transfer of a rectangular block of pixels (possibly full screen).• Host access - read/write - to an external device, through the AHB-slave port• Access types• Direct access - emulating a directly-addressed access (see below) Thisincludes burst access (incremental; up to 8 words/burst)• Low-level access - leaving to the host the explicit generation of the accessprotocol• The possible accessing modules include the ARM platform and the system DMAcontroller (as well as any other AHB master connected to the ARM's cross-barswitch).
We have seen that the Display Port is very versatile, it can even read from the display.
188.8.131.52 Display ports channelsThe display port send data to the display over several channels. The data source may bethe system's memory (via the IDMAC) the IC block and the ARM platform. The displayport can read data from the display and send it to the ARM platform or IDMAC.
Is this more internal documentation available that helps me implement this mode? I have an NDA in place with Freescale.
another idea: we do only need 25 Hz. I am thinking of running at 50 Hz and then change the IPU mapping registers on each vertical sync, so that alternating "AR" and "GB" are available on the 24-bit LCD output interface.
This last idea was impossible, as the DP cuts of 24-bits of the 32-bit prior to splitting the 24-bit in 3 components.
A new idea is to use the "DS3" dataflow that flows directly from memory to display, without going through the DP, which is think is what Philip Hatcher meant.
This is called GENERIC_DATA mode and is meant to stream any arbitrary data / format (such as JPEG) over the display bus.
However, I could not find any info or example driver under Linux on how to use this mode. Any pointers or app notes on this?
Retrieving data ...