1. 20 2月, 2010 1 次提交
  2. 05 1月, 2010 1 次提交
    • R
      PCI/PM: Use per-device D3 delays · 1ae861e6
      Rafael J. Wysocki 提交于
      It turns out that some PCI devices require extra delays when changing
      power state from D3 to D0 (and the other way around).  Although this
      is against the PCI specification, we can handle it quite easily by
      allowing drivers to define arbitrary D3 delays for devices known to
      require extra time for switching power states.
      
      Introduce additional field d3_delay in struct pci_dev and use it to
      store the value of the device's D0->D3 delay, in miliseconds.  Make
      the PCI PM core code use the per-device d3_delay unless
      pci_pm_d3_delay is greater (in which case the latter is used).
      [This also allows the driver to specify d3_delay shorter than the
       10 ms required by the PCI standard if the device is known to be able
       to handle that.]
      
      Make the sky2 driver set d3_delay to 150 for devices handled by it.
      
      Fixes http://bugzilla.kernel.org/show_bug.cgi?id=14730 which is a
      listed regression from 2.6.30.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      1ae861e6
  3. 01 1月, 2010 1 次提交
  4. 17 12月, 2009 3 次提交
  5. 05 12月, 2009 4 次提交
    • K
      PCI: fix coding style issue in pci_save_state() · 9e0b5b2c
      Kleber Sacilotto de Souza 提交于
      Remove a stray space in pci_save_state().
      Signed-off-by: NKleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      9e0b5b2c
    • C
      PCI: add pci_request_acs · 5d990b62
      Chris Wright 提交于
      Commit ae21ee65 "PCI: acs p2p upsteram
      forwarding enabling" doesn't actually enable ACS.
      
      Add a function to pci core to allow an IOMMU to request that ACS
      be enabled.  The existing mechanism of using iommu_found() in the pci
      core to know when ACS should be enabled doesn't actually work due to
      initialization order;  iommu has only been detected not initialized.
      
      Have Intel and AMD IOMMUs request ACS, and Xen does as well during early
      init of dom0.
      
      Cc: Allen Kay <allen.m.kay@intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      Signed-off-by: NChris Wright <chrisw@sous-sol.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      5d990b62
    • S
      PCI: read-modify-write the pcie device control register when initiating pcie flr · 04b55c47
      Shmulik Ravid 提交于
      The pcie_flr routine writes the device control register with the FLR bit
      set clearing all other fields for the FLR duration. Among other fields,
      the Max_Payload_Size is also cleared which can cause errors if there are
      transactions lurking in the HW pipeline. The patch replaces the blank
      write with read-modify-write of the control register keeping the other
      fields intact.
      Signed-off-by: NShmulik Ravid <shmulikr@broadcom.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      04b55c47
    • Y
      PCI: add debug output for DMA mask info · c6a41576
      Yinghai Lu 提交于
      This allows us to find out what DMA mask is used for each PCI device at boot
      time; useful for debugging.
      
      After the patch:
      ehci_hcd 0000:00:02.1: using 31bit consistent DMA mask
      e1000 0000:0b:01.0: using 64bit DMA mask
      e1000 0000:0b:01.0: using 64bit consistent DMA mask
      e1000e 0000:04:00.0: using 64bit DMA mask
      e1000e 0000:04:00.0: using 64bit consistent DMA mask
      ixgb 0000:0c:01.0: using 64bit DMA mask
      ixgb 0000:0c:01.0: using 64bit consistent DMA mask
      aacraid 0000:86:00.0: using 32bit DMA mask
      aacraid 0000:86:00.0: using 32bit consistent DMA mask
      aacraid 0000:86:00.0: using 64bit DMA mask
      aacraid 0000:86:00.0: using 64bit consistent DMA mask
      qla2xxx 0000:0c:02.0: using 64bit consistent DMA mask
      qla2xxx 0000:0c:02.1: using 64bit consistent DMA mask
      lpfc 0000:06:00.0: using 64bit DMA mask
      lpfc 0000:06:00.1: using 64bit DMA mask
      pata_amd 0000:00:06.0: using 32bit DMA mask
      pata_amd 0000:00:06.0: using 32bit consistent DMA mask
      mptsas 0000:0c:04.0: using 64bit DMA mask
      mptsas 0000:0c:04.0: using 64bit consistent DMA mask
      
      forcedeth 0000:00:08.0: using 39bit DMA mask
      forcedeth 0000:00:08.0: using 39bit consistent DMA mask
      niu 0000:02:00.0: using 44bit DMA mask
      niu 0000:02:00.0: using 44bit consistent DMA mask
      sata_nv 0000:00:05.0: using 32bit DMA mask
      sata_nv 0000:00:05.0: using 32bit consistent DMA mask
      ib_mthca 0000:03:00.0: using 64bit DMA mask
      ib_mthca 0000:03:00.0: using 64bit consistent DMA mask
      Reviewed-by: NGrant Grundler <grundler@google.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      c6a41576
  6. 25 11月, 2009 2 次提交
  7. 11 11月, 2009 1 次提交
    • L
      PCI: allow matching of prefetchable resources to non-prefetchable windows · 8c8def26
      Linus Torvalds 提交于
      I'm not entirely sure it needs to go into 32, but it's probably the right
      thing to do. Another way of explaining the patch is:
      
       - we currently pick the _first_ exactly matching bus resource entry, but
         the _last_ inexactly matching one. Normally first/last shouldn't
         matter, but bus resource entries aren't actually all created equal: in
         a transparent bus, the last resources will be the parent resources,
         which we should generally try to avoid unless we have no choice. So
         "first matching" is the thing we should always aim for.
      
       - the patch is a bit bigger than it needs to be, because I simplified the
         logic at the same time. It used to be a fairly incomprehensible
      
      	if ((res->flags & IORESOURCE_PREFETCH) && !(r->flags & IORESOURCE_PREFETCH))
      		best = r;       /* Approximating prefetchable by non-prefetchable */
      
         and technically, all the patch did was to make that complex choice be
         even more complex (it basically added a "&& !best" to say that if we
         already gound a non-prefetchable window for the prefetchable resource,
         then we won't override an earlier one with that later one: remember
         "first matching").
      
       - So instead of that complex one with three separate conditionals in one,
         I split it up a bit, and am taking advantage of the fact that we
         already handled the exact case, so if 'res->flags' has the PREFETCH
         bit, then we already know that 'r->flags' will _not_ have it. So the
         simplified code drops the redundant test, and does the new '!best' test
         separately. It also uses 'continue' as a way to ignore the bus
         resource we know doesn't work (ie a prefetchable bus resource is _not_
         acceptable for anything but an exact match), so it turns into:
      
      	/* We can't insert a non-prefetch resource inside a prefetchable parent .. */
      	if (r->flags & IORESOURCE_PREFETCH)
      		continue;
      	/* .. but we can put a prefetchable resource inside a non-prefetchable one */
      	if (!best)
      		best = r;
      
         instead. With the comments, it's now six lines instead of two, but it's
         conceptually simpler, and I _could_ have written it as two lines:
      
      	if ((res->flags & IORESOURCE_PREFETCH) && !best)
      		best = r;	/* Approximating prefetchable by non-prefetchable */
      
         but I thought that was too damn subtle.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      8c8def26
  8. 07 11月, 2009 1 次提交
  9. 05 11月, 2009 9 次提交
  10. 12 10月, 2009 1 次提交
  11. 08 10月, 2009 1 次提交
  12. 07 10月, 2009 1 次提交
    • R
      PCI PM: Read device power state from register after updating it · e13cdbd7
      Rafael J. Wysocki 提交于
      After attempting to change the power state of a PCI device
      pci_raw_set_power_state() doesn't check if the value it wrote into
      the device's PCI_PM_CTRL register has been stored in there, but
      unconditionally modifies the device's current_state field to reflect
      the change.  This may cause problems to happen if the power state of
      the device hasn't been changed in fact, because it will make the PCI
      PM core make a wrong assumption.
      
      To prevent such situations from happening modify
      pci_raw_set_power_state() so that it reads the device's PCI_PM_CTRL
      register after writing into it and uses the value read from the
      register to update the device's current_state field.  Also make it
      print a message saying that the device refused to change its power
      state as requested (returning an error code in such cases would cause
      suspend regressions to appear on some systems, where device drivers'
      suspend routines return error codes if pci_set_power_state() fails).
      Reviewed-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      e13cdbd7
  13. 15 9月, 2009 1 次提交
    • R
      PCI: Clear saved_state after the state has been restored · 4b77b0a2
      Rafael J. Wysocki 提交于
      Some PCI devices fail if their standard configuration registers are
      restored twice in a row.  Prevent this from happening by making
      pci_restore_state() clear the saved_state flag of the device right
      after the device's standard configuration registers have been
      populated with the previously saved values.
      
      Simplify PCI PM callbacks by removing the direct clearing of
      state_saved from them, as it shouldn't be necessary any more (except
      in pci_pm_thaw(), where it has to be cleared, so that the values saved
      during the "freeze" phase of hibernation are not used later by mistake).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      4b77b0a2
  14. 10 9月, 2009 5 次提交
  15. 21 8月, 2009 1 次提交
  16. 02 7月, 2009 1 次提交
  17. 30 6月, 2009 1 次提交
  18. 17 6月, 2009 5 次提交