1. 23 10月, 2017 1 次提交
    • K
      PCI: dra7xx: Create functional dependency between PCIe and PHY · 7a4db656
      Kishon Vijay Abraham I 提交于
      PCI core access configuration space registers in resume_noirq callbacks.
      In the case of dra7xx, PIPE3 PHY connected to PCIe controller has to be
      enabled before accessing configuration space registers. Since
      PIPE3 PHY is enabled by only configuring control module registers, no
      aborts has been observed so far (though during noirq stage, interface
      clock of PIPE3 PHY is not enabled).
      
      With new TRM updates, PIPE3 PHY has to be initialized (PIPE3 PHY
      registers has to be accessed) as well which requires the interface
      clock of PIPE3 PHY to be enabled. The interface clock of PIPE3 PHY is
      derived from OCP2SCP and hence PCIe PHY is modeled as a child of
      OCP2SCP. Since pm_runtime is not enabled during noirq stage,
      pm_runtime_get_sync done in phy_init doesn't enable
      OCP2SCP clocks resulting in abort when PIPE3 PHY registers are
      accessed.
      
      Create a function dependency between PCIe and PHY here to make
      sure PCIe is suspended before PCIe PHY/OCP2SCP and resumed after
      PCIe PHY/OCP2SCP.
      Suggested-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      7a4db656
  2. 06 9月, 2017 1 次提交
  3. 02 9月, 2017 1 次提交
  4. 30 8月, 2017 1 次提交
  5. 23 8月, 2017 1 次提交
  6. 17 8月, 2017 1 次提交
  7. 04 8月, 2017 1 次提交
  8. 03 7月, 2017 2 次提交
  9. 28 4月, 2017 3 次提交
  10. 04 4月, 2017 2 次提交
  11. 22 2月, 2017 8 次提交
  12. 12 10月, 2016 7 次提交
  13. 25 8月, 2016 1 次提交
    • P
      PCI: dra7xx: Make explicitly non-modular · d29438d6
      Paul Gortmaker 提交于
      This code is not being built as a module by anyone:
      
        drivers/pci/host/Kconfig:config PCI_DRA7XX
        drivers/pci/host/Kconfig:  bool "TI DRA7xx PCIe controller"
      
      Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
      etc., so that when reading the driver there is no doubt it is builtin-only.
      The information is preserved in comments at the top of the file.
      
      Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op and
      builtin_platform_driver_probe() uses the same init level priority as
      module_platform_driver_probe(), so this doesn't change init ordering.
      
      Explicitly disallow driver unbind, since that doesn't have a sensible use
      case anyway, and it allows us to drop the ".remove" code for non-modular
      drivers.
      
      [bhelgaas: changelog]
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Kishon Vijay Abraham I <kishon@ti.com>
      d29438d6
  14. 26 7月, 2016 1 次提交
  15. 06 4月, 2016 1 次提交
    • J
      PCI: designware: Move Root Complex setup code to dw_pcie_setup_rc() · 7e57fd14
      Jisheng Zhang 提交于
      dw_pcie_host_init() looks up host bridge resources, ioremaps them, creates
      IRQ domains, and enumerates devices below the bridge.  dw_pcie_setup_rc()
      programs the Root Complex registers.  The Root Complex may lose power
      during suspend-to-RAM, and when we resume, we want to redo the latter but
      not the former.
      
      Move some Root Complex programming from dw_pcie_host_init() to
      dw_pcie_setup_rc() where it belongs.  DesignWare-based drivers can call
      dw_pcie_setup_rc() in their resume paths.
      
      [Niklas Cassel <niklas.cassel@axis.com>:  This change moves outbound ATU
      programming, which uses pp->mem_base, to dw_pcie_setup_rc().  Apply the
      dra7xx pp->mem_base update before calling dw_pcie_setup_rc().]
      
      [bhelgaas: changelog, fold in dra7xx fix from Niklas]
      Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NPratyush Anand <pratyush.anand@gmail.com>
      7e57fd14
  16. 15 3月, 2016 1 次提交
    • J
      PCI: designware: Add generic dw_pcie_wait_for_link() · 886bc5ce
      Joao Pinto 提交于
      Several DesignWare-based drivers (dra7xx, exynos, imx6, keystone, qcom, and
      spear13xx) had similar loops waiting for the link to come up.
      
      Add a generic dw_pcie_wait_for_link() for use by all these drivers so the
      waiting is done consistently, e.g., always using usleep_range() rather than
      mdelay() and using similar timeouts and retry counts.
      
      Note that this changes the Keystone link training/wait for link strategy,
      so we initiate link training, then wait longer for the link to come up
      before re-initiating link training.
      
      [bhelgaas: changelog, split into its own patch, update pci-keystone.c, pcie-qcom.c]
      Signed-off-by: NJoao Pinto <jpinto@synopsys.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NPratyush Anand <pratyush.anand@gmail.com>
      886bc5ce
  17. 07 1月, 2016 1 次提交
    • G
      PCI: host: Mark PCIe/PCI (MSI) IRQ cascade handlers as IRQF_NO_THREAD · 8ff0ef99
      Grygorii Strashko 提交于
      On -RT and if kernel is booting with "threadirqs" cmd line parameter,
      PCIe/PCI (MSI) IRQ cascade handlers (like dra7xx_pcie_msi_irq_handler())
      will be forced threaded and, as result, will generate warnings like this:
      
        WARNING: CPU: 1 PID: 82 at kernel/irq/handle.c:150 handle_irq_event_percpu+0x14c/0x174()
        irq 460 handler irq_default_primary_handler+0x0/0x14 enabled interrupts
        Backtrace:
         (warn_slowpath_common) from (warn_slowpath_fmt+0x38/0x40)
         (warn_slowpath_fmt) from (handle_irq_event_percpu+0x14c/0x174)
         (handle_irq_event_percpu) from (handle_irq_event+0x84/0xb8)
         (handle_irq_event) from (handle_simple_irq+0x90/0x118)
         (handle_simple_irq) from (generic_handle_irq+0x30/0x44)
         (generic_handle_irq) from (dra7xx_pcie_msi_irq_handler+0x7c/0x8c)
         (dra7xx_pcie_msi_irq_handler) from (irq_forced_thread_fn+0x28/0x5c)
         (irq_forced_thread_fn) from (irq_thread+0x128/0x204)
      
      This happens because all of them invoke generic_handle_irq() from the
      requested handler.  generic_handle_irq() grabs raw_locks and thus needs to
      run in raw-IRQ context.
      
      This issue was originally reproduced on TI dra7-evem, but, as was
      identified during discussion [1], other hosts can also suffer from this
      issue.  Fix all them at once by marking PCIe/PCI (MSI) IRQ cascade handlers
      IRQF_NO_THREAD explicitly.
      
      [1] http://lkml.kernel.org/r/1448027966-21610-1-git-send-email-grygorii.strashko@ti.com
      
      [bhelgaas: add stable tag, fix typos]
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: Lucas Stach <l.stach@pengutronix.de> (for imx6)
      CC: stable@vger.kernel.org
      CC: Kishon Vijay Abraham I <kishon@ti.com>
      CC: Jingoo Han <jingoohan1@gmail.com>
      CC: Kukjin Kim <kgene@kernel.org>
      CC: Krzysztof Kozlowski <k.kozlowski@samsung.com>
      CC: Richard Zhu <Richard.Zhu@freescale.com>
      CC: Thierry Reding <thierry.reding@gmail.com>
      CC: Stephen Warren <swarren@wwwdotorg.org>
      CC: Alexandre Courbot <gnurou@gmail.com>
      CC: Simon Horman <horms@verge.net.au>
      CC: Pratyush Anand <pratyush.anand@gmail.com>
      CC: Michal Simek <michal.simek@xilinx.com>
      CC: "Sören Brinkmann" <soren.brinkmann@xilinx.com>
      CC: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      8ff0ef99
  18. 03 11月, 2015 2 次提交
  19. 20 8月, 2015 1 次提交
  20. 12 8月, 2015 3 次提交