Skip to contentSkip to conversation

make the non-consistent DMA allocator more userful (resend)

PATCH In review Christoph Hellwig 5 participants 21 messages Dec 8, 2018 – Dec 15, 2018 7 messages not in the archive

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

[sorry for the spam, had to resend due a wrongly typed linux-arm-kernel
address]

Hi all,

we had all kinds of discussions about how to best allocate DMAable memory without having to deal with the problem that your normal "coherent" DMA allocator can be very slow on platforms where DMA is not DMA coherent.

To work around this drivers basically two choices at the moment:

(1) just allocate memory using the page or slab allocator and the call one of the dma_map_* APIs on it. This has a few drawbacks:

- normal GFP_KERNEL memory might not actually be DMA addressable for all devices, forcing fallbacks to slow bounce buffering
- there is no easy way to access the CMA allocator for large chunks, or to map small pages into single device and virtually contigous chunks using the iommu and vmap

(2) use dma_alloc_attrs with the DMA_ATTR_NON_CONSISTENT flag. This has a different set of drawbacks

- only very few architectures actually implement this API fully, if it is not implemented it falls back to the potentially uncached and slow coherent allocator
- the dma_cache_sync API to use with it is not very well specified and problematic in that it does not clearly transfer ownership

Based on that I've been planning to introduce a proper API for allocating DMAable memory for a while. In the end I've ended up improving the DMA_ATTR_NON_CONSISTENT flag instead of designing something new. To make it useful we need to:

(a) ensure we don't fall back to the slow coherent allocator except on fully coherent platforms where they are the same anyway
(b) replace the odd dma_cache_sync calls with the proper dma_sync_* APIs that we also use for other ownership trasnfers

This turned out to be surprisingly simple now that we have consolidated most of the direct mapping code. Note that this series is missing the updates for powerpc which is in the process of being migrated to the common direct mapping code in another series and would be covered by that.

Note that these patches don't use iommu/vmap coalescing as they can be problematic depending on the cache architecture. But we could opt into those when we know we don't have cache interaction problems based on the API.

All the patches are on top of the dma-mapping for-net tree and also available as a git tree here:

git://git.infradead.org/users/hch/misc.git dma-noncoherent-allocator

Gitweb:

http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-noncoherent-allocator

#1 lore raw

PATCH 1/6 sparc: remove no needed sbus_dma_ops methods

No need to BUG_ON() on the cache maintainance ops - they are no-ops by default, and there is nothing in the DMA API contract that prohibits calling them on sbus devices (even if such drivers are unlikely to ever appear).

Similarly a dma_supported method that always returns 0 is rather pointless. The only thing that indicates is that no one ever calls the method on sbus devices.

---
 arch/sparc/kernel/ioport.c | 20 --------------------
 1 file changed, 20 deletions(-)
arch/sparc/kernel/ioport.c +0 -20
index 6799c93c9f27..4b2167a0ec0b 100644
@@ -391,23 +391,6 @@ static void sbus_unmap_sg(struct device *dev, struct scatterlist *sg, int n,
 	mmu_release_scsi_sgl(dev, sg, n);
 }
 
-static void sbus_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
-				 int n,	enum dma_data_direction dir)
-{
-	BUG();
-}
-
-static void sbus_sync_sg_for_device(struct device *dev, struct scatterlist *sg,
-				    int n, enum dma_data_direction dir)
-{
-	BUG();
-}
-
-static int sbus_dma_supported(struct device *dev, u64 mask)
-{
-	return 0;
-}
-
 static const struct dma_map_ops sbus_dma_ops = {
 	.alloc			= sbus_alloc_coherent,
 	.free			= sbus_free_coherent,
@@ -415,9 +398,6 @@ static const struct dma_map_ops sbus_dma_ops = {
 	.unmap_page		= sbus_unmap_page,
 	.map_sg			= sbus_map_sg,
 	.unmap_sg		= sbus_unmap_sg,
-	.sync_sg_for_cpu	= sbus_sync_sg_for_cpu,
-	.sync_sg_for_device	= sbus_sync_sg_for_device,
-	.dma_supported		= sbus_dma_supported,
 };
 
 static int __init sparc_register_ioport(void)
Signature · 1 line
2.19.2

A message that is not in the archive (sent off-list or not yet received): [email protected]

Acked-by
#3 lore raw

Re: [PATCH 1/6] sparc: remove no needed sbus_dma_ops methods

From: Christoph Hellwig <[email protected]>
Date: Sat, 8 Dec 2018 09:41:10 -0800

Quoted 10 lines

No need to BUG_ON() on the cache maintainance ops - they are no-ops by default, and there is nothing in the DMA API contract that prohibits calling them on sbus devices (even if such drivers are unlikely to ever appear).

Similarly a dma_supported method that always returns 0 is rather pointless. The only thing that indicates is that no one ever calls the method on sbus devices.

#4 lore raw

PATCH 2/6 sparc: factor the dma coherent mapping into helper

In reply to Christoph Hellwig

Factor the code to remap memory returned from the DMA coherent allocator into two helpers that can be shared by the IOMMU and direct mapping code.

---
 arch/sparc/kernel/ioport.c | 151 ++++++++++++++++---------------------
 1 file changed, 67 insertions(+), 84 deletions(-)
arch/sparc/kernel/ioport.c +67 -84
index 4b2167a0ec0b..fd7a41c6d688 100644
@@ -247,6 +247,53 @@ static void _sparc_free_io(struct resource *res)
 	release_resource(res);
 }
 
+static unsigned long sparc_dma_alloc_resource(struct device *dev, size_t len)
+{
+	struct resource *res;
+
+	res = kzalloc(sizeof(*res), GFP_KERNEL);
+	if (!res)
+		return 0;
+	res->name = dev->of_node->name;
+
+	if (allocate_resource(&_sparc_dvma, res, len, _sparc_dvma.start,
+			_sparc_dvma.end, PAGE_SIZE, NULL, NULL) != 0) {
+		printk("sbus_alloc_consistent: cannot occupy 0x%zx", len);
+		kfree(res);
+		return 0;
+	}
+
+	return res->start;
+}
+
+static bool sparc_dma_free_resource(void *cpu_addr, size_t size)
+{
+	unsigned long addr = (unsigned long)cpu_addr;
+	struct resource *res;
+
+	res = lookup_resource(&_sparc_dvma, addr);
+	if (!res) {
+		printk("%s: cannot free %p\n", __func__, cpu_addr);
+		return false;
+	}
+
+	if ((addr & (PAGE_SIZE - 1)) != 0) {
+		printk("%s: unaligned va %p\n", __func__, cpu_addr);
+		return false;
+	}
+
+	size = PAGE_ALIGN(size);
+	if (resource_size(res) != size) {
+		printk("%s: region 0x%lx asked 0x%zx\n",
+			__func__, (long)resource_size(res), size);
+		return false;
+	}
+
+	release_resource(res);
+	kfree(res);
+	return true;
+}
+
 #ifdef CONFIG_SBUS
 
 void sbus_set_sbus64(struct device *dev, int x)
@@ -264,10 +311,8 @@ static void *sbus_alloc_coherent(struct device *dev, size_t len,
 				 dma_addr_t *dma_addrp, gfp_t gfp,
 				 unsigned long attrs)
 {
-	struct platform_device *op = to_platform_device(dev);
 	unsigned long len_total = PAGE_ALIGN(len);
-	unsigned long va;
-	struct resource *res;
+	unsigned long va, addr;
 	int order;
 
 	/* XXX why are some lengths signed, others unsigned? */
@@ -284,32 +329,23 @@ static void *sbus_alloc_coherent(struct device *dev, size_t len,
 	if (va == 0)
 		goto err_nopages;
 
-	if ((res = kzalloc(sizeof(struct resource), GFP_KERNEL)) == NULL)
+	addr = sparc_dma_alloc_resource(dev, len_total);
+	if (!addr)
 		goto err_nomem;
 
-	if (allocate_resource(&_sparc_dvma, res, len_total,
-	    _sparc_dvma.start, _sparc_dvma.end, PAGE_SIZE, NULL, NULL) != 0) {
-		printk("sbus_alloc_consistent: cannot occupy 0x%lx", len_total);
-		goto err_nova;
-	}
-
 	// XXX The sbus_map_dma_area does this for us below, see comments.
 	// srmmu_mapiorange(0, virt_to_phys(va), res->start, len_total);
 	/*
 	 * XXX That's where sdev would be used. Currently we load
 	 * all iommu tables with the same translations.
 	 */
-	if (sbus_map_dma_area(dev, dma_addrp, va, res->start, len_total) != 0)
+	if (sbus_map_dma_area(dev, dma_addrp, va, addr, len_total) != 0)
 		goto err_noiommu;
 
-	res->name = op->dev.of_node->name;
-
-	return (void *)(unsigned long)res->start;
+	return (void *)addr;
 
 err_noiommu:
-	release_resource(res);
-err_nova:
-	kfree(res);
+	sparc_dma_free_resource((void *)addr, len_total);
 err_nomem:
 	free_pages(va, order);
 err_nopages:
@@ -319,29 +355,11 @@ static void *sbus_alloc_coherent(struct device *dev, size_t len,
 static void sbus_free_coherent(struct device *dev, size_t n, void *p,
 			       dma_addr_t ba, unsigned long attrs)
 {
-	struct resource *res;
 	struct page *pgv;
 
-	if ((res = lookup_resource(&_sparc_dvma,
-	    (unsigned long)p)) == NULL) {
-		printk("sbus_free_consistent: cannot free %p\n", p);
-		return;
-	}
-
-	if (((unsigned long)p & (PAGE_SIZE-1)) != 0) {
-		printk("sbus_free_consistent: unaligned va %p\n", p);
-		return;
-	}
-
 	n = PAGE_ALIGN(n);
-	if (resource_size(res) != n) {
-		printk("sbus_free_consistent: region 0x%lx asked 0x%zx\n",
-		    (long)resource_size(res), n);
+	if (!sparc_dma_free_resource(p, n))
 		return;
-	}
-
-	release_resource(res);
-	kfree(res);
 
 	pgv = virt_to_page(p);
 	sbus_unmap_dma_area(dev, ba, n);
@@ -418,45 +436,30 @@ arch_initcall(sparc_register_ioport);
 void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
 		gfp_t gfp, unsigned long attrs)
 {
-	unsigned long len_total = PAGE_ALIGN(size);
+	unsigned long addr;
 	void *va;
-	struct resource *res;
-	int order;
 
-	if (size == 0) {
+	if (!size || size > 256 * 1024)	/* __get_free_pages() limit */
 		return NULL;
-	}
-	if (size > 256*1024) {			/* __get_free_pages() limit */
-		return NULL;
-	}
 
-	order = get_order(len_total);
-	va = (void *) __get_free_pages(gfp, order);
-	if (va == NULL) {
-		printk("%s: no %ld pages\n", __func__, len_total>>PAGE_SHIFT);
-		goto err_nopages;
+	size = PAGE_ALIGN(size);
+	va = (void *) __get_free_pages(gfp, get_order(size));
+	if (!va) {
+		printk("%s: no %zd pages\n", __func__, size >> PAGE_SHIFT);
+		return NULL;
 	}
 
-	if ((res = kzalloc(sizeof(struct resource), GFP_KERNEL)) == NULL) {
-		printk("%s: no core\n", __func__);
+	addr = sparc_dma_alloc_resource(dev, size);
+	if (!addr)
 		goto err_nomem;
-	}
 
-	if (allocate_resource(&_sparc_dvma, res, len_total,
-	    _sparc_dvma.start, _sparc_dvma.end, PAGE_SIZE, NULL, NULL) != 0) {
-		printk("%s: cannot occupy 0x%lx", __func__, len_total);
-		goto err_nova;
-	}
-	srmmu_mapiorange(0, virt_to_phys(va), res->start, len_total);
+	srmmu_mapiorange(0, virt_to_phys(va), addr, size);
 
 	*dma_handle = virt_to_phys(va);
-	return (void *) res->start;
+	return (void *)addr;
 
-err_nova:
-	kfree(res);
 err_nomem:
-	free_pages((unsigned long)va, order);
-err_nopages:
+	free_pages((unsigned long)va, get_order(size));
 	return NULL;
 }
 
@@ -471,31 +474,11 @@ void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
 void arch_dma_free(struct device *dev, size_t size, void *cpu_addr,
 		dma_addr_t dma_addr, unsigned long attrs)
 {
-	struct resource *res;
-
-	if ((res = lookup_resource(&_sparc_dvma,
-	    (unsigned long)cpu_addr)) == NULL) {
-		printk("%s: cannot free %p\n", __func__, cpu_addr);
-		return;
-	}
-
-	if (((unsigned long)cpu_addr & (PAGE_SIZE-1)) != 0) {
-		printk("%s: unaligned va %p\n", __func__, cpu_addr);
+	if (!sparc_dma_free_resource(cpu_addr, PAGE_ALIGN(size)))
 		return;
-	}
-
-	size = PAGE_ALIGN(size);
-	if (resource_size(res) != size) {
-		printk("%s: region 0x%lx asked 0x%zx\n", __func__,
-		    (long)resource_size(res), size);
-		return;
-	}
 
 	dma_make_coherent(dma_addr, size);
 	srmmu_unmapiorange((unsigned long)cpu_addr, size);
-
-	release_resource(res);
-	kfree(res);
 	free_pages((unsigned long)phys_to_virt(dma_addr), get_order(size));
 }
 
Signature · 1 line
2.19.2
maintainer Acked-by on v1 2/6
#5 lore raw

Re: [PATCH 2/6] sparc: factor the dma coherent mapping into helper

From: Christoph Hellwig <[email protected]>
Date: Sat, 8 Dec 2018 09:41:11 -0800

Quoted 4 lines

Factor the code to remap memory returned from the DMA coherent allocator into two helpers that can be shared by the IOMMU and direct mapping code.

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#6 lore raw

PATCH 3/6 sparc: remove the sparc32_dma_ops indirection

In reply to Christoph Hellwig

There is no good reason to have a double indirection for the sparc32 dma ops, so remove the sparc32_dma_ops and define separate dma_map_ops instance for the different IOMMU types.

---
 arch/sparc/include/asm/dma.h |  48 +-----------
 arch/sparc/kernel/ioport.c   | 124 +------------------------------
 arch/sparc/mm/io-unit.c      |  65 ++++++++++++-----
 arch/sparc/mm/iommu.c        | 137 ++++++++++++++++++++++-------------
 4 files changed, 138 insertions(+), 236 deletions(-)
arch/sparc/include/asm/dma.h +2 -46
index a1d7c86917c6..462e7c794a09 100644
@@ -91,54 +91,10 @@ extern int isa_dma_bridge_buggy;
 #endif
 
 #ifdef CONFIG_SPARC32
-
-/* Routines for data transfer buffers. */
 struct device;
-struct scatterlist;
-
-struct sparc32_dma_ops {
-	__u32 (*get_scsi_one)(struct device *, char *, unsigned long);
-	void (*get_scsi_sgl)(struct device *, struct scatterlist *, int);
-	void (*release_scsi_one)(struct device *, __u32, unsigned long);
-	void (*release_scsi_sgl)(struct device *, struct scatterlist *,int);
-#ifdef CONFIG_SBUS
-	int (*map_dma_area)(struct device *, dma_addr_t *, unsigned long, unsigned long, int);
-	void (*unmap_dma_area)(struct device *, unsigned long, int);
-#endif
-};
-extern const struct sparc32_dma_ops *sparc32_dma_ops;
-
-#define mmu_get_scsi_one(dev,vaddr,len) \
-	sparc32_dma_ops->get_scsi_one(dev, vaddr, len)
-#define mmu_get_scsi_sgl(dev,sg,sz) \
-	sparc32_dma_ops->get_scsi_sgl(dev, sg, sz)
-#define mmu_release_scsi_one(dev,vaddr,len) \
-	sparc32_dma_ops->release_scsi_one(dev, vaddr,len)
-#define mmu_release_scsi_sgl(dev,sg,sz) \
-	sparc32_dma_ops->release_scsi_sgl(dev, sg, sz)
-
-#ifdef CONFIG_SBUS
-/*
- * mmu_map/unmap are provided by iommu/iounit; Invalid to call on IIep.
- *
- * The mmu_map_dma_area establishes two mappings in one go.
- * These mappings point to pages normally mapped at 'va' (linear address).
- * First mapping is for CPU visible address at 'a', uncached.
- * This is an alias, but it works because it is an uncached mapping.
- * Second mapping is for device visible address, or "bus" address.
- * The bus address is returned at '*pba'.
- *
- * These functions seem distinct, but are hard to split.
- * On sun4m, page attributes depend on the CPU type, so we have to
- * know if we are mapping RAM or I/O, so it has to be an additional argument
- * to a separate mapping function for CPU visible mappings.
- */
-#define sbus_map_dma_area(dev,pba,va,a,len) \
-	sparc32_dma_ops->map_dma_area(dev, pba, va, a, len)
-#define sbus_unmap_dma_area(dev,ba,len) \
-	sparc32_dma_ops->unmap_dma_area(dev, ba, len)
-#endif /* CONFIG_SBUS */
 
+unsigned long sparc_dma_alloc_resource(struct device *dev, size_t len);
+bool sparc_dma_free_resource(void *cpu_addr, size_t size);
 #endif
 
 #endif /* !(_ASM_SPARC_DMA_H) */
arch/sparc/kernel/ioport.c +3 -121

154 lines not on this page · raw message

arch/sparc/mm/io-unit.c +47 -18

129 lines not on this page · raw message

arch/sparc/mm/iommu.c +86 -51

238 lines not on this page · raw message

Signature · 6 lines
2.19.2

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
maintainer Acked-by on v1 3/6
#7 lore raw

Re: [PATCH 3/6] sparc: remove the sparc32_dma_ops indirection

From: Christoph Hellwig <[email protected]>
Date: Sat, 8 Dec 2018 09:41:12 -0800

Quoted 5 lines

There is no good reason to have a double indirection for the sparc32 dma ops, so remove the sparc32_dma_ops and define separate dma_map_ops instance for the different IOMMU types.

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

A message that is not in the archive (sent off-list or not yet received): [email protected]

#9 lore raw

Re: [PATCH 3/6] sparc: remove the sparc32_dma_ops indirection

Quoted 4 lines · Christoph Hellwig

There is no good reason to have a double indirection for the sparc32 dma ops, so remove the sparc32_dma_ops and define separate dma_map_ops instance for the different IOMMU types.

Except maybe this:

scsi host0: esp
scsi host0: Data transfer overflow.
scsi host0: cur_residue[0] tot_residue[-36] len[36]
scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5
scsi target0:0:0: Beginning Domain Validation scsi host0: Data transfer overflow.
scsi host0: cur_residue[0] tot_residue[-36] len[36] scsi host0: Data transfer overflow.
scsi host0: cur_residue[0] tot_residue[-36] len[36] scsi host0: Data transfer overflow.
scsi host0: cur_residue[0] tot_residue[-36] len[36] scsi host0: Data transfer overflow.
scsi host0: cur_residue[0] tot_residue[-36] len[36]

and so on, until qemu is terminated. This is seen with all sparc32 qemu emulations. Reverting the patch fixes the problem.

Guenter

A message that is not in the archive (sent off-list or not yet received): [email protected]

#11 lore raw

Re: [PATCH 3/6] sparc: remove the sparc32_dma_ops indirection

Quoted 2 lines · Guenter Roeck

and so on, until qemu is terminated. This is seen with all sparc32 qemu emulations. Reverting the patch fixes the problem.

Hi Guenter,

can you check which of the three new ops is used in this case? Or provide the qemu config and rootfs?

A message that is not in the archive (sent off-list or not yet received): [email protected]

#13 lore raw

Re: [PATCH 3/6] sparc: remove the sparc32_dma_ops indirection

Quoted 9 lines · Christoph Hellwig
Quoted 2 lines · Guenter Roeck

and so on, until qemu is terminated. This is seen with all sparc32 qemu emulations. Reverting the patch fixes the problem.

Hi Guenter,

can you check which of the three new ops is used in this case? Or provide the qemu config and rootfs?

sparc32 defconfig+CONFIG_SQUASHFS=y+CONFIG_DEVTMPFS=y, and:

qemu-system-sparc -M SPARCClassic -kernel arch/sparc/boot/image \
	-no-reboot -snapshot -drive file=/var/cache/buildbot/sparc/hda.sqf,if=scsi,format=raw \
	-append 'root=/dev/sda rw init=/sbin/init.sh panic=1 console=ttyS0' \
	-nographic

qemu version doesn't seem to matter. I used gcc-7.3.0 using the toolchain from kernel.org to build the image.

Root file system is at https://github.com/groeck/linux-build-test/tree/master/rootfs/sparc/.

Guenter

#14 lore raw

PATCH 4/6 sparc: remove not required includes from dma-mapping.h

In reply to Christoph Hellwig

The only thing we need to explicitly pull in is the defines for the CPU type.

---
 arch/sparc/include/asm/dma-mapping.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
arch/sparc/include/asm/dma-mapping.h +1 -3
index b0bb2fcaf1c9..55a44f08a9a4 100644
@@ -2,9 +2,7 @@
 #ifndef ___ASM_SPARC_DMA_MAPPING_H
 #define ___ASM_SPARC_DMA_MAPPING_H
 
-#include <linux/scatterlist.h>
-#include <linux/mm.h>
-#include <linux/dma-debug.h>
+#include <asm/cpu_type.h>
 
 extern const struct dma_map_ops *dma_ops;
 
Signature · 6 lines
2.19.2

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

A message that is not in the archive (sent off-list or not yet received): [email protected]

#17 lore raw

PATCH 5/6 sparc: move the leon PCI memory space comment to <asm/leon.h>

In reply to Christoph Hellwig

It has nothing to do with the content of the pci.h header.

Suggested by: Sam Ravnborg <[email protected]>

---
 arch/sparc/include/asm/leon.h   | 9 +++++++++
 arch/sparc/include/asm/pci_32.h | 9 ---------
 2 files changed, 9 insertions(+), 9 deletions(-)
arch/sparc/include/asm/leon.h +9 -0
index c68bb5b76e3d..77ea406ff9df 100644
@@ -255,4 +255,13 @@ extern int leon_ipi_irq;
 #define _pfn_valid(pfn)	 ((pfn < last_valid_pfn) && (pfn >= PFN(phys_base)))
 #define _SRMMU_PTE_PMASK_LEON 0xffffffff
 
+/*
+ * On LEON PCI Memory space is mapped 1:1 with physical address space.
+ *
+ * I/O space is located at low 64Kbytes in PCI I/O space. The I/O addresses
+ * are converted into CPU addresses to virtual addresses that are mapped with
+ * MMU to the PCI Host PCI I/O space window which are translated to the low
+ * 64Kbytes by the Host controller.
+ */
+
 #endif
arch/sparc/include/asm/pci_32.h +0 -9
index cfc0ee9476c6..a475380ea108 100644
@@ -23,15 +23,6 @@
 /* generic pci stuff */
 #include <asm-generic/pci.h>
 #else
-/*
- * On LEON PCI Memory space is mapped 1:1 with physical address space.
- *
- * I/O space is located at low 64Kbytes in PCI I/O space. The I/O addresses
- * are converted into CPU addresses to virtual addresses that are mapped with
- * MMU to the PCI Host PCI I/O space window which are translated to the low
- * 64Kbytes by the Host controller.
- */
-
 static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
 {
 	return PCI_IRQ_NONE;
Signature · 6 lines
2.19.2

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
maintainer Acked-by on v1 5/6
#18 lore raw

Re: [PATCH 5/6] sparc: move the leon PCI memory space comment to <asm/leon.h>

From: Christoph Hellwig <[email protected]>
Date: Sat, 8 Dec 2018 09:41:14 -0800

Quoted 4 lines

It has nothing to do with the content of the pci.h header.

Suggested by: Sam Ravnborg <[email protected]>

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#19 lore raw

PATCH 6/6 sparc: merge 32-bit and 64-bit version of pci.h

In reply to Christoph Hellwig

There are enough common defintions that a single header seems nicer.

Also drop the pointless <linux/dma-mapping.h> include.

---
 arch/sparc/include/asm/pci.h    | 53 ++++++++++++++++++++++++++++++---
 arch/sparc/include/asm/pci_32.h | 32 --------------------
 arch/sparc/include/asm/pci_64.h | 52 --------------------------------
 3 files changed, 49 insertions(+), 88 deletions(-)
 delete mode 100644 arch/sparc/include/asm/pci_32.h
 delete mode 100644 arch/sparc/include/asm/pci_64.h
arch/sparc/include/asm/pci.h +49 -4
index cad79a6ce0e4..cfec79bb1831 100644
@@ -1,9 +1,54 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 #ifndef ___ASM_SPARC_PCI_H
 #define ___ASM_SPARC_PCI_H
-#if defined(__sparc__) && defined(__arch64__)
-#include <asm/pci_64.h>
+
+
+/* Can be used to override the logic in pci_scan_bus for skipping
+ * already-configured bus numbers - to be used for buggy BIOSes
+ * or architectures with incomplete PCI setup by the loader.
+ */
+#define pcibios_assign_all_busses()	0
+
+#define PCIBIOS_MIN_IO		0UL
+#define PCIBIOS_MIN_MEM		0UL
+
+#define PCI_IRQ_NONE		0xffffffff
+
+
+#ifdef CONFIG_SPARC64
+
+/* PCI IOMMU mapping bypass support. */
+
+/* PCI 64-bit addressing works for all slots on all controller
+ * types on sparc64.  However, it requires that the device
+ * can drive enough of the 64 bits.
+ */
+#define PCI64_REQUIRED_MASK	(~(u64)0)
+#define PCI64_ADDR_BASE		0xfffc000000000000UL
+
+/* Return the index of the PCI controller for device PDEV. */
+int pci_domain_nr(struct pci_bus *bus);
+static inline int pci_proc_domain(struct pci_bus *bus)
+{
+	return 1;
+}
+
+/* Platform support for /proc/bus/pci/X/Y mmap()s. */
+#define HAVE_PCI_MMAP
+#define arch_can_pci_mmap_io()	1
+#define HAVE_ARCH_PCI_GET_UNMAPPED_AREA
+#define get_pci_unmapped_area get_fb_unmapped_area
+
+#define HAVE_ARCH_PCI_RESOURCE_TO_USER
+#endif /* CONFIG_SPARC64 */
+
+#if defined(CONFIG_SPARC64) || defined(CONFIG_LEON_PCI)
+static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
+{
+	return PCI_IRQ_NONE;
+}
 #else
-#include <asm/pci_32.h>
-#endif
+#include <asm-generic/pci.h>
 #endif
+
+#endif /* ___ASM_SPARC_PCI_H */
arch/sparc/include/asm/pci_32.h deleted +0 -32
deleted file mode 100644
index a475380ea108..000000000000
@@ -1,32 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __SPARC_PCI_H
-#define __SPARC_PCI_H
-
-#ifdef __KERNEL__
-
-#include <linux/dma-mapping.h>
-
-/* Can be used to override the logic in pci_scan_bus for skipping
- * already-configured bus numbers - to be used for buggy BIOSes
- * or architectures with incomplete PCI setup by the loader.
- */
-#define pcibios_assign_all_busses()	0
-
-#define PCIBIOS_MIN_IO		0UL
-#define PCIBIOS_MIN_MEM		0UL
-
-#define PCI_IRQ_NONE		0xffffffff
-
-#endif /* __KERNEL__ */
-
-#ifndef CONFIG_LEON_PCI
-/* generic pci stuff */
-#include <asm-generic/pci.h>
-#else
-static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
-{
-	return PCI_IRQ_NONE;
-}
-#endif
-
-#endif /* __SPARC_PCI_H */
arch/sparc/include/asm/pci_64.h deleted +0 -52

52 lines not on this page · raw message

Signature · 6 lines
2.19.2

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
maintainer Acked-by on v1 6/6
#20 lore raw

Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h

From: Christoph Hellwig <[email protected]>
Date: Sat, 8 Dec 2018 09:41:15 -0800

Quoted 6 lines

There are enough common defintions that a single header seems nicer.

Also drop the pointless <linux/dma-mapping.h> include.

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

maintainer
#22 lore raw

Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h

From: Christoph Hellwig <[email protected]>
Date: Mon, 10 Dec 2018 17:32:56 +0100

Quoted 3 lines

Dave, can you pick the series up through the sparc tree? I could also merge it through the dma-mapping tree, but given that there is no dependency on it the sparc tree seem like the better fit.

I thought that some of this is a prerequisite for the DMA mapping work and overall consolidation you are doing. So I kinda assumed you wanted to merge it via your tree.

I anticipate no conflicts at all, even until the next merge window, so it could very easily go through your tree.

Let me know if you still want me to merge this.

Thanks.
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

A message that is not in the archive (sent off-list or not yet received): 20181210.101039.1882227517259366533.davem-fT/PcQaiUtIeIZ0/[email protected]

#24 lore raw

Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h

Quoted 7 lines · David Miller

From: Christoph Hellwig <[email protected]>
Date: Mon, 10 Dec 2018 17:32:56 +0100

Quoted 3 lines

Dave, can you pick the series up through the sparc tree? I could also merge it through the dma-mapping tree, but given that there is no dependency on it the sparc tree seem like the better fit.

Quoted 8 lines

I thought that some of this is a prerequisite for the DMA mapping work and overall consolidation you are doing. So I kinda assumed you wanted to merge it via your tree.

I anticipate no conflicts at all, even until the next merge window, so it could very easily go through your tree.

Let me know if you still want me to merge this.

These patches are purely cleanups I found while auditing the DMA mapping code, at least as of now there are no dependencies.

That being said now that I looked into it a bit more they do however depend on the ->mapping_error removal, so I'll take them through the dma-mapping tree.

maintainer
#25 lore raw

Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h

From: Christoph Hellwig <[email protected]>
Date: Mon, 10 Dec 2018 20:22:28 +0100

Quoted 15 lines · David Miller
Quoted 14 lines

From: Christoph Hellwig <[email protected]>
Date: Mon, 10 Dec 2018 17:32:56 +0100

Quoted 3 lines

Dave, can you pick the series up through the sparc tree? I could also merge it through the dma-mapping tree, but given that there is no dependency on it the sparc tree seem like the better fit.

I thought that some of this is a prerequisite for the DMA mapping work and overall consolidation you are doing. So I kinda assumed you wanted to merge it via your tree.

I anticipate no conflicts at all, even until the next merge window, so it could very easily go through your tree.

Quoted 8 lines
Quoted 1 line

Let me know if you still want me to merge this.

These patches are purely cleanups I found while auditing the DMA mapping code, at least as of now there are no dependencies.

That being said now that I looked into it a bit more they do however depend on the ->mapping_error removal, so I'll take them through the dma-mapping tree.

Ok, thanks.
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

A message that is not in the archive (sent off-list or not yet received): 20181210.113310.460303100337934249.davem-fT/PcQaiUtIeIZ0/[email protected]

#27 lore raw

Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h

I've pulled this into the dma-mapping for-next tree now.