1. 02 12月, 2006 1 次提交
    • 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
  2. 27 9月, 2006 1 次提交
  3. 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
  4. 28 6月, 2006 1 次提交
  5. 22 6月, 2006 1 次提交
  6. 15 4月, 2006 1 次提交
  7. 24 3月, 2006 1 次提交
  8. 10 1月, 2006 1 次提交
  9. 05 1月, 2006 1 次提交
  10. 29 10月, 2005 1 次提交
    • B
      [PATCH] PCI: Block config access during BIST · e04b0ea2
      Brian King 提交于
      Some PCI adapters (eg.  ipr scsi adapters) have an exposure today in that they
      issue BIST to the adapter to reset the card.  If, during the time it takes to
      complete BIST, userspace attempts to access PCI config space, the host bus
      bridge will master abort the access since the ipr adapter does not respond on
      the PCI bus for a brief period of time when running BIST.  On PPC64 hardware,
      this master abort results in the host PCI bridge isolating that PCI device
      from the rest of the system, making the device unusable until Linux is
      rebooted.  This patch is an attempt to close that exposure by introducing some
      blocking code in the PCI code.  When blocked, writes will be humored and reads
      will return the cached value.  Ben Herrenschmidt has also mentioned that he
      plans to use this in PPC power management.
      Signed-off-by: NBrian King <brking@us.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
       drivers/pci/access.c    |   89 ++++++++++++++++++++++++++++++++++++++++++++++++
       drivers/pci/pci-sysfs.c |   20 +++++-----
       drivers/pci/pci.h       |    7 +++
       drivers/pci/proc.c      |   28 +++++++--------
       drivers/pci/syscall.c   |   14 +++----
       include/linux/pci.h     |    7 +++
       6 files changed, 134 insertions(+), 31 deletions(-)
      e04b0ea2
  11. 10 9月, 2005 1 次提交
  12. 17 8月, 2005 2 次提交
  13. 12 7月, 2005 2 次提交
  14. 18 5月, 2005 1 次提交
  15. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4