Re: [PATCH] ucc_geth: Rework the TX logic.
From: Joakim Tjernlund <hidden>
Date: 2009-03-31 09:07:40
Also in:
linuxppc-dev
Scott Wood [off-list ref] wrote on 30/03/2009 21:32:23:
Joakim Tjernlund wrote:quoted
quoted
different since descriptors are in MURAM which is ioremap()ed --
though
quoted
quoted
switching to a cacheable mapping with barriers should be a
performance
quoted
quoted
improvement.I always thought that MURAM was very fast. The whole reason to have
BDs in
quoted
MURAM is that it is faster than normal RAM, at least that is what I thought.Yeah, on second thought it probably wouldn't be worth it. There's also the question of under what circumstances the QE's MURAM accesses will be
cache-coherent.
I am a bit confused, what isn't worth it? Currently MURAM isn't used by ucc_geth, but it is easy to change. Swap MEM_PART_SYSTEM to MEM_PART_MURAM, however, just tried that and the driver stopped working. I known this worked earlier because I tried it and I even think I sent a patch to Leo. What choices do we have, I see three: 1) MEM_PART_SYSTEM, as today. 2) MEM_PART_MURAM. I guess this should be uncacheable memory? 3) as gianfar, dma_alloc_coherent(). I presume this is uncacheable memory? My guess would be 2 or 3. Do they have the same synchronization sematics?
As for the CPU not reordering guarded+cache inhibited accesses, that initially seemed to be true for the new arch stuff (book3e/book3s, but not really, see below), but the classic arch documentation only guarantees stores to such regions to be in-order (and the explicitly-specified operation of eieio on I+G accesses wouldn't make much sense if they were already guaranteed to be in-order). Then I looked at the EREF to see what older book E documents had to say on the issue, and it suggests that when the architecture document says "out of order", it really means "speculative" (and reading the arch doc's definition of "out of order" seems to confirm this -- redefining terms is bad, m'kay?). So it seems that the simple answer is no, guarded storage is not guaranteed to be in order, unless the only thing that can cause an out-of-order access is speculative execution.
Very informative, thanks.