[U-Boot] [PATCH] video: cfb_console: flush dcache for frame buffer in DRAM
Eric Nelson
eric.nelson at boundarydevices.com
Tue Sep 18 04:49:32 CEST 2012
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
More information about the U-Boot
mailing list