| 36e5f7ce | 19-Oct-2015 |
Alexandre Courbot <acourbot@nvidia.com> |
ARM: tegra: remove vpr_configured() function
There is no justification for this function, especially in exported
form.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Tom Warr
ARM: tegra: remove vpr_configured() function
There is no justification for this function, especially in exported
form.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
show more ...
|
| f35cb125 | 23-Oct-2015 |
Stephen Warren <swarren@nvidia.com> |
ARM: tegra: error check Tegra210 XUSB padctl waits
Add code to detect timeouts when waiting for HW events such as PLL
lock done. Any errors are logged and trigger an error return code.
Signed-off-b
ARM: tegra: error check Tegra210 XUSB padctl waits
Add code to detect timeouts when waiting for HW events such as PLL
lock done. Any errors are logged and trigger an error return code.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
show more ...
|
| 4e4b5574 | 23-Oct-2015 |
Stephen Warren <swarren@nvidia.com> |
ARM: tegra: add lane tables to Tegra210 XUSB padctl
Add the tables defining which pads and mux options exist in the Tegra210
XUSB padctl hardware.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: add lane tables to Tegra210 XUSB padctl
Add the tables defining which pads and mux options exist in the Tegra210
XUSB padctl hardware.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
show more ...
|
| 7a908c7e | 23-Oct-2015 |
Stephen Warren <swarren@nvidia.com> |
ARM: tegra: switch Tegra210 to common XUSB padctl
This change simply deletes code from the Tegra210 XUSB padctl driver that
is already present in the common XUSB padctl code. Since all the arrays
in
ARM: tegra: switch Tegra210 to common XUSB padctl
This change simply deletes code from the Tegra210 XUSB padctl driver that
is already present in the common XUSB padctl code. Since all the arrays
in tegra210_socdata are empty, this update may leave the Tegra210 XUSB
padctl driver non-functional at run-time. However, (a) this driver is not
used yet so no regression can be observed and (b) the next commit will
immediately fix this up.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
show more ...
|
| 095e6583 | 23-Oct-2015 |
Stephen Warren <swarren@nvidia.com> |
ARM: tegra: parameterize common XUSB code
There are some differences between the Tegra124 and Tegra210 XUSB padctl
code. So far, the common XUSB padctl code only supports Tegra124. Add
some paramete
ARM: tegra: parameterize common XUSB code
There are some differences between the Tegra124 and Tegra210 XUSB padctl
code. So far, the common XUSB padctl code only supports Tegra124. Add
some parameters etc. so that it can work for both chips.
This also allows moving Tegra124's process_nodes() into the common file;
something that would have requires edits during the move if done in the
previous commit.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
show more ...
|
| 1680d7b6 | 23-Oct-2015 |
Stephen Warren <swarren@nvidia.com> |
ARM: tegra: create common XUSB padctl driver file
A fair amount of the XUSB padctl driver will be common between Tegra124
and Tegra210. To avoid cut/paste between the two chips, create a new
file th
ARM: tegra: create common XUSB padctl driver file
A fair amount of the XUSB padctl driver will be common between Tegra124
and Tegra210. To avoid cut/paste between the two chips, create a new
file that will contain the common code, and convert the Tegra124 code to
use it. This change doesn't move every last piece of code that can/will be
shared, but rather concentrates on moving code that can be moved with zero
changes, so there are no other diffs mixed in.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
show more ...
|
| 057fd32f | 23-Oct-2015 |
Stephen Warren <swarren@nvidia.com> |
ARM: tegra: clean up XUSB padctl error() calls
This file defines pr_fmt(), so the individual error() calls don't need to
include the prefix in their format strings. Doing so results in duplicate
tex
ARM: tegra: clean up XUSB padctl error() calls
This file defines pr_fmt(), so the individual error() calls don't need to
include the prefix in their format strings. Doing so results in duplicate
text in any error messages. Remove the duplication.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
show more ...
|
| 8e1601d9 | 08-Sep-2015 |
Thierry Reding <treding@nvidia.com> |
ARM: tegra114: Clear IDDQ when enabling PLLC
Enabling a PLL while IDDQ is high. The Linux kernel checks for this
condition and warns about it verbosely, so while this seems to work
fine, fix it up a
ARM: tegra114: Clear IDDQ when enabling PLLC
Enabling a PLL while IDDQ is high. The Linux kernel checks for this
condition and warns about it verbosely, so while this seems to work
fine, fix it up according to the programming guidelines provided in
the Tegra K1 TRM (v02p), Section 5.3.8.1 ("PLLC and PLLC4 Startup
Sequence"). The Tegra114 TRM doesn't contain this information, but
the programming of PLLC is the same on Tegra114 and Tegra124.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
show more ...
|
| aba11d44 | 08-Sep-2015 |
Thierry Reding <treding@nvidia.com> |
ARM: tegra124: Clear IDDQ when enabling PLLC
Enabling a PLL while IDDQ is high. The Linux kernel checks for this
condition and warns about it verbosely, so while this seems to work
fine, fix it up a
ARM: tegra124: Clear IDDQ when enabling PLLC
Enabling a PLL while IDDQ is high. The Linux kernel checks for this
condition and warns about it verbosely, so while this seems to work
fine, fix it up according to the programming guidelines provided in
the Tegra K1 TRM (v02p), Section 5.3.8.1 ("PLLC and PLLC4 Startup
Sequence").
Reported-by: Nicolas Chauvet <kwizart@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
show more ...
|
| 97c02d87 | 20-Aug-2015 |
Thierry Reding <treding@nvidia.com> |
ARM: tegra: clk_m is the architected timer source clock
While clk_m and the oscillator run at the same frequencies on Tegra114
and Tegra124, clk_m is the proper source for the architected timer. On
ARM: tegra: clk_m is the architected timer source clock
While clk_m and the oscillator run at the same frequencies on Tegra114
and Tegra124, clk_m is the proper source for the architected timer. On
more recent Tegra generations, Tegra210 and later, both the oscillator
and clk_m can run at different frequencies. clk_m will be divided down
from the oscillator.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
show more ...
|
| 6c7dc623 | 19-Aug-2015 |
Stephen Warren <swarren@nvidia.com> |
ARM: tegra: fix PLLP frequency calc on T210
AFAIK, for all PLLs on all Tegra SoCs, the primary PLL output frequency
is (input * m) / (n * p). However, PLLP's primary output (pllP_out0) on
T210 is th
ARM: tegra: fix PLLP frequency calc on T210
AFAIK, for all PLLs on all Tegra SoCs, the primary PLL output frequency
is (input * m) / (n * p). However, PLLP's primary output (pllP_out0) on
T210 is the VCO output, and divp is not applied. pllP_out2 does have divp
applied. All other pllP_outN are divided down from pllP_out0. We only
support pllP_out0 in U-Boot at the time of writing.
Fix clock_get_rate() to handle this special case.
This corrects the returned rate for PLLP to be 408MHz rather than 204MHz.
In turn, this causes high enough dividers to be calculated for the various
peripheral clocks that feed off of PLLP. Without this, some peripherals
failed to operate correctly. For instance, one of my SD cards worked
perfectly but an older (presumably slower) card could not be read.
Note that prior to commit 722e000ccd72 "Tegra: PLL: use per-SoC pllinfo
table instead of PLL_DIVM/N/P, etc.", the calculated PLL frequency was
816MHz since the wrong values were being extracted from the PLLP divider
register. This caused overly large peripheral dividers to be calculated,
which while wrong, didn't cause any correctness issues; things simply ran
slower than they could.
Reported-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
show more ...
|