1. 02 8月, 2011 1 次提交
    • J
      PCI: Set PCI-E Max Payload Size on fabric · b03e7495
      Jon Mason 提交于
      On a given PCI-E fabric, each device, bridge, and root port can have a
      different PCI-E maximum payload size.  There is a sizable performance
      boost for having the largest possible maximum payload size on each PCI-E
      device.  However, if improperly configured, fatal bus errors can occur.
      Thus, it is important to ensure that PCI-E payloads sends by a device
      are never larger than the MPS setting of all devices on the way to the
      destination.
      
      This can be achieved two ways:
      
      - A conservative approach is to use the smallest common denominator of
        the entire tree below a root complex for every device on that fabric.
      
      This means for example that having a 128 bytes MPS USB controller on one
      leg of a switch will dramatically reduce performances of a video card or
      10GE adapter on another leg of that same switch.
      
      It also means that any hierarchy supporting hotplug slots (including
      expresscard or thunderbolt I suppose, dbl check that) will have to be
      entirely clamped to 128 bytes since we cannot predict what will be
      plugged into those slots, and we cannot change the MPS on a "live"
      system.
      
      - A more optimal way is possible, if it falls within a couple of
        constraints:
      * The top-level host bridge will never generate packets larger than the
        smallest TLP (or if it can be controlled independently from its MPS at
        least)
      * The device will never generate packets larger than MPS (which can be
        configured via MRRS)
      * No support of direct PCI-E <-> PCI-E transfers between devices without
        some additional code to specifically deal with that case
      
      Then we can use an approach that basically ignores downstream requests
      and focuses exclusively on upstream requests. In that case, all we need
      to care about is that a device MPS is no larger than its parent MPS,
      which allows us to keep all switches/bridges to the max MPS supported by
      their parent and eventually the PHB.
      
      In this case, your USB controller would no longer "starve" your 10GE
      Ethernet and your hotplug slots won't affect your global MPS.
      Additionally, the hotplugged devices themselves can be configured to a
      larger MPS up to the value configured in the hotplug bridge.
      
      To choose between the two available options, two PCI kernel boot args
      have been added to the PCI calls.  "pcie_bus_safe" will provide the
      former behavior, while "pcie_bus_perf" will perform the latter behavior.
      By default, the latter behavior is used.
      
      NOTE: due to the location of the enablement, each arch will need to add
      calls to this function.  This patch only enables x86.
      
      This patch includes a number of changes recommended by Benjamin
      Herrenschmidt.
      
      Tested-by: Jordan_Hargrave@dell.com
      Signed-off-by: NJon Mason <mason@myri.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b03e7495
  2. 23 7月, 2011 3 次提交
  3. 22 7月, 2011 1 次提交
  4. 08 6月, 2011 1 次提交
    • B
      pci/of: Match PCI devices to OF nodes dynamically · 98d9f30c
      Benjamin Herrenschmidt 提交于
      powerpc has two different ways of matching PCI devices to their
      corresponding OF node (if any) for historical reasons. The ppc64 one
      does a scan looking for matching bus/dev/fn, while the ppc32 one does a
      scan looking only for matching dev/fn on each level in order to be
      agnostic to busses being renumbered (which Linux does on some
      platforms).
      
      This removes both and instead moves the matching code to the PCI core
      itself. It's the most logical place to do it: when a pci_dev is created,
      we know the parent and thus can do a single level scan for the matching
      device_node (if any).
      
      The benefit is that all archs now get the matching for free. There's one
      hook the arch might want to provide to match a PHB bus to its device
      node. A default weak implementation is provided that looks for the
      parent device device node, but it's not entirely reliable on powerpc for
      various reasons so powerpc provides its own.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NMichal Simek <monstr@monstr.eu>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      98d9f30c
  5. 01 6月, 2011 1 次提交
    • D
      PCI: Fix warning in drivers/pci/probe.c on sparc64 · 5aceca9d
      David S. Miller 提交于
      IO_SPACE_LIMIT is currently used in two ways:
      
      1) As a way to mask I/O port values read out of PCI base address
         registers.  This value should be 64-bit.
      
      2) As a value which is the upper limit for all I/O "ports" in the
         system.
      
      On sparc64 we store the full 64-bit physical I/O address in the
      resources.  For this reason we define IO_SPACE_LIMIT at a 64-bit
      "all 1's".
      
      This is the right value to use for ioport_resource.end and for the
      check made in drivers/pcmcia/rsrc_nonstatic.c:adjust_io().
      
      But in driver/pci/probe.c:__pci_read_base() we mask this against
      a "u32" variable and thus get the following warning:
      
      drivers/pci/probe.c: In function ¡__pci_read_base¢:
      drivers/pci/probe.c:207: warning: large integer implicitly truncated to unsigned type
      
      Fix this by using an explicit "u32" cast.
      
      I considered changing sparc64 to define a 32-bit "all 1's" like
      most other systems do, but this wouldn't work because the checks
      in PCMCIA's rsrc_nonstatic.c would no longer be right since they
      are testing against fully formed 64-bit resources.  As described
      above, on sparc64 such resources will hold full 64-bit physical
      I/O addresses, not bus-centric 32-bit ones.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      5aceca9d
  6. 22 5月, 2011 2 次提交
  7. 09 2月, 2011 1 次提交
    • J
      PCI: Avoid potential NULL pointer dereference in pci_scan_bridge · 7c867c88
      Jesper Juhl 提交于
      pci_add_new_bus() calls pci_alloc_child_bus() which calls pci_alloc_bus()
      that allocates memory dynamically with kzalloc(). The return value of
      kzalloc() is the pointer that's eventually returned from
      pci_add_new_bus(), so since kzalloc() can fail and return NULL so can
      pci_add_new_bus(). Thus we may end up dereferencing a NULL pointer in
      drivers/pci/probe.c::pci_scan_bridge(). Seems to me we should test for
      this and bail out if it happens rather than crashing.
      Also removed some trailing whitespace that bugged me while looking at
      this.
      Signed-off-by: NJesper Juhl <jj@chaosbits.net>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      7c867c88
  8. 18 10月, 2010 1 次提交
  9. 31 7月, 2010 1 次提交
  10. 20 5月, 2010 1 次提交
  11. 23 4月, 2010 1 次提交
  12. 25 3月, 2010 3 次提交
  13. 27 2月, 2010 1 次提交
    • R
      PM: Allow PCI devices to suspend/resume asynchronously · a1e4d72c
      Rafael J. Wysocki 提交于
      Set power.async_suspend for all PCI devices and PCIe port services,
      so that they can be suspended and resumed in parallel with other
      devices they don't depend on in a known way (i.e. devices which are
      not their parents or children).
      
      This only affects the "regular" suspend and resume stages, which
      means in particular that the restoration of the PCI devices' standard
      configuration registers during resume will still be carried out
      synchronously (at the "early" resume stage).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      a1e4d72c
  14. 24 2月, 2010 3 次提交
    • 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: read bridge windows before filling in subtractive decode resources · 2adf7516
      Bjorn Helgaas 提交于
      No functional change; this fills in the bus subtractive decode resources
      after reading the bridge window information rather than before.  Also,
      print out the subtractive decode resources as we already do for the
      positive decode windows.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      2adf7516
    • B
      PCI: split up pci_read_bridge_bases() · fa27b2d1
      Bjorn Helgaas 提交于
      No functional change; this breaks up pci_read_bridge_bases() into separate
      pieces for the I/O, memory, and prefetchable memory windows, similar to how
      Yinghai recently split up pci_setup_bridge() in 68e84ff3bdc.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      fa27b2d1
  15. 23 2月, 2010 7 次提交
  16. 29 1月, 2010 1 次提交
  17. 05 12月, 2009 1 次提交
    • 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
  18. 25 11月, 2009 1 次提交
  19. 07 11月, 2009 1 次提交
  20. 05 11月, 2009 8 次提交