Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 15 7月, 2015 1 次提交
  3. 27 1月, 2015 1 次提交
  5. 25 9月, 2014 1 次提交
  7. 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
  9. 04 1月, 2014 1 次提交
  11. 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
  13. 16 12月, 2013 1 次提交
  15. 15 11月, 2013 1 次提交
  17. 28 9月, 2013 1 次提交
  19. 24 9月, 2013 1 次提交
  21. 29 8月, 2013 4 次提交
  23. 28 8月, 2013 1 次提交
  25. 30 5月, 2013 1 次提交
  27. 23 4月, 2013 1 次提交
    • B
      PCI: Clean up MSI/MSI-X capability #defines · 24bc69da
      由 Bjorn Helgaas 提交于 
      This doesn't change any existing symbols, but it puts them in logical
order and uses explicit masks instead of shifts, like the rest of the
file.

It also adds new symbols for PCI_MSIX_TABLE_BIR,
PCI_MSIX_TABLE_OFFSET, PCI_MSIX_PBA_BIR, and PCI_MSIX_PBA_OFFSET to
replace the mis-named PCI_MSIX_FLAGS_BIRMASK (the BAR index fields
are part of the Table and PBA registers, not the flags register).
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      24bc69da
  29. 27 12月, 2012 1 次提交
    • B
      PCI: Add PCIe Link Capability link speed and width names · 130f1b8f
      由 Bjorn Helgaas 提交于 
      Add standard #defines for the Supported Link Speeds field in the PCIe
Link Capabilities register.

Note that prior to PCIe spec r3.0, these encodings were defined:

    0001b  2.5GT/s Link speed supported
    0010b  5.0GT/s and 2.5GT/s Link speed supported

Starting with spec r3.0, these encodings refer to bits 0 and 1 in the
Supported Link Speeds Vector in the Link Capabilities 2 register, and bits
0 and 1 there mean 2.5 GT/s and 5.0 GT/s, respectively.  Therefore, code
that followed r2.0 and interpreted 0x1 as 2.5GT/s and 0x2 as 5.0GT/s will
continue to work, and we can identify a device using the new encodings
because it will have a non-zero Link Capabilities 2 register.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      130f1b8f
  31. 08 12月, 2012 1 次提交
  33. 06 12月, 2012 1 次提交
  35. 10 11月, 2012 1 次提交
  37. 13 10月, 2012 1 次提交
  39. 23 8月, 2012 2 次提交
    • J
      PCI: Add accessors for PCI Express Capability · 8c0d3a02
      由 Jiang Liu 提交于 
      The PCI Express Capability (PCIe spec r3.0, sec 7.8) comes in two
versions, v1 and v2.  In v1 Capability structures (PCIe spec r1.0 and
r1.1), some fields are optional, so the structure size depends on the
device type.

This patch adds functions to access this capability so drivers don't
have to be aware of the differences between v1 and v2.  Note that these
new functions apply only to the "PCI Express Capability," not to any of
the other "PCI Express Extended Capabilities" (AER, VC, ACS, MFVC, etc.)

Function pcie_capability_read_word/dword() reads the PCIe Capabilities
register and returns the value in the reference parameter "val".  If
the PCIe Capabilities register is not implemented on the PCIe device,
"val" is set to 0.

Function pcie_capability_write_word/dword() writes the value to the
specified PCIe Capability register.

Function pcie_capability_clear_and_set_word/dword() sets and/or clears bits
of a PCIe Capability register.

[bhelgaas: changelog, drop "pci_" prefixes, don't export
pcie_capability_reg_implemented()]
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      8c0d3a02
    • B
      PCI: Add Vendor-Specific Extended Capability header info · defb9446
      由 Bjorn Helgaas 提交于 
      This adds the fields in the Vendor-Specific Header: ID, Rev, and Length.
There may be multiple Vendor-Specific capabilities, so drivers should use
the VSEC ID to identify the one of interest.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      defb9446
  41. 20 7月, 2012 1 次提交
  43. 10 7月, 2012 1 次提交
    • 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
  45. 12 6月, 2012 2 次提交
    • A
      PCI: misc pci_reg additions · a0dee2ed
      由 Alex Williamson 提交于 
      Fill in many missing definitions and add sizeof fields for many
sections allowing for more extensive config parsing.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      a0dee2ed
    • M
      PCI: add pci_pcie_cap2() check for PCIe feature capabilities >= v2 · c463b8cb
      由 Myron Stowe 提交于 
      This patch resolves potential issues when accessing PCI Express
Capability structures.  The makeup of the capability varies
substantially between v1 and v2:

    Version 1 of the PCI Express Capability (defined by PCI Express
    1.0 and 1.1 base) neither requires the endpoint to implement the
    entire PCIe capability structure nor specifies default values of
    registers that are not implemented by the device.

    Version 2 of the PCI Express Capability (defined by PCIe 1.1
    Capability Structure Expansion ECN, PCIe 2.0, 2.1, and 3.0) added
    additional registers to the structure and requires all registers
    to be either implemented or hardwired to 0.

Due to the differences in the capability structures, code dealing with
capability features must be careful not to access the additional
registers introduced with v2 unless the device is specifically known to
be a v2 capable device.  Otherwise, attempts to access non-existant
registers will occur.  This is a subtle issue that is hard to track down
when it occurs (and it has - see commit 864d296c).

To try and help mitigate such occurrences, this patch introduces
pci_pcie_cap2() which is similar to pci_pcie_cap() but also checks
that the PCIe capability version is >= 2.  pci_pcie_cap2() should be
used for qualifying PCIe capability features introduced after v1.

Suggested by Don Dutile.
Acked-by: NDonald Dutile <ddutile@redhat.com>
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      c463b8cb
  47. 24 2月, 2012 1 次提交
  49. 07 1月, 2012 2 次提交
  51. 06 12月, 2011 2 次提交
  53. 15 10月, 2011 2 次提交
  55. 12 5月, 2011 3 次提交
  57. 31 3月, 2011 1 次提交