public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] move consistent_dma_mask to the generic device
@ 2004-02-26 16:53 James Bottomley
  2004-02-27  6:57 ` Jeremy Higdon
  0 siblings, 1 reply; 3+ messages in thread
From: James Bottomley @ 2004-02-26 16:53 UTC (permalink / raw)
  To: Andrew Morton, willy, Jes Sorensen, Grant Grundler,
	alex.williamson, jbarnes, jeremy, ak
  Cc: Linux Kernel

This is a reroll of the previous patch.  It fixes up badness in the
sound drivers which were accessing the dma_mask directly instead of
using the accessor functions.

It also modifies the arch's that were using consistent_dma_mask:

x86_64, ia64 (both sn and hp) and parisc

Here's the previous description:


pci_dev.consistent_dma_mask was introduced to get around problems in the
IA64 Altix machine. 

Now, we have a use for it in x86: the aacraid needs coherent memory in a
31 bit address range (2GB).  Unfortunately, x86 is converted to the dma
model, so it can't see the pci_dev by the time coherent memory is
allocated. 

The solution to all of this is to move pci_dev.consistent_dma_mask to
dev.coherent_dma_mask and make x86 use it in the dma_alloc_coherent()
calls. 

This should allow me to make the aacraid set the coherent mask instead
of using it's current dma_mask juggling. 

James

===== arch/i386/kernel/pci-dma.c 1.11 vs edited =====
--- 1.11/arch/i386/kernel/pci-dma.c	Mon Jan 13 10:28:47 2003
+++ edited/arch/i386/kernel/pci-dma.c	Thu Feb 26 10:26:01 2004
@@ -20,8 +20,9 @@
 	/* ignore region specifiers */
 	gfp &= ~(__GFP_DMA | __GFP_HIGHMEM);
 
-	if (dev == NULL || (*dev->dma_mask < 0xffffffff))
+	if (dev == NULL || (dev->coherent_dma_mask < 0xffffffff))
 		gfp |= GFP_DMA;
+
 	ret = (void *)__get_free_pages(gfp, get_order(size));
 
 	if (ret != NULL) {
===== arch/ia64/hp/common/sba_iommu.c 1.37 vs edited =====
--- 1.37/arch/ia64/hp/common/sba_iommu.c	Mon Feb  2 09:58:46 2004
+++ edited/arch/ia64/hp/common/sba_iommu.c	Thu Feb 26 10:21:49 2004
@@ -1055,13 +1055,13 @@
 	*dma_handle = virt_to_phys(addr);
 
 #ifdef ALLOW_IOV_BYPASS
-	ASSERT(to_pci_dev(dev)->consistent_dma_mask);
+	ASSERT(dev->coherent_dma_mask);
 	/*
  	** Check if the PCI device can DMA to ptr... if so, just return ptr
  	*/
-	if (likely((*dma_handle & ~to_pci_dev(dev)->consistent_dma_mask) == 0)) {
+	if (likely((*dma_handle & ~dev->coherent_dma_mask) == 0)) {
 		DBG_BYPASS("sba_alloc_coherent() bypass mask/addr: 0x%lx/0x%lx\n",
-		           to_pci_dev(dev)->consistent_dma_mask, *dma_handle);
+		           dev->coherent_dma_mask, *dma_handle);
 
 		return addr;
 	}
===== arch/ia64/sn/io/machvec/pci_dma.c 1.26 vs edited =====
--- 1.26/arch/ia64/sn/io/machvec/pci_dma.c	Fri Feb 20 10:35:57 2004
+++ edited/arch/ia64/sn/io/machvec/pci_dma.c	Thu Feb 26 10:21:49 2004
@@ -152,7 +152,7 @@
 	 *   pcibr_dmatrans_addr ignores a missing PCIIO_DMA_A64 flag on
 	 *   PCI-X buses.
 	 */
-	if (hwdev->consistent_dma_mask == ~0UL)
+	if (hwdev->dev.coherent_dma_mask == ~0UL)
 		*dma_handle = pcibr_dmatrans_addr(vhdl, NULL, phys_addr, size,
 					  PCIIO_DMA_CMD | PCIIO_DMA_A64);
 	else {
@@ -169,7 +169,7 @@
 		}
 	}
 
-	if (!*dma_handle || *dma_handle > hwdev->consistent_dma_mask) {
+	if (!*dma_handle || *dma_handle > hwdev->dev.coherent_dma_mask) {
 		if (dma_map) {
 			pcibr_dmamap_done(dma_map);
 			pcibr_dmamap_free(dma_map);
===== arch/parisc/kernel/drivers.c 1.10 vs edited =====
--- 1.10/arch/parisc/kernel/drivers.c	Fri Feb  6 08:23:39 2004
+++ edited/arch/parisc/kernel/drivers.c	Thu Feb 26 10:21:50 2004
@@ -618,6 +618,7 @@
 		 tmp1);
 	/* make the generic dma mask a pointer to the parisc one */
 	dev->dev.dma_mask = &dev->dma_mask;
+	dev->dev.coherent_dma_mask = dev->dma_mask;
 	pr_debug("device_register(%s)\n", dev->dev.bus_id);
 	device_register(&dev->dev);
 }
===== arch/parisc/kernel/pci-dma.c 1.7 vs edited =====
--- 1.7/arch/parisc/kernel/pci-dma.c	Tue Feb  3 23:41:56 2004
+++ edited/arch/parisc/kernel/pci-dma.c	Thu Feb 26 10:21:50 2004
@@ -372,7 +372,7 @@
 ** ISA cards will certainly only support 24-bit DMA addressing.
 ** Not clear if we can, want, or need to support ISA.
 */
-	if (!dev || *dev->dma_mask != 0xffffffff)
+	if (!dev || *dev->coherent_dma_mask < 0xffffffff)
 		gfp |= GFP_DMA;
 #endif
 	return (void *)vaddr;
===== arch/x86_64/kernel/pci-gart.c 1.29 vs edited =====
--- 1.29/arch/x86_64/kernel/pci-gart.c	Tue Feb 17 20:14:37 2004
+++ edited/arch/x86_64/kernel/pci-gart.c	Thu Feb 26 10:21:51 2004
@@ -177,7 +177,7 @@
 		gfp |= GFP_DMA; 
 		dma_mask = 0xffffffff; 
 	} else {
-		dma_mask = hwdev->consistent_dma_mask; 
+		dma_mask = hwdev->dev.coherent_dma_mask; 
 	}
 
 	if (dma_mask == 0) 
===== drivers/eisa/eisa-bus.c 1.14 vs edited =====
--- 1.14/drivers/eisa/eisa-bus.c	Sun Oct  5 03:07:57 2003
+++ edited/drivers/eisa/eisa-bus.c	Thu Feb 26 10:21:51 2004
@@ -187,6 +187,7 @@
 	edev->dev.parent = root->dev;
 	edev->dev.bus = &eisa_bus_type;
 	edev->dev.dma_mask = &edev->dma_mask;
+	edev->dev.coherent_dma_mask = edev->dma_mask;
 	sprintf (edev->dev.bus_id, "%02X:%02X", root->bus_nr, slot);
 
 	for (i = 0; i < EISA_MAX_RESOURCES; i++) {
===== drivers/mca/mca-bus.c 1.5 vs edited =====
--- 1.5/drivers/mca/mca-bus.c	Sun Aug 17 13:44:15 2003
+++ edited/drivers/mca/mca-bus.c	Thu Feb 26 10:21:52 2004
@@ -106,6 +106,7 @@
 	sprintf (mca_dev->dev.bus_id, "%02d:%02X", bus, mca_dev->slot);
 	mca_dev->dma_mask = mca_bus->default_dma_mask;
 	mca_dev->dev.dma_mask = &mca_dev->dma_mask;
+	mca_dev->dev.coherent_dma_mask = mca_dev->dma_mask;
 
 	if (device_register(&mca_dev->dev))
 		return 0;
===== drivers/pci/pci.c 1.61 vs edited =====
--- 1.61/drivers/pci/pci.c	Tue Feb 10 12:01:13 2004
+++ edited/drivers/pci/pci.c	Thu Feb 26 10:21:52 2004
@@ -691,7 +691,7 @@
 	if (!pci_dma_supported(dev, mask))
 		return -EIO;
 
-	dev->consistent_dma_mask = mask;
+	dev->dev.coherent_dma_mask = mask;
 
 	return 0;
 }
===== drivers/pci/probe.c 1.59 vs edited =====
--- 1.59/drivers/pci/probe.c	Wed Feb 18 21:42:58 2004
+++ edited/drivers/pci/probe.c	Thu Feb 26 10:21:53 2004
@@ -566,7 +566,6 @@
 	/* Assume 32-bit PCI; let 64-bit PCI cards (which are far rarer)
 	   set this higher, assuming the system even supports it.  */
 	dev->dma_mask = 0xffffffff;
-	dev->consistent_dma_mask = 0xffffffff;
 	if (pci_setup_device(dev) < 0) {
 		kfree(dev);
 		return NULL;
@@ -578,6 +577,7 @@
 	pci_name_device(dev);
 
 	dev->dev.dma_mask = &dev->dma_mask;
+	dev->dev.coherent_dma_mask = 0xffffffffull;
 
 	return dev;
 }
===== include/linux/device.h 1.115 vs edited =====
--- 1.115/include/linux/device.h	Mon Feb  9 17:40:25 2004
+++ edited/include/linux/device.h	Thu Feb 26 10:21:53 2004
@@ -285,6 +285,12 @@
 					   detached from its driver. */
 
 	u64		*dma_mask;	/* dma mask (if dma'able device) */
+	u64		coherent_dma_mask;/* Like dma_mask, but for
+					     alloc_coherent mappings as
+					     not all hardware supports
+					     64 bit addresses for consistent
+					     allocations such descriptors. */
+
 	struct list_head	dma_pools;	/* dma pools (if dma'ble) */
 
 	void	(*release)(struct device * dev);
===== include/linux/pci.h 1.117 vs edited =====
--- 1.117/include/linux/pci.h	Tue Feb 10 11:51:08 2004
+++ edited/include/linux/pci.h	Thu Feb 26 10:21:54 2004
@@ -392,11 +392,6 @@
 					   this if your device has broken DMA
 					   or supports 64-bit transfers.  */
 
-	u64		consistent_dma_mask;/* Like dma_mask, but for
-					       pci_alloc_consistent mappings as
-					       not all hardware supports
-					       64 bit addresses for consistent
-					       allocations such descriptors. */
 	u32             current_state;  /* Current operating state. In ACPI-speak,
 					   this is D0-D3, D0 being fully functional,
 					   and D3 being off. */
===== sound/core/memalloc.c 1.16 vs edited =====
--- 1.16/sound/core/memalloc.c	Mon Jan 19 04:37:35 2004
+++ edited/sound/core/memalloc.c	Thu Feb 26 10:21:54 2004
@@ -100,13 +100,13 @@
 	if (hwdev == NULL)
 		return pci_alloc_consistent(hwdev, size, dma_handle);
 	dma_mask = hwdev->dma_mask;
-	cdma_mask = hwdev->consistent_dma_mask;
+	cdma_mask = hwdev->dev.coherent_dma_mask;
 	mask = (unsigned long)dma_mask && (unsigned long)cdma_mask;
 	hwdev->dma_mask = 0xffffffff; /* do without masking */
-	hwdev->consistent_dma_mask = 0xffffffff; /* do without masking */
+	hwdev->dev.coherent_dma_mask = 0xffffffff; /* do without masking */
 	ret = pci_alloc_consistent(hwdev, size, dma_handle);
 	hwdev->dma_mask = dma_mask; /* restore */
-	hwdev->consistent_dma_mask = cdma_mask; /* restore */
+	hwdev->dev.coherent_dma_mask = cdma_mask; /* restore */
 	if (ret) {
 		/* obtained address is out of range? */
 		if (((unsigned long)*dma_handle + size - 1) & ~mask) {
@@ -648,7 +648,7 @@
 	dma_addr_t addr;
 	unsigned long mask;
 
-	mask = pci ? (unsigned long)pci->consistent_dma_mask : 0x00ffffffUL;
+	mask = pci ? (unsigned long)pci->dev.coherent_dma_mask : 0x00ffffffUL;
 	ptr = (void *)__get_free_page(GFP_KERNEL);
 	if (ptr) {
 		addr = virt_to_phys(ptr);


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] move consistent_dma_mask to the generic device
  2004-02-26 16:53 [PATCH] move consistent_dma_mask to the generic device James Bottomley
@ 2004-02-27  6:57 ` Jeremy Higdon
  2004-02-27 14:55   ` James Bottomley
  0 siblings, 1 reply; 3+ messages in thread
From: Jeremy Higdon @ 2004-02-27  6:57 UTC (permalink / raw)
  To: James Bottomley
  Cc: Andrew Morton, willy, Jes Sorensen, Grant Grundler,
	alex.williamson, jbarnes, ak, Linux Kernel

I haven't had a chance to try it yet, but it looks good.

If you're going to get rid of pci_dev.consistent_dma_mask in favor
of pci_dev.dev.coherent_dma_mask, would you want to do the same
with pci_dev.dma_mask?

Which brings to mind a second question; why is device.dma_mask
a u64 * instead of u64?  Does it typically point to pci_dev.dma_mask?

thanks

jeremy


On Thu, Feb 26, 2004 at 10:53:12AM -0600, James Bottomley wrote:
> This is a reroll of the previous patch.  It fixes up badness in the
> sound drivers which were accessing the dma_mask directly instead of
> using the accessor functions.
> 
> It also modifies the arch's that were using consistent_dma_mask:
> 
> x86_64, ia64 (both sn and hp) and parisc

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] move consistent_dma_mask to the generic device
  2004-02-27  6:57 ` Jeremy Higdon
@ 2004-02-27 14:55   ` James Bottomley
  0 siblings, 0 replies; 3+ messages in thread
From: James Bottomley @ 2004-02-27 14:55 UTC (permalink / raw)
  To: Jeremy Higdon
  Cc: Andrew Morton, willy, Jes Sorensen, Grant Grundler,
	alex.williamson, jbarnes, ak, Linux Kernel

On Fri, 2004-02-27 at 00:57, Jeremy Higdon wrote:
> I haven't had a chance to try it yet, but it looks good.
> 
> If you're going to get rid of pci_dev.consistent_dma_mask in favor
> of pci_dev.dev.coherent_dma_mask, would you want to do the same
> with pci_dev.dma_mask?

It's probably about time that was done, yes.

> Which brings to mind a second question; why is device.dma_mask
> a u64 * instead of u64?  Does it typically point to pci_dev.dma_mask?

That's a bad design decision that will forever haunt me.  When I first
proposed moving from the PCI DMA model to the generic device DMA model,
the dma_mask was in the wrong place.  Quite a few drivers touched it
themselves outside of the accessor functions, so actually moving it in
to struct device became quite involved, so I took the easy way out and
simply made the entry in struct device a pointer to the real one so that
anything that updated the mask outside of the accessors would still
work.

I suppose I should really do the work as pennance, plus write out a
hundred times "never sacrifice design integrity for expediency", sigh.

James



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-02-27 14:56 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-02-26 16:53 [PATCH] move consistent_dma_mask to the generic device James Bottomley
2004-02-27  6:57 ` Jeremy Higdon
2004-02-27 14:55   ` James Bottomley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox