Message ID | 20230327121317.4081816-14-arnd@kernel.org |
---|---|
State | New |
Headers | show |
Series | dma-mapping: unify support for cache flushes | expand |
CC Shahab On 3/27/23 17:43, Arnd Bergmann wrote: > From: Arnd Bergmann<arnd@arndb.de> > > Some architectures that need to invalidate buffers after bidirectional > DMA because of speculative prefetching only do a simpler writeback > before that DMA, while architectures that don't need to do the second > invalidate tend to have a combined writeback+invalidate before the > DMA. > > arc is one of the architectures that does both, which seems unnecessary. > > Change it to behave like arm/arm64/xtensa instead, and use just a > writeback before the DMA when we do the invalidate afterwards. > > Signed-off-by: Arnd Bergmann<arnd@arndb.de> Reviewed-by: Vineet Gupta <vgupta@kernel.org> Shahab can you give this a spin on hsdk - run glibc testsuite over ssh and make sure nothing strange happens. Thx, -Vineet
On 4/2/23 08:52, Vineet Gupta wrote: > CC Shahab > > On 3/27/23 17:43, Arnd Bergmann wrote: >> From: Arnd Bergmann<arnd@arndb.de> >> >> Some architectures that need to invalidate buffers after bidirectional >> DMA because of speculative prefetching only do a simpler writeback >> before that DMA, while architectures that don't need to do the second >> invalidate tend to have a combined writeback+invalidate before the >> DMA. >> >> arc is one of the architectures that does both, which seems unnecessary. >> >> Change it to behave like arm/arm64/xtensa instead, and use just a >> writeback before the DMA when we do the invalidate afterwards. >> >> Signed-off-by: Arnd Bergmann<arnd@arndb.de> > > Reviewed-by: Vineet Gupta <vgupta@kernel.org> > > Shahab can you give this a spin on hsdk - run glibc testsuite over ssh and make sure nothing strange happens. > > Thx, > -Vineet On it.
On 4/2/23 08:52, Vineet Gupta wrote: > CC Shahab > > On 3/27/23 17:43, Arnd Bergmann wrote: >> From: Arnd Bergmann<arnd@arndb.de> >> >> Some architectures that need to invalidate buffers after bidirectional >> DMA because of speculative prefetching only do a simpler writeback >> before that DMA, while architectures that don't need to do the second >> invalidate tend to have a combined writeback+invalidate before the >> DMA. >> >> arc is one of the architectures that does both, which seems unnecessary. >> >> Change it to behave like arm/arm64/xtensa instead, and use just a >> writeback before the DMA when we do the invalidate afterwards. >> >> Signed-off-by: Arnd Bergmann<arnd@arndb.de> > > Reviewed-by: Vineet Gupta <vgupta@kernel.org> > > Shahab can you give this a spin on hsdk - run glibc testsuite over ssh > and make sure nothing strange happens. > > Thx, > -Vineet Tested-by: Shahab Vahedi <shahab@synopsys.com> No regression was observed for the ARC target before and after applying these 21 patches. The test environment and its summary follow. board: ARC HSDK base: repo: linux-next tag: next-20230403 commit: 31bd35b66249 Add linux-next specific files for 20230403 hotfix: net: stmmac: check fwnode for phy device before scanning for phy [1] glibc: 2.37 Summary of test results: 20 FAIL 4227 PASS 38 UNSUPPORTED 16 XFAIL 2 XPASS [1] https://lore.kernel.org/lkml/20230405093945.3549491-1-michael.wei.hong.sit@intel.com/#r
diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c index 2a7fbbb83b70..ddb96786f765 100644 --- a/arch/arc/mm/dma.c +++ b/arch/arc/mm/dma.c @@ -40,7 +40,7 @@ void arch_dma_prep_coherent(struct page *page, size_t size) * |---------------------------------------------------------------- * TO_DEV | writeback writeback | none none * FROM_DEV | invalidate invalidate | invalidate* invalidate* - * BIDIR | writeback+inv writeback+inv | invalidate invalidate + * BIDIR | writeback writeback | invalidate invalidate * * [*] needed for CPU speculative prefetches * @@ -61,7 +61,7 @@ void arch_sync_dma_for_device(phys_addr_t paddr, size_t size, break; case DMA_BIDIRECTIONAL: - dma_cache_wback_inv(paddr, size); + dma_cache_wback(paddr, size); break; default: