1. 12 Apr, 2004 1 commit
  2. 07 Apr, 2004 1 commit
  3. 31 Mar, 2004 3 commits
    • Deepak Saxena's avatar
      [PATCH] PCI: Allow arch-specific pci_set_dma_mask and friends · 6e302b79
      Deepak Saxena authored
      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.
      6e302b79
    • John Rose's avatar
      [PATCH] PCI Hotplug: RPA PCI Hotplug - redundant free · e09e044a
      John Rose authored
      Please commit the following patch, which removes a redundant call to a
      cleanup function from an error path of the module init code.
      e09e044a
    • Randy Dunlap's avatar
      7553ed46
  4. 30 Mar, 2004 2 commits
    • Randy Dunlap's avatar
      [PATCH] PCI: add DMA_{64,32}BIT constants · 47287358
      Randy Dunlap authored
      On Tue, 23 Mar 2004 00:23:05 -0500 Jeff Garzik <jgarzik@pobox.com> wrote:
      >>Yeah well...  in the intervening time, somebody on IRC commented
      >>
      >>"so what is so PCI-specific about those constants?"
      >>
      >>They probably ought to be DMA_{32,64}BIT_MASK or somesuch.
      
      Here's an updated patch, applies to 2.6.5-rc2-bk9.
      I left the DMA_xxBIT_MASK defines in linux/pci.h, although
      they aren't necessarily PCI-specific.  Would we prefer to
      have them in linux/dma-mapping.h ?
      47287358
    • Greg Kroah-Hartman's avatar
  5. 26 Mar, 2004 5 commits
    • Matthew Wilcox's avatar
      [PATCH] PCI Hotplug: Rewrite acpiphp detect_used_resource · a975072b
      Matthew Wilcox authored
      There are two unrelated problems in acpiphp that are fixed by this patch.
      First, acpiphp can be a module, so it is unsafe to probe the BARs of each
      device while it initialises -- the device may be active at the time.
      Second, it does not know about PCI-PCI bridge registers and so it reads
      garbage for the last 4 registers of the PCI-PCI bridge card and doesn't
      take into account the ranges that are forwarded by the bridge.
      
      This patch avoids all that by using the struct resources embedded in
      the pci_dev.  Note that we no longer need to recurse as all the devices
      on the other side of a PCI-PCI bridge have their resources entirely
      contained within the PCI-PCI bridge's ranges.
      a975072b
    • Matthew Wilcox's avatar
      [PATCH] PCI Hotplug: Don't up() twice in acpiphp · 4e3b369f
      Matthew Wilcox authored
      On the error path, we currently try to up() a semaphore twice.
      There was also a typo in an error message.
      4e3b369f
    • Dely Sy's avatar
      25a3a555
    • Greg Kroah-Hartman's avatar
      Merge bk://kernel.bkbits.net/jgarzik/pci-dma-mask-2.6 · bae19b18
      Greg Kroah-Hartman authored
      into kroah.com:/home/greg/linux/BK/pci-2.6
      bae19b18
    • Greg Kroah-Hartman's avatar
      PCI: add ability to access pci extended config space for PCI Express devices · ec99630f
      Greg Kroah-Hartman authored
      Patch originally written by Intel, cleaned up and made sane by 
      Matthew Wilcox <willy@debian.org> and then tweaked a bit more by me.
      
      From Matt's original email:
       - Add cfg_size to struct pci_dev.
       - Use it in sysfs and procfs.
       - Introduce pci_find_ext_capability() for finding extended capabilities.
       - Change the PCI_X_STATUS defines to match the spec (mea culpa there).
       - Add defines for the extended capabilities.
      ec99630f
  6. 25 Mar, 2004 28 commits