summaryrefslogtreecommitdiff
path: root/arch/arm/mach-tegra/clock.c
Commit message (Collapse)AuthorAgeLines
* ARM: tegra: Implement clk_mThierry Reding2015-09-16-0/+10
| | | | | | | | | | On currently supported SoCs, clk_m always runs at the same frequency as the oscillator input. However newer SoC generations such as Tegra210 no longer have that restriction. Prepare for that by separating clk_m from the oscillator clock and allow SoC code to override the clk_m rate. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* ARM: tegra: fix PLLP frequency calc on T210Stephen Warren2015-09-16-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* of: clean up OF_CONTROL ifdef conditionalsMasahiro Yamada2015-08-18-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We have flipped CONFIG_SPL_DISABLE_OF_CONTROL. We have cleansing devices, $(SPL_) and CONFIG_IS_ENABLED(), so we are ready to clear away the ugly logic in include/fdtdec.h: #ifdef CONFIG_OF_CONTROL # if defined(CONFIG_SPL_BUILD) && !defined(SPL_OF_CONTROL) # define OF_CONTROL 0 # else # define OF_CONTROL 1 # endif #else # define OF_CONTROL 0 #endif Now CONFIG_IS_ENABLED(OF_CONTROL) is the substitute. It refers to CONFIG_OF_CONTROL for U-boot proper and CONFIG_SPL_OF_CONTROL for SPL. Also, we no longer have to cancel CONFIG_OF_CONTROL in include/config_uncmd_spl.h and scripts/Makefile.spl. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
* tegra: Correct logic for reading pll_misc in clock_start_pll()Simon Glass2015-08-13-12/+21
| | | | | | | | | | | | The logic for simple PLLs on T124 was broken by this commit: 722e000c Tegra: PLL: use per-SoC pllinfo table instead of PLL_DIVM/N/P, etc. Correct it by reading from the same pll_misc register that it writes to and adding an entry for the DP PLL in the pllinfo table. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* Tegra: PLL: use per-SoC pllinfo table instead of PLL_DIVM/N/P, etc.Tom Warren2015-08-05-67/+41
| | | | | | | | | | | | | Added PLL variables (dividers mask/shift, lock enable/detect, etc.) to new pllinfo struct for each Soc/PLL. PLLA/C/D/E/M/P/U/X. Used pllinfo struct in all clock functions, validated on T210. Should be equivalent to prior code on T124/114/30/20. Thanks to Marcel Ziswiler for corrections to the T20/T30 values. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* Tegra: clocks: Add 38.4MHz OSC support for T210 useTom Warren2015-08-05-4/+9
| | | | | | | | | | | | | | | Added 38.4MHz/48MHz entries to pll_x_table for CPU PLL. Needs to be measured - should be close to 700MHz (1.4G/2). Note that some freqs aren't in the PLLU table in T210 TRM (13, 26MHz), so I used the 12MHz table entry for them. They shouldn't be selected since they're not viable T210 OSC freqs. Since there are now 2 new OSC defines, all tables (pll_x_table, PLLU) had to increase by two entries, but since 38.4/48MHz are not viable osc freqs on T20/30/114, etc, they're just set to 0. Signed-off-by: Tom Warren <twarren@nvidia.com>
* ARM: Tegra210: Add support to common Tegra source/config filesTom Warren2015-07-28-2/+28
| | | | | | | | | | | Derived from Tegra124, modified as appropriate during T210 board bringup. Cleaned up debug statements to conserve string space, too. This also adds misc 64-bit changes from Thierry Reding/Stephen Warren. Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
* ARM: tegra: Initialize timer earlierThierry Reding2015-07-28-6/+0
| | | | | | | | | | | | | A subsequent patch will enable the use of the architected timer on ARMv8. Doing so implies that udelay() will be backed by this timer implementation, and hence the architected timer must be ready when udelay() is first called. The first time udelay() is used is while resetting the debug UART, which happens very early. Make sure that arch_timer_init() is called before that. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* tegra: clock: Adjust PLL access to avoid a warningSimon Glass2015-06-09-2/+5
| | | | | | | | A harmless but confusing warning is displayed when looking up the DisplayPort PLL. Correct this. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* tegra: clock: Support enabling external clocksSimon Glass2015-06-09-0/+17
| | | | | | | Add a simple function to enable external clocks. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* tegra124: clock: Add display clocks and functionsSimon Glass2015-05-13-0/+2
| | | | | | | | Add functions to provide access to the display clocks on Tegra124 including setting the clock rate for an EDP display. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* tegra: clock: Split the clock source code into a separate functionSimon Glass2015-05-13-22/+29
| | | | | | | | | Create a function which sets the source clock for a peripheral, given the number of mux bits to adjust. This can then be used more generally. For now, don't export it. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* tegra: clock: Add checking for invalid clock IDsSimon Glass2015-05-13-4/+26
| | | | | | | | | The get_pll() function can do the wrong thing if passed values that are out of range. Add checks for this and add a function which can return a 'simple' PLL. This can be defined by SoCs with their own clocks. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* ARM: tegra: support running in non-secure modeStephen Warren2015-03-04-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the CPU is in non-secure (NS) mode (when running U-Boot under a secure monitor), certain actions cannot be taken, since they would need to write to secure-only registers. One example is configuring the ARM architectural timer's CNTFRQ register. We could support this in one of two ways: 1) Compile twice, once for secure mode (in which case anything goes) and once for non-secure mode (in which case certain actions are disabled). This complicates things, since everyone needs to keep track of different U-Boot binaries for different situations. 2) Detect NS mode at run-time, and optionally skip any impossible actions. This has the advantage of a single U-Boot binary working in all cases. (2) is not possible on ARM in general, since there's no architectural way to detect secure-vs-non-secure. However, there is a Tegra-specific way to detect this. This patches uses that feature to detect secure vs. NS mode on Tegra, and uses that to: * Skip the ARM arch timer initialization. * Set/clear an environment variable so that boot scripts can take different action depending on which mode the CPU is in. This might be something like: if CPU is secure: load secure monitor code into RAM. boot secure monitor. secure monitor will restart (a new copy of) U-Boot in NS mode. else: execute normal boot process Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* ARM: tegra: collect SoC sources into mach-tegraMasahiro Yamada2015-02-21-0/+669
This commit moves files as follows: arch/arm/cpu/arm720t/tegra20/* -> arch/arm/mach-tegra/tegra20/* arch/arm/cpu/arm720t/tegra30/* -> arch/arm/mach-tegra/tegra30/* arch/arm/cpu/arm720t/tegra114/* -> arch/arm/mach-tegra/tegra114/* arch/arm/cpu/arm720t/tegra124* -> arch/arm/mach-tegra/tegra124/* arch/arm/cpu/arm720t/tegra-common/* -> arch/arm/mach-tegra/* arch/arm/cpu/armv7/tegra20/* -> arch/arm/mach-tegra/tegra20/* arch/arm/cpu/armv7/tegra30/* -> arch/arm/mach-tegra/tegra30/* arch/arm/cpu/armv7/tegra114/* -> arch/arm/mach-tegra/tegra114/* arch/arm/cpu/armv7/tegra124/* -> arch/arm/mach-tegra/tegra124/* arch/arm/cpu/armv7/tegra-common/* -> arch/arm/mach-tegra/* arch/arm/cpu/tegra20-common/* -> arch/arm/mach-tegra/tegra20/* arch/arm/cpu/tegra30-common/* -> arch/arm/mach-tegra/tegra30/* arch/arm/cpu/tegra114-common/* -> arch/arm/mach-tegra/tegra114/* arch/arm/cpu/tegra124-common/* -> arch/arm/mach-tegra/tegra124/* arch/arm/cpu/tegra-common/* -> arch/arm/mach-tegra/* Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Tested-by: Simon Glass <sjg@chromium.org> [ on nyan-big ] Cc: Stephen Warren <swarren@nvidia.com> Cc: Tom Warren <twarren@nvidia.com>