| To: | David Daney <ddaney@avtrex.com> |
|---|---|
| Subject: | Re: What's up with cpu_is_noncoherent_r10000() ? |
| From: | tsbogend@alpha.franken.de (Thomas Bogendoerfer) |
| Date: | Mon, 25 Aug 2008 20:46:01 +0200 |
| Cc: | MIPS Linux List <linux-mips@linux-mips.org> |
| In-reply-to: | <48B2DF15.5030903@avtrex.com> |
| Original-recipient: | rfc822;linux-mips@linux-mips.org |
| References: | <48B2DF15.5030903@avtrex.com> |
| Sender: | linux-mips-bounce@linux-mips.org |
| User-agent: | Mutt/1.5.13 (2006-08-11) |
On Mon, Aug 25, 2008 at 09:34:29AM -0700, David Daney wrote:
> What is the reasoning for only doing the cache operation on R10K based
> systems?
non coherent R10k need after DMA operations to get rid of remains
of load/store speculations. Other CPUs don't pollute the cache
after it got flushed.
But this optimization is wrong, we need to do the flush for
every non coherent device otherwise polling a descriptor via
a cached mapping can't work. And this exactly what E100 does.
Instead of if (cpu_is_noncoherent_r10000(deva)) something like
if (cpu_is_noncoherent_r10000(dev) ||
(!plat_device_is_coherent(dev) && (direction != DMA_TO_DEVICE)))
should do the trick with minimum flushes for non R10k CPUs. But probably
a simple
if ((!plat_device_is_coherent(dev))
is the safest approach.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea. [ RFC1925, 2.3 ]
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: What's up with cpu_is_noncoherent_r10000() ?, Thiemo Seufer |
|---|---|
| Next by Date: | Re: What's up with cpu_is_noncoherent_r10000() ?, David Daney |
| Previous by Thread: | Re: What's up with cpu_is_noncoherent_r10000() ?, Thiemo Seufer |
| Next by Thread: | Re: What's up with cpu_is_noncoherent_r10000() ?, Ralf Baechle |
| Indexes: | [Date] [Thread] [Top] [All Lists] |