On Thu, Jan 25, 2018 at 4:45 AM, Greentime Hu <green.hu@xxxxxxxxx> wrote: > 2018-01-24 19:36 GMT+08:00 Arnd Bergmann <arnd@xxxxxxxx>: >> On Tue, Jan 23, 2018 at 12:52 PM, Greentime Hu <green.hu@xxxxxxxxx> wrote: >>> 2018-01-23 16:23 GMT+08:00 Greentime Hu <green.hu@xxxxxxxxx>: >>>> 2018-01-18 18:26 GMT+08:00 Arnd Bergmann <arnd@xxxxxxxx>: >>>>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu@xxxxxxxxx> 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 <arnd@xxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
