On Tue, Jun 23, 2015 at 10:03:25AM +0100, Vineet Gupta wrote: > On Tuesday 23 June 2015 02:19 PM, Will Deacon wrote: > >> +/* > >> > + * MMIO can also get buffered/optimized in micro-arch, so barriers > >> > needed > >> > + * Based on ARM model for the typical use case > >> > + * > >> > + * <writel_relaxed DMA buffer> > >> > + * <writel MMIO "go" reg> > >> > + * or: > >> > + * <readl MMIO "status" reg> > >> > + * <readl_relaxed DMA buffer> > > The writel_relaxed/readl_relaxed parts here would actually just be > > bog-standard loads and stores to an in-memory buffer. I was trying too hard > > to show the barrier semantics and accidentally turned the DMA buffers into > > __iomem regions. > > Not sure if I follow you completely :-)
D'oh, sorry. > IMHO, It doesn't matter if we are dealing with a typical DMA buffer (cached) > or a > buffer descriptor (typically uncached unless there's hardware IO-coh or some > such). Both the cases assume a vanilla ld/st to buffer (using relaxed API) > with a > surrounding MMIO access. It's more that you should only pass __iomem pointers (i.e. stuff you got back from something like ioremap) to readl_relaxed/writel_relaxed and that's not typically how you would allocate your DMA buffer. > > If you fix the comment: > > Does this look better ? > > - * <writel_relaxed DMA buffer> > + * <writel_relaxed DMA buffer (cached or uncached)> I'd just replace 'writel_relaxed' with whatever your store instruction is (ST)? Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
