Hi,
Would like to report some problems that appears to be the limitation of LCDC DMA capability.
First is regarding a bit “LCDEN” for enabling DMA transfers, documented in L138 TRM SPRUH77 page 1000, 1001, 1035 (page might differ across revisions but ) for a total of 5 times, yet it is not found in any register field. I suspect it might be a typo in the TRM.
It appears that the LCDC’s bandwidth is extremely limited:
1. First, when Ping-Pong buffering is used, I use a slightly modified version of the L138 Starterware to update frame buffer content. This is just by CPU writing and naturally very slow: a 200-by-200 image would need several frames’ time to complete. For images of dimensions like this, even double-buffering could not eliminate the apparent visual artifacts that the image was being drawn across several frames.
2. Since the intended application has a higher expectation on visual appearance and we do not wish to see artifacts like above during ping-pong buffer updates, we decided to use EDMA3, and chose the straightforward AB synchronization. It works fairly well for moderately-sized images of like 16000 pixels (around 130 by 130). However, for larger size EDMA updates like 200 by 200, EDMA3 seems to disrupt LCD DMA operation and would result in displaced screen. The effect is exactly like that the origin has been moved away from (0,0) to another location (like (50,50) ) and the screen got wrapped bottom-to-up and left-to-right.
a. An immediately cure to the displacement problem is by turning off raster controller during frame update, and turns it on after update has completed. We achieved this using:
LCDC->RASTER_CTRL &= ~0x00000001;
Update frame
LCDC->RASTER_CTRL |= 0x00000001;
However, it is apparently an “insecure” and imperfect approach since in theory the LCD screen would have flash “white” and then back to normal, although in practice we didn’t see this effect with a fresh rate at 60Hz. Nonetheless, after turning on raster controller again it seems defaults to output frame buffer 0 even when it should output frame 1, and frequently we could see flashing artifacts that we suspect might owing to this.
b. As we have mentioned above, with smaller size images updated by EDMA the displacement artifact doesn’t happen. We therefore suspect that the EDMA3’s competition with LCDC DMA on DDR2 access might have caused the artifact. We check LCDC status register every time a displacement artifact happens:
LCD_STAT: 0x00000344: end of both frame detected + palette loaded + Frame Synchronization Lost has occurred.
We tried to mitigate the problem using ensemble of the following approaches:
I. Tuning LCDDMA_CTRL.TH_FIFO_READY and LCDDMA_CTRL. BURST_SIZE. We found that if both are set to their maximum (512 dwords, and burst size of 16), the screen would show a full of screen of uniform dark green color with the following LCD_STAT value:
LCD_STAT: 0x00000060: The palette is loaded + LCD dither logic not supplying data to FIFO at a sufficient rate, FIFO has completely emptied and data pin driver logic has attempted to take added data from FIFO
The FIFO empty message is not a surprise as we have set the FIFO threshold to 512 dwords. Intermediate values for LCDDMA_CTRL.TH_FIFO_READY and LCDDMA_CTRL. BURST_SIZE does not cause extreme problems like this but could displacement issue still exists.
II. EDMA3 fragmentation.
1) First, according the first example of Example 18-4 in EDMA chapter (page 593), we split the original continuous source into even and odd parts and transfer them in two pass, in order to prevent the EDMA’s default optimization like the example shown: ACNT = 8, BCNT = 8 optimized to ACNT = 64, BCNT = 1.
2) We also attempted to reduce burst size according to instructions at page 592, 18.2.11.1.1 EDMA3TC Configuration. However, the documents says that only DBS (burst size) can be changed. However the option in CFGCHIP0 and CFGCHIP1 allows only increasing burst size from 16 bytes to 32 or 64 bytes, apparently contrary to our will of decreasing it.
3) Trying to “reroute” the traffic so that EDMA3 and LCDC DMA goes through different SCR parts. We examine the colorful Figure 4-1. System Interconnect Block Diagram without finding a possibly better configuration:
All three transfer controllers (EDMA3_0_TC0, EDMA3_0_TC1, EDMA3_1_TC0) access DDR2 via SCR1 and SCRF3, and LCDC also access DDR2 via SCRF3, so they both have to pass through SCRF3. We found no way to change this.
4) Assigning a different part of memory to at least one of the two LCDC ping-pong buffers. However according to Table 4-1. OMAP-L138 Applications Processor System Interconnect Matrix, LCDC can only access DDR2 so this approach is also inapplicable.
We have no idea why the displacement error could happen; and regarding one of the LCD_STAT values above, why frame synchronization could have lost? And why turning off and on raster controller could some cure the displacement problem much like doing a “reset.”
We also want to get advices from TI experts on how the displacement problem could be solved. After all, has there been any successful application of L138 in which ping-pong update of probably the entire frame buffer content does not cause displacement like we described?
Paul
