Commit Graph

13 Commits

Author SHA1 Message Date
Dmitry Osipenko 1b19b0561d memory: tegra: Add Tegra124 memory controller hot resets
Define the table of memory controller hot resets for Tegra124.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-04-30 10:12:21 +02:00
Dmitry Osipenko 1c74d5c0de memory: tegra: Apply interrupts mask per SoC
Currently we are enabling handling of interrupts specific to Tegra124+
which happen to overlap with previous generations. Let's specify
interrupts mask per SoC generation for consistency and in a preparation
of squashing of Tegra20 driver into the common one that will enable
handling of GART faults which may be undesirable by newer generations.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-04-27 11:23:04 +02:00
Thierry Reding 2a8102dfe0 memory: tegra: Create SMMU display groups
Create SMMU display groups for Tegra30, Tegra114, Tegra124 and Tegra210.
This allows the display controllers on these devices to share the same
IOMMU domain using the standard IOMMU group mechanism.

Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-12-15 10:12:32 +01:00
Vince Hsu e2127ae7a5 memory/tegra: Add number of TLB lines for Tegra124
Tegra124 was accidentally left out when the number of TLB lines was
parameterized in commit 11cec15bf3 ("iommu/tegra-smmu: Parameterize
number of TLB lines"). Fortunately this doesn't cause any noticeable
regressions upstream, presumably because there aren't any use-cases
that exercise enough pressure on the SMMU. But it is a regression
nonetheless, so let's fix it.

Fixes: 11cec15bf3 ("iommu/tegra-smmu: Parameterize number of TLB lines")
Signed-off-by: Vince Hsu <vince.h@nvidia.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
[treding@nvidia.com: extract from unrelated patch]
Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-12-14 16:11:35 +01:00
Linus Torvalds 9a9952bbd7 IOMMU Updates for Linux v4.3
This time the IOMMU updates are mostly cleanups or fixes. No big new
 features or drivers this time. In particular the changes include:
 
 	* Bigger cleanup of the Domain<->IOMMU data structures and the
 	  code that manages them in the Intel VT-d driver. This makes
 	  the code easier to understand and maintain, and also easier to
 	  keep the data structures in sync. It is also a preparation
 	  step to make use of default domains from the IOMMU core in the
 	  Intel VT-d driver.
 
 	* Fixes for a couple of DMA-API misuses in ARM IOMMU drivers,
 	  namely in the ARM and Tegra SMMU drivers.
 
 	* Fix for a potential buffer overflow in the OMAP iommu driver's
 	  debug code
 
 	* A couple of smaller fixes and cleanups in various drivers
 
 	* One small new feature: Report domain-id usage in the Intel
 	  VT-d driver to easier detect bugs where these are leaked.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.22 (GNU/Linux)
 
 iQIcBAABAgAGBQJV7sCEAAoJECvwRC2XARrjz3YP/Au4IIfqykfPvmI0cmPhVnAV
 Q72tltwkbK2u2iP+pHheveaMngJtAshsZrnhBon4KJRIt/KTLZQvsFplHDaRhPfY
 yw3LIxhC5kLG/S6irY9Ozb0+uTMdQ3BU2uS23pyoFVfCz+RngBrAwDBcTKqZDCDG
 8dNd+T21XlzxuyeGr58h9upz2VFtq6feoGFhLU5PNxTlf4JWZe77D7NlbSvx6Nwy
 7Ai8dVRgpV9ciUP7w8FXrCUvbMZQDIoTMiWGNSlogVMgA0dllGES91UZYhWf3pil
 abuX6DeFul/cOhEOnH2xa+j5zz2O/upe9stU4wAFw6IhPiAELTHc2NKlWAhwb0SY
 bpDRf7dgLnUfqpmZLpWjTwN4jllc0qS2MIHj+eUu0uhdFi4Z0BuH2wSCdbR7xkqk
 u5u0Jq7hDNKs5FmQTSsWSiAdjakMsRjIN7jMrBbOeZnBSmUnLx74KGPLTb63ncR3
 WIOi4Iyu+LSXBIvZDiLu3lIIh7Atzd+y7IDnb8KXdyqfy+h53OZZOJNbP/qTWHgT
 ZUdm/qrqjIQpTQfleOEadC7vY/y3fR5sBtOQHUamfntni3oYCc4AMRlNdf3eV9lb
 Tyss6F699mU7d/vennTaIToBgVwaXdLYtmvGWjnoT/kqOMclyDf3cIUtZGtp2rJR
 ddmzDA3vBUC5pGj8Hd8R
 =yoGE
 -----END PGP SIGNATURE-----

Merge tag 'iommu-updates-v4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu

Pull iommu updates for from Joerg Roedel:
 "This time the IOMMU updates are mostly cleanups or fixes.  No big new
  features or drivers this time.  In particular the changes include:

   - Bigger cleanup of the Domain<->IOMMU data structures and the code
     that manages them in the Intel VT-d driver.  This makes the code
     easier to understand and maintain, and also easier to keep the data
     structures in sync.  It is also a preparation step to make use of
     default domains from the IOMMU core in the Intel VT-d driver.

   - Fixes for a couple of DMA-API misuses in ARM IOMMU drivers, namely
     in the ARM and Tegra SMMU drivers.

   - Fix for a potential buffer overflow in the OMAP iommu driver's
     debug code

   - A couple of smaller fixes and cleanups in various drivers

   - One small new feature: Report domain-id usage in the Intel VT-d
     driver to easier detect bugs where these are leaked"

* tag 'iommu-updates-v4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: (83 commits)
  iommu/vt-d: Really use upper context table when necessary
  x86/vt-d: Fix documentation of DRHD
  iommu/fsl: Really fix init section(s) content
  iommu/io-pgtable-arm: Unmap and free table when overwriting with block
  iommu/io-pgtable-arm: Move init-fn declarations to io-pgtable.h
  iommu/msm: Use BUG_ON instead of if () BUG()
  iommu/vt-d: Access iomem correctly
  iommu/vt-d: Make two functions static
  iommu/vt-d: Use BUG_ON instead of if () BUG()
  iommu/vt-d: Return false instead of 0 in irq_remapping_cap()
  iommu/amd: Use BUG_ON instead of if () BUG()
  iommu/amd: Make a symbol static
  iommu/amd: Simplify allocation in irq_remapping_alloc()
  iommu/tegra-smmu: Parameterize number of TLB lines
  iommu/tegra-smmu: Factor out tegra_smmu_set_pde()
  iommu/tegra-smmu: Extract tegra_smmu_pte_get_use()
  iommu/tegra-smmu: Use __GFP_ZERO to allocate zeroed pages
  iommu/tegra-smmu: Remove PageReserved manipulation
  iommu/tegra-smmu: Convert to use DMA API
  iommu/tegra-smmu: smmu_flush_ptc() wants device addresses
  ...
2015-09-08 17:22:35 -07:00
Thierry Reding 11cec15bf3 iommu/tegra-smmu: Parameterize number of TLB lines
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: 8918465163 ("memory: Add NVIDIA Tegra memory controller support")
Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-08-13 17:05:28 +02:00
Paul Walmsley 3c01cf3bef memory: tegra: Add support for a variable-size client ID bitfield
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: Paul 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: Thierry Reding <treding@nvidia.com>
2015-08-13 16:07:52 +02:00
Russell King 4b3c7d1076 iommu/tegra-smmu: Move flush_dcache to tegra-smmu.c
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: Russell King <rmk+kernel@arm.linux.org.uk>
[treding@nvidia.com: fix build failure on 64-bit ARM]
Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-08-13 16:06:40 +02:00
Arnd Bergmann 44fb3026ad ARM: tegra: Add EMC driver for v4.2-rc1
This introduces the EMC driver that's required to scale the external
 memory frequency.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJVU1FHAAoJEN0jrNd/PrOhClAQAKDOt5OYvadTfmPogJiwxlQl
 7NvVVsnIzHfScANP6B/pynoC8Gfx1owRdLzPPWKM860gtdtaA9pXOWRuxQV8NLcR
 5WQO4Z4sNXyvA704MNFK+EqydCN2Iu/Z+2Ups8VHZ9VmukSNaCu/se6JvW+GJMm1
 DHytjzHeckNUruNrZnXLA6ckwymDbMtCBV3W9hIeKe9aPjJrgjR7Rlhhu7cX9XGF
 XSCF9eigh4MsyLgf3cWMoVl2NIePCW3sbAQEKkiM5xzPo21VlpPyja7OWoytcQkC
 HEMmuICfwT8XEd7fTabW+WHxTnVhkL+OZ833p+LSBUCeXJ82N8vSV8HZlRHly9LZ
 diXoJ9+2l/C02FtnnB7BtLxnyQ2NF6LAP1CvYZ7eF/Z+lxthErs0bIXyjC0RTuBN
 9y6t0/VhEGMv6ApOly1VrHLtU6LnQEbYryvlOjvP4NQVb6jQc165UdPZtXufgx9o
 VprQoOIHdBzMnThI7ndRWgZcayn+VmJy0TvjTGmhLcurwigbCjkqYdwhq2c7Z0F2
 FpEOCqWMJ0mywQXoZadIk5ON51IVRin0otyKed14PY9QU6c6hJ6NCZQi1pQnB95W
 Ut7ZrdZnZMIjMui8EOzeJc82mjKL3agpbYTQqqiIV+kHY9dXpxSOOHd4DbMN5Kc2
 3xvgkGtj61VOlGiGnp/W
 =QeY4
 -----END PGP SIGNATURE-----

Merge tag 'tegra-for-4.2-emc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers

Merge "ARM: tegra: Add EMC driver for v4.2-rc1" from Thierry Reding:

This introduces the EMC driver that's required to scale the external
memory frequency.

* tag 'tegra-for-4.2-emc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
  memory: tegra: Add EMC frequency debugfs entry
  memory: tegra: Add EMC (external memory controller) driver
  memory: tegra: Add API needed by the EMC driver
  of: Add Tegra124 EMC bindings
  of: Document timings subnode of nvidia,tegra-mc
2015-05-13 17:59:35 +02:00
Mikko Perttunen 3d9dd6fdd2 memory: tegra: Add API needed by the EMC driver
The EMC driver needs to know the number of external memory devices and
also needs to update the EMEM configuration based on the new rate of the
memory bus.

To know how to update the EMEM config, looks up the values of the burst
regs in the DT, for a given timing.

Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-05-05 11:10:19 +02:00
Thierry Reding 242b1d7133 memory: tegra: Add Tegra132 support
The memory controller on Tegra132 is very similar to the one found on
Tegra124. But the Denver CPUs don't have an outer cache, so dcache
maintenance is done slightly differently.

Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-05-04 12:54:23 +02:00
Thierry Reding e660df07ab memory: tegra: Add SWGROUP names
Subsequent patches will add debugfs files that print the status of the
SWGROUPs. Add a new names field and complement the SoC tables with the
names of the individual SWGROUPs.

Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-05-04 12:54:23 +02:00
Thierry Reding 8918465163 memory: Add NVIDIA Tegra memory controller support
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: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-12-04 16:11:47 +01:00