1. 07 Sep, 2017 13 commits
  2. 05 Sep, 2017 8 commits
  3. 28 Aug, 2017 2 commits
    • Oza Pawandeep's avatar
      PCI: iproc: Work around Stingray CRS defects · 39b7a4ff
      Oza Pawandeep authored
      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: default avatarOza 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: default avatarBjorn Helgaas <bhelgaas@google.com>
      39b7a4ff
    • Oza Pawandeep's avatar
      PCI: iproc: Factor out memory-mapped config access address calculation · d005045b
      Oza Pawandeep authored
      Factor out the address calculation for memory-mapped config accesses as a
      separate function.  No functional change intended.
      Signed-off-by: default avatarOza Pawandeep <oza.oza@broadcom.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      d005045b
  4. 22 Aug, 2017 2 commits
  5. 19 Aug, 2017 1 commit
  6. 16 Aug, 2017 7 commits
    • Paul Burton's avatar
      PCI: faraday: Use PCI_NUM_INTX · 341d3299
      Paul Burton authored
      Use the PCI_NUM_INTX macro to indicate the number of PCI INTx interrupts
      rather than the magic number 4. This makes it clearer where the number
      comes from & what it relates to.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      341d3299
    • Sergei Shtylyov's avatar
      PCI: faraday: Fix of_irq_get() error check · b9f27afb
      Sergei Shtylyov authored
      of_irq_get() may return a negative error number as well as 0 on failure,
      while the driver only checks for 0, blithely continuing with the call to
      irq_set_chained_handler_and_data() -- that function expects *unsigned int*
      so should probably do nothing when a large IRQ number resulting from a
      conversion of a negative error number is passed to it. The driver then
      probes successfully while being only partly functional...
      
      Check for 'irq <= 0' instead and propagate the negative error number to the
      probe method --  that will allow the deferred probing as well.
      
      Fixes: d3c68e0a ("PCI: faraday: Add Faraday Technology FTPCI100 PCI Host Bridge driver")
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      b9f27afb
    • Bjorn Helgaas's avatar
      PCI: dra7xx: Use PCI_NUM_INTX · 61534d1a
      Bjorn Helgaas authored
      Use the PCI_NUM_INTX macro to indicate the number of PCI INTx interrupts
      rather than the magic number 4. This makes it clearer where the number
      comes from & what it relates to.
      Based-on-similar-patches-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: Kishon Vijay Abraham I <kishon@ti.com>
      61534d1a
    • Paul Burton's avatar
      PCI: altera: Use size=4 IRQ domain for legacy INTx · bfdbbf0e
      Paul Burton authored
      The devicetree binding documentation for the Altera PCIe controller 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 5
      in order to cover this range, with hwirq=0 left unused.
      
      This patch cleans up this wasted IRQ domain entry, modifying the driver to
      use an IRQ domain of size 4 which matches the actual number of PCI INTx
      interrupts. Since the hwirq numbers 1-4 are part of the devicetree binding,
      and this is considered ABI, we cannot simply change the interrupt-map
      property to use the range 0-3. Instead we make use of the
      pci_irqd_intx_xlate() helper function to translate the range 1-4 used at
      the DT level into the range 0-3 which is now used within the driver, and
      stop adding 1 to decoded hwirq numbers in altera_pcie_isr().
      
      Whilst cleaning up INTx handling we make use of the new PCI_NUM_INTX macro
      & drop the custom INTX_NUM definition.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: Ley Foon Tan <lftan@altera.com>
      bfdbbf0e
    • Shawn Lin's avatar
      PCI: altera: Remove unused num_of_vectors variable · 8a307386
      Shawn Lin authored
      The local variable "num_of_vectors" was unused, so remove it.
      Signed-off-by: default avatarShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: Ley Foon Tan <lftan@altera.com>
      8a307386
    • Paul Burton's avatar
      PCI: aardvark: Use PCI_NUM_INTX · 0d2977a3
      Paul Burton authored
      Switch from using a custom LEGACY_IRQ_NUM macro to the generic PCI_NUM_INTX
      definition for the number of INTx interrupts.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      0d2977a3
    • Paul Burton's avatar
      PCI: Add pci_irqd_intx_xlate() · 0d58e6c1
      Paul Burton authored
      Legacy PCI INTx interrupts are represented in the PCI_INTERRUPT_PIN
      register using the range 1-4, which matches our enum pci_interrupt_pin.
      This is however not ideal for an IRQ domain, where with 4 interrupts we
      would ideally have a domain of size 4 & hwirq numbers in the range 0-3.
      
      Different PCI host controller drivers have handled this in different ways.
      Of those under drivers/pci/ which register an INTx IRQ domain, we have:
      
        - pcie-altera uses the range 1-4 in device trees and an IRQ domain of
          size 5 to cover that range, with entry 0 wasted.
      
        - pcie-xilinx & pcie-xilinx-nwl use the range 1-4 in device trees but
          register an IRQ domain of size 4, which doesn't cover the hwirq=4/INTD
          case leading to that interrupt being broken.
      
        - pci-ftpci100 & pci-aardvark use the range 0-3 in both device trees & as
          hwirq numbering in the driver & IRQ domain.
      
      In order to introduce some level of consistency in at least the hwirq
      numbering used by the drivers & IRQ domains, this patch introduces a new
      pci_irqd_intx_xlate() helper function which drivers using the 1-4 range in
      device trees can assign as the xlate callback for their INTx IRQ domain.
      This translates the 1-4 range into a 0-3 range, allowing us to use an IRQ
      domain of size 4 & avoid a wasted entry. Further patches will make use of
      this in drivers to allow them to use an IRQ domain of size 4 for legacy
      INTx interrupts without breaking INTD.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      0d58e6c1
  7. 15 Aug, 2017 1 commit
    • Paul Burton's avatar
      PCI: Move enum pci_interrupt_pin to linux/pci.h · b352baf1
      Paul Burton authored
      We currently have a definition of enum pci_interrupt_pin in a header
      specific to PCI endpoints - linux/pci-epf.h. In order to allow for use of
      this enum from PCI host code in a future commit, move its definition to
      linux/pci.h & include that from linux/pci-epf.h.
      
      Additionally we add a PCI_NUM_INTX macro which indicates the number of PCI
      INTx interrupts, and will be used alongside enum pci_interrupt_pin in
      further patches.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      [bhelgaas: move enum pci_interrupt_pin outside #ifdef CONFIG_PCI]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      b352baf1
  8. 03 Aug, 2017 6 commits