1. 25 8月, 2015 1 次提交
    • L
      PCI: Add pci_ioremap_wc_bar() · c43996f4
      Luis R. Rodriguez 提交于
      This lets drivers take advantage of PAT when available. It
      should help with the transition of converting video drivers over
      to ioremap_wc() to help with the goal of eventually using
      _PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
      ioremap_nocache(), see:
      
        de33c442 ("x86 PAT: fix performance drop for glx, use UC minus for ioremap(), ioremap_nocache() and pci_mmap_page_range()")
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Cc: <syrjala@sci.fi>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Antonino Daplas <adaplas@gmail.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Davidlohr Bueso <dbueso@suse.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Suresh Siddha <sbsiddha@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Ville Syrjälä <syrjala@sci.fi>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: airlied@linux.ie
      Cc: benh@kernel.crashing.org
      Cc: dan.j.williams@intel.com
      Cc: konrad.wilk@oracle.com
      Cc: linux-fbdev@vger.kernel.org
      Cc: linux-pci@vger.kernel.org
      Cc: mst@redhat.com
      Cc: vinod.koul@intel.com
      Cc: xen-devel@lists.xensource.com
      Link: http://lkml.kernel.org/r/1440443613-13696-2-git-send-email-mcgrof@do-not-panic.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      c43996f4
  2. 24 8月, 2015 1 次提交
    • K
      PCI: Set MPS to match upstream bridge · 27d868b5
      Keith Busch 提交于
      Firmware typically configures the PCIe fabric with a consistent Max Payload
      Size setting based on the devices present at boot.  A hot-added device
      typically has the power-on default MPS setting (128 bytes), which may not
      match the fabric.
      
      The previous Linux default, in the absence of any "pci=pcie_bus_*" options,
      was PCIE_BUS_TUNE_OFF, in which we never touch MPS, even for hot-added
      devices.
      
      Add a new default setting, PCIE_BUS_DEFAULT, in which we make sure every
      device's MPS setting matches the upstream bridge.  This makes it more
      likely that a hot-added device will work in a system with optimized MPS
      configuration.
      
      Note that if we hot-add a device that only supports 128-byte MPS, it still
      likely won't work because we don't reconfigure the rest of the fabric.
      Booting with "pci=pcie_bus_peer2peer" is a workaround for this because it
      sets MPS to 128 for everything.
      
      [bhelgaas: changelog, new default, rework for pci_configure_device() path]
      Tested-by: NKeith Busch <keith.busch@intel.com>
      Tested-by: NJordan Hargrave <jharg93@gmail.com>
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      27d868b5
  3. 21 7月, 2015 1 次提交
  4. 15 7月, 2015 3 次提交
  5. 23 5月, 2015 1 次提交
  6. 07 5月, 2015 1 次提交
  7. 10 4月, 2015 1 次提交
  8. 09 4月, 2015 1 次提交
  9. 13 3月, 2015 2 次提交
  10. 24 1月, 2015 1 次提交
    • R
      PCI / PM: Avoid resuming PCI devices during system suspend · bac2a909
      Rafael J. Wysocki 提交于
      Commit f25c0ae2 (ACPI / PM: Avoid resuming devices in ACPI PM
      domain during system suspend) modified the ACPI PM domain's system
      suspend callbacks to allow devices attached to it to be left in the
      runtime-suspended state during system suspend so as to optimize
      the suspend process.
      
      This was based on the general mechanism introduced by commit
      aae4518b (PM / sleep: Mechanism to avoid resuming runtime-suspended
      devices unnecessarily).
      
      Extend that approach to PCI devices by modifying the PCI bus type's
      ->prepare callback to return 1 for devices that are runtime-suspended
      when it is being executed and that are in a suitable power state and
      need not be resumed going forward.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      bac2a909
  11. 17 1月, 2015 2 次提交
    • A
      PCI: Add flag for devices that don't reset on D3hot->D0 transition · 51e53738
      Alex Williamson 提交于
      Per the PCI Power Management spec r1.2, sec 3.2.4, a device that advertises
      No_Soft_Reset == 0 in the PMCSR register (reported by lspci as "NoSoftRst-")
      should perform an internal reset when transitioning from D3hot to D0 via
      software control.  Configuration context is lost and the device requires a
      full reinitialization sequence.
      
      Unfortunately the definition of "internal reset", beyond the application of
      the configuration context, is largely left to the interpretation of the
      specific device.  Some devices don't seem to perform an "internal reset"
      even if they report No_Soft_Reset == 0.
      
      We still need to honor the PCI specification and restore PCI config context
      in the event that we do a PM reset, so we don't cache and modify the
      PCI_PM_CTRL_NO_SOFT_RESET bit for the device, but for interfaces where the
      intention is to reset the device, like pci_reset_function(), we need a
      mechanism to flag that PM reset (a D3hot->D0 transition) doesn't perform
      any significant "internal reset" of the device.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      51e53738
    • A
      PCI: Add flag for devices where we can't use bus reset · f331a859
      Alex Williamson 提交于
      Enable a mechanism for devices to quirk that they do not behave when
      doing a PCI bus reset.  We require a modest level of spec compliant
      behavior in order to do a reset, for instance the device should come
      out of reset without throwing errors and PCI config space should be
      accessible after reset.  This is too much to ask for some devices.
      
      Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.orgSigned-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.14+
      f331a859
  12. 28 12月, 2014 1 次提交
  13. 04 12月, 2014 1 次提交
  14. 20 11月, 2014 1 次提交
  15. 14 11月, 2014 1 次提交
  16. 11 11月, 2014 1 次提交
  17. 01 10月, 2014 2 次提交
    • L
      PCI: Add pci_remap_iospace() to map bus I/O resources · 8b921acf
      Liviu Dudau 提交于
      Add pci_remap_iospace() to map bus I/O resources into the CPU virtual
      address space.  Architectures with special needs may provide their own
      version, but most should be able to use this one.
      
      This function is useful for PCI host bridge drivers that need to map the
      PCI I/O resources into virtual memory space.
      
      [bhelgaas: phys_addr description, drop temporary "err" variable]
      Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NRob Herring <robh@kernel.org>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      CC: Arnd Bergmann <arnd@arndb.de>
      8b921acf
    • L
      of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr() · 41e5c0f8
      Liviu Dudau 提交于
      Add pci_get_new_domain_nr() to allocate a new domain number and
      of_get_pci_domain_nr() to retrieve the PCI domain number of a given device
      from DT.  Host bridge drivers or architecture-specific code can choose to
      implement their PCI domain number policy using these two functions.
      
      Using of_get_pci_domain_nr() guarantees a stable PCI domain number on every
      boot provided that all host bridge controllers are assigned a number in the
      device tree using "linux,pci-domain" property.  Mixing use of
      pci_get_new_domain_nr() and of_get_pci_domain_nr() is not recommended as it
      can lead to potentially conflicting domain numbers being assigned to root
      buses behind different host bridges.
      Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Arnd Bergmann <arnd@arndb.de>
      CC: Grant Likely <grant.likely@linaro.org>
      CC: Rob Herring <robh+dt@kernel.org>
      CC: Catalin Marinas <catalin.marinas@arm.com>
      41e5c0f8
  18. 24 9月, 2014 1 次提交
  19. 03 9月, 2014 1 次提交
  20. 17 7月, 2014 1 次提交
    • V
      PCI: Configure ASPM when enabling device · 1f6ae47e
      Vidya Sagar 提交于
      We can't do ASPM configuration at enumeration-time because enabling it
      makes some defective hardware unresponsive, even if ASPM is disabled later
      (see 41cd766b ("PCI: Don't enable aspm before drivers have had a chance
      to veto it").  Therefore, we have to do it after a driver claims the
      device.
      
      We previously configured ASPM in pci_set_power_state(), but that's not a
      very good place because it's not really related to setting the PCI device
      power state, and doing it there means:
      
        - We incorrectly skipped ASPM config when setting a device that's
          already in D0 to D0.
      
        - We unnecessarily configured ASPM when setting a device to a low-power
          state (the ASPM feature only applies when the device is in D0).
      
        - We unnecessarily configured ASPM when called from a .resume() method
          (ASPM configuration needs to be restored during resume, but
          pci_restore_pcie_state() should already do this).
      
      Move ASPM configuration from pci_set_power_state() to
      do_pci_enable_device() so we do it when a driver enables a device.
      
      [bhelgaas: changelog]
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=79621
      Fixes: db288c9c ("PCI / PM: restore the original behavior of pci_set_power_state()")
      Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NVidya Sagar <sagar.tv@gmail.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.6+
      1f6ae47e
  21. 04 7月, 2014 1 次提交
  22. 18 6月, 2014 1 次提交
  23. 11 6月, 2014 3 次提交
  24. 28 5月, 2014 2 次提交
  25. 20 5月, 2014 1 次提交
  26. 05 5月, 2014 1 次提交
  27. 28 4月, 2014 1 次提交
  28. 26 4月, 2014 1 次提交
  29. 20 3月, 2014 1 次提交
  30. 13 3月, 2014 1 次提交
    • B
      PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled · 3cdeb713
      Bjorn Helgaas 提交于
      Andreas reported that after 1f42db78 ("PCI: Enable INTx if BIOS left
      them disabled"), pciehp surprise removal stopped working.
      
      This happens because pci_reenable_device() on the hotplug bridge (used in
      the pciehp_configure_device() path) clears the Interrupt Disable bit, which
      apparently breaks the bridge's MSI hotplug event reporting.
      
      Previously we cleared the Interrupt Disable bit in do_pci_enable_device(),
      which is used by both pci_enable_device() and pci_reenable_device().  But
      we use pci_reenable_device() after the driver may have enabled MSI or
      MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X.
      
      This patch clears Interrupt Disable only when MSI/MSI-X has not been
      enabled.
      
      Fixes: 1f42db78 PCI: Enable INTx if BIOS left them disabled
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691Reported-and-tested-by: NAndreas Noever <andreas.noever@gmail.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org
      CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
      3cdeb713
  31. 08 3月, 2014 1 次提交
    • B
      PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled · 866d5417
      Bjorn Helgaas 提交于
      Andreas reported that after 1f42db78 ("PCI: Enable INTx if BIOS left
      them disabled"), pciehp surprise removal stopped working.
      
      This happens because pci_reenable_device() on the hotplug bridge (used in
      the pciehp_configure_device() path) clears the Interrupt Disable bit, which
      apparently breaks the bridge's MSI hotplug event reporting.
      
      Previously we cleared the Interrupt Disable bit in do_pci_enable_device(),
      which is used by both pci_enable_device() and pci_reenable_device().  But
      we use pci_reenable_device() after the driver may have enabled MSI or
      MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X.
      
      This patch clears Interrupt Disable only when MSI/MSI-X has not been
      enabled.
      
      Fixes: 1f42db78 PCI: Enable INTx if BIOS left them disabled
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691Reported-and-tested-by: NAndreas Noever <andreas.noever@gmail.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org
      CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
      866d5417
  32. 28 2月, 2014 1 次提交