From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH v6 16/36] nds32: DMA mapping API Date: Thu, 25 Jan 2018 11:42:38 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-arch-owner@vger.kernel.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@vger.kernel.org, Geert Uytterhoeven , Linus Walleij , Mark Rutland , Greg KH , Guo Ren List-Id: devicetree@vger.kernel.org On Thu, Jan 25, 2018 at 4:45 AM, Greentime Hu wrote: > 2018-01-24 19:36 GMT+08:00 Arnd Bergmann : >> On Tue, Jan 23, 2018 at 12:52 PM, Greentime Hu wrote: >>> 2018-01-23 16:23 GMT+08:00 Greentime Hu : >>>> 2018-01-18 18:26 GMT+08:00 Arnd Bergmann : >>>>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu wrote: >> >> 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? > Yes, we can config it to write-back or write-through. Ok. If a WT-cache is common enough, you could optimize for that case by skipping the explicit writeback here and just doing a synchronizing instruction. Usually if the cache is configurable, one would pick the writeback option though, so it's probably not important. >> - is the CPU physical address always the same as the address visible to the >> device? > Yes, it is always the same unless the CPU uses local memory. The > physical address of local memory will overlap the original bus > address. > I think the local memory case can be ignored because we don't use it for now. Ok, makes sense. >> - are there devices that can only see a subset of the physical memory? > All devices are able to see the whole physical memory in our current > SoC, but I think other SoC may support such kind of HW behavior. This is one area that might need a more complex implementation then, depending on what devices are used in other SoCs. For network or storage devices, it's usually sufficient to configure a DMA mask from the "dma-ranges" property of the parent bus in the device tree, the kernel code will then use bounce buffers. For other types of drivers, using the streaming DMA interfaces can require using the swiotlb helper that performs the bounce buffering at in place of the cache operations. With a bit of luck, you won't ever need to worry about it, just mentioning it here in case you run into that problem later. The consistent_sync() implementaiton you showed earlier should be good enough then. With that change, Acked-by: Arnd Bergmann