linux-mips
[Top] [All Lists]

RE: cacheflush system call-MIPS

To: "Eugene Surovegin" <ebs@ebshome.net>, "David Daney" <ddaney@caviumnetworks.com>
Subject: RE: cacheflush system call-MIPS
From: "David VomLehn (dvomlehn)" <dvomlehn@cisco.com>
Date: Tue, 17 Feb 2009 15:50:41 -0500
Authentication-results: sj-dkim-4; header.From=dvomlehn@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
Cc: <post@pfrst.de>, "Ralf Baechle" <ralf@linux-mips.org>, <linux-mips@linux-mips.org>
Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; l=1419; t=1234903843; x=1235767843; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dvomlehn@cisco.com; z=From:=20=22David=20VomLehn=20(dvomlehn)=22=20<dvomlehn@cis co.com> |Subject:=20RE=3A=20cacheflush=20system=20call-MIPS |Sender:=20; bh=ohbDmGwN89Vu2BS4gIircPBZ2hoTSjBe8305JZvlHvQ=; b=nJMX9wGcLRaHl55pvaLJHp+ZMUdmV5kmWAZ8IHlpa15VawE0eh37D2KM8x S85LntM40zGrNJOtHEN8tcZe36WmIW/Mqi+C+XlPE4V/qKRuZNkjMcGCwprd 7pEImHMz2Z;
In-reply-to: <20090217194509.GA16134@gate.ebshome.net>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <f5a7b3810902100716t2658ce95t2dcc7f85634522@mail.gmail.com> <20090211131649.GA1365@linux-mips.org> <Pine.LNX.4.58.0902140002180.408@Indigo2.Peter> <20090213235603.GA32274@linux-mips.org> <Pine.LNX.4.58.0902150312460.459@Indigo2.Peter> <499AEE98.1010908@caviumnetworks.com> <20090217194509.GA16134@gate.ebshome.net>
Sender: linux-mips-bounce@linux-mips.org
Thread-index: AcmROGb9yqOYrNbLSiuqcc+e/OQPuAAA06nA
Thread-topic: cacheflush system call-MIPS
> 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.

<Prev in Thread] Current Thread [Next in Thread>