Hi, Arnd: 2018-01-25 18:42 GMT+08:00 Arnd Bergmann <arnd@xxxxxxxx>: > 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. Thank you for this suggestion. We have optimized in cpu_dcache_wb_range() and it will be called from cpu_dma_wb_range(). It will do nothing if it is a write-through config cache. >>> - 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> Thank you. :)
