RE: cacheflush system call-MIPS

["David VomLehn (dvomlehn)" <dvomlehn@cisco.com>]

> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Eugene 
> Surovegin
> Sent: Tuesday, February 17, 2009 11:45 AM
> To: David Daney
> Cc: post@pfrst.de; Ralf Baechle; linux-mips@linux-mips.org
> Subject: Re: cacheflush system call-MIPS
> 
> On Tue, Feb 17, 2009 at 09:06:32AM -0800, David Daney wrote:
> > peter fuerst wrote:
> >>> Why does it need that flush?
> >> To prepare the update-area (in the Shadow-FB) for DMA to RE.
> >
> > And on systems where the root frame buffer is directly 
> manipulated by the 
> > CPU, the video system is continually using DMA to refresh 
> the display.  A 
> > cache flush can be required to eliminate transient visual glitches.
> 
> In this case using uncached fb access is the only way to avoid 
> glitches - you cannot control cache line evictions. And it's usually 
> faster to use uncached mappings for effectively write-only regions.

A far more appropriate caching mode for frame buffers, if your processor
supports it, is to use uncached accelerated
(_CACHED_UNCACHED_ACCELERATED in the kernel source). Unfortunately, at
least as far as I can tell, you'd need to write your own driver to do
the memory mapping so that it can set the cache coherency attributes to
get this behavior. Not especially hard if you are familiar with device
drivers, much harder if you are note.