diff options
author | Andrew Bresticker <abrestic@chromium.org> | 2016-05-26 12:41:31 -0400 |
---|---|---|
committer | Thierry Reding <treding@nvidia.com> | 2016-06-30 17:43:17 +0200 |
commit | 15d68e8c2e95e8b62465c7cb3bc642784365ee1b (patch) | |
tree | 4d4fbd41dae32aa51be48aa9a2e31fb02a9a080e /crypto/async_tx | |
parent | 74d3ba0b6f1b22ed02ae16031c741822c9928793 (diff) |
clk: tegra: Initialize UTMI PLL when enabling PLLU
Move the UTMI PLL initialization code form clk-tegra<chip>.c files into
clk-pll.c. UTMI PLL was being configured and set in HW control right
after registration. However, when the clock init_table is processed and
child clks of PLLU are enabled, it will call in and enable PLLU as
well, and initiate SW enabling sequence even though PLLU is already in
HW control. This leads to getting UTMIPLL stuck with a SEQ_BUSY status.
Doing the initialization once during pllu_enable means we configure it
properly into HW control.
A side effect of the commonization/localization of the UTMI PLL init
code, is that it corrects some errors that were present for earlier
generations. For instance, in clk-tegra124.c, it used to have:
#define UTMIP_PLL_CFG1_ENABLE_DLY_COUNT(x) (((x) & 0x1f) << 6)
when the correct shift to use is present in the new version:
#define UTMIP_PLL_CFG1_ENABLE_DLY_COUNT(x) (((x) & 0x1f) << 27)
which matches the Tegra124 TRM register definition.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
[rklein: Merged in some later fixes for potential deadlocks]
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
[treding: coding style bike-shedding, remove unused variable]
Signed-off-by: Thierry Reding <treding@nvidia.com>
Diffstat (limited to 'crypto/async_tx')
0 files changed, 0 insertions, 0 deletions