Dear All, As the post above will be probably often found by google, I will post here also a temporary solution colleague of mine found to the flickering problem.
devmem2 0x4c000054 w 0x00FFFFF10 It is probably not ideal - there should be a way how to prioritize just the LCD transfers (according to the TI wiki), but the values there do not work. This fix just ensures that any "too old" command gets executed sooner than it would otherwise, maybe that is a good thing anyway. However, I believe I understand all the various issues we've seen (although I could still be wrong - but this at least makes sense): static image shift - here, the DMA for transferring data to LCD fifo is blocked for a short period of time once, but then it continues normally. This produces the fifo-underflow interrupt once, the data for display are few pixels late, but then all works normally so the image is just shifted (although not too visible in the photo, the "extra" pixels at top-left corner are black, and not white if the image was just wrapped). full flickering - in this case, the memory load is so severe that the DMA is blocked too often and can't supply steady stream of data; producing fifo-underflow interrupts all over. The image still starts from the top-left corner as usual, but then the rest of the "pixel stream" contains some extra 0s so the testimage produces diagonal patterns (with varying error, hence the flickering). So these 2 are the same issue, just with different outcome. The problem is the DDR command prioritization logic in our memory controller, the memset() loop manages to starve the DMA data stream. The "fix" just tweaks the REG_PR_OLD_COUNT value - now if there is a DDR command in the memory controller fifo for too long, it will get executed (out of the prioritized ordering). (I can probably also explain why it +- works with >2k buffers; but there I'm not fully sure yet.) All this is based on this info: http://processors.wiki.ti.com/index.php/DA8xx_LCDC_Linux_FB_FAQs Thanks, Radek
