[U-Boot] [PATCH] video: cfb_console: flush dcache for frame buffer in DRAM

[Eric Nelson <eric.nelson@boundarydevices.com>]

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