summaryrefslogtreecommitdiff
path: root/drivers/memory/tegra/mc.c
AgeCommit message (Collapse)AuthorFilesLines
2021-01-23memory: tegra: Check whether reset is already assertedDmitry Osipenko1-0/+7
Check whether memory client reset is already asserted in order to prevent DMA-flush error on trying to re-assert an already asserted reset. This becomes a problem once PMC GENPD is enabled to use memory resets since GENPD will get a error and fail to toggle power domain. PMC GENPDs can't be toggled safely without holding memory reset on Tegra and we're about to fix this. Tested-by: Peter Geis <pgwipeout@gmail.com> # Ouya T30 Tested-by: Nicolas Chauvet <kwizart@gmail.com> # PAZ00 T20 Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30 Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20210119235210.13006-1-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-11-26memory: tegra30-emc: Make driver modularDmitry Osipenko1-0/+3
Add modularization support to the Tegra30 EMC driver, which now can be compiled as a loadable kernel module. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20201111011456.7875-8-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-11-26memory: tegra-mc: Add interconnect frameworkDmitry Osipenko1-0/+100
Add common SoC-agnostic ICC framework which turns Tegra Memory Controller into a memory interconnection provider. This allows us to use interconnect API for tuning of memory configurations. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Tested-by: Nicolas Chauvet <kwizart@gmail.com> Link: https://lore.kernel.org/r/20201104164923.21238-33-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-11-26memory: tegra: Remove superfluous error messages around platform_get_irq()Dmitry Osipenko1-3/+1
The platform_get_irq() prints error message telling that interrupt is missing, hence there is no need to duplicated that message in the drivers. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20201104164923.21238-31-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-11-26memory: tegra: Add and use devm_tegra_memory_controller_get()Dmitry Osipenko1-0/+48
Multiple Tegra drivers need to retrieve Memory Controller and there is duplication of the retrieval code among the drivers. Add new devm_tegra_memory_controller_get() helper to remove the code's duplication and to fix put_device() which was missed in the duplicated code. Make EMC drivers to use the new helper. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20201104164923.21238-29-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-11-11memory: tegra: Consolidate registers definition into common headerDmitry Osipenko1-30/+0
The Memory Controller registers definition is sparse and duplicated, let's consolidate everything into a common place for consistency. Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-11-11memory: tegra: Ensure timing control debug features are disabledDmitry Osipenko1-0/+3
Timing control debug features should be disabled at a boot time, but you never now and hence it's better to disable them explicitly because some of those features are crucial for the driver to do a proper thing. Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-11-11memory: tegra: Introduce Tegra30 EMC driverDmitry Osipenko1-5/+4
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-11-11memory: tegra: Set DMA mask based on supported address bitsThierry Reding1-0/+10
The memory controller on Tegra124 and later supports 34 or more address bits. Advertise that by setting the DMA mask based on the number of the address bits. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-06-19treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner1-4/+1
Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-18memory: tegra: Replace readl-writel with mc_readl-mc_writelDmitry Osipenko1-5/+5
There is no need for a memory barriers on reading/writing of register values as we only care about the read/write order, hence let's use the common helpers. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-04-18memory: tegra: Fix integer overflow on tick value calculationDmitry Osipenko1-1/+1
Multiplying the Memory Controller clock rate by the tick count results in an integer overflow and in result the truncated tick value is being programmed into hardware, such that the GR3D memory client performance is reduced by two times. Cc: stable <stable@vger.kernel.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-04-18memory: tegra: Fix missed registers values latchingDmitry Osipenko1-0/+6
Some of Memory Controller registers are shadowed and require latching in order to copy assembly state into the active, MC_EMEM_ARB_CFG is one of these registers. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-04-11memory: tegra: Properly spell "tegra"Thierry Reding1-9/+9
Rename all occurrences of "terga" to "tegra". It's an easy typo to make and a difficult one to spot. Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-01-16memory: tegra: Clean up error messagesDmitry Osipenko1-7/+8
Make all messages to start with a lower case and don't unnecessarily go over 80 chars in the code. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-01-16memory: tegra: Do not ask for IRQ sharingDmitry Osipenko1-1/+1
Memory Controller driver never shared IRQ with any other driver and very unlikely that it will. Hence there is no need to request IRQ sharing and the corresponding flag can be dropped safely. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-01-16memory: tegra: Do not try to probe SMMU on Tegra20Dmitry Osipenko1-2/+4
Tegra20 doesn't have SMMU. Move out checking of the SMMU presence from the SMMU driver into the Memory Controller driver. This change makes code consistent in regards to how GART/SMMU presence checking is performed. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-01-16iommu/tegra: gart: Integrate with Memory Controller driverDmitry Osipenko1-0/+43
The device-tree binding has been changed. There is no separate GART device anymore, it is squashed into the Memory Controller. Integrate GART module with the MC in a way it is done for the SMMU on Tegra30+. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-01-16memory: tegra: Use of_device_get_match_data()Dmitry Osipenko1-6/+2
There is no need to match device with the DT node since it was already matched, use of_device_get_match_data() helper to get the match-data. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-01-16memory: tegra: Read client ID on GART page faultDmitry Osipenko1-2/+10
With the device tree binding changes, now Memory Controller has access to GART registers. Hence it is now possible to read client ID on GART page fault to get information about what memory client causes the fault. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-01-16memory: tegra: Adapt to Tegra20 device-tree binding changesDmitry Osipenko1-13/+8
The tegra20-mc device-tree binding has been changed, GART has been squashed into Memory Controller and now the clock property is mandatory for Tegra20, the DT compatible has been changed as well. Adapt driver to the DT changes. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-01-16memory: tegra: Don't invoke Tegra30+ specific memory timing setup on Tegra20Dmitry Osipenko1-5/+6
This fixes irrelevant "tegra-mc 7000f000.memory-controller: no memory timings for RAM code 0 registered" warning message during of kernels boot-up on Tegra20. Fixes: a8d502fd3348 ("memory: tegra: Squash tegra20-mc into common tegra-mc driver") Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-11-27memory: Convert to using %pOFn instead of device_node.nameRob Herring1-3/+3
In preparation to remove the node name pointer from struct device_node, convert printf users to use the %pOFn format specifier. Cc: Roger Quadros <rogerq@ti.com> Cc: Kukjin Kim <kgene@kernel.org> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: linux-omap@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-tegra@vger.kernel.org Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org>
2018-07-10memory: tegra: Correct driver probe orderDmitry Osipenko1-10/+6
The Reset Controller should be registered in the end of probe, otherwise Memory Controller device goes away if IRQ requesting fails and the Reset Controller stays registered. To avoid having to unwind the MC probing in a case of SMMU probe failure, let's simply print the error message without failing the MC probe. This allows us to just move the Reset Controller registering before the SMMU registration, reducing code churning. Also let's not fail MC probe in a case of Reset Controller registration failure as it doesn't prevent the MC driver to work. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-05-18memory: tegra: Register SMMU after MC driver became readyDmitry Osipenko1-9/+9
Memory Controller driver invokes SMMU driver registration and MC's registers mapping is shared with SMMU. This mapping goes away if MC driver probing fails after SMMU registration. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-04-30memory: tegra: Introduce memory client hot resetDmitry Osipenko1-0/+210
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: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-04-30memory: tegra: Squash tegra20-mc into common tegra-mc driverDmitry Osipenko1-12/+100
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: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-04-27memory: tegra: Apply interrupts mask per SoCDmitry Osipenko1-18/+3
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-27memory: tegra: Setup interrupts mask before requesting IRQDmitry Osipenko1-8/+8
This avoids unwanted interrupt during MC driver probe. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-04-27memory: tegra: Do not handle spurious interruptsDmitry Osipenko1-1/+4
The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the mask to the interrupt status and don't handle interrupts that MC driver haven't asked for. Kernel would disable spurious MC IRQ and report the error. This would happen only in a case of a very severe bug. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-06-14memory: tegra: mc: Add missing of_node_put()Amitoj Kaur Chawla1-2/+4
for_each_child_of_node() performs an of_node_get() on each iteration, so to break out of the loop an of_node_put() is required. Found using Coccinelle. The semantic patch used for this is as follows: // <smpl> @@ expression e; local idexpression n; @@ for_each_child_of_node(..., n) { ... when != of_node_put(n) when != e = n ( return n; | + of_node_put(n); ? return ...; ) ... } // </smpl> Signed-off-by: Amitoj Kaur Chawla <amitoj1606@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-06-14memory: tegra: Delete unneeded of_node_put()Julia Lawall1-3/+1
for_each_child_of_node() performs an of_node_put() on each iteration, so putting an of_node_put() before a continue results in a double put. The semantic match that finds this problem is as follows (http://coccinelle.lip6.fr): // <smpl> @@ expression root,e; local idexpression child; iterator name for_each_child_of_node; @@ for_each_child_of_node(root, child) { ... when != of_node_get(child) * of_node_put(child); ... * continue; } // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-08-13memory: tegra: Add Tegra210 supportThierry Reding1-0/+3
Add the table of memory clients and SWGROUPs for Tegra210 to enable SMMU support for this new SoC. Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-08-13memory: tegra: Add support for a variable-size client ID bitfieldPaul Walmsley1-2/+3
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-05-13Merge tag 'tegra-for-4.2-emc' of ↵Arnd Bergmann1-0/+136
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-05memory: tegra: Add API needed by the EMC driverMikko Perttunen1-0/+136
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-04memory: tegra: Disable ARBITRATION_EMEM interruptTomeu Vizoso1-2/+2
As this interrupt is just for development purposes, as the TRM says, and the sheer amount of interrupts fired can seriously disrupt userspace when testing the lower frequencies supported by the EMC. From the TRM: "There is one performance warning type interrupt: ARBITRATION_EMEM. It fires when the MC detects that a request has been pending in the Row Sorter long enough to hit the DEADLOCK_PREVENTION_SLACK_THRESHOLD. In addition to true performance problems, this interrupt may fire in situations such as clock-change where the EMC backpressures pending traffic for long periods of time. This interrupt helps developers identify and debug performance issues and configuration issues." Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-05-04memory: tegra: Add Tegra132 supportThierry Reding1-0/+3
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>
2014-12-04memory: Add NVIDIA Tegra memory controller supportThierry Reding1-0/+301
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>
generated by cgit v1.2.3 (git 2.39.0) at 2024-09-16 20:59:54 +0300