Thx Arnd, On Tue, Jul 30, 2019 at 9:43 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Tue, Jul 30, 2019 at 2:16 PM <guoren@xxxxxxxxxx> wrote: > > From: Guo Ren <ren_guo@xxxxxxxxx> > > > diff --git a/arch/csky/mm/dma-mapping.c b/arch/csky/mm/dma-mapping.c > > index 3f1ff9d..d8f0f81 100644 > > --- a/arch/csky/mm/dma-mapping.c > > +++ b/arch/csky/mm/dma-mapping.c > > @@ -72,6 +72,8 @@ void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr, > > cache_op(paddr, size, dma_wb_range); > > break; > > case DMA_FROM_DEVICE: > > + cache_op(paddr, size, dma_inv_range); > > + break; > > case DMA_BIDIRECTIONAL: > > cache_op(paddr, size, dma_wbinv_range); > > break; > > @@ -88,6 +90,8 @@ void arch_sync_dma_for_cpu(struct device *dev, phys_addr_t paddr, > > cache_op(paddr, size, dma_wb_range); > > break; > > case DMA_FROM_DEVICE: > > + cache_op(paddr, size, dma_inv_range); > > + break; > > case DMA_BIDIRECTIONAL: > > cache_op(paddr, size, dma_wbinv_range); > > break; > > When syncing 'for_cpu', you should not need to write back, because > there won't be any dirty cache lines. I just follow the dma_data_direction param, seems dir param and function are a little bit duplicated. And our cpu won't clear clean cache line into memory, so dma_wb_page won't cause problem. Seems arch_sync_dma_for_cpu with dir=DMA_TO_DEVICE is self-contradictory. Do you want me modfiy like these: @@ -88,6 +90,8 @@ void arch_sync_dma_for_cpu(struct device *dev, phys_addr_t paddr, case DMA_TO_DEVICE: case DMA_FROM_DEVICE: case DMA_BIDIRECTIONAL: cache_op(paddr, size, dma_inv_range); break; @@ -72,6 +72,8 @@ void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr, case DMA_TO_DEVICE: cache_op(paddr, size, dma_wb_range); break; case DMA_FROM_DEVICE: case DMA_BIDIRECTIONAL: cache_op(paddr, size, dma_wbinv_range); break; > > If you have a CPU core that does not do speculative loads, you also don't > need to invalidate here, because you have already done that in the > _for_device() case, the only reason to invalidate the CPU cache > again is if a speculative load created a stale cache line that now > shadows the data received from the device. Our CPU support speculative loads :) -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/