summaryrefslogtreecommitdiff
path: root/drivers/memory/tegra/Kconfig
AgeCommit message (Collapse)Author
2020-06-22memory: tegra: Add EMC scaling support code for Tegra210Joseph Lo
This is the initial patch for Tegra210 EMC frequency scaling. It has the code to program various aspects of the EMC that are standardized, but it does not yet include the specific programming sequence needed for clock scaling. The driver is designed to support LPDDR4 SDRAM. Devices that use LPDDR4 need to perform training of the RAM before it can be used. Firmware will perform this training during early boot and pass a table of supported frequencies to the kernel via device tree. For the frequencies above 800 MHz, periodic retraining is needed to compensate for changes in timing. This periodic training will have to be performed until the frequency drops back to or below 800 MHz. This driver provides helpers used during this runtime retraining that will be used by the sequence specific code in a follow-up patch. Based on work by Peter De Schrijver <pdeschrijver@nvidia.com>. Signed-off-by: Joseph Lo <josephl@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-11-11memory: tegra: Introduce Tegra30 EMC driverDmitry Osipenko
Introduce driver for the External Memory Controller (EMC) found on Tegra30 chips, it controls the external DRAM on the board. The purpose of this driver is to program memory timing for external memory on the EMC clock rate change. Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-05-21treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner
Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-08memory: tegra: Introduce Tegra20 EMC driverDmitry Osipenko
Introduce driver for the External Memory Controller (EMC) found on Tegra20 chips, which controls the external DRAM on the board. The purpose of this driver is to program memory timing for external memory on the EMC clock rate change. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-05-05memory: tegra: Add EMC (external memory controller) driverMikko Perttunen
Implements functionality needed to change the rate of the memory bus clock. 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>
2014-12-04memory: Add NVIDIA Tegra memory controller supportThierry Reding
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>