1. 08 2月, 2007 1 次提交
  2. 12 1月, 2007 1 次提交
    • B
      [PATCH] increment pos before looking for the next cap in __pci_find_next_ht_cap · 47a4d5be
      Brice Goglin 提交于
      While testing 2.6.20-rc3 on a machine with some CK804 chipsets, we noticed
      that quirk_nvidia_ck804_msi_ht_cap() was not detecting HT MSI capabilities
      anymore.  It is actually caused by the MSI mapping on the root chipset
      being the 2nd HT capability in the chain.  pci_find_ht_capability() does
      not seem to find anything but the first HT cap correctly, because it
      forgets to increment the position before looking for the next cap.  The
      following patch seems to fix it.
      
      At least, this proves that having a ttl is good idea since the machine
      would have been stucked in an infinite loop if we didn't have a ttl :)
      
      We have to pass pos + PCI_CAP_LIST_NEXT to __pci_find_next_cap_ttl to
      get the next HT cap instead of the same one again.
      Signed-off-by: NBrice Goglin <brice@myri.com>
      Signed-off-by: NAndrew J. Gallatin <gallatin@myri.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      47a4d5be
  3. 21 12月, 2006 2 次提交
  4. 02 12月, 2006 4 次提交
    • I
      PCI: switch pci_{enable,disable}_device() to be nestable · bae94d02
      Inaky Perez-Gonzalez 提交于
      Changes the pci_{enable,disable}_device() functions to work in a
      nested basis, so that eg, three calls to enable_device() require three
      calls to disable_device().
      
      The reason for this is to simplify PCI drivers for
      multi-interface/capability devices. These are devices that cram more
      than one interface in a single function. A relevant example of that is
      the Wireless [USB] Host Controller Interface (similar to EHCI) [see
      http://www.intel.com/technology/comms/wusb/whci.htm]. 
      
      In these kind of devices, multiple interfaces are accessed through a
      single bar and IRQ line. For that, the drivers map only the smallest
      area of the bar to access their register banks and use shared IRQ
      handlers. 
      
      However, because the order at which those drivers load cannot be known
      ahead of time, the sequence in which the calls to pci_enable_device()
      and pci_disable_device() cannot be predicted. Thus:
      
      1. driverA     starts     pci_enable_device()
      2. driverB     starts     pci_enable_device()
      3. driverA     shutdown   pci_disable_device()
      4. driverB     shutdown   pci_disable_device()
      
      between steps 3 and 4, driver B would loose access to it's device,
      even if it didn't intend to.
      
      By using this modification, the device won't be disabled until all the
      callers to enable() have called disable().
      
      This is implemented by replacing 'struct pci_dev->is_enabled' from a
      bitfield to an atomic use count. Each caller to enable increments it,
      each caller to disable decrements it. When the count increments from 0
      to 1, __pci_enable_device() is called to actually enable the
      device. When it drops to zero, pci_disable_device() actually does the
      disabling.
      
      We keep the backend __pci_enable_device() for pci_default_resume() to
      use and also change the sysfs method implementation, so that userspace
      enabling/disabling the device doesn't disable it one time too much.
      Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bae94d02
    • M
      PCI: Replace HAVE_ARCH_PCI_MWI with PCI_DISABLE_MWI · edb2d97e
      Matthew Wilcox 提交于
      pSeries is the only architecture left using HAVE_ARCH_PCI_MWI and it's
      really inappropriate for its needs.  It really wants to disable MWI
      altogether.  So here are a pair of stub implementations for pci_set_mwi
      and pci_clear_mwi.
      
      Also rename pci_generic_prep_mwi to pci_set_cacheline_size since that
      better reflects what it does.
      Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
      Cc: Paul Mackerras <paulus@samba.org>
      Acked-by: NJeff Garzik <jeff@garzik.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      edb2d97e
    • M
      PCI: Use pci_generic_prep_mwi on sparc64 · ebf5a248
      Matthew Wilcox 提交于
      The setting of the CACHE_LINE_SIZE register in sparc64's pci
      initialisation code isn't quite adequate as the device may have
      incompatible requirements.  The generic code tests for this, so switch
      sparc64 over to using it.
      
      Since sparc64 has different L1 cache line size and PCI cache line size,
      it would need to override the generic code like i386 and ia64 do.  We
      know what the cache line size is at compile time though, so introduce a
      new optional constant PCI_CACHE_LINE_BYTES.
      Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
      Signed-off-by: NDavid Miller <davem@davemloft.net>
      Acked-by: NJeff Garzik <jeff@garzik.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ebf5a248
    • S
      PCI: save/restore PCI-X state · cc692a5f
      Stephen Hemminger 提交于
      Shouldn't PCI-X state be saved/restored?  No device really needs this
      right now. qla24xx (fc HBA) and mthca (infiniband) don't do suspend, 
      and sky2 resets its tweaks when links are brought up.
      Signed-off-by: NStephen Hemminger <shemminger@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      cc692a5f
  5. 27 9月, 2006 1 次提交
  6. 26 9月, 2006 2 次提交
  7. 13 7月, 2006 1 次提交
    • K
      [PATCH] PCI: PCIE power management quirk · ffadcc2f
      Kristen Carlson Accardi 提交于
      When changing power states from D0->DX and then from DX->D0, some
      Intel PCIE chipsets will cause a device reset to occur.  This will
      cause problems for any D State other than D3, since any state
      information that the driver will expect to be present coming from
      a D1 or D2 state will have been cleared.  This patch addes a
      flag to the pci_dev structure to indicate that devices should
      not use states D1 or D2, and will set that flag for the affected
      chipsets.  This patch also modifies pci_set_power_state() so that
      when a device driver tries to set the power state on
      a device that is downstream from an affected chipset, or on one
      of the affected devices it only allows state changes to or
      from D0 & D3.  In addition, this patch allows the delay time
      between D3->D0 to be changed via a quirk.  These chipsets also
      need additional time to change states beyond the normal 10ms.
      Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ffadcc2f
  8. 28 6月, 2006 1 次提交
  9. 27 6月, 2006 1 次提交
  10. 22 6月, 2006 2 次提交
  11. 12 6月, 2006 2 次提交
  12. 24 5月, 2006 1 次提交
  13. 15 4月, 2006 2 次提交
  14. 24 3月, 2006 4 次提交
  15. 01 2月, 2006 1 次提交
  16. 10 1月, 2006 2 次提交
  17. 11 11月, 2005 1 次提交
    • R
      [PATCH] PCI: add pci_find_next_capability() · 24a4e377
      Roland Dreier 提交于
      Some devices have more than one capability of the same type.  For
      example, the PCI header for the PathScale InfiniPath looks like:
      
      	04:01.0 InfiniBand: Unknown device 1fc1:000d (rev 02)
      		Subsystem: Unknown device 1fc1:000d
      		Flags: bus master, fast devsel, latency 0, IRQ 193
      		Memory at fea00000 (64-bit, non-prefetchable) [size=2M]
      		Capabilities: [c0] HyperTransport: Slave or Primary Interface
      		Capabilities: [f8] HyperTransport: Interrupt Discovery and Configuration
      
      There are _two_ HyperTransport capabilities, and the PathScale driver
      wants to look at both of them.
      
      The current pci_find_capability() API doesn't work for this, since it
      only allows us to get to the first capability of a given type.  The
      patch below introduces a new pci_find_next_capability(), which can be
      used in a loop like
      
      	for (pos = pci_find_capability(pdev, <ID>);
      	     pos;
      	     pos = pci_find_next_capability(pdev, pos, <ID>)) {
      		/* ... */
      	}
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      24a4e377
  18. 31 10月, 2005 1 次提交
    • T
      [PATCH] fix missing includes · 4e57b681
      Tim Schmielau 提交于
      I recently picked up my older work to remove unnecessary #includes of
      sched.h, starting from a patch by Dave Jones to not include sched.h
      from module.h. This reduces the number of indirect includes of sched.h
      by ~300. Another ~400 pointless direct includes can be removed after
      this disentangling (patch to follow later).
      However, quite a few indirect includes need to be fixed up for this.
      
      In order to feed the patches through -mm with as little disturbance as
      possible, I've split out the fixes I accumulated up to now (complete for
      i386 and x86_64, more archs to follow later) and post them before the real
      patch.  This way this large part of the patch is kept simple with only
      adding #includes, and all hunks are independent of each other.  So if any
      hunk rejects or gets in the way of other patches, just drop it.  My scripts
      will pick it up again in the next round.
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4e57b681
  19. 29 10月, 2005 2 次提交
  20. 15 9月, 2005 1 次提交
  21. 10 9月, 2005 1 次提交
  22. 09 9月, 2005 5 次提交
  23. 05 9月, 2005 1 次提交