Scott Wood <scottw...@freescale.com> wrote on 30/03/2009 21:32:23: > > Joakim Tjernlund wrote: > >> different since descriptors are in MURAM which is ioremap()ed -- though > >> switching to a cacheable mapping with barriers should be a performance > >> improvement. > > > > I always thought that MURAM was very fast. The whole reason to have BDs in > > 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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev