On Mon, Apr 09, 2018 at 07:45:22AM -0700, James Bottomley wrote: > > https://parisc.wiki.kernel.org/images-parisc/7/73/Parisc2.0.pdf > > > > I don't see the U-bit mentioned in the below blurb, and also, I see > > no mention on why SYNCDMA is not needed. > > Um, well U is uncached and is used mostly for memory based IO regions. > We also have the odd system that doesn't have the U bit, which is why > there's a network and a scsi driver with dma_cache_sync() in them. > > The point here is that U being caching is nothing to do with ordering. So I clearly had my reading skills disabled this morning (this wasn't the only such occurence). In appending G, Memory Ordering Model, it states that U=1 results in strongly ordered stuff, and for some reason I read it as being required. But you're right, it's just one of many possible cases. The O-bit is indeed what we should be looking at. > > A paranoid me would do mb() as SYNCDMA and __smp_mb() as SYNC, given > > that the manual also states it NO-OPs these instructions when not > > needed. > > I think you misunderstand how ordering and caching work. Ordering is > the province of barriers and we insert the ordering into the code > assuming we're in the CPU domain (usually everything as seen by the > cpus is fully cache coherent on parisc). Caching is the province of > the coherence domains (usually CPU to bus) and we handle that in the > dma_ IO operations. > > So we can quibble about whether we need a syncdma in our dma_ > operations, we'd never need one in the execution barriers. I was under the impression that mb() should (also) order against DMA and MMIO things, while smp_mb() is just for the SMP/CPU domain. Also note how with asm-generic/barrier.h the dma_*mb() things default to being mb(). -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
