An error occurred fetching the project authors.
  1. 01 Jul, 2009 1 commit
  2. 29 Jun, 2009 1 commit
  3. 16 Jun, 2009 8 commits
  4. 11 Jun, 2009 2 commits
    • Andrew Patterson's avatar
      PCI: Add support for turning PCIe ECRC on or off · 43c16408
      Andrew Patterson authored
      Adds support for PCI Express transaction layer end-to-end CRC checking
      (ECRC).  This patch will enable/disable ECRC checking by setting/clearing
      the ECRC Check Enable and/or ECRC Generation Enable bits for devices that
      support ECRC.
      
      The ECRC setting is controlled by the "pci=ecrc=<policy>" command-line
      option. If this option is not set or is set to 'bios", the enable and
      generation bits are left in whatever state that firmware/BIOS set them to.
      The "off" setting turns them off, and the "on" option turns them on (if the
      device supports it).
      
      Turning ECRC on or off can be a data integrity versus performance
      tradeoff.  In theory, turning it on will catch more data errors, turning
      it off means possibly better performance since CRC does not need to be
      calculated by the PCIe hardware and packet sizes are reduced.
      Signed-off-by: default avatarAndrew Patterson <andrew.patterson@hp.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      43c16408
    • Rafael J. Wysocki's avatar
      PCI PM: Follow PCI_PM_CTRL_NO_SOFT_RESET during transitions from D3 · f62795f1
      Rafael J. Wysocki authored
      According to the PCI PM specification (PCI Bus Power Management
      Interface Specification, Rev. 1.2, Section 5.4.1) we are supposed to
      reinitialize devices that have PCI_PM_CTRL_NO_SOFT_RESET clear during
      all transitions from PCI_D3hot to PCI_D0, but we only do it if the
      device's current_state field is equal to PCI_UNKNOWN.
      
      This may lead to problems if a device with PCI_PM_CTRL_NO_SOFT_RESET
      unset is put into PCI_D3hot at run time by its driver and
      pci_set_power_state() is used to put it back into PCI_D0, because in
      that case the device will remain uninitialized after
      pci_set_power_state() has returned.  Prevent that from happening by
      modifying pci_raw_set_power_state() to reinitialize devices with
      PCI_PM_CTRL_NO_SOFT_RESET unset during all transitions from D3 to D0.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      f62795f1
  5. 19 May, 2009 1 commit
    • Rafael J. Wysocki's avatar
      PCI PM: Fix initialization and kexec breakage for some devices · b3bad72e
      Rafael J. Wysocki authored
      Recent PCI PM changes introduced a bug that causes some devices to be
      mishandled after kexec and during early initialization.  The failure
      scenario in the kexec case is the following:
      
      * Assume a PCI device is not power-manageable by the platform and has
        PCI_PM_CTRL_NO_SOFT_RESET set in PMCSR.
      * The device is put into D3 before kexec (using the native PCI PM).
      * After kexec, pci_setup_device() sets the device's power state to
        PCI_UNKNOWN.
      * pci_set_power_state(dev, PCI_D0) is called by the device's driver.
      * __pci_start_power_transition(dev, PCI_D0) is called and since the
        device is not power-manageable by the platform, it causes
        pci_update_current_state(dev, PCI_D0) to be called.  As a result
        the device's current_state field is updated to PCI_D3, in
        accordance with the contents of its PCI PM registers.
      * pci_raw_set_power_state() is called and it changes the device power
        state to D0.  *However*, it should also call pci_restore_bars() to
        reinitialize the device, but it doesn't, because the device's
        current_state field has been modified earlier.
      
      To prevent this from happening, modify pci_platform_power_transition()
      so that it doesn't use pci_update_current_state() to update the
      current_state field for devices that aren't power-manageable by the
      platform.  Instead, this field should be updated directly for devices
      that don't support the native PCI PM.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      b3bad72e
  6. 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
  7. 06 Apr, 2009 1 commit
    • Yuji Shimada's avatar
      PCI: Setup disabled bridges even if buses are added · 296ccb08
      Yuji Shimada authored
      This patch sets up disabled bridges even if buses have already been
      added.
      
      pci_assign_unassigned_resources is called after buses are added.
      pci_assign_unassigned_resources calls pci_bus_assign_resources.
      pci_bus_assign_resources calls pci_setup_bridge to configure BARs of
      bridges.
      
      Currently pci_setup_bridge returns immediately if the bus have already
      been added. So pci_assign_unassigned_resources can't configure BARs of
      bridges that were added in a disabled state; this patch fixes the issue.
      
      On logical hot-add, we need to prevent the kernel from re-initializing
      bridges that have already been initialized. To achieve this,
      pci_setup_bridge returns immediately if the bridge have already been
      enabled.
      
      We don't need to check whether the specified bus is a root bus or not.
      pci_setup_bridge is not called on a root bus, because a root bus does
      not have a bridge.
      
      The patch adds a new helper function, pci_is_enabled. I made the
      function name similar to pci_is_managed. The codes which use
      enable_cnt directly are changed to use pci_is_enabled.
      Acked-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarYuji Shimada <shimada-yxb@necst.nec.co.jp>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      296ccb08
  8. 30 Mar, 2009 6 commits
  9. 26 Mar, 2009 1 commit
  10. 20 Mar, 2009 7 commits
  11. 13 Feb, 2009 1 commit
  12. 05 Feb, 2009 2 commits
  13. 27 Jan, 2009 2 commits
    • Rafael J. Wysocki's avatar
      PCI PM: Do not wait for buses in B2 or B3 during resume · 476e7fae
      Rafael J. Wysocki authored
      pci_restore_standard_config() adds extra delay for PCI buses in
      low power states (B2 or B3), but this is only correct for buses in
      B2, because the buses in B3 are reset when they are put back into
      B0.  Thus we should wait for such buses to settle after the reset,
      but it's not a good idea to wait that long (1.1 s) with interrupts
      off.
      
      On the other hand, we have never waited for buses in B2 and B3
      during resume and it seems reasonable to go back to this well
      tested behaviour.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      476e7fae
    • Rafael J. Wysocki's avatar
      PCI PM: Power up devices before restoring their state · 48f67f54
      Rafael J. Wysocki authored
      Devices that have MSI-X enabled before suspend to RAM or hibernation
      and that are in a low power state during resume will not be handled
      correctly by pci_restore_standard_config().  Namely, it first calls
      pci_restore_state() which calls pci_restore_msi_state(), which in turn
      executes __pci_restore_msix_state() that accesses the device's memory
      space to restore the contents of the MSI-X table.  However, if the
      device is in a low power state at this point, it's memory space is
      not accessible.
      
      The easiest way to fix this potential problem is to make
      pci_restore_standard_config() call pci_restore_state() after
      it has put the device into the full power state, D0.  Fortunately,
      all of this is done with interrupts off, so the change of ordering
      should not cause any trouble.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      48f67f54
  14. 16 Jan, 2009 2 commits
    • Rafael J. Wysocki's avatar
      PCI PM: Restore standard config registers of all devices early · aa8c6c93
      Rafael J. Wysocki authored
      There is a problem in our handling of suspend-resume of PCI devices that
      many of them have their standard config registers restored with
      interrupts enabled and they are put into the full power state with
      interrupts enabled as well.  This may lead to the following scenario:
        * an interrupt vector is shared between two or more devices
        * one device is resumed earlier and generates an interrupt
        * the interrupt handler of another device tries to handle it and
          attempts to access the device the config space of which hasn't been
          restored yet and/or which still is in a low power state
        * the system crashes as a result
      
      To prevent this from happening we should restore the standard
      configuration registers of all devices with interrupts disabled and we
      should put them into the D0 power state right after that.
      Unfortunately, this cannot be done using the existing
      pci_set_power_state(), because it can sleep.  Also, to do it we have to
      make sure that the config spaces of all devices were actually saved
      during suspend.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      aa8c6c93
    • Linus Torvalds's avatar
      Revert "PCI PM: Register power state of devices during initialization" · 50246dd4
      Linus Torvalds authored
      This reverts commit 98e6e286, as Yinghai
      Lu reports that it breaks kexec with at least the e1000 and e1000e
      drivers.  The reason is that the shutdown sequence puts the hardware
      into D3 sleep, and the commit causes us to claim that it then is in D0
      (running) state just because we don't understand the PM capabilities.
      
      Which then later makes "pci_set_power_state()" not do anything, and the
      device never wakes up properly and just returns 0xff to everything.
      Reported-by: default avatarYinghai Lu <yinghai@kernel.org>
      Acked-by: default avatarFrom: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Jesse Barnes <jesse.barnes@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      50246dd4
  15. 07 Jan, 2009 4 commits