Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 29 1月, 2018 1 次提交
  3. 06 10月, 2017 1 次提交
  5. 06 9月, 2017 3 次提交
  7. 29 8月, 2017 2 次提交
    • O
      PCI: iproc: Work around Stingray CRS defects · 39b7a4ff
      由 Oza Pawandeep 提交于 
      Configuration Request Retry Status ("CRS") completions are a required part
of PCIe.  A PCIe device may respond to config a request with a CRS
completion to indicate that it needs more time to initialize.  A Root Port
that receives a CRS completion may automatically retry the request, or it
may treat the request as a failed transaction.  For a failed read, it will
likely synthesize all 1's data, i.e., 0xffffffff, to complete the read to
the CPU.

CRS Software Visibility ("CRS SV") is an optional feature.  Per PCIe r3.1,
sec 2.3.2, if supported and enabled, a Root Port that receives a CRS
completion for a config read of the Vendor ID will synthesize 0x0001 data
(an invalid Vendor ID) instead of retrying or failing the transaction.  The
0x0001 data makes the CRS completion visible to software, so it can perform
other tasks while waiting for the device.

The iProc "Stingray" PCIe controller does not support CRS completions
correctly.  From the Stingray PCIe Controller spec:

  4.7.3.3. Retry Status On Configuration Cycle

  Endpoints are allowed to generate retry status on configuration cycles.
  In this case, the RC needs to re-issue the request. The IP does not
  handle this because the number of configuration cycles needed will
  probably be less than the total number of non-posted operations needed.

  When a retry status is received on the User RX interface for a
  configuration request that was sent on the User TX interface, it will be
  indicated with a completion with the CMPL_STATUS field set to 2=CRS, and
  the user will have to find the address and data values and send a new
  transaction on the User TX interface.  When the internal configuration
  space returns a retry status during a configuration cycle (user_cscfg =
  1) on the Command/Status interface, the pcie_cscrs will assert with the
  pcie_csack signal to indicate the CRS status.

  When the CRS Software Visibility Enable register in the Root Control
  register is enabled, the IP will return the data value to 0x0001 for the
  Vendor ID value and 0xffff  (all 1’s) for the rest of the data in the
  request for reads of offset 0 that return with CRS status.  This is true
  for both the User RX Interface and for the Command/Status interface.
  When CRS Software Visibility is enabled, the CMPL_STATUS field of the
  completion on the User RX Interface will not be 2=CRS and the pcie_cscrs
  signal will not assert on the Command/Status interface.

The Stingray hardware never reissues configuration requests when it
receives CRS completions.  Contrary to what sec 4.7.3.3 above says, when it
receives a CRS completion, it synthesizes 0xffff0001 data regardless of the
address of the read or the value of the CRS SV enable bit.

This is broken in two ways:

  1) When CRS SV is disabled, the Root Port should never synthesize the
  0x0001 value.  If it receives a CRS completion, it should fail the
  transaction and synthesize all 1's data.

  2) When CRS SV is enabled, the Root Port should only synthesize 0x0001
  data if it receives a CRS completion for a read of the Vendor ID.  If it
  receives a CRS completion for any other read, it should fail the
  transaction and synthesize all 1's data.

This breaks pci_flr_wait(), which reads the Command register and expects to
see all 1's data if the read fails because of CRS completions.  On
Stingray, it sees the incorrect 0xffff0001 data instead.

It also breaks config registers that contain the 0xffff0001 value.  If we
read such a register, software can't distinguish a CRS completion from the
actual value read from the device.

On Stingray, if we read 0xffff0001 data, assume this indicates a CRS
completion and retry the read for 500ms.  If we time out, return all 1's
(0xffffffff) data.  Note that this corrupts registers that happen to
contain 0xffff0001.

Stingray advertises CRS SV support in its Root Capabilities register, and
the CRS SV enable bit is writable (even though the hardware ignores it).
Mask out PCI_EXP_RTCAP_CRSVIS so software doesn't try to use CRS SV.
Signed-off-by: NOza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add probe-time warning about corruption, don't
advertise CRS SV support, remove duplicate pci_generic_config_read32(),
fix alignment based on patch from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      39b7a4ff
    • O
      PCI: iproc: Factor out memory-mapped config access address calculation · d005045b
      由 Oza Pawandeep 提交于 
      Factor out the address calculation for memory-mapped config accesses as a
separate function.  No functional change intended.
Signed-off-by: NOza Pawandeep <oza.oza@broadcom.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      d005045b
  9. 03 7月, 2017 2 次提交
  11. 29 6月, 2017 1 次提交
    • L
      PCI: iproc: Convert link check to raw PCI config accessors · 022adcfc
      由 Lorenzo Pieralisi 提交于 
      The current iproc driver host bridge controller driver requires struct
pci_bus to be created in order to carry out PCI link checks with standard
PCI config space accessors.

This struct pci_bus dependency is fictitious and burdens the driver with
unneeded constraints (eg to use separate APIs to create and scan the root
bus).

Add PCI raw config space accessors to the iproc driver and remove the
fictitious struct pci_bus dependency.
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Jon Mason <jonmason@broadcom.com>
      022adcfc
  13. 09 2月, 2017 1 次提交
  15. 09 12月, 2016 1 次提交
  17. 24 11月, 2016 2 次提交
  19. 18 11月, 2016 3 次提交
  21. 15 11月, 2016 4 次提交
  23. 12 10月, 2016 4 次提交
  25. 21 6月, 2016 1 次提交
  27. 28 1月, 2016 1 次提交
  29. 07 1月, 2016 1 次提交
    • R
      PCI: iproc: Add iProc PCIe MSI support · 3bc2b234
      由 Ray Jui 提交于 
      Add PCIe MSI support for both PAXB and PAXC interfaces on all iProc-based
platforms.

The iProc PCIe MSI support deploys an event queue-based implementation.
Each event queue is serviced by a GIC interrupt and can support up to 64
MSI vectors.  Host memory is allocated for the event queues, and each event
queue consists of 64 word-sized entries.  MSI data is written to the lower
16-bit of each entry, whereas the upper 16-bit of the entry is reserved for
the controller for internal processing.

Each event queue is tracked by a head pointer and tail pointer.  Head
pointer indicates the next entry in the event queue to be processed by
the driver and is updated by the driver after processing is done.
The controller uses the tail pointer as the next MSI data insertion
point.  The controller ensures MSI data is flushed to host memory before
updating the tail pointer and then triggering the interrupt.

MSI IRQ affinity is supported by evenly distributing the interrupts to each
CPU core.  MSI vector is moved from one GIC interrupt to another in order
to steer to the target CPU.

Therefore, the actual number of supported MSI vectors is:

  M * 64 / N

where M denotes the number of GIC interrupts (event queues), and N denotes
the number of CPU cores.

This iProc event queue-based MSI support should not be used with newer
platforms with integrated MSI support in the GIC (e.g., giv2m or
gicv3-its).

[bhelgaas: fold in Kconfig fixes from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: NRay Jui <rjui@broadcom.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAnup Patel <anup.patel@broadcom.com>
Reviewed-by: NVikram Prakash <vikramp@broadcom.com>
Reviewed-by: NScott Branden <sbranden@broadcom.com>
Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      3bc2b234
  31. 08 12月, 2015 1 次提交
    • R
      PCI: iproc: Add PAXC interface support · 943ebae7
      由 Ray Jui 提交于 
      Traditionally, all iProc PCIe root complexes use PAXB-based wrapper, with
an integrated on-chip Serdes to support external endpoint devices.  On
newer iProc platforms, a PAXC-based wrapper is introduced, for connection
with internally emulated PCIe endpoint devices in the ASIC.

Add support for PAXC-based iProc PCIe root complex in the iProc PCIe core
driver.  This change factors out common logic between PAXB and PAXC, and
uses tables to store register offsets that are different between PAXB and
PAXC.  This allows the driver to be scaled to support subsequent PAXC
revisions in the future.
Signed-off-by: NRay Jui <rjui@broadcom.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NScott Branden <sbranden@broadcom.com>
      943ebae7
  33. 01 12月, 2015 1 次提交
  35. 23 10月, 2015 1 次提交
  37. 16 10月, 2015 1 次提交
  39. 26 9月, 2015 3 次提交
  41. 30 7月, 2015 1 次提交
  43. 23 7月, 2015 1 次提交
    • R
      PCI: iproc: Add arm64 support · 8d9bfe37
      由 Ray Jui 提交于 
      Add arm64 support to the iProc PCIe driver.

Note that on arm32, bus->sysdata points to the arm32-specific pci_sys_data
struct, and pci_sys_data.private_data contains the iproc_pcie pointer.
For arm64, there's nothing corresponding to pci_sys_data, so we keep the
iproc_pcie pointer directly in bus->sysdata.

In addition, arm64 does IRQ mapping in pcibios_add_device(), so it doesn't
need pci_fixup_irqs() as arm32 does.
Signed-off-by: NRay Jui <rjui@broadcom.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NScott Branden <sbranden@broadcom.com>
      8d9bfe37
  45. 15 7月, 2015 1 次提交
  47. 28 5月, 2015 1 次提交
  49. 20 5月, 2015 1 次提交