Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 07 9月, 2017 3 次提交
  3. 06 9月, 2017 6 次提交
  5. 31 8月, 2017 1 次提交
  7. 30 8月, 2017 20 次提交
  9. 29 8月, 2017 4 次提交
    • 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
    • S
      PCI: rockchip: Idle inactive PHY(s) · f06c6c41
      由 Shawn Lin 提交于 
      Check the status of all lanes and idle the inactive one(s).
Tested-by: NJeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
[bhelgaas: always set lanes_map, even for legacy_phy case]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Acked-by: NKishon Vijay Abraham I <kishon@ti.com>
      f06c6c41
    • S
      PCI: rockchip: Add per-lane PHY support · 9e87240c
      由 Shawn Lin 提交于 
      We distinguish the legacy PHY from newer per-lane PHYs by adding legacy_phy
flag.  Note that the legacy PHY is still the first option to be searched in
order not to break the backward compatibility of DTB.
Tested-by: NJeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
[bhelgaas: tidy rockchip_pcie_get_phys()]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Acked-by: NKishon Vijay Abraham I <kishon@ti.com>
      9e87240c
  11. 25 8月, 2017 1 次提交
  13. 17 8月, 2017 5 次提交
    • P
      PCI: xilinx: Allow build on MIPS platforms · 293962d6
      由 Paul Burton 提交于 
      Allow the xilinx-pcie driver to be built on MIPS platforms which make use
of generic PCI drivers rather than legacy MIPS-specific interfaces.  This
is used on the MIPS Boston development board.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Bharat Kumar Gogada <bharatku@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Ravikiran Gummaluri <rgummal@xilinx.com>
      293962d6
    • P
      PCI: xilinx: Don't enable config completion interrupts · aac2e96b
      由 Paul Burton 提交于 
      The Xilinx AXI bridge for PCI Express device provides interrupts indicating
the completion of config space accesses. We have previously
enabled/unmasked them but do nothing with them besides acknowledge them.

Leave the interrupts masked in order to avoid servicing a large number of
pointless interrupts during boot.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Bharat Kumar Gogada <bharatku@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Ravikiran Gummaluri <rgummal@xilinx.com>
      aac2e96b
    • P
      PCI: xilinx: Unify INTx & MSI interrupt decode · d0b5dda6
      由 Paul Burton 提交于 
      The INTx & MSI interrupt decode paths duplicated a fair bit of common
functionality. They also strictly handled interrupts in order of INTx then
MSI, so if both types of interrupt were to be asserted simultaneously and
the MSI interrupt were first in the FIFO then the INTx code would read it &
ignore it before the MSI code then had to read it again, wasting the
original FIFO read.

Unify the INTx & MSI decode in order to reduce that duplication & allow a
single FIFO read to be performed for each interrupt regardless of its type.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Bharat Kumar Gogada <bharatku@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Ravikiran Gummaluri <rgummal@xilinx.com>
      d0b5dda6
    • P
      PCI: xilinx-nwl: Translate INTx range to hwirqs 0-3 · b8550f11
      由 Paul Burton 提交于 
      The devicetree binding documentation for the Xilinx NWL PCIe root port
bridge shows an example which uses an interrupt-map property to map PCI
INTx interrupts to hardware IRQ numbers 1-4. The driver creates an IRQ
domain with size 4, which therefore covers the hwirq range 0-3.

This means that if we attempt to make use of the INTD interrupt then we're
likely to hit a WARN() in irq_domain_associate() because INTD, or hwirw=4,
is outside of the range covered by the IRQ domain.  irq_domain_associate()
will then return -EINVAL and we'll be unable to make use of INTD.

Fix this by making use of the pci_irqd_intx_xlate() helper function to
translate the 1-4 range used in the DT to a 0-3 range used within the
driver, and stop adding 1 to decoded hwirq numbers.

Whilst cleaning up INTx handling we make use of the new PCI_NUM_INTX macro
& drop the custom INTX definitions.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: "Sören Brinkmann" <soren.brinkmann@xilinx.com>
      b8550f11
    • P
      PCI: xilinx: Translate INTx range to hwirqs 0-3 · 5c125683
      由 Paul Burton 提交于 
      The pcie-xilinx driver creates an IRQ domain of size 4 for legacy PCI INTx
interrupts, which at first glance seems reasonable since there are 4
possible such interrupts. Unfortunately the driver then proceeds to use the
range 1-4 as the hwirq numbers for INTA-INTD, causing warnings & broken
interrupts when attempting to use INTD/hwirq=4 due to it being beyond the
range of the IRQ domain:

  WARNING: CPU: 0 PID: 1 at kernel/irq/irqdomain.c:365
      irq_domain_associate+0x170/0x220
  error: hwirq 0x4 is too large for dummy
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W
      4.12.0-rc5-00126-g19e1b3a10aad-dirty #427
  Stack : 0000000000000000 0000000000000004 0000000000000006 ffffffff8092c78a
          0000000000000061 ffffffff8018bf60 0000000000000000 0000000000000000
          ffffffff8088c287 ffffffff80811d18 a8000000ffc60000 ffffffff80926678
          0000000000000001 0000000000000000 ffffffff80887880 ffffffff80960000
          ffffffff80920000 ffffffff801e6744 ffffffff80887880 a8000000ffc4f8f8
          000000000000089c ffffffff8018d260 0000000000010000 ffffffff80811d18
          0000000000000000 0000000000000001 0000000000000000 0000000000000000
          0000000000000000 a8000000ffc4f840 0000000000000000 ffffffff8042cf34
          0000000000000000 0000000000000000 0000000000000000 0000000000040c00
          0000000000000000 ffffffff8010d1c8 0000000000000000 ffffffff8042cf34
          ...
  Call Trace:
  [<ffffffff8010d1c8>] show_stack+0x80/0xa0
  [<ffffffff8042cf34>] dump_stack+0xd4/0x110
  [<ffffffff8013ea98>] __warn+0xf0/0x108
  [<ffffffff8013eb14>] warn_slowpath_fmt+0x3c/0x48
  [<ffffffff80196528>] irq_domain_associate+0x170/0x220
  [<ffffffff80196bf0>] irq_create_mapping+0x88/0x118
  [<ffffffff801976a8>] irq_create_fwspec_mapping+0xb8/0x320
  [<ffffffff80197970>] irq_create_of_mapping+0x60/0x70
  [<ffffffff805d1318>] of_irq_parse_and_map_pci+0x20/0x38
  [<ffffffff8049c210>] pci_fixup_irqs+0x60/0xe0
  [<ffffffff8049cd64>] xilinx_pcie_probe+0x28c/0x478
  [<ffffffff804e8ca8>] platform_drv_probe+0x50/0xd0
  [<ffffffff804e73a4>] driver_probe_device+0x2c4/0x3a0
  [<ffffffff804e7544>] __driver_attach+0xc4/0xd0
  [<ffffffff804e5254>] bus_for_each_dev+0x64/0xa8
  [<ffffffff804e5e40>] bus_add_driver+0x1f0/0x268
  [<ffffffff804e8000>] driver_register+0x68/0x118
  [<ffffffff801001a4>] do_one_initcall+0x4c/0x178
  [<ffffffff808d3ca8>] kernel_init_freeable+0x204/0x2b0
  [<ffffffff80730b68>] kernel_init+0x10/0xf8
  [<ffffffff80106218>] ret_from_kernel_thread+0x14/0x1c

Fix this by making use of the new pci_irqd_intx_xlate() helper to translate
the INTx 1-4 range into the 0-3 range suitable for the IRQ domain of size
4, and stop adding 1 to the hwirq number decoded from the interrupt FIFO
which is already in the range 0-3.

Whilst we're here we switch to using PCI_NUM_INTX rather than the magic
number 4, making it clearer what the 4 means.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Bharat Kumar Gogada <bharatku@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Ravikiran Gummaluri <rgummal@xilinx.com>
      5c125683