Correctly set clk rate-range if number of available timings is zero.
This fixes noisy "invalid range [4294967295, 0]" error messages during
boot.
Fixes: 6b9acd9355 ("memory: tegra: Refashion EMC debugfs interface on Tegra124")
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Correctly set clk rate-range if number of available timings is zero.
This fixes noisy "invalid range [4294967295, 0]" error messages during
boot.
Fixes: 8cee32b400 ("memory: tegra: Implement EMC debugfs interface on Tegra30")
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Correctly set clk rate-range if number of available timings is zero.
This fixes noisy "invalid range [4294967295, 0]" error messages during
boot.
Fixes: 8209eefa3d ("memory: tegra: Implement EMC debugfs interface on Tegra20")
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The code waits for auto calibration to be finished and not to be disabled.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Previously there was a problem where a late handshake handling caused
a memory corruption, this problem was resolved by issuing calibration
command right after changing the timing, but looks like the solution
wasn't entirely correct since calibration interval could be disabled as
well. Now programming sequence is completed immediately after receiving
handshake from CaR, without potentially long delays and in accordance to
the TRM's programming guide.
Secondly, the TRM's programming guide suggests to flush EMC writes by
reading any *MC* register before doing CaR changes. This is also addressed
now.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The current code doesn't prevent race conditions of suspend/resume vs CCF.
Let's take exclusive control over the EMC clock during suspend in a way
that is free from race conditions.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
According to Tegra X1 (Tegra210) TRM, the reset value of xusb_hostr
field (bit [7:0]) should be 0x7a. So this patch simply corrects it.
Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The memory and external memory controllers on Tegra194 are very similar
to their predecessors from Tegra186. Add the necessary SoC-specific data
to support the newer versions.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The memory client tables can be fairly large and they can easily be
omitted if support for the corresponding SoC is not enabled.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add a Tegra186 (and later) EMC driver that reads the EMC DVFS tables
from BPMP and uses the EMC clock to change the external memory clock.
This currently only provides a debugfs interface to show the available
frequencies and set lower and upper limits of the allowed range. This
can be used for testing the various frequencies. The goal is to
eventually integrate this with the interconnect framework so that the
EMC frequency can be scaled based on demand from memory clients.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add system suspend/resume support for the memory controller found on
Tegra186 and later. This is required so that the SID registers can be
reprogrammed after their content was lost during system sleep.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Move programming of the memory client to SID mapping into a separate
function so that it can be reused from multiple call sites.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Instead of hard-coding the memory client table, use per-SoC data in
preparation for adding support for other SoCs.
Signed-off-by: Thierry Reding <treding@nvidia.com>
A common debugfs interface is already available on Tegra20, Tegra124,
Tegra186 and Tegra194. Implement the same interface on Tegra30 to enable
testing of the EMC frequency scaling code using a unified interface.
Signed-off-by: Thierry Reding <treding@nvidia.com>
A common debugfs interface is already available on Tegra124, Tegra186
and Tegra194. Implement the same interface on Tegra20 to enable testing
of the EMC frequency scaling code using a unified interface.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The current debugfs interface is only partially useful. While it allows
listing supported frequencies and testing individual clock rates, it is
limited in that it can't be used to restrict the range of frequencies
that the driver is allowed to set. This is something we may want to use
to test adaptive scaling once that's implemented.
Signed-off-by: Thierry Reding <treding@nvidia.com>
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>
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>
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>
Contrary to its wait_for_completion_timeout_interruptible() sibling, the
wait_for_completion_timeout() function does not return an error.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Turned out that it could take over a millisecond under some circumstances,
like running on a very low CPU/memory frequency. TRM says that handshake
happens when there is a "safe" moment, but not explains exactly what that
moment is. Apparently at least memory should be idling and thus the low
frequency should be a reasonable cause for a longer handshake delay.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
During boot print how many memory timings got the driver and what's the
RAM code. This is a very useful information when something is wrong with
boards memory timing.
Suggested-by: Marc Dietrich <marvin24@gmx.de>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The driver expects certain debug features to be disabled in order to
work properly. Let's disable them explicitly for consistency and to not
rely on a boot state.
Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Dmitry Osipenko
Nicolin Chen
Thierry Reding