1. 23 4月, 2009 1 次提交
    • Y
      PCI: only save/restore existent registers in the PCIe capability · 1b6b8ce2
      Yu Zhao 提交于
      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: NYu Zhao <yu.zhao@intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      1b6b8ce2
  2. 07 4月, 2009 1 次提交
    • Y
      PCI: Setup disabled bridges even if buses are added · 296ccb08
      Yuji Shimada 提交于
      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: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NYuji Shimada <shimada-yxb@necst.nec.co.jp>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      296ccb08
  3. 31 3月, 2009 5 次提交
  4. 30 3月, 2009 1 次提交
  5. 27 3月, 2009 1 次提交
  6. 21 3月, 2009 5 次提交
  7. 20 3月, 2009 2 次提交
  8. 14 2月, 2009 1 次提交
  9. 05 2月, 2009 2 次提交
  10. 28 1月, 2009 2 次提交
    • R
      PCI PM: Do not wait for buses in B2 or B3 during resume · 476e7fae
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      476e7fae
    • R
      PCI PM: Power up devices before restoring their state · 48f67f54
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      48f67f54
  11. 17 1月, 2009 2 次提交
    • R
      PCI PM: Restore standard config registers of all devices early · aa8c6c93
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      aa8c6c93
    • L
      Revert "PCI PM: Register power state of devices during initialization" · 50246dd4
      Linus Torvalds 提交于
      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: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NFrom: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Jesse Barnes <jesse.barnes@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      50246dd4
  12. 08 1月, 2009 17 次提交