summaryrefslogtreecommitdiff
path: root/examples
diff options
context:
space:
mode:
authorStephen Warren <swarren@nvidia.com>2014-05-08 09:33:45 -0600
committerTom Warren <twarren@nvidia.com>2014-05-13 10:41:32 -0700
commit2364e151e432b4ccf32dc9e6147121253d4ff86d (patch)
tree9cf273d4dea39e550202799b006a14aff81a01da /examples
parent3365479ce78a07df7ca281eb0b193bf269c17c6e (diff)
downloadu-boot-imx-2364e151e432b4ccf32dc9e6147121253d4ff86d.zip
u-boot-imx-2364e151e432b4ccf32dc9e6147121253d4ff86d.tar.gz
u-boot-imx-2364e151e432b4ccf32dc9e6147121253d4ff86d.tar.bz2
ARM: tegra: use a CPU freq that all SKUs can support
U-Boot on Tegra30 currently selects a main CPU frequency that cannot be supported at all on some SKUs, and needs higher VDD_CPU/VDD_CORE values on some others. This can result in unreliable operation of the main CPUs. Resolve this by switching to a CPU frequency that can be supported by any SKU. According to the following link, the maximum supported CPU frequency of the slowest Tegra30 SKU is 600MHz: repo http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=summary branch l4t/l4t-r16-r2 path arch/arm/mach-tegra/tegra3_dvfs.c table cpu_dvfs_table[] According to that same table, the minimum VDD_CPU required to operate at that frequency across all SKUs is 1.007V. Given the adjustment resolution of the TPS65911 PMIC that's used on all Tegra30-based boards we support, we'll end up using 1.0125V instead. At that VDD_CPU, tegra3_get_core_floor_mv() in that same file dictates that VDD_CORE must be at least 1.2V on all SKUs. According to tegra_core_speedo_mv() (in tegra3_speedo.c in the same source tree), that voltage is safe for all SKUs. An alternative would be to port much of the code from tegra3_dvfs.c and tegra3_speedo.c in the kernel tree mentioned above. That's more work than I want to take on right now. While all the currently supported boards use the same regulator chip for VDD_CPU, different types of regulators are used for VDD_CORE. Hence, we add some small conditional code to select how VDD_CORE is programmed. If this becomes more complex in the future as new boards are added, or we end up adding code to detect the SoC SKU and dynamically determine the allowed frequency and required voltages, we should probably make this a runtime call into a function provided by the board file and/or relevant PMIC driver. Cc: Alban Bedel <alban.bedel@avionic-design.de> Cc: Marcel Ziswiler <marcel@ziswiler.com> Cc: Bard Liao <bardliao@realtek.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Diffstat (limited to 'examples')
0 files changed, 0 insertions, 0 deletions