1. 14 Oct, 2011 2 commits
  2. 11 May, 2011 3 commits
  3. 31 Mar, 2011 1 commit
  4. 23 Dec, 2010 3 commits
  5. 18 Oct, 2010 1 commit
  6. 11 May, 2010 1 commit
  7. 27 Apr, 2010 1 commit
  8. 24 Feb, 2010 1 commit
    • Jesse Barnes's avatar
      x86/PCI: Moorestown PCI support · a712ffbc
      Jesse Barnes authored
      
      
      The Moorestown platform only has a few devices that actually support
      PCI config cycles.  The rest of the devices use an in-RAM MCFG space
      for the purposes of device enumeration and initialization.
      
      There are a few uglies in the fake support, like BAR sizes that aren't
      a power of two, sizing detection, and writes to the real devices, but
      other than that it's pretty straightforward.
      
      Another way to think of this is not really as PCI at all, but just a
      table in RAM describing which devices are present, their capabilities
      and their offsets in MMIO space.  This could have been done with a
      special new firmware table on this platform, but given that we do have
      some real PCI devices too, simply describing things in an MCFG type
      space was pretty simple.
      
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      LKML-Reference: <43F901BD926A4E43B106BF17856F07559FB80D08@orsmsx508.amr.corp.intel.com>
      Signed-off-by: default avatarJacob Pan <jacob.jun.pan@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      a712ffbc
  9. 04 Nov, 2009 2 commits
    • Gabe Black's avatar
      PCI: populate subsystem vendor and device IDs for PCI bridges · bc577d2b
      Gabe Black authored
      
      
      Change to populate the subsystem vendor and subsytem device IDs for
      PCI-PCI bridges that implement the PCI Subsystem Vendor ID capability.
      Previously bridges left subsystem vendor IDs unpopulated.
      
      Signed-off-by: default avatarGabe Black <gabe.black@ni.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      bc577d2b
    • Allen Kay's avatar
      PCI: acs p2p upsteram forwarding enabling · ae21ee65
      Allen Kay authored
      
      
      Note: dom0 checking in v4 has been separated out into 2/2.
      
      This patch enables P2P upstream forwarding in ACS capable PCIe switches.
      It solves two potential problems in virtualization environment where a PCIe
      device is assigned to a guest domain using a HW iommu such as VT-d:
      
      1) Unintentional failure caused by guest physical address programmed
         into the device's DMA that happens to match the memory address range
         of other downstream ports in the same PCIe switch.  This causes the PCI
         transaction to go to the matching downstream port instead of go to the
         root complex to get translated by VT-d as it should be.
      
      2) Malicious guest software intentionally attacks another downstream
         PCIe device by programming the DMA address into the assigned device
         that matches memory address range of the downstream PCIe port.
      
      We are in process of implementing device filtering software in KVM/XEN
      management software to allow device assignment of PCIe devices behind a PCIe
      switch only if it has ACS capability and with the P2P upstream forwarding bits
      enabled.  This patch is intended to work for both KVM and Xen environments.
      
      Signed-off-by: default avatarAllen Kay <allen.m.kay@intel.com>
      Reviewed-by: default avatarMathew Wilcox <willy@linux.intel.com>
      Reviewed-by: default avatarChris Wright <chris@sous-sol.org>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      ae21ee65
  10. 15 Sep, 2009 1 commit
    • Michael S. Tsirkin's avatar
      uio: add generic driver for PCI 2.3 devices · ccb86a69
      Michael S. Tsirkin authored
      
      
      This adds a generic uio driver that can bind to any PCI device.  First
      user will be virtualization where a qemu userspace process needs to give
      guest OS access to the device.
      
      Interrupts are handled using the Interrupt Disable bit in the PCI
      command register and Interrupt Status bit in the PCI status register.
      All devices compliant to PCI 2.3 (circa 2002) and all compliant PCI
      Express devices should support these bits.  Driver detects this support,
      and won't bind to devices which do not support the Interrupt Disable Bit
      in the command register.
      
      It's expected that more features of interest to virtualization will be
      added to this driver in the future. Possibilities are: mmap for device
      resources, MSI/MSI-X, eventfd (to interface with kvm), iommu.
      
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarChris Wright <chrisw@redhat.com>
      Signed-off-by: default avatarHans J. Koch <hjk@linutronix.de>
      Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      
      ccb86a69
  11. 11 Jun, 2009 2 commits
  12. 18 May, 2009 1 commit
  13. 22 Apr, 2009 1 commit
    • Yu Zhao's avatar
      PCI: only save/restore existent registers in the PCIe capability · 1b6b8ce2
      Yu Zhao authored
      
      
      PCIe 1.1 base neither requires the endpoint to implement the entire
      PCIe capability structure nor specifies default values of registers
      that are not implemented by the device. So we only save and restore
      registers that must be implemented by different device types if the
      device PCIe capability version is 1.
      
      PCIe 1.1 Capability Structure Expansion ECN and PCIe 2.0 requires
      all registers in the PCIe capability to be either implemented or
      hardwired to 0. Their PCIe capability version is 2.
      
      Signed-off-by: default avatarYu Zhao <yu.zhao@intel.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      1b6b8ce2
  14. 26 Mar, 2009 1 commit
  15. 20 Mar, 2009 2 commits
  16. 07 Jan, 2009 2 commits
  17. 22 Oct, 2008 1 commit
    • Sheng Yang's avatar
      PCI: add support for function level reset · 8dd7f803
      Sheng Yang authored
      
      
      Sometimes, it's necessary to enable software's ability to quiesce and
      reset endpoint hardware with function-level granularity, so provide
      support for it.
      
      The patch implement Function Level Reset(FLR) feature following PCI-e
      spec. And this is the first step. We would add more generic method, like
      D0/D3, to allow more devices support this function.
      
      The patch contains two functions. pcie_reset_function() is the new
      driver API, and, contains some action to quiesce a device.  The other
      function is a helper:  pcie_execute_reset_function() just executes the
      reset for a particular device function.
      
      Current the usage model is in KVM. Function reset is necessary for
      assigning device to a guest, or moving it between partitions.
      
      For Function Level Reset(FLR), please refer to PCI Express spec chapter
      6.6.2.
      
      Signed-off-by: default avatarSheng Yang <sheng@linux.intel.com>
      Signed-off-by: default avatarMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      8dd7f803
  18. 20 Oct, 2008 1 commit
  19. 28 Jul, 2008 1 commit
  20. 07 Jul, 2008 1 commit
  21. 21 Apr, 2008 1 commit
    • Shaohua Li's avatar
      PCI: add PCI Express ASPM support · 7d715a6c
      Shaohua Li authored
      
      
      PCI Express ASPM defines a protocol for PCI Express components in the D0
      state to reduce Link power by placing their Links into a low power state
      and instructing the other end of the Link to do likewise. This
      capability allows hardware-autonomous, dynamic Link power reduction
      beyond what is achievable by software-only controlled power management.
      However, The device should be configured by software appropriately.
      Enabling ASPM will save power, but will introduce device latency.
      
      This patch adds ASPM support in Linux. It introduces a global policy for
      ASPM, a sysfs file /sys/module/pcie_aspm/parameters/policy can control
      it. The interface can be used as a boot option too. Currently we have
      below setting:
              -default, BIOS default setting
              -powersave, highest power saving mode, enable all available ASPM
      state and clock power management
              -performance, highest performance, disable ASPM and clock power
      management
      By default, the 'default' policy is used currently.
      
      In my test, power difference between powersave mode and performance mode
      is about 1.3w in a system with 3 PCIE links.
      
      Note: some devices might not work well with aspm, either because chipset
      issue or device issue. The patch provide API (pci_disable_link_state),
      driver can disable ASPM for specific device.
      
      Signed-off-by: default avatarShaohua Li <shaohua.li@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      7d715a6c
  22. 02 Feb, 2008 1 commit
  23. 01 Feb, 2008 1 commit
    • Shaohua Li's avatar
      PCI: PCIE ASPM support · 6c723d5b
      Shaohua Li authored
      
      
      PCI Express ASPM defines a protocol for PCI Express components in the D0
      state to reduce Link power by placing their Links into a low power state
      and instructing the other end of the Link to do likewise. This
      capability allows hardware-autonomous, dynamic Link power reduction
      beyond what is achievable by software-only controlled power management.
      However, The device should be configured by software appropriately.
      Enabling ASPM will save power, but will introduce device latency.
      
      This patch adds ASPM support in Linux. It introduces a global policy for
      ASPM, a sysfs file /sys/module/pcie_aspm/parameters/policy can control
      it. The interface can be used as a boot option too. Currently we have
      below setting:
              -default, BIOS default setting
              -powersave, highest power saving mode, enable all available ASPM
      state
      and clock power management
              -performance, highest performance, disable ASPM and clock power
      management
      By default, the 'default' policy is used currently.
      
      In my test, power difference between powersave mode and performance mode
      is about 1.3w in a system with 3 PCIE links.
      
      Signed-off-by: default avatarShaohua Li <shaohua.li@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      6c723d5b
  24. 12 Oct, 2007 2 commits
  25. 10 Oct, 2007 1 commit
  26. 12 Mar, 2007 1 commit
    • Eric W. Biederman's avatar
      [PATCH] msi: Safer state caching. · 392ee1e6
      Eric W. Biederman authored
      
      
      There are two ways pci_save_state and pci_restore_state are used.  As
      helper functions during suspend/resume, and as helper functions around
      a hardware reset event.  When used as helper functions around a hardware
      reset event there is no reason to believe the calls will be paired, nor
      is there a good reason to believe that if we restore the msi state from
      before the reset that it will match the current msi state.  Since arch
      code may change the msi message without going through the driver, drivers
      currently do not have enough information to even know when to call
      pci_save_state to ensure they will have msi state in sync with the other
      kernel irq reception data structures.
      
      It turns out the solution is straight forward, cache the state in the
      existing msi data structures (not the magic pci saved things) and
      have the msi code update the cached state each time we write to the hardware.
      This means we never need to read the hardware to figure out what the hardware
      state should be.
      
      By modifying the caching in this manner we get to remove our save_state
      routines and only need to provide restore_state routines.
      
      The only fields that were at all tricky to regenerate were the msi and msi-x
      control registers and the way we regenerate them currently is a bit dependent
      upon assumptions on how we use the allow msi registers to be configured and used
      making the code a little bit brittle.  If we ever change what cases we allow
      or how we configure the msi bits we can address the fragility then.
      
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: default avatarAuke Kok <auke-jan.h.kok@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      392ee1e6
  27. 05 Mar, 2007 1 commit
    • Eric W. Biederman's avatar
      [PATCH] msi: sanely support hardware level msi disabling · f5f2b131
      Eric W. Biederman authored
      
      
      In some cases when we are not using msi we need a way to ensure that the
      hardware does not have an msi capability enabled.  Currently the code has been
      calling disable_msi_mode to try and achieve that.  However disable_msi_mode
      has several other side effects and is only available when msi support is
      compiled in so it isn't really appropriate.
      
      Instead this patch implements pci_msi_off which disables all msi and msix
      capabilities unconditionally with no additional side effects.
      
      pci_disable_device was redundantly clearing the bus master enable flag and
      clearing the msi enable bit.  A device that is not allowed to perform bus
      mastering operations cannot generate intx or msi interrupt messages as those
      are essentially a special case of dma, and require bus mastering.  So the call
      in pci_disable_device to disable msi capabilities was redundant.
      
      quirk_pcie_pxh also called disable_msi_mode and is updated to use pci_msi_off.
      
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f5f2b131
  28. 20 Dec, 2006 2 commits
  29. 01 Dec, 2006 1 commit