1. 11 6月, 2014 1 次提交
  2. 28 5月, 2014 1 次提交
  3. 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
  4. 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
  5. 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
  6. 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
  7. 15 11月, 2013 1 次提交
  8. 26 9月, 2013 2 次提交
  9. 06 8月, 2013 1 次提交
  10. 03 8月, 2013 3 次提交
  11. 26 7月, 2013 9 次提交
  12. 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
  13. 18 4月, 2013 1 次提交
  14. 13 4月, 2013 1 次提交
  15. 26 1月, 2013 1 次提交
  16. 04 11月, 2012 2 次提交
  17. 31 10月, 2012 1 次提交
  18. 12 9月, 2012 3 次提交
  19. 24 7月, 2012 1 次提交
  20. 10 7月, 2012 2 次提交
    • Y
      PCI: support sizing P2P bridge I/O windows with 1K granularity · fd591341
      Yinghai Lu 提交于
      Some bridges support I/O windows with 1K alignment, not just the 4K
      alignment defined by the PCI spec.  For example, see the IOBL_ADR register
      and the EN1K bit in the CNF register in the Intel 82870P2 (P64H2).
      
      This patch adds support for sizing the window in 1K increments based
      on the requirements of downstream devices.
      
      [bhelgaas: changelog, comment]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      fd591341
    • B
      PCI: reimplement P2P bridge 1K I/O windows (Intel P64H2) · 2b28ae19
      Bjorn Helgaas 提交于
      9d265124 and 15a260d5 added quirks for P2P bridges that support
      I/O windows that start/end at 1K boundaries, not just the 4K boundaries
      defined by the PCI spec.  For details, see the IOBL_ADR register and the
      EN1K bit in the CNF register in the Intel 82870P2 (P64H2).
      
      These quirks complicate the code that reads P2P bridge windows
      (pci_read_bridge_io() and pci_cfg_fake_ranges()) because the bridge
      I/O resource is updated in the HEADER quirk, in pci_read_bridge_io(),
      in pci_setup_bridge(), and again in the FINAL quirk.  This is confusing
      and makes it impossible to reassign the bridge windows after FINAL
      quirks are run.
      
      This patch adds support for 1K windows in the generic paths, so the
      HEADER quirk only has to enable this support.  The FINAL quirk, which
      used to undo damage done by pci_setup_bridge(), is no longer needed.
      
      This removes "if (!res->start) res->start = ..." from pci_read_bridge_io();
      that was part of 9d265124 to avoid overwriting the resource filled in
      by the quirk.  Since pci_read_bridge_io() itself now knows about
      granularity, the quirk no longer updates the resource and this test is no
      longer needed.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      2b28ae19
  21. 21 6月, 2012 1 次提交