1. 12 5月, 2011 2 次提交
    • J
      PCI: add OBFF enable/disable support · 48a92a81
      Jesse Barnes 提交于
      OBFF (optimized buffer flush/fill), where supported, can help improve
      energy efficiency by giving devices information about when interrupts
      and other activity will have a reduced power impact.  It requires
      support from both the device and system (i.e. not only does the device
      need to respond to OBFF messages, but the platform must be capable of
      generating and routing them to the end point).
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      48a92a81
    • J
      PCI: add ID-based ordering enable/disable support · b48d4425
      Jesse Barnes 提交于
      Add support to allow drivers to enable/disable ID-based ordering.  Where
      supported, ID-based ordering can significantly improve the latency of
      individual requests by preventing them from queueing up behind unrelated
      traffic.
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b48d4425
  2. 22 3月, 2011 1 次提交
  3. 10 3月, 2011 1 次提交
  4. 17 2月, 2011 1 次提交
  5. 15 1月, 2011 3 次提交
  6. 24 12月, 2010 1 次提交
  7. 18 10月, 2010 1 次提交
  8. 16 10月, 2010 1 次提交
  9. 14 8月, 2010 1 次提交
  10. 31 7月, 2010 1 次提交
  11. 17 7月, 2010 1 次提交
    • B
      PCI: fall back to original BIOS BAR addresses · 58c84eda
      Bjorn Helgaas 提交于
      If we fail to assign resources to a PCI BAR, this patch makes us try the
      original address from BIOS rather than leaving it disabled.
      
      Linux tries to make sure all PCI device BARs are inside the upstream
      PCI host bridge or P2P bridge apertures, reassigning BARs if necessary.
      Windows does similar reassignment.
      
      Before this patch, if we could not move a BAR into an aperture, we left
      the resource unassigned, i.e., at address zero.  Windows leaves such BARs
      at the original BIOS addresses, and this patch makes Linux do the same.
      
      This is a bit ugly because we disable the resource long before we try to
      reassign it, so we have to keep track of the BIOS BAR address somewhere.
      For lack of a better place, I put it in the struct pci_dev.
      
      I think it would be cleaner to attempt the assignment immediately when the
      claim fails, so we could easily remember the original address.  But we
      currently claim motherboard resources in the middle, after attempting to
      claim PCI resources and before assigning new PCI resources, and changing
      that is a fairly big job.
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16263Reported-by: NAndrew <nitr0@seti.kr.ua>
      Tested-by: NAndrew <nitr0@seti.kr.ua>
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      58c84eda
  12. 20 5月, 2010 1 次提交
  13. 10 5月, 2010 1 次提交
    • M
      i7core_edac: Add a code to probe Xeon 55xx bus · d1fd4fb6
      Mauro Carvalho Chehab 提交于
      This code changes the detection procedure of i7core_edac. Instead of
      directly probing for MC registers, it probes for another register found
      on Nehalem. If found, it tries to pick the first MC PCI BUS. This should
      work fine with Xeon 35xx, but, on Xeon 55xx, this is at bus 254 and 255
      that are not properly detected by the non-legacy PCI methods.
      
      The new detection code scans specifically at buses 254 and 255 for the
      Xeon 55xx devices.
      
      This code has not tested yet. After working, a change at the code will
      be needed, since the i7core is not yet ready for working with 2 sets of
      MC.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      d1fd4fb6
  14. 10 4月, 2010 1 次提交
  15. 13 3月, 2010 2 次提交
  16. 28 2月, 2010 5 次提交
  17. 24 2月, 2010 2 次提交
    • B
      PCI: augment bus resource table with a list · 2fe2abf8
      Bjorn Helgaas 提交于
      Previously we used a table of size PCI_BUS_NUM_RESOURCES (16) for resources
      forwarded to a bus by its upstream bridge.  We've increased this size
      several times when the table overflowed.
      
      But there's no good limit on the number of resources because host bridges
      and subtractive decode bridges can forward any number of ranges to their
      secondary buses.
      
      This patch reduces the table to only PCI_BRIDGE_RESOURCE_NUM (4) entries,
      which corresponds to the number of windows a PCI-to-PCI (3) or CardBus (4)
      bridge can positively decode.  Any additional resources, e.g., PCI host
      bridge windows or subtractively-decoded regions, are kept in a list.
      
      I'd prefer a single list rather than this split table/list approach, but
      that requires simultaneous changes to every architecture.  This approach
      only requires immediate changes where we set up (a) host bridges with more
      than four windows and (b) subtractive-decode P2P bridges, and we can
      incrementally change other architectures to use the list.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      2fe2abf8
    • B
      PCI: add pci_bus_for_each_resource(), remove direct bus->resource[] refs · 89a74ecc
      Bjorn Helgaas 提交于
      No functional change; this converts loops that iterate from 0 to
      PCI_BUS_NUM_RESOURCES through pci_bus resource[] table to use the
      pci_bus_for_each_resource() iterator instead.
      
      This doesn't change the way resources are stored; it merely removes
      dependencies on the fact that they're in a table.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      89a74ecc
  18. 23 2月, 2010 13 次提交
  19. 20 2月, 2010 1 次提交