1. 15 5月, 2018 1 次提交
  2. 19 3月, 2018 1 次提交
    • M
      PCI: tegra: Add power management support · da76ba50
      Manikanta Maddireddy 提交于
      Tegra186 powergate driver is implemented as power domain driver, power
      partition ungate/gate are registered as power_on/power_off callback
      functions. There are no direct functions to power gate/ungate host
      controller in Tegra186. Host controller driver should add "power-domains"
      property in device tree and implement runtime suspend and resume
      callback functons. Power gate and ungate is taken care by power domain
      driver when host controller driver calls pm_runtime_put_sync and
      pm_runtime_get_sync respectively.
      
      Register suspend_noirq & resume_noirq callback functions to allow PCIe to
      come up after resume from RAM. Both runtime and noirq pm ops share same
      callback functions.
      Signed-off-by: NManikanta Maddireddy <mmaddireddy@nvidia.com>
      [lorenzo.pieralisi@arm.com: squashed patch to fix compilation]
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: NThierry Reding <treding@nvidia.com>
      Tested-by: NThierry Reding <treding@nvidia.com>
      da76ba50
  3. 02 3月, 2018 2 次提交
  4. 29 1月, 2018 1 次提交
  5. 16 1月, 2018 1 次提交
  6. 12 1月, 2018 1 次提交
  7. 21 12月, 2017 1 次提交
  8. 19 12月, 2017 1 次提交
    • B
      PCI: Remove PCI_REASSIGN_ALL_RSRC use on arm and arm64 · 7153884c
      Bjorn Helgaas 提交于
      On arm, PCI_REASSIGN_ALL_RSRC is used only in pcibios_assign_all_busses(),
      which helps decide whether to reconfigure bridge bus numbers.  It has
      nothing to do with BAR assignments.  On arm64 and powerpc,
      pcibios_assign_all_busses() tests PCI_REASSIGN_ALL_BUS, which makes more
      sense.
      
      Align arm with arm64 and powerpc, so they all use PCI_REASSIGN_ALL_BUS for
      pcibios_assign_all_busses().
      
      Remove PCI_REASSIGN_ALL_RSRC from the generic, Tegra, Versatile, and
      R-Car drivers.  These drivers are used only on arm or arm64, where
      PCI_REASSIGN_ALL_RSRC is not used after this change, so removing it
      should have no effect.
      
      No functional change intended.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NManikanta Maddireddy <mmaddireddy@nvidia.com>
      Reviewed-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      7153884c
  9. 19 10月, 2017 1 次提交
  10. 12 10月, 2017 1 次提交
  11. 11 10月, 2017 1 次提交
    • T
      Revert "PCI: tegra: Do not allocate MSI target memory" · 8c2b4e3c
      Thierry Reding 提交于
      This reverts commit d7bd554f.
      
      It turns out that Tegra20 has a bug in the implementation of the MSI
      target address register (which is worked around by the existence of the
      struct tegra_pcie_soc.msi_base_shift parameter) that restricts the MSI
      target memory to the lower 32 bits of physical memory on that particular
      generation. The offending patch causes a regression on TrimSlice, which
      is a Tegra20-based device and has a PCI network interface card.
      
      An initial, simpler fix was to change the MSI target address for Tegra20
      only, but it was pointed out that the offending commit also prevents the
      use of 32-bit only MSI capable devices, even on later chips. Technically
      this was never guaranteed to work with the prior code in the first place
      because the allocated page could have resided beyond the 4 GiB boundary,
      but it is still possible that this could've introduced a regression.
      
      The proper fix that was settled on is to select a fixed address within
      the lowest 32 bits of physical address space that is otherwise unused,
      but testing of that patch has provided mixed results that are not fully
      understood yet.
      
      Given all of the above and the relative urgency to get this fixed in
      v4.13, revert the offending commit until a universal fix is found.
      
      Fixes: d7bd554f ("PCI: tegra: Do not allocate MSI target memory")
      Reported-by: NTomasz Maciej Nowak <tmn505@gmail.com>
      Reported-by: NErik Faye-Lund <kusmabite@gmail.com>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org	# 4.13.x
      8c2b4e3c
  12. 25 8月, 2017 1 次提交
  13. 04 8月, 2017 1 次提交
  14. 03 7月, 2017 3 次提交
  15. 29 6月, 2017 2 次提交
  16. 25 4月, 2017 1 次提交
  17. 08 12月, 2016 3 次提交
  18. 12 10月, 2016 3 次提交
  19. 07 9月, 2016 1 次提交
    • L
      PCI: tegra: Fix pci_remap_iospace() failure path · 13f392eb
      Lorenzo Pieralisi 提交于
      On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
      IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
      and by mapping the PCI host bridges memory address space driving PCI IO
      cycles to it.
      
      PCI host bridge drivers that enable downstream PCI IO cycles map the host
      bridge memory address responding to PCI IO cycles to the fixed virtual
      address space through the pci_remap_iospace() API.
      
      This means that if the pci_remap_iospace() function fails, the
      corresponding host bridge PCI IO resource must be considered invalid, in
      that there is no way for the kernel to actually drive PCI IO transactions
      if the memory addresses responding to PCI IO cycles cannot be mapped into
      the CPU virtual address space.
      
      The PCI tegra host bridge driver adds the PCI IO resource retrieved from
      firmware to the host bridge resource windows even if the
      pci_remap_iospace() call fails; this is an actual bug in that the PCI host
      bridge would consider the PCI IO resource valid (and possibly assign it to
      downstream devices) even if the kernel was not able to map the PCI host
      bridge memory address driving IO cycle to the CPU virtual address space (ie
      pci_remap_iospace() failures).
      
      Add the PCI host bridge driver pci_remap_iospace() failure path and do not
      add the corresponding PCI host bridge PCI IO resources retrieved through
      firmware when the pci_remap_iospace() function call fails, fixing the
      issue.
      
      Fixes: e6e9f471 ("PCI: tegra: Use generic pci_remap_iospace() rather than ARM32-specific one")
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Thierry Reding <treding@nvidia.com>
      13f392eb
  20. 19 8月, 2016 2 次提交
  21. 02 8月, 2016 1 次提交
    • P
      PCI: tegra: Make explicitly non-modular · ad183271
      Paul Gortmaker 提交于
      This code is not being built as a module by anyone:
      
        drivers/pci/host/Kconfig:config PCI_TEGRA
        drivers/pci/host/Kconfig:       bool "NVIDIA Tegra 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.
      
      Replace module_platform_driver() with builtin_platform_driver(), which uses
      the same init level priority, so init ordering is unchanged.
      
      Note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
      
      [bhelgaas: changelog]
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Thierry Reding <thierry.reding@gmail.com>
      CC: Stephen Warren <swarren@wwwdotorg.org>
      CC: Alexandre Courbot <gnurou@gmail.com>
      CC: linux-tegra@vger.kernel.org
      ad183271
  22. 27 7月, 2016 2 次提交
  23. 26 7月, 2016 3 次提交
  24. 25 6月, 2016 2 次提交
    • B
      PCI: tegra: Request host bridge window resources with core function · 45c64b6a
      Bjorn Helgaas 提交于
      Use devm_request_pci_bus_resources() to request host bridge window
      resources instead of doing it by hand in the driver.
      
      No functional change intended.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      45c64b6a
    • B
      PCI: tegra: Remove top-level resource from hierarchy · c4102c92
      Bjorn Helgaas 提交于
      41534e53 ("PCI: tegra: Implement a proper resource hierarchy") did two
      things:
      
        1) It added a top-level resource that encloses all resources declared in
           the DT description, including registers and bridge apertures, and
      
        2) It requested the bridge apertures, which means the PCI core can track
           the resources used by PCI devices below the bridge.
      
      The latter is necessary, but the former is questionable because there's no
      guarantee that the bridge registers and the apertures are contiguous.  In
      this example:
      
        # cat /proc/iomem
        00000000-3fffffff : /pcie-controller@00003000
          00000000-00000fff : /pcie-controller@00003000/pci@1,0
          00003000-000037ff : pads
          00003800-000039ff : afi
          10000000-1fffffff : cs
      
      the resource tree claims that [mem 0x00003a00-0x0fffffff] is consumed by
      /pcie-controller@00003000, but it's not mentioned in the DT, and it might
      actually be used by other devices.
      
      Remove the top-level resource so we don't claim more than the device
      actually consumes.
      
      This reintroduces the problem that we can't match the resources, e.g.,
      "pads", "afi", "cs", etc., to the DT device.  I think this should be solved
      by having the DT core request all resources of all devices in the DT (it
      does not do that today).  If a driver claims the device, it can request the
      resources it uses.  For example:
      
        # cat /proc/iomem
        00000000-00000fff : /pcie-controller@00003000
          00000000-00000fff : /pcie-controller@00003000/pci@1,0
        00003000-000037ff : /pcie-controller@00003000
          00003000-000037ff : pads
        00003800-000039ff : /pcie-controller@00003000
          00003800-000039ff : afi
        10000000-1fffffff : /pcie-controller@00003000
          10000000-1fffffff : cs
        ...
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      c4102c92
  25. 29 4月, 2016 1 次提交
  26. 09 3月, 2016 2 次提交