From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH v6 16/36] nds32: DMA mapping API Date: Wed, 24 Jan 2018 12:36:17 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Greentime Hu Cc: Greentime , Linux Kernel Mailing List , linux-arch , Thomas Gleixner , Jason Cooper , Marc Zyngier , Rob Herring , Networking , Vincent Chen , DTML , Al Viro , David Howells , Will Deacon , Daniel Lezcano , linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Geert Uytterhoeven , Linus Walleij , Mark Rutland , Greg KH , Guo Ren List-Id: devicetree@vger.kernel.org On Tue, Jan 23, 2018 at 12:52 PM, Greentime Hu wrote: > Hi, Arnd: > > 2018-01-23 16:23 GMT+08:00 Greentime Hu : >> Hi, Arnd: >> >> 2018-01-18 18:26 GMT+08:00 Arnd Bergmann : >>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu wrote: >>>> From: Greentime Hu >>>> >>>> This patch adds support for the DMA mapping API. It uses dma_map_ops for >>>> flexibility. >>>> >>>> Signed-off-by: Vincent Chen >>>> Signed-off-by: Greentime Hu >>> >>> I'm still unhappy about the way the cache flushes are done here as discussed >>> before. It's not a show-stopped, but no Ack from me. >> >> How about this implementation? > I am not sure if I understand it correctly. > I list all the combinations. > > RAM to DEVICE > before DMA => writeback cache > after DMA => nop > > DEVICE to RAM > before DMA => nop > after DMA => invalidate cache > > static void consistent_sync(void *vaddr, size_t size, int direction, int master) > { > unsigned long start = (unsigned long)vaddr; > unsigned long end = start + size; > > if (master == FOR_CPU) { > switch (direction) { > case DMA_TO_DEVICE: > break; > case DMA_FROM_DEVICE: > case DMA_BIDIRECTIONAL: > cpu_dma_inval_range(start, end); > break; > default: > BUG(); > } > } else { > /* FOR_DEVICE */ > switch (direction) { > case DMA_FROM_DEVICE: > break; > case DMA_TO_DEVICE: > case DMA_BIDIRECTIONAL: > cpu_dma_wb_range(start, end); > break; > default: > BUG(); > } > } > } That looks reasonable enough, but it does depend on a number of factors, and the dma-mapping.h implementation is not just about cache flushes. As I don't know the microarchitecture, can you answer these questions: - are caches always write-back, or could they be write-through? - can the cache be shared with another CPU or a device? - if the cache is shared, is it always coherent, never coherent, or either of them? - could the same memory be visible at different physical addresses and have conflicting caches? - is the CPU physical address always the same as the address visible to the device? - are there devices that can only see a subset of the physical memory? - can there be an IOMMU? - are there write-buffers in the CPU that might need to get flushed before flushing the cache? - could cache lines be loaded speculatively or with read-ahead while a buffer is owned by a device? Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html