1. 27 Aug, 2018 2 commits
  2. 02 Jun, 2018 1 commit
    • Arnd Bergmann's avatar
      ARM: tegra: fix compile-testing PCI host driver · 32561354
      Arnd Bergmann authored
      The tegra_cpuidle_pcie_irqs_in_use() function is stubbed out for non-ARM
      builds, but now we can compile-test the Tegra pci driver on non-Tegra
      ARM platforms as well, which results in a new link error:
      
      drivers/pci/host/pci-tegra.o: In function `tegra_pcie_map_irq':
      pci-tegra.c:(.text+0x288): undefined reference to `tegra_cpuidle_pcie_irqs_in_use'
      drivers/pci/host/pci-tegra.o: In function `tegra_msi_map':
      pci-tegra.c:(.text+0xba0): undefined reference to `tegra_cpuidle_pcie_irqs_in_use'
      
      This adapts the #ifdef statement to match the exact condition under which
      the function can be called.
      
      Fixes: 51bc085d ("PCI: Improve host drivers compile test coverage")
      Cc: Rob Herring <robh@kernel.org>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: Rob Herring's avatarRob Herring <robh@kernel.org>
      Acked-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: Olof Johansson's avatarOlof Johansson <olof@lixom.net>
      32561354
  3. 30 Apr, 2018 2 commits
    • Dmitry Osipenko's avatar
      memory: tegra: Introduce memory client hot reset · 20e92462
      Dmitry Osipenko authored
      In order to reset busy HW properly, memory controller needs to be
      involved, otherwise it is possible to get corrupted memory or hang machine
      if HW was reset during DMA. Introduce memory client 'hot reset' that will
      be used for resetting of busy HW.
      Signed-off-by: default avatarDmitry Osipenko <digetx@gmail.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      20e92462
    • Dmitry Osipenko's avatar
      memory: tegra: Squash tegra20-mc into common tegra-mc driver · a8d502fd
      Dmitry Osipenko authored
      Tegra30+ has some minor differences in registers / bits layout compared
      to Tegra20. Let's squash Tegra20 driver into the common tegra-mc driver
      in a preparation for the upcoming MC hot reset controls implementation,
      avoiding code duplication.
      
      Note that this currently doesn't report the value of MC_GART_ERROR_REQ
      because it is located within the GART register area and cannot be safely
      accessed from the MC driver (this happens to work only by accident). The
      proper solution is to integrate the GART driver with the MC driver, much
      like is done for the Tegra SMMU, but that is an invasive change and will
      be part of a separate patch series.
      Signed-off-by: default avatarDmitry Osipenko <digetx@gmail.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      a8d502fd
  4. 27 Apr, 2018 1 commit
  5. 08 Mar, 2018 1 commit
    • Mikko Perttunen's avatar
      firmware: tegra: Simplify channel management · 1abb081e
      Mikko Perttunen authored
      The Tegra194 BPMP only implements 5 channels (4 to BPMP, 1 to CCPLEX),
      and they are not placed contiguously in memory. The current channel
      management in the BPMP driver does not support this.
      
      Simplify and refactor the channel management such that only one atomic
      transmit channel and one receive channel are supported, and channels
      are not required to be placed contiguously in memory. The same
      configuration also works on T186 so we end up with less code.
      Signed-off-by: default avatarMikko Perttunen <mperttunen@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      1abb081e
  6. 15 Dec, 2017 1 commit
  7. 13 Dec, 2017 1 commit
  8. 19 Oct, 2017 3 commits
  9. 17 Oct, 2017 1 commit
  10. 17 Aug, 2017 1 commit
    • Thierry Reding's avatar
      soc/tegra: Register SoC device · 27a0342a
      Thierry Reding authored
      Move this code from arch/arm/mach-tegra and make it common among 32-bit
      and 64-bit Tegra SoCs. This is slightly complicated by the fact that on
      32-bit Tegra, the SoC device is used as the parent for all devices that
      are instantiated from device tree.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      27a0342a
  11. 13 Jun, 2017 2 commits
    • Thierry Reding's avatar
      soc/tegra: bpmp: Implement generic PM domains · e7149a7a
      Thierry Reding authored
      The BPMP firmware, found on Tegra186 and later, provides an ABI that can
      be used to enable and disable power to several power partitions in Tegra
      SoCs. The ABI allows for enumeration of the available power partitions,
      so the driver can be reused on future generations, provided the BPMP ABI
      remains stable.
      
      Based on work by Stefan Kristiansson <stefank@nvidia.com> and Mikko
      Perttunen <mperttunen@nvidia.com>.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      e7149a7a
    • Thierry Reding's avatar
      soc/tegra: bpmp: Update ABI header · 52b8b803
      Thierry Reding authored
      Update the BPMP ABI header to a more recent version. The new version
      adds support for a new powergating ABI as well as access to the ring
      buffer console, which allows debug messages to be output to the BPMP
      debug console.
      
      Some of the previously undocumented fields have been documented and
      missing bitmasks have been added. Furthermore the MRQ_RESET request
      now has a sub-command that allows to determine the maximum ID which
      in turn allows the resets to be enumerated, thereby allowing drivers
      to become agnostic of the Tegra generation.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      52b8b803
  12. 04 Apr, 2017 2 commits
    • Jon Hunter's avatar
      soc/tegra: Move Tegra flowctrl driver · 7e10cf74
      Jon Hunter authored
      The flowctrl driver is required for both ARM and ARM64 Tegra devices
      and in order to enable support for it for ARM64, move the Tegra flowctrl
      driver into drivers/soc/tegra.
      
      By moving the flowctrl driver, tegra_flowctrl_init() is now called by
      via an early initcall and to prevent this function from attempting to
      mapping IO space for a non-Tegra device, a test for 'soc_is_tegra()'
      is also added.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      7e10cf74
    • Arnd Bergmann's avatar
      soc/tegra: Fix link errors with PMC disabled · bd737038
      Arnd Bergmann authored
      With the new Tegra186 PMC driver merged, anything that relies on the previous
      PMC driver fails to link when that is disabled:
      
      arch/arm/mach-tegra/pm.o: In function `tegra_pm_set':
      pm.c:(.text.tegra_pm_set+0x3c): undefined reference to `tegra_pmc_enter_suspend_mode'
      arch/arm/mach-tegra/pm.o: In function `tegra_suspend_enter':
      pm.c:(.text.tegra_suspend_enter+0x4): undefined reference to `tegra_pmc_get_suspend_mode'
      arch/arm/mach-tegra/pm.o: In function `tegra_init_suspend':
      pm.c:(.init.text+0x1c): undefined reference to `tegra_pmc_get_suspend_mode'
      pm.c:(.init.text+0x74): undefined reference to `tegra_pmc_set_suspend_mode'
      
      ERROR: tegra_powergate_sequence_power_up [drivers/ata/ahci_tegra.ko] undefined!
      ERROR: tegra_powergate_power_off [drivers/ata/ahci_tegra.ko] undefined!
      
      Making the definition depend on the presence of the driver makes it build
      again, though that might not be the correct fix.
      Reported-by: Krzysztof Kozłowski's avatarKrzysztof Kozlowski <krzk@kernel.org>
      Fixes: 854014236290 ("soc/tegra: Implement Tegra186 PMC support")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      bd737038
  13. 18 Nov, 2016 2 commits
    • Thierry Reding's avatar
      firmware: tegra: Add BPMP support · 983de5f9
      Thierry Reding authored
      The Boot and Power Management Processor (BPMP) is a co-processor found
      on Tegra SoCs. It is designed to handle the early stages of the boot
      process and offload power management tasks (such as clocks, resets,
      powergates, ...) as well as system control services.
      
      Compared to the ARM SCPI, the services provided by BPMP are message-
      based rather than method-based. The BPMP firmware driver provides the
      services to transmit data to and receive data from the BPMP. Users can
      also register a Message ReQuest (MRQ), for which a service routine will
      be run when a corresponding event is received from the firmware.
      
      A set of messages, called the BPMP ABI, are specified for a number of
      different services provided by the BPMP (such as clocks or resets).
      
      Based on work by Sivaram Nair <sivaramn@nvidia.com> and Joseph Lo
      <josephl@nvidia.com>.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      983de5f9
    • Thierry Reding's avatar
      firmware: tegra: Add IVC library · ca791d7f
      Thierry Reding authored
      The Inter-VM communication (IVC) is a communication protocol which is
      designed for interprocessor communication (IPC) or the communication
      between the hypervisor and the virtual machine with a guest OS.
      
      Message channels are used to communicate between processors. They are
      backed by DRAM or SRAM, so care must be taken to maintain coherence of
      data.
      
      The IVC library maintains memory-based descriptors for the transmission
      and reception channels as well as the data coherence of the counter and
      payload. Clients, such as the driver for the BPMP firmware, can use the
      library to exchange messages with remote processors.
      
      Based on work by Peter Newman <pnewman@nvidia.com> and Joseph Lo
      <josephl@nvidia.com>.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      ca791d7f
  14. 15 Nov, 2016 1 commit
    • Laxman Dewangan's avatar
      soc/tegra: pmc: Add I/O pad voltage support · 21b49910
      Laxman Dewangan authored
      I/O pins on Tegra SoCs are grouped into so-called I/O pads. Each such
      pad can be used to control the common voltage signal level and power
      state of the pins in the given pad.
      
      I/O pads can be powered down even if the system is active, which can
      save power from that I/O interface. For SoC generations prior to
      Tegra124 the I/O pad voltage is automatically detected and hence the
      system software doesn't need to configure it. However, starting with
      Tegra210 the detection logic has been removed, so explicit control of
      the I/O pad voltage by system software is required.
      Signed-off-by: default avatarLaxman Dewangan <ldewangan@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      21b49910
  15. 30 Jun, 2016 1 commit
  16. 29 Apr, 2016 2 commits
    • Jon Hunter's avatar
      soc/tegra: pmc: Add generic PM domain support · a3804512
      Jon Hunter authored
      Adds generic PM domain support to the PMC driver where the PM domains
      are populated from device-tree and the PM domain consumer devices are
      bound to their relevant PM domains via device-tree as well.
      
      Update the tegra_powergate_sequence_power_up() API so that internally
      it calls the same tegra_powergate_xxx functions that are used by the
      Tegra generic PM domain code for consistency.
      
      To ensure that the Tegra power domains (a.k.a. powergates) cannot be
      controlled via both the legacy tegra_powergate_xxx functions as well
      as the generic PM domain framework, add a bit map for available
      powergates that can be controlled via the legacy powergate functions.
      
      Move the majority of the tegra_powergate_remove_clamping() function
      to a sub-function, so that this can be used by both the legacy and
      generic power domain code.
      
      This is based upon work by Thierry Reding <treding@nvidia.com>
      and Vince Hsu <vinceh@nvidia.com>.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      a3804512
    • Thierry Reding's avatar
      phy: tegra: Add Tegra210 support · 87d66f28
      Thierry Reding authored
      Add support for the XUSB pad controller found on Tegra210 SoCs. The
      hardware is roughly the same, but some of the registers have been moved
      around and the number and type of supported pads has changed.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      87d66f28
  17. 05 Apr, 2016 1 commit
  18. 13 Aug, 2015 3 commits
    • Thierry Reding's avatar
      iommu/tegra-smmu: Parameterize number of TLB lines · 11cec15b
      Thierry Reding authored
      The number of TLB lines was increased from 16 on Tegra30 to 32 on
      Tegra114 and later. Parameterize the value so that the initial default
      can be set accordingly.
      
      On Tegra30, initializing the value to 32 would effectively disable the
      TLB and hence cause massive latencies for memory accesses translated
      through the SMMU. This is especially noticeable for isochronuous clients
      such as display, whose FIFOs would continuously underrun.
      
      Fixes: 89184651 ("memory: Add NVIDIA Tegra memory controller support")
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      11cec15b
    • Paul Walmsley's avatar
      memory: tegra: Add support for a variable-size client ID bitfield · 3c01cf3b
      Paul Walmsley authored
      Recent versions of the Tegra MC hardware extend the size of the client
      ID bitfield in the MC_ERR_STATUS register by one bit.  While one could
      simply extend the bitfield for older hardware, that would allow data
      from reserved bits into the driver code, which is generally a bad idea
      on principle.  So this patch instead passes in the client ID mask from
      from the per-SoC MC data.
      
      There's no MC support for T210 (yet), but when that support winds up
      in the kernel, the appropriate soc->client_id_mask value for that chip
      will be 0xff.
      
      Based on an original patch by David Ung <davidu@nvidia.com>.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Paul Walmsley <pwalmsley@nvidia.com>
      Cc: Thierry Reding <treding@nvidia.com>
      Cc: David Ung <davidu@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      3c01cf3b
    • Russell King's avatar
      iommu/tegra-smmu: Move flush_dcache to tegra-smmu.c · 4b3c7d10
      Russell King authored
      Drivers should not be using __cpuc_* functions nor outer_cache_flush()
      directly.  This change partly cleans up tegra-smmu.c.
      
      The only difference between cache handling of the tegra variants is
      Denver, which omits the call to outer_cache_flush().  This is due to
      Denver being an ARM64 CPU, and the ARM64 architecture does not provide
      this function.  (This, in itself, is a good reason why these should not
      be used.)
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      [treding@nvidia.com: fix build failure on 64-bit ARM]
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      4b3c7d10
  19. 16 Jul, 2015 3 commits
  20. 05 May, 2015 2 commits
  21. 04 May, 2015 4 commits
  22. 09 Jan, 2015 2 commits
  23. 04 Dec, 2014 1 commit
    • Thierry Reding's avatar
      memory: Add NVIDIA Tegra memory controller support · 89184651
      Thierry Reding authored
      The memory controller on NVIDIA Tegra exposes various knobs that can be
      used to tune the behaviour of the clients attached to it.
      
      Currently this driver sets up the latency allowance registers to the HW
      defaults. Eventually an API should be exported by this driver (via a
      custom API or a generic subsystem) to allow clients to register latency
      requirements.
      
      This driver also registers an IOMMU (SMMU) that's implemented by the
      memory controller. It is supported on Tegra30, Tegra114 and Tegra124
      currently. Tegra20 has a GART instead.
      
      The Tegra SMMU operates on memory clients and SWGROUPs. A memory client
      is a unidirectional, special-purpose DMA master. A SWGROUP represents a
      set of memory clients that form a logical functional unit corresponding
      to a single device. Typically a device has two clients: one client for
      read transactions and one client for write transactions, but there are
      also devices that have only read clients, but many of them (such as the
      display controllers).
      
      Because there is no 1:1 relationship between memory clients and devices
      the driver keeps a table of memory clients and the SWGROUPs that they
      belong to per SoC. Note that this is an exception and due to the fact
      that the SMMU is tightly integrated with the rest of the Tegra SoC. The
      use of these tables is discouraged in drivers for generic IOMMU devices
      such as the ARM SMMU because the same IOMMU could be used in any number
      of SoCs and keeping such tables for each SoC would not scale.
      Acked-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      89184651