Hi Anatolij,
I hate to come in late to the discussion, but while testing [1] with cache enabled, I started down the path of fixing up code paths within drivers/video/cfb_console.c that are followed by SABRE Lite as you did in [2].
[1] [PATCH V2 0/2] i.MX6: mx6qsabrelite: Add splash screen support http://lists.denx.de/pipermail/u-boot/2012-September/134241.html [2] [PATCH] video: cfb_console: flush dcache for frame buffer in DRAM http://lists.denx.de/pipermail/u-boot/2012-April/123333.html
That code essentially looks like this:
void video_drawchars(...) { ... switch (VIDEO_DATA_FORMAT) { case GDF__8BIT_INDEX: case GDF__8BIT_332RGB: case GDF_15BIT_555RGB: case GDF_16BIT_565RGB: ... cache not flushed in these cases
case GDF_32BIT_X888RGB: ... cache is flushed here }
SABRE Lite (ipu3) code happens to use the RGB565 frame buffer format, so it needs additional fixup.
Continuing this pattern seems to be a mistake though. There are a lot of cases, with all sorts of different alignments (most of which won't sync with cache line boundaries) and it seems that there's little to no benefit in the fine granularity. It seems that by the time we fix up all of the individual spots where we're writing to a line in the frame buffer, the cache can never get dirty in the first place.
It seems much more sensible to simply use flush_dcache_range() on the entire frame buffer in each of the public calls and let the MMU figure out what needs flushing.
Is there something I'm missing?
My other immediate thought was that we should really place the frame buffer in un-cacheable memory, but then we really will be doing more memory accesses.
Please advise,
Eric