1. 17 1月, 2015 2 次提交
    • Y
      PCI: Add pci_claim_bridge_resource() to clip window if necessary · 8505e729
      Yinghai Lu 提交于
      Add pci_claim_bridge_resource() to claim a PCI-PCI bridge window.  This is
      like regular pci_claim_resource(), except that if we fail to claim the
      window, we check to see if we can reduce the size of the window and try
      again.
      
      This is for scenarios like this:
      
        pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff]
        pci 0000:00:01.0:   bridge window [mem 0xbdf00000-0xddefffff 64bit pref]
        pci 0000:01:00.0: reg 0x10: [mem 0xc0000000-0xcfffffff pref]
      
      The 00:01.0 window is illegal: it starts before the host bridge window, so
      we have to assume the [0xbdf00000-0xbfffffff] region is inaccessible.  We
      can make it legal by clipping it to [mem 0xc0000000-0xddefffff 64bit pref].
      
      Previously we discarded the 00:01.0 window and tried to reassign that part
      of the hierarchy from scratch.  That is a problem because Linux doesn't
      always assign things optimally.  For example, in this case, BIOS put the
      01:00.0 device in a prefetchable window below 4GB, but after 5b285415,
      Linux puts the prefetchable window above 4GB where the 32-bit 01:00.0
      device can't use it.
      
      Clipping the 00:01.0 window is less intrusive than completely reassigning
      things and is sufficient to let us use most of the BIOS configuration.  Of
      course, it's possible that devices below 00:01.0 will no longer fit.  If
      that's the case, we'll have to reassign things.  But that's a separate
      problem.
      
      [bhelgaas: changelog, split into separate patch]
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491Reported-by: NMarek Kordik <kordikmarek@gmail.com>
      Fixes: 5b285415 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.16+
      8505e729
    • Y
      PCI: Pass bridge device, not bus, when updating bridge windows · 3f2f4dc4
      Yinghai Lu 提交于
      pci_setup_bridge_io(), pci_setup_bridge_mmio(), and
      pci_setup_bridge_mmio_pref() program the windows of PCI-PCI bridges.
      Previously they accepted a pointer to the pci_bus of the secondary bus,
      then looked up the bridge leading to that bus.  Pass the bridge directly,
      which will make it more convenient for future callers.
      
      No functional change.
      
      [bhelgaas: changelog, split into separate patch]
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491Reported-by: NMarek Kordik <kordikmarek@gmail.com>
      Fixes: 5b285415 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.16+
      3f2f4dc4
  2. 01 10月, 2014 1 次提交
  3. 09 7月, 2014 1 次提交
  4. 11 6月, 2014 2 次提交
  5. 28 5月, 2014 1 次提交
  6. 24 5月, 2014 4 次提交
    • B
      PCI: Add resource allocation comments · 67d29b5c
      Bjorn Helgaas 提交于
      Add comments in the code to match the allocation strategy of 7c671426dfc3
      ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources").
      
      No functional change.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      67d29b5c
    • B
      PCI: Change pbus_size_mem() return values to be more conventional · 30afe8d0
      Bjorn Helgaas 提交于
      pbus_size_mem() previously returned 0 for failure and 1 for success.
      Change it to return -ENOSPC for failure and 0 for success.
      
      No functional change.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      30afe8d0
    • Y
      PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources · 5b285415
      Yinghai Lu 提交于
      This patch changes the way we handle 64-bit prefetchable bridge windows to
      make it more likely that we can assign space to all devices.
      
      Previously we put all prefetchable resources in the prefetchable bridge
      window.  If any of those resources was 32-bit only, we restricted the
      window to be below 4GB.
      
      After this patch, we only put 64-bit prefetchable resources in a 64-bit
      prefetchable window.  We put all 32-bit prefetchable resources in the
      non-prefetchable window, even if there are no 64-bit prefetchable
      resources.
      
      With the previous approach, if there was a 32-bit prefetchable resource
      behind a bridge, we forced the bridge's prefetchable window below 4GB,
      which meant that even if there was plenty of space above 4GB available, we
      couldn't use it, and assignment of large 64-bit resources could fail, as
      in the bugzilla below.
      
      The new strategy is:
      
        1) If the prefetchable window is 64 bits wide, we put only 64-bit
           prefetchable resources in it.  Any 32-bit prefetchable resources go in
           the non-prefetchable window.
      
        2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
           prefetchable resources in it.
      
        3) If there is no prefetchable window, all MMIO resources go in the
           non-prefetchable window.
      
      This reduces performance for 32-bit prefetchable resources below a bridge
      with a 64-bit prefetchable window.  We previously assigned prefetchable
      space, but now we'll assign non-prefetchable space.  This is the case even
      if there are no 64-bit prefetchable resources, or if they would all fit
      below 4GB.  In those cases, the old strategy would work and would have
      better performance.
      
      [bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151Tested-by: NGuo Chao <yan@linux.vnet.ibm.com>
      Tested-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      5b285415
    • A
      PCI: Support BAR sizes up to 8GB · 14c8530d
      Alan 提交于
      This is needed for some of the Xeon Phi type systems.
      
      [bhelgaas: added Nikhil, use ARRAY_SIZE() to connect with decl, folded in
      Kevin's "order < 0" fix to ARRAY_SIZE() usage]
      Signed-off-by: NNikhil P Rao <nikhil.rao@intel.com>
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NKevin Hilman <khilman@linaro.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      14c8530d
  7. 30 4月, 2014 1 次提交
    • B
      PCI: Remove unnecessary __ref annotations · 10874f5a
      Bjorn Helgaas 提交于
      Some PCI functions used to be marked __devinit.  When CONFIG_HOTPLUG was
      not set, these functions were discarded after boot.  A few callers of these
      __devinit functions were marked __ref to indicate that they could safely
      call the __devinit functions even though the callers were not __devinit.
      
      But CONFIG_HOTPLUG and __devinit are now gone, and the need for the __ref
      annotations is also gone, so remove them.  Relevant historical commits:
      
        54b956b9 Remove __dev* markings from init.h
        a8e4b9c1 PCI: add generic pci_hp_add_bridge()
        0ab2b57f PCI: fix section mismatch warning in pci_scan_child_bus
        451124a7 PCI: fix 4x section mismatch warnings
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      10874f5a
  8. 22 12月, 2013 1 次提交
    • Y
      PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev · fc279850
      Yinghai Lu 提交于
      These interfaces:
      
        pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
        pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
      
      took a pci_dev, but they really depend only on the pci_bus.  And we want to
      use them in resource allocation paths where we have the bus but not a
      device, so this patch converts them to take the pci_bus instead of the
      pci_dev:
      
        pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
        pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
      
      In fact, with standard PCI-PCI bridges, they only depend on the host
      bridge, because that's the only place address translation occurs, but
      we aren't going that far yet.
      
      [bhelgaas: changelog]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      fc279850
  9. 13 12月, 2013 2 次提交
    • B
      PCI: Stop clearing bridge Secondary Status when setting up I/O aperture · 5b764b83
      Bjorn Helgaas 提交于
      pci_setup_bridge_io() accessed PCI_IO_BASE and PCI_IO_LIMIT using dword
      (32-bit) reads and writes, which also access the Secondary Status register.
      Since the Secondary Status register is in the upper 16 bits of the dword,
      and we preserved those upper 16 bits, this had the effect of clearing any
      of the write-1-to-clear bits that happened to be set in the Secondary
      Status register.
      
      That's not what we want, so use word (16-bit) accesses to update only
      PCI_IO_BASE and PCI_IO_LIMIT.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      5b764b83
    • B
      PCI: Prevent bus conflicts while checking for bridge apertures · d2f54d9b
      Bjorn Helgaas 提交于
      pci_bridge_check_ranges() determines whether the bridge supports an I/O
      aperture and a prefetchable memory aperture.
      
      Previously, if the I/O aperture was unsupported, disabled, or configured at
      [io 0x0000-0x0fff], we wrote 0xf0 to PCI_IO_BASE and PCI_IO_LIMIT, which,
      if the bridge supports it, enables the I/O aperture at [io 0xf000-0xffff].
      The enabled aperture may conflict with other devices in the system.
      
      Similarly, we wrote 0xfff0 to PCI_PREF_MEMORY_BASE and
      PCI_PREF_MEMORY_LIMIT, which enables the prefetchable memory aperture at
      [mem 0xfff00000-0xffffffff], and that may also conflict with other devices.
      
      All we need to know is whether the base and limit registers are writable,
      so we can use values that leave the apertures disabled, e.g., PCI_IO_BASE =
      0xf0, PCI_IO_LIMIT = 0xe0, PCI_PREF_MEMORY_BASE = 0xfff0,
      PCI_PREF_MEMORY_LIMIT = 0xffe0.
      
      Writing non-zero values to both the base and limit registers means we
      detect whether either or both are writable, as we did before.
      Reported-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Based-on-patch-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      d2f54d9b
  10. 15 11月, 2013 1 次提交
  11. 26 9月, 2013 2 次提交
  12. 06 8月, 2013 1 次提交
  13. 03 8月, 2013 3 次提交
  14. 26 7月, 2013 9 次提交
  15. 23 6月, 2013 1 次提交
    • J
      PCI / ACPI: Use boot-time resource allocation rules during hotplug · d66ecb72
      Jiang Liu 提交于
      On x86 platforms, the kernel respects PCI resource assignments from
      the BIOS and only reassigns resources for unassigned BARs at boot
      time.  However, with the ACPI-based hotplug (acpiphp), it ignores the
      BIOS' PCI resource assignments completely and reassigns all resources
      by itself.  This causes differences in PCI resource allocation
      between boot time and runtime hotplug to occur, which is generally
      undesirable and sometimes actively breaks things.
      
      Namely, if there are enough resources, reassigning all PCI resources
      during runtime hotplug should work, but it may fail if the resources
      are constrained.  This may happen, for instance, when some PCI
      devices with huge MMIO BARs are involved in the runtime hotplug
      operations, because the current PCI MMIO alignment algorithm may
      waste huge chunks of MMIO address space in those cases.
      
      On the Alexander's Sony VAIO VPCZ23A4R the BIOS allocates limited
      MMIO resources for the dock station which contains a device
      (graphics adapter) with a 256MB MMIO BAR.  An attempt to reassign
      that during runtime hotplug causes the dock station MMIO window to be
      exhausted and acpiphp fails to allocate resources for the majority
      of devices on the dock station as a result.
      
      To prevent that from happening, modify acpiphp to follow the boot
      time resources allocation behavior so that the BIOS' resource
      assignments are respected during runtime hotplug too.
      
      [rjw: Changelog]
      References: https://bugzilla.kernel.org/show_bug.cgi?id=56531Reported-and-tested-by: NAlexander E. Patrakov <patrakov@gmail.com>
      Tested-by: NIllya Klymov <xanf@xanf.me>
      Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Cc: 3.9+ <stable@vger.kernel.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d66ecb72
  16. 18 4月, 2013 1 次提交
  17. 13 4月, 2013 1 次提交
  18. 26 1月, 2013 1 次提交
  19. 04 11月, 2012 2 次提交
  20. 31 10月, 2012 1 次提交
  21. 12 9月, 2012 2 次提交