1. 22 3月, 2018 1 次提交
  2. 31 1月, 2018 2 次提交
  3. 24 1月, 2018 1 次提交
    • J
      PCI: Add pci_enable_atomic_ops_to_root() · 430a2368
      Jay Cornwall 提交于
      The Atomic Operations feature (PCIe r4.0, sec 6.15) allows atomic
      transctions to be requested by, routed through and completed by PCIe
      components. Routing and completion do not require software support.
      Component support for each is detectable via the DEVCAP2 register.
      
      A Requester may use AtomicOps only if its PCI_EXP_DEVCTL2_ATOMIC_REQ is
      set. This should be set only if the Completer and all intermediate routing
      elements support AtomicOps.
      
      A concrete example is the AMD Fiji-class GPU (which is capable of making
      AtomicOp requests), below a PLX 8747 switch (advertising AtomicOp routing)
      with a Haswell host bridge (advertising AtomicOp completion support).
      
      Add pci_enable_atomic_ops_to_root() for per-device control over AtomicOp
      requests. This checks to be sure the Root Port supports completion of the
      desired AtomicOp sizes and the path to the Root Port supports routing the
      AtomicOps.
      Signed-off-by: NJay Cornwall <Jay.Cornwall@amd.com>
      Signed-off-by: NFelix Kuehling <Felix.Kuehling@amd.com>
      [bhelgaas: changelog, comments, whitespace]
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      430a2368
  4. 11 1月, 2018 1 次提交
  5. 14 11月, 2017 2 次提交
  6. 02 11月, 2017 1 次提交
    • G
      License cleanup: add SPDX license identifier to uapi header files with no license · 6f52b16c
      Greg Kroah-Hartman 提交于
      Many user space API headers are missing licensing information, which
      makes it hard for compliance tools to determine the correct license.
      
      By default are files without license information under the default
      license of the kernel, which is GPLV2.  Marking them GPLV2 would exclude
      them from being included in non GPLV2 code, which is obviously not
      intended. The user space API headers fall under the syscall exception
      which is in the kernels COPYING file:
      
         NOTE! This copyright does *not* cover user programs that use kernel
         services by normal system calls - this is merely considered normal use
         of the kernel, and does *not* fall under the heading of "derived work".
      
      otherwise syscall usage would not be possible.
      
      Update the files which contain no license information with an SPDX
      license identifier.  The chosen identifier is 'GPL-2.0 WITH
      Linux-syscall-note' which is the officially assigned identifier for the
      Linux syscall exception.  SPDX license identifiers are a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.  See the previous patch in this series for the
      methodology of how this patch was researched.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f52b16c
  7. 25 10月, 2017 1 次提交
  8. 20 10月, 2017 1 次提交
  9. 01 9月, 2017 1 次提交
  10. 25 8月, 2017 2 次提交
  11. 20 6月, 2017 1 次提交
  12. 29 4月, 2017 1 次提交
  13. 19 4月, 2017 1 次提交
  14. 11 2月, 2017 2 次提交
  15. 13 12月, 2016 1 次提交
  16. 15 10月, 2016 1 次提交
  17. 25 8月, 2016 1 次提交
    • B
      PCI: Add PTM clock granularity information · 8b2ec318
      Bjorn Helgaas 提交于
      The PTM Control register (PCIe r3.1, sec 7.32.3) contains an Effective
      Granularity field:
      
        This provides information relating to the expected accuracy of the PTM
        clock, but does not otherwise affect the PTM mechanism.
      
      Set the Effective Granularity based on the PTM Root and any intervening PTM
      Time Sources.
      
      This does not set Effective Granularity for Root Complex Integrated
      Endpoints because I don't know how to figure out clock granularity for
      them.  The spec says:
      
        ... system software must set [Effective Granularity] to the value
        reported in the Local Clock Granularity field by the associated PTM
        Time Source.
      
      but I don't know how to identify the associated PTM Time Source.  Normally
      it's the upstream bridge, but an integrated endpoint has no upstream
      bridge.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      8b2ec318
  18. 19 8月, 2016 1 次提交
  19. 16 8月, 2016 1 次提交
  20. 03 5月, 2016 2 次提交
  21. 30 10月, 2015 2 次提交
  22. 15 7月, 2015 1 次提交
  23. 27 1月, 2015 1 次提交
  24. 25 9月, 2014 1 次提交
  25. 09 9月, 2014 1 次提交
    • R
      PCI: Enable CRS Software Visibility for root port if it is supported · f3dbd802
      Rajat Jain 提交于
      Per PCIe r3.0, sec 2.3.2, an endpoint may respond to a Configuration
      Request with a Completion with Configuration Request Retry Status (CRS).
      This terminates the Configuration Request.
      
      When the CRS Software Visibility feature is disabled (as it is by default),
      a Root Complex must handle a CRS Completion by re-issuing the Configuration
      Request.  This is invisible to software.  From the CPU's point of view, an
      endpoint that always responds with CRS causes a hang because the Root
      Complex never supplies data to complete the CPU read.
      
      When CRS Software Visibility is enabled, a Root Complex that receives a CRS
      Completion for a read of the Vendor ID must return data of 0x0001.  The
      Vendor ID of 0x0001 indicates to software that the endpoint is not ready.
      
      We now have more devices that require CRS Software Visibility.  For
      example, a PLX 8713 NT bridge may respond with CRS until it has been
      configured via I2C, and the I2C configuration is completely independent of
      PCI enumeration.
      
      Enable CRS Software Visibility if it is supported.  This allows a system
      with such a device to work (though the PCI core times out waiting for it to
      become ready, and we have to rescan the bus after it is ready).
      
      This essentially reverts ad7edfe0 ("[PCI] Do not enable CRS Software
      Visibility by default").  The failures that led to ad7edfe0 should be
      addressed by 89665a6a ("PCI: Check only the Vendor ID to identify
      Configuration Request Retry").
      
      [bhelgaas: changelog]
      Link: http://lkml.kernel.org/r/20071029061532.5d10dfc6@snowcone
      Link: http://lkml.kernel.org/r/alpine.LFD.0.9999.0712271023090.21557@woody.linux-foundation.orgSigned-off-by: NRajat Jain <rajatxjain@gmail.com>
      Signed-off-by: NRajat Jain <rajatjain@juniper.net>
      Signed-off-by: NGuenter Roeck <groeck@juniper.net>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      f3dbd802
  26. 04 1月, 2014 1 次提交
  27. 18 12月, 2013 2 次提交
    • A
      PCI: Rename PCI_VC_PORT_REG1/2 to PCI_VC_PORT_CAP1/2 · 274127a1
      Alex Williamson 提交于
      These are set of two capability registers, it's pretty much given that
      they're registers, so reflect their purpose in the name.
      Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      274127a1
    • A
      PCI: Add Virtual Channel to save/restore support · 425c1b22
      Alex Williamson 提交于
      While we don't really have any infrastructure for making use of VC
      support, the system BIOS can configure the topology to non-default
      VC values prior to boot.  This may be due to silicon bugs, desire to
      reserve traffic classes, or perhaps just BIOS bugs.  When we reset
      devices, the VC configuration may return to default values, which can
      be incompatible with devices upstream.  For instance, Nvidia GRID
      cards provide a PCIe switch and some number of GPUs, all supporting
      VC.  The power-on default for VC is to support TC0-7 across VC0,
      however some platforms will only enable TC0/VC0 mapping across the
      topology.  When we do a secondary bus reset on the downstream switch
      port, the GPU is reset to a TC0-7/VC0 mapping while the opposite end
      of the link only enables TC0/VC0.  If the GPU attempts to use TC1-7,
      it fails.
      
      This patch attempts to provide complete support for VC save/restore,
      even beyond the minimally required use case above.  This includes
      save/restore and reload of the arbitration table, save/restore and
      reload of the port arbitration tables, and re-enabling of the
      channels for VC, VC9, and MFVC capabilities.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      425c1b22
  28. 16 12月, 2013 1 次提交
  29. 15 11月, 2013 1 次提交
  30. 28 9月, 2013 1 次提交
  31. 24 9月, 2013 1 次提交
  32. 29 8月, 2013 2 次提交