* barriers vs I/O and DMA for ia64 @ 2018-07-31 17:20 Christoph Hellwig 2018-07-31 17:20 ` Christoph Hellwig 0 siblings, 1 reply; 10+ messages in thread From: Christoph Hellwig @ 2018-07-31 17:20 UTC (permalink / raw) To: Tony Luck, Fenghua Yu Cc: Sinan Kaya, Arnd Bergmann, linux-ia64, linux-arch, linux-kernel, iommu Hi all, please review these patches carefully - ia64 currenly seems to be the odd one out in terms of barrier placement for DMA and I/O and this patch tries to resolve it. But I don't have any IA64 hardware nor do I know the architecture to well, so don't blindly trust me. ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] ia64: fix barrier placement for write* / dma mapping 2018-07-31 17:20 barriers vs I/O and DMA for ia64 Christoph Hellwig @ 2018-07-31 17:20 ` Christoph Hellwig 0 siblings, 0 replies; 10+ messages in thread From: Christoph Hellwig @ 2018-07-31 17:20 UTC (permalink / raw) To: Tony Luck, Fenghua Yu Cc: Sinan Kaya, Arnd Bergmann, linux-ia64, linux-arch, linux-kernel, iommu memory-barriers.txt has been updated with the following requirement. "When using writel(), a prior wmb() is not needed to guarantee that the cache coherent memory writes have completed before writing to the MMIO region." The current writeX() and iowriteX() implementations on ia64 are not satisfying this requirement as the barrier is after the register write. This adds the missing memory barriers, and instead drops them from the dma sync routine where they are misplaced (and were missing in the more important map/unmap cases anyway). All this doesn't affect the SN2 platform, which already has barrier in the I/O accessors, and none in dma mapping (but then again swiotlb doesn't have any either). Signed-off-by: Christoph Hellwig <hch@lst.de> --- arch/ia64/hp/common/sba_iommu.c | 4 ---- arch/ia64/include/asm/dma-mapping.h | 5 ----- arch/ia64/include/asm/io.h | 5 +++++ arch/ia64/kernel/machvec.c | 16 ---------------- arch/ia64/kernel/pci-dma.c | 5 ----- 5 files changed, 5 insertions(+), 30 deletions(-) diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c index ee5b652d320a..e8da6503ed2f 100644 --- a/arch/ia64/hp/common/sba_iommu.c +++ b/arch/ia64/hp/common/sba_iommu.c @@ -2207,10 +2207,6 @@ const struct dma_map_ops sba_dma_ops = { .unmap_page = sba_unmap_page, .map_sg = sba_map_sg_attrs, .unmap_sg = sba_unmap_sg_attrs, - .sync_single_for_cpu = machvec_dma_sync_single, - .sync_sg_for_cpu = machvec_dma_sync_sg, - .sync_single_for_device = machvec_dma_sync_single, - .sync_sg_for_device = machvec_dma_sync_sg, .dma_supported = sba_dma_supported, .mapping_error = sba_dma_mapping_error, }; diff --git a/arch/ia64/include/asm/dma-mapping.h b/arch/ia64/include/asm/dma-mapping.h index 76e4d6632d68..2b8cd4a6d958 100644 --- a/arch/ia64/include/asm/dma-mapping.h +++ b/arch/ia64/include/asm/dma-mapping.h @@ -16,11 +16,6 @@ extern const struct dma_map_ops *dma_ops; extern struct ia64_machine_vector ia64_mv; extern void set_iommu_machvec(void); -extern void machvec_dma_sync_single(struct device *, dma_addr_t, size_t, - enum dma_data_direction); -extern void machvec_dma_sync_sg(struct device *, struct scatterlist *, int, - enum dma_data_direction); - static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus) { return platform_dma_get_ops(NULL); diff --git a/arch/ia64/include/asm/io.h b/arch/ia64/include/asm/io.h index fb0651961e2c..ba5523b67eaf 100644 --- a/arch/ia64/include/asm/io.h +++ b/arch/ia64/include/asm/io.h @@ -22,6 +22,7 @@ #include <asm/unaligned.h> #include <asm/early_ioremap.h> +#include <asm/barrier.h> /* We don't use IO slowdowns on the ia64, but.. */ #define __SLOW_DOWN_IO do { } while (0) @@ -345,24 +346,28 @@ ___ia64_readq (const volatile void __iomem *addr) static inline void __writeb (unsigned char val, volatile void __iomem *addr) { + mb(); *(volatile unsigned char __force *) addr = val; } static inline void __writew (unsigned short val, volatile void __iomem *addr) { + mb(); *(volatile unsigned short __force *) addr = val; } static inline void __writel (unsigned int val, volatile void __iomem *addr) { + mb(); *(volatile unsigned int __force *) addr = val; } static inline void __writeq (unsigned long val, volatile void __iomem *addr) { + mb(); *(volatile unsigned long __force *) addr = val; } diff --git a/arch/ia64/kernel/machvec.c b/arch/ia64/kernel/machvec.c index 7bfe98859911..1b604d02250b 100644 --- a/arch/ia64/kernel/machvec.c +++ b/arch/ia64/kernel/machvec.c @@ -73,19 +73,3 @@ machvec_timer_interrupt (int irq, void *dev_id) { } EXPORT_SYMBOL(machvec_timer_interrupt); - -void -machvec_dma_sync_single(struct device *hwdev, dma_addr_t dma_handle, size_t size, - enum dma_data_direction dir) -{ - mb(); -} -EXPORT_SYMBOL(machvec_dma_sync_single); - -void -machvec_dma_sync_sg(struct device *hwdev, struct scatterlist *sg, int n, - enum dma_data_direction dir) -{ - mb(); -} -EXPORT_SYMBOL(machvec_dma_sync_sg); diff --git a/arch/ia64/kernel/pci-dma.c b/arch/ia64/kernel/pci-dma.c index 3c2884bef3d4..2512aa3029f5 100644 --- a/arch/ia64/kernel/pci-dma.c +++ b/arch/ia64/kernel/pci-dma.c @@ -55,11 +55,6 @@ void __init pci_iommu_alloc(void) { dma_ops = &intel_dma_ops; - intel_dma_ops.sync_single_for_cpu = machvec_dma_sync_single; - intel_dma_ops.sync_sg_for_cpu = machvec_dma_sync_sg; - intel_dma_ops.sync_single_for_device = machvec_dma_sync_single; - intel_dma_ops.sync_sg_for_device = machvec_dma_sync_sg; - /* * The order of these functions is important for * fall-back/fail-over reasons -- 2.18.0 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH] ia64: fix barrier placement for write* / dma mapping @ 2018-07-31 17:20 ` Christoph Hellwig 0 siblings, 0 replies; 10+ messages in thread From: Christoph Hellwig @ 2018-07-31 17:20 UTC (permalink / raw) To: Tony Luck, Fenghua Yu Cc: Sinan Kaya, Arnd Bergmann, linux-ia64, linux-arch, linux-kernel, iommu memory-barriers.txt has been updated with the following requirement. "When using writel(), a prior wmb() is not needed to guarantee that the cache coherent memory writes have completed before writing to the MMIO region." The current writeX() and iowriteX() implementations on ia64 are not satisfying this requirement as the barrier is after the register write. This adds the missing memory barriers, and instead drops them from the dma sync routine where they are misplaced (and were missing in the more important map/unmap cases anyway). All this doesn't affect the SN2 platform, which already has barrier in the I/O accessors, and none in dma mapping (but then again swiotlb doesn't have any either). Signed-off-by: Christoph Hellwig <hch@lst.de> --- arch/ia64/hp/common/sba_iommu.c | 4 ---- arch/ia64/include/asm/dma-mapping.h | 5 ----- arch/ia64/include/asm/io.h | 5 +++++ arch/ia64/kernel/machvec.c | 16 ---------------- arch/ia64/kernel/pci-dma.c | 5 ----- 5 files changed, 5 insertions(+), 30 deletions(-) diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c index ee5b652d320a..e8da6503ed2f 100644 --- a/arch/ia64/hp/common/sba_iommu.c +++ b/arch/ia64/hp/common/sba_iommu.c @@ -2207,10 +2207,6 @@ const struct dma_map_ops sba_dma_ops = { .unmap_page = sba_unmap_page, .map_sg = sba_map_sg_attrs, .unmap_sg = sba_unmap_sg_attrs, - .sync_single_for_cpu = machvec_dma_sync_single, - .sync_sg_for_cpu = machvec_dma_sync_sg, - .sync_single_for_device = machvec_dma_sync_single, - .sync_sg_for_device = machvec_dma_sync_sg, .dma_supported = sba_dma_supported, .mapping_error = sba_dma_mapping_error, }; diff --git a/arch/ia64/include/asm/dma-mapping.h b/arch/ia64/include/asm/dma-mapping.h index 76e4d6632d68..2b8cd4a6d958 100644 --- a/arch/ia64/include/asm/dma-mapping.h +++ b/arch/ia64/include/asm/dma-mapping.h @@ -16,11 +16,6 @@ extern const struct dma_map_ops *dma_ops; extern struct ia64_machine_vector ia64_mv; extern void set_iommu_machvec(void); -extern void machvec_dma_sync_single(struct device *, dma_addr_t, size_t, - enum dma_data_direction); -extern void machvec_dma_sync_sg(struct device *, struct scatterlist *, int, - enum dma_data_direction); - static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus) { return platform_dma_get_ops(NULL); diff --git a/arch/ia64/include/asm/io.h b/arch/ia64/include/asm/io.h index fb0651961e2c..ba5523b67eaf 100644 --- a/arch/ia64/include/asm/io.h +++ b/arch/ia64/include/asm/io.h @@ -22,6 +22,7 @@ #include <asm/unaligned.h> #include <asm/early_ioremap.h> +#include <asm/barrier.h> /* We don't use IO slowdowns on the ia64, but.. */ #define __SLOW_DOWN_IO do { } while (0) @@ -345,24 +346,28 @@ ___ia64_readq (const volatile void __iomem *addr) static inline void __writeb (unsigned char val, volatile void __iomem *addr) { + mb(); *(volatile unsigned char __force *) addr = val; } static inline void __writew (unsigned short val, volatile void __iomem *addr) { + mb(); *(volatile unsigned short __force *) addr = val; } static inline void __writel (unsigned int val, volatile void __iomem *addr) { + mb(); *(volatile unsigned int __force *) addr = val; } static inline void __writeq (unsigned long val, volatile void __iomem *addr) { + mb(); *(volatile unsigned long __force *) addr = val; } diff --git a/arch/ia64/kernel/machvec.c b/arch/ia64/kernel/machvec.c index 7bfe98859911..1b604d02250b 100644 --- a/arch/ia64/kernel/machvec.c +++ b/arch/ia64/kernel/machvec.c @@ -73,19 +73,3 @@ machvec_timer_interrupt (int irq, void *dev_id) { } EXPORT_SYMBOL(machvec_timer_interrupt); - -void -machvec_dma_sync_single(struct device *hwdev, dma_addr_t dma_handle, size_t size, - enum dma_data_direction dir) -{ - mb(); -} -EXPORT_SYMBOL(machvec_dma_sync_single); - -void -machvec_dma_sync_sg(struct device *hwdev, struct scatterlist *sg, int n, - enum dma_data_direction dir) -{ - mb(); -} -EXPORT_SYMBOL(machvec_dma_sync_sg); diff --git a/arch/ia64/kernel/pci-dma.c b/arch/ia64/kernel/pci-dma.c index 3c2884bef3d4..2512aa3029f5 100644 --- a/arch/ia64/kernel/pci-dma.c +++ b/arch/ia64/kernel/pci-dma.c @@ -55,11 +55,6 @@ void __init pci_iommu_alloc(void) { dma_ops = &intel_dma_ops; - intel_dma_ops.sync_single_for_cpu = machvec_dma_sync_single; - intel_dma_ops.sync_sg_for_cpu = machvec_dma_sync_sg; - intel_dma_ops.sync_single_for_device = machvec_dma_sync_single; - intel_dma_ops.sync_sg_for_device = machvec_dma_sync_sg; - /* * The order of these functions is important for * fall-back/fail-over reasons -- 2.18.0 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] ia64: fix barrier placement for write* / dma mapping @ 2018-08-01 6:41 ` okaya-sgV2jX0FEOL9JmXXK+q4OQ 0 siblings, 0 replies; 10+ messages in thread From: okaya @ 2018-08-01 6:41 UTC (permalink / raw) To: Christoph Hellwig Cc: Tony Luck, Fenghua Yu, Arnd Bergmann, linux-ia64, linux-arch, linux-kernel, iommu, okaya + my new email On 2018-07-31 10:20, Christoph Hellwig wrote: > memory-barriers.txt has been updated with the following requirement. > > "When using writel(), a prior wmb() is not needed to guarantee that the > cache coherent memory writes have completed before writing to the MMIO > region." > > The current writeX() and iowriteX() implementations on ia64 are not > satisfying this requirement as the barrier is after the register write. > I asked this question to Tony Luck before. If I remember right, his answer was: CPU guarantees outstanding writes to be flushed when a register write instruction is executed and an additional barrier instruction is not needed. > This adds the missing memory barriers, and instead drops them from the > dma sync routine where they are misplaced (and were missing in the > more important map/unmap cases anyway). > > All this doesn't affect the SN2 platform, which already has barrier > in the I/O accessors, and none in dma mapping (but then again > swiotlb doesn't have any either). > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] ia64: fix barrier placement for write* / dma mapping @ 2018-08-01 6:41 ` okaya-sgV2jX0FEOL9JmXXK+q4OQ 0 siblings, 0 replies; 10+ messages in thread From: okaya @ 2018-08-01 6:41 UTC (permalink / raw) To: Christoph Hellwig Cc: Tony Luck, Fenghua Yu, Arnd Bergmann, linux-ia64, linux-arch, linux-kernel, iommu, okaya + my new email On 2018-07-31 10:20, Christoph Hellwig wrote: > memory-barriers.txt has been updated with the following requirement. > > "When using writel(), a prior wmb() is not needed to guarantee that the > cache coherent memory writes have completed before writing to the MMIO > region." > > The current writeX() and iowriteX() implementations on ia64 are not > satisfying this requirement as the barrier is after the register write. > I asked this question to Tony Luck before. If I remember right, his answer was: CPU guarantees outstanding writes to be flushed when a register write instruction is executed and an additional barrier instruction is not needed. > This adds the missing memory barriers, and instead drops them from the > dma sync routine where they are misplaced (and were missing in the > more important map/unmap cases anyway). > > All this doesn't affect the SN2 platform, which already has barrier > in the I/O accessors, and none in dma mapping (but then again > swiotlb doesn't have any either). > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] ia64: fix barrier placement for write* / dma mapping @ 2018-08-01 6:41 ` okaya-sgV2jX0FEOL9JmXXK+q4OQ 0 siblings, 0 replies; 10+ messages in thread From: okaya-sgV2jX0FEOL9JmXXK+q4OQ @ 2018-08-01 6:41 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-arch-u79uwXL29TY76Z2rM5mHXA, Fenghua Yu, Tony Luck, linux-ia64-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, okaya-DgEjT+Ai2ygdnm+yROfE0A, linux-kernel-u79uwXL29TY76Z2rM5mHXA, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA + my new email On 2018-07-31 10:20, Christoph Hellwig wrote: > memory-barriers.txt has been updated with the following requirement. > > "When using writel(), a prior wmb() is not needed to guarantee that the > cache coherent memory writes have completed before writing to the MMIO > region." > > The current writeX() and iowriteX() implementations on ia64 are not > satisfying this requirement as the barrier is after the register write. > I asked this question to Tony Luck before. If I remember right, his answer was: CPU guarantees outstanding writes to be flushed when a register write instruction is executed and an additional barrier instruction is not needed. > This adds the missing memory barriers, and instead drops them from the > dma sync routine where they are misplaced (and were missing in the > more important map/unmap cases anyway). > > All this doesn't affect the SN2 platform, which already has barrier > in the I/O accessors, and none in dma mapping (but then again > swiotlb doesn't have any either). > > Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org> > --- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] ia64: fix barrier placement for write* / dma mapping 2018-08-01 6:41 ` okaya-sgV2jX0FEOL9JmXXK+q4OQ @ 2018-08-01 7:29 ` Christoph Hellwig -1 siblings, 0 replies; 10+ messages in thread From: Christoph Hellwig @ 2018-08-01 7:29 UTC (permalink / raw) To: okaya Cc: Christoph Hellwig, Tony Luck, Fenghua Yu, Arnd Bergmann, linux-ia64, linux-arch, linux-kernel, iommu, okaya On Tue, Jul 31, 2018 at 11:41:23PM -0700, okaya@codeaurora.org wrote: > I asked this question to Tony Luck before. If I remember right, > his answer was: > > CPU guarantees outstanding writes to be flushed when a register write > instruction is executed and an additional barrier instruction is not > needed. That would be great. It still doesn't explain the barriers in the dma sync routines. Those have been there since the following commit in the history tree: commit 66b99421d118a5ddd98a72913670b0fcf0a38d45 Author: Andrew Morton <akpm@osdl.org> Date: Sat Mar 13 17:05:37 2004 -0800 [PATCH] DMA: Fill gaping hole in DMA API interfaces. From: "David S. Miller" <davem@redhat.com> which in fact only added them for the HP zx1 platform, and doesn't contain any good explanation of why we need a barrier. So I guess the right answer might be to just remove these barriers without replacement. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] ia64: fix barrier placement for write* / dma mapping @ 2018-08-01 7:29 ` Christoph Hellwig 0 siblings, 0 replies; 10+ messages in thread From: Christoph Hellwig @ 2018-08-01 7:29 UTC (permalink / raw) To: okaya Cc: Christoph Hellwig, Tony Luck, Fenghua Yu, Arnd Bergmann, linux-ia64, linux-arch, linux-kernel, iommu, okaya On Tue, Jul 31, 2018 at 11:41:23PM -0700, okaya@codeaurora.org wrote: > I asked this question to Tony Luck before. If I remember right, > his answer was: > > CPU guarantees outstanding writes to be flushed when a register write > instruction is executed and an additional barrier instruction is not > needed. That would be great. It still doesn't explain the barriers in the dma sync routines. Those have been there since the following commit in the history tree: commit 66b99421d118a5ddd98a72913670b0fcf0a38d45 Author: Andrew Morton <akpm@osdl.org> Date: Sat Mar 13 17:05:37 2004 -0800 [PATCH] DMA: Fill gaping hole in DMA API interfaces. From: "David S. Miller" <davem@redhat.com> which in fact only added them for the HP zx1 platform, and doesn't contain any good explanation of why we need a barrier. So I guess the right answer might be to just remove these barriers without replacement. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] ia64: fix barrier placement for write* / dma mapping 2018-08-01 7:29 ` Christoph Hellwig @ 2018-08-01 8:00 ` Sinan Kaya -1 siblings, 0 replies; 10+ messages in thread From: Sinan Kaya @ 2018-08-01 8:00 UTC (permalink / raw) To: Christoph Hellwig, okaya Cc: Tony Luck, Fenghua Yu, Arnd Bergmann, linux-ia64, linux-arch, linux-kernel, iommu On 8/1/2018 12:29 AM, Christoph Hellwig wrote: >> I asked this question to Tony Luck before. If I remember right, >> his answer was: >> >> CPU guarantees outstanding writes to be flushed when a register write >> instruction is executed and an additional barrier instruction is not >> needed. > That would be great. It still doesn't explain the barriers in the > dma sync routines. Those have been there since the following commit > in the history tree: Yeah, I'll let Tony confirm my understanding. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] ia64: fix barrier placement for write* / dma mapping @ 2018-08-01 8:00 ` Sinan Kaya 0 siblings, 0 replies; 10+ messages in thread From: Sinan Kaya @ 2018-08-01 8:00 UTC (permalink / raw) To: Christoph Hellwig, okaya Cc: Tony Luck, Fenghua Yu, Arnd Bergmann, linux-ia64, linux-arch, linux-kernel, iommu On 8/1/2018 12:29 AM, Christoph Hellwig wrote: >> I asked this question to Tony Luck before. If I remember right, >> his answer was: >> >> CPU guarantees outstanding writes to be flushed when a register write >> instruction is executed and an additional barrier instruction is not >> needed. > That would be great. It still doesn't explain the barriers in the > dma sync routines. Those have been there since the following commit > in the history tree: Yeah, I'll let Tony confirm my understanding. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-08-01 8:00 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-07-31 17:20 barriers vs I/O and DMA for ia64 Christoph Hellwig 2018-07-31 17:20 ` [PATCH] ia64: fix barrier placement for write* / dma mapping Christoph Hellwig 2018-07-31 17:20 ` Christoph Hellwig 2018-08-01 6:41 ` okaya 2018-08-01 6:41 ` okaya 2018-08-01 6:41 ` okaya-sgV2jX0FEOL9JmXXK+q4OQ 2018-08-01 7:29 ` Christoph Hellwig 2018-08-01 7:29 ` Christoph Hellwig 2018-08-01 8:00 ` Sinan Kaya 2018-08-01 8:00 ` Sinan Kaya
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.