| To: | David Daney <ddaney@caviumnetworks.com> |
|---|---|
| Subject: | Re: cacheflush system call-MIPS |
| From: | Eugene Surovegin <ebs@ebshome.net> |
| Date: | Tue, 17 Feb 2009 11:45:09 -0800 |
| Cc: | post@pfrst.de, Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org |
| In-reply-to: | <499AEE98.1010908@caviumnetworks.com> |
| 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> |
| Sender: | linux-mips-bounce@linux-mips.org |
| User-agent: | Mutt/1.5.16 (2007-06-09) |
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. -- Eugene |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: cacheflush system call-MIPS, David Daney |
|---|---|
| Next by Date: | RE: cacheflush system call-MIPS, David VomLehn (dvomlehn) |
| Previous by Thread: | Re: cacheflush system call-MIPS, David Daney |
| Next by Thread: | RE: cacheflush system call-MIPS, David VomLehn (dvomlehn) |
| Indexes: | [Date] [Thread] [Top] [All Lists] |