public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI and PCI Hotplug update for 2.6.6-rc1
Date: Thu, 15 Apr 2004 10:23:46 -0700	[thread overview]
Message-ID: <1082049826312@kroah.com> (raw)
In-Reply-To: <1082049825348@kroah.com>

ChangeSet 1.1692.3.10, 2004/03/31 14:57:52-08:00, dsaxena@plexity.net

[PATCH] PCI: Allow arch-specific pci_set_dma_mask and friends

The patch provides the ability for architectures to have custom
implementations of pci_set_dma_mask() and friends (dac_set_dma_mask
and set_consistent_dma_mask). The reason I need this is b/c I have
a chipset (Intel ARM IXP425) that has a broken PCI interface that
only allows PCI dma to/from the bottom 64MB of system memory.  To get
around this limitation, I trap a custom dma-mapping implementation that
bounces buffers outside the 64MB window. At device discover time, my
custom platform_notify() function gets called and it sets the dma_mask
to (64MB-1) and in ARM's dma-mapping code, I check for dma_mask != 0xffffffff
and if that is true, I call the special bounce helpers. This works great
except that certain drivers (e100, ide-pci) call pci_set_dma_mask()
with 0xffffffff and the generic implementation only allows for the
architecture-defined pci_dma_supported() to return true or false. There
is no method for the architecture to tell the PCI layer "I can't set
the mask to 0xffffffff, but I can set it to this other value" and there
is no way to pass that back to the driver. What this means is that if
I have pci_set_dma_supported() return failure on full 32-bit DMA, the
driver will not initialize the card; however, if I return true,
pci_set_dma_mask() will set the dma mask to full 32-bits and I can no
longer trap and will have buffers that are not dma-able and cause
PCI master aborts.  Both of those are not acceptable.  IMHO, the
driver shouldn't care if the architecture has to bounce DMA outside of
64MB and since this is not something most architectures have to worry
about, the easiest way to get around the issue is by allowing custom
pci_set_dma_mask() for arches that need it but keeping the generic
implementation for those that do not.  In my case, it simply returns
0 to the driver but keeps the device mask set to 64MB-1 so I can trap.


 drivers/pci/pci.c |    5 +++++
 1 files changed, 5 insertions(+)


diff -Nru a/drivers/pci/pci.c b/drivers/pci/pci.c
--- a/drivers/pci/pci.c	Thu Apr 15 10:04:10 2004
+++ b/drivers/pci/pci.c	Thu Apr 15 10:04:10 2004
@@ -700,6 +700,10 @@
 	}
 }
 
+#ifndef HAVE_ARCH_PCI_SET_DMA_MASK
+/*
+ * These can be overridden by arch-specific implementations
+ */
 int
 pci_set_dma_mask(struct pci_dev *dev, u64 mask)
 {
@@ -732,6 +736,7 @@
 
 	return 0;
 }
+#endif
      
 static int __devinit pci_init(void)
 {


  reply	other threads:[~2004-04-15 17:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-15 17:19 [BK PATCH] PCI and PCI Hotplug update for 2.6.6-rc1 Greg KH
2004-04-15 17:23 ` [PATCH] " Greg KH
2004-04-15 17:23   ` Greg KH
2004-04-15 17:23     ` Greg KH
2004-04-15 17:23       ` Greg KH
2004-04-15 17:23         ` Greg KH
2004-04-15 17:23           ` Greg KH
2004-04-15 17:23             ` Greg KH
2004-04-15 17:23               ` Greg KH
2004-04-15 17:23                 ` Greg KH
2004-04-15 17:23                   ` Greg KH [this message]
2004-04-15 17:23                     ` Greg KH
2004-04-15 17:23                       ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1082049826312@kroah.com \
    --to=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox