commit 40db569d6769ffa3864fd1b89616b1a7323568a8 upstream.

There are wrongly set parenthesis in the code that are resulting in a
wrong configuration being programmed for PLLM. The original fix was made
by Danny Huang in the downstream kernel. The patch was tested on Nyan Big
Tegra124 chromebook, PLLM rate changing works correctly now and system
doesn't lock up after changing the PLLM rate due to EMC scaling.

Cc: <stable@vger.kernel.org>
Tested-by: NSteev Klimaszewski <steev@kali.org>
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Acked-By: NPeter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: NStephen Boyd <sboyd@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Turns out latest upstream U-Boot does not configure/enable pll_u which
leaves it at some default rate of 500 kHz:

root@apalis-t30:~# cat /sys/kernel/debug/clk/clk_summary | grep pll_u
       pll_u                  3        3        0      500000          0

Of course this won't quite work leading to the following messages:

[    6.559593] usb 2-1: new full-speed USB device number 2 using tegra-
ehci
[   11.759173] usb 2-1: device descriptor read/64, error -110
[   27.119453] usb 2-1: device descriptor read/64, error -110
[   27.389217] usb 2-1: new full-speed USB device number 3 using tegra-
ehci
[   32.559454] usb 2-1: device descriptor read/64, error -110
[   47.929777] usb 2-1: device descriptor read/64, error -110
[   48.049658] usb usb2-port1: attempt power cycle
[   48.759475] usb 2-1: new full-speed USB device number 4 using tegra-
ehci
[   59.349457] usb 2-1: device not accepting address 4, error -110
[   59.509449] usb 2-1: new full-speed USB device number 5 using tegra-
ehci
[   70.069457] usb 2-1: device not accepting address 5, error -110
[   70.079721] usb usb2-port1: unable to enumerate USB device

Fix this by actually allowing the rate also being set from within
the Linux kernel.
Signed-off-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Switched Tegra210 PLLRE registration to common PLL ops instead of special
PLLRE ops used on previous Tegra chips. The latter ops do not follow
chip specific PLL frequency table, and do not apply chip specific rate
calculation method.

Removed unnecessary default rate setting that duplicates h/w reset
state, and is overwritten by clock initialization, anyway.
Signed-off-by: NAlex Frid <afrid@nvidia.com>
Reviewed-by: NPeter De Schrijver <pdeschrijver@nvidia.com>
Reviewed-by: NJon Mayo <jmayo@nvidia.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Remove from Tegra210 PLLSS registration code sections that
- attempt to set PLL minimum rate (unnecessary, and dangerous if PLL
  is already enabled on boot)
- apply pre-Tegra210 defaults settings
- check IDDQ setting (duplicated with Tegra210 PLLSS check defaults)

Replaced setting of reference clock with check that default oscillator
selection is not changed, and failed registration otherwise as validation
was only done with the oscillator as the reference clock.

Reordered registration, so that PLL initialization is called after
VCOmin adjustment.
Signed-off-by: NAlex Frid <afrid@nvidia.com>
Reviewed-by: NPeter De Schrijver <pdeschrijver@nvidia.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Tegra210 PLLX uses the same sequences than then PLLC instances. So there
is no need to have a special registration function and ops struct for it.
Simplify the code by changing all references to the Tegra210 PLLX
registration function to the Tegra210 PLLC registration function and
avoid duplicate functionality.

Based on work by Alex Frid <afrid@nvidia.com>
Signed-off-by: NPeter De Schrijver <pdeschrijver@nvidia.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Increase delay after PLL IDDQ release to 5us per PLL specifications.

based on work by Alex Frid <afrid@nvidia.com>
Signed-off-by: NPeter De Schrijver <pdeschrijver@nvidia.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Not all fields are read from the hw depending on the PLL type. Make sure
the other fields are 0 by clearing the structure beforehand to prevent
users such as the rate re-calculation code from using bogus values.

Based on work by  Alex Frid <afrid@nvidia.com>
Signed-off-by: NPeter De Schrijver <pdeschrijver@nvidia.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Make sure the pll_ss ops are compiled even when only building for Tegra210.
Signed-off-by: NPeter De Schrijver <pdeschrijver@nvidia.com>
Reviewed-by: NShreshtha Sahu <ssahu@nvidia.com>
Tested-by: NShreshtha Sahu <ssahu@nvidia.com>
Reviewed-by: NJon Mayo <jmayo@nvidia.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

PLL SS was only controlled when setting the PLL rate, not when the PLL itself
is enabled or disabled.
Signed-off-by: NPeter De Schrijver <pdeschrijver@nvidia.com>
Reviewed-by: NJon Mayo <jmayo@nvidia.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

In normal operation pll_u is under hardware control and has a fixed rate
of 480MHz. Hardware will turn on pll_u on whenever any of the XUSB
powerdomains is on. From a software point of view we model this is if
pll_u is always on using a fixed rate clock. However the bootloader
might or might not have configured pll_u this way. So we will check the
current state of pll_u at boot and reconfigure it if required.

There are 3 possiblities at kernel boot:
1) pll_u is under hardware control: do nothing
2) pll_u is under hardware control and enabled: enable hardware control
3) pll_u is disabled: enable pll_u and enable hardware control

In all cases we also check if UTMIPLL is under hardware control at boot
and configure it for hardware control if that is not the case.
The same is done during SC7 resume.

Thanks to Joseph Lo <josephl@nvidia.com> for bug fixes.
Signed-off-by: NPeter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

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: NAndrew Bresticker <abrestic@chromium.org>
[rklein: Merged in some later fixes for potential deadlocks]
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
[treding: coding style bike-shedding, remove unused variable]
Signed-off-by: NThierry Reding <treding@nvidia.com>

Use a new Tegra210 version of the pll_register_pllre function to
allow setting the proper settings for the m and n div fields.

Additionally define PLL_RE_OUT1 on Tegra210.
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
[treding@nvidia.com: define PLLRE_OUT1 register offset]
Signed-off-by: NThierry Reding <treding@nvidia.com>

The PLLE SS coefficients are different between Tegra210 and Tegra114.
Add SoC generation specific versions for Tegra114 and Tegra210 and use
them in their respective ->enable() callbacks.
Signed-off-by: NMark Kuo <mkuo@nvidia.com>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

While enabling PLLE on both Tegra114 and Tegra210, we should be clearing
PLLE_MISC_VREG_BG_CTRL_MASK and PLLE_MISC_VREG_CTRL_MASK not setting
them. This patch fixes both places where we incorrectly set instead of
cleared those bits.
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Software should not disable PLLE if PLLE is already put under hardware
control.
Signed-off-by: NMark Kuo <mkuo@nvidia.com>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Since the ->enable() callback is called with a spinlock held, we cannot
call potentially blocking functions such as clk_get_rate() or
clk_get_parent(), so use the unlocked versions instead.
Signed-off-by: NAndrew Bresticker <abrestic@chromium.org>
[rklein: Adapted from ChromeOS patch, removing pllu_enable cleanup as
it isn't present upstream]
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This fixes a bug in tegra_clk_register_pllss() which mistakenly assume
the IDDQ register is the PLL base address.
Signed-off-by: NBill Huang <bilhuang@nvidia.com>
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This fixes two things.

- Read the correct IDDQ register
- Check the correct IDDQ bit position
Signed-off-by: NBill Huang <bilhuang@nvidia.com>
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Without this change clk_get_rate would return the final output
rather than the VCO output as it would factor in the pdiv when
it shouldn't. This will cause problems for all dividers in the
subtree of the VCO PLL.
Signed-off-by: NAndrew Bresticker <abrestic@chromium.org>
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Implement clock support for Tegra210.
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Add some logic for Spread Spectrum control. It is used in conjuncture
with SDM fractional dividers. SSC has to be disabled when we configure
the divider settings.
Signed-off-by: NBill Huang <bilhuang@nvidia.com>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Add a callback to the pll_params for custom dynamic ramping
functions which can be specified per PLL.
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NBill Huang <bilhuang@nvidia.com>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Add logic which (if specified for a pll) can verify that a PLL is set
to the proper default value and if not can set it. This can be
specified per PLL as each will have different default values.

Based on original work by Aleksandr Frid <afrid@nvidia.com>
Signed-off-by: NBill Huang <bilhuang@nvidia.com>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This code makes use of the SDM fractional divider if present to
constrain the allowable programming range of the PLL divider register
bitfields to take advantage of higher frequency granularity that can
be induced by the SDM divider.

Based on original work by Aleksandr Frid <afrid@nvidia.com>
Signed-off-by: NBill Huang <bilhuang@nvidia.com>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Tegra210 SoC's have 2 PLLs for memory usage. Add plumbing to register
and handle PLLMB.

PLLMB is used to allow switching between 2 PLLM's without having to use
and intermediate backup PLL, as we need to lock the PLL before we can
switch to it.
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

On Tegra210 SoC's, the logic to enable several of the plls is different
from previous generations. Therefore, add registration functions specific
to Tegra210 which will handle them appropriately.
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

PLLM is fixed for Tegra30 up through Tegra114. Starting with Tegra124
PLLM can change rate. Mark PLLM as TEGRA_PLL_FIXED for the generations
where it should be. Modify the check in clk_pll_round_rate() and
clk_pll_recalc_rate() to allow for the non-fixed version to return the
correct rate.

Note that there is no change for Tegra20. This is because PLLM is not
distinguished in that driver, and adding either the PLLM or FIXED_RATE
flags will cause potential problems.

PLLM never supported dynamic ramping. On Tegra20 and Tegra30, there is
no dynamic ramping at all, and on Tegra114, Tegra124 and Tegra132, only
PLLX and PLLC support dynamic ramping, so we can go ahead and remove the
specialized pllm_ops.
Signed-off-by: NDanny Huang <dahuang@nvidia.com>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This removes the conversion from pdiv to hw, which is already taken
care of by _get_table_rate before this code is run. This avoids
incorrectly converting pdiv to hw twice and getting the wrong hw value.

Also set the input_rate in the freq cfg in _calc_dynamic_ramp_rate while
setting all the other fields.

In order to prevent regressions on earlier SoC generations, all of the
frequency tables need to be updated so that they contain the actual
divider values. If they contain hardware values these would be converted
to hardware values again, yielding the wrong value.
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
[treding@nvidia.com: fix regressions on earlier SoC generations]
Signed-off-by: NThierry Reding <treding@nvidia.com>

If a PLL has a reset_reg specified, properly handle that in the
enable/disable logic paths.
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NBill Huang <bilhuang@nvidia.com>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

For Tegra210, the logic to calculate out-of-table rates is different
from previous generations. Add callbacks that can be overridden to
allow for different ways of calculating rates. Default to
_cal_rate when not specified.

This patch also includes a new flag which is used to set which method
of fixed_mdiv calculation is used. The new method for calculating the
fixed divider value for M can be more accurate especially when
fractional dividers are in play. This allows for older chipsets to use
the existing logic and new generations to use a newer version which
may work better for them.

Based on original work by Aleksandr Frid <afrid@nvidia.com>
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This adds logic for taking SDM_DIN (Sigma Delta Modulator) setting into
the equation to calculate the effective N value for PLL which supports
fractional divider.

The effective N = NDIV + 1/2 + SDM_DIN/2^13, where NDIV is the integer
feedback divider.
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

SoC specific drivers should define the appropriate flags for each
PLL rather than relying on the registration functions to automatically
set flags on their behalf. This will properly allow for changes between
SoC generations where flags might be different and allow sharing the
same logic functions.
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Swap out the generic WARN_ON with a WARN which gives more information
about what is happening.
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Instead of having multiple similar wrapper functions for
_clk_pll_[enable|disable], we can simplify it to single
wrappers and use checks to avoid the logic we don't want to use.
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Create a wrapper interface to make use of the existing
clk_pll_wait_for_lock. This will be useful for implementations
of callbacks in Tegra SoC specific clock drivers.
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This is static data that is never modified, so make it const.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Use unsigned int for loop variables that can never become negative and
remove a couple of gratuitous blank lines. Also use single spaces around
operators and use a single space instead of a tab to separate comments
from code.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Use the provider based method to get a clock's name so that we
can get rid of the clk member in struct clk_hw one day. Mostly
converted with the following coccinelle script.

@@
struct clk_hw *E;
@@

-__clk_get_name(E->clk)
+clk_hw_get_name(E)
Acked-by: NHeiko Stuebner <heiko@sntech.de>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Peter De Schrijver <pdeschrijver@nvidia.com>
Cc: Prashant Gaikwad <pgaikwad@nvidia.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: NThierry Reding <treding@nvidia.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: NAndrew Bresticker <abrestic@chromium.org>
Cc: Ezequiel Garcia <ezequiel.garcia@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Kevin Cernekee <cernekee@chromium.org>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Cc: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-tegra@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

We're removing struct clk from the clk provider API, so switch
this code to using the clk_hw based provider APIs.

Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Clock provider drivers generally shouldn't include clk.h because
it's the consumer API. Only include clk.h in files that are using
it. Also add in a clkdev.h include that was missing in a file
using clkdev APIs.

Cc: Peter De Schrijver <pdeschrijver@nvidia.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>