Raspberry Pi Forums

I could be wrong about this, but is the DMA code in the bcm2708_fb driver missing code to do L1 cache cleaning? Without this, most operations will work fine, but if you get unlucky, small regions (of the order of 8k pixels for a 16bit display) might come out corrupted.

Presumably it needs something to clean the cache in the area being copied from, and invalidate it in the destination region.

It might actually be quicker just to flush the entire L1 cache, given that it's quite small (16k L1) and it only does DMA for large(ish) regions. Possibly a call to dmac_flush_user_all() ?

I'd be interested to hear the answer here.
In my bare-metal VMM experiments, I saw exactly the symptom you describe, the last part of the display not being fully updated due to the data being in the cache. My solution was to modify the memory attributes for the framebuffer memory to be write-through rather than write-back. Having done that screen updates are correct without needing a cache clean. I'm not however using DMA so not sure what would happen about the source; I suspect that unless you're using memory marked as shared you would need to do a cache clean to ensure that the DMA reads the latest data from the source. I don't ever read data back from the framebuffer so no need to invalidate the cache.

Cheers, Simon

I belive the whole framebuffer is non-L1 allocating. Even without the DMA patch you will see stale pixels when it's allocated in the L1 cache as the framebuffer is displayed "live" but hardware that is not coherent with ARM's L1.