clk: tegra: Support runtime PM and power domain

The Clock-and-Reset controller resides in a core power domain on NVIDIA
Tegra SoCs. In order to support voltage scaling of the core power domain,
we

clk: tegra: Support runtime PM and power domain

The Clock-and-Reset controller resides in a core power domain on NVIDIA
Tegra SoCs. In order to support voltage scaling of the core power domain,
we hook up DVFS-capable clocks to the core GENPD for managing of the
GENPD's performance state based on the clock changes.

Some clocks don't have any specific physical hardware unit that backs
them, like root PLLs and system clock and they have theirs own voltage
requirements. This patch adds new clk-device driver that backs the clocks
and provides runtime PM functionality for them. A virtual clk-device is
created for each such DVFS-capable clock at the clock's registration time
by the new tegra_clk_register() helper. Driver changes clock's device
GENPD performance state based on clk-rate notifications.

In result we have this sequence of events:

1. Clock driver creates virtual device for selective clocks, enables
runtime PM for the created device and registers the clock.
2. Clk-device driver starts to listen to clock rate changes.
3. Something changes clk rate or enables/disables clk.
4. CCF core propagates the change through the clk tree.
5. Clk-device driver gets clock rate-change notification or GENPD core
handles prepare/unprepare of the clock.
6. Clk-device driver changes GENPD performance state on clock rate
change.
7. GENPD driver changes voltage regulator state change.
8. The regulator state is committed to hardware via I2C.

We rely on fact that DVFS is not needed for Tegra I2C and that Tegra I2C
driver already keeps clock always-prepared. Hence I2C subsystem stays
independent from the clk power management and there are no deadlock spots
in the sequence.

Currently all clocks are registered very early during kernel boot when the
device driver core isn't available yet. The clk-device can't be created
at that time. This patch splits the registration of the clocks in two
phases:

1. Register all essential clocks which don't use RPM and are needed
during early boot.

2. Register at a later boot time the rest of clocks.

This patch adds power management support for Tegra20 and Tegra30 clocks.

Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Peter Geis <pgwipeout@gmail.com> # Ouya T30
Tested-by: Paul Fertser <fercerpav@gmail.com> # PAZ00 T20
Tested-by: Nicolas Chauvet <kwizart@gmail.com> # PAZ00 T20 and TK1 T124
Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

show more ...

clk: tegra: Don't allow zero clock rate for PLLs

Zero clock rate doesn't make sense for PLLs and tegra-clk driver enters
into infinite loop on trying to calculate PLL parameters for zero rate.
Make

clk: tegra: Don't allow zero clock rate for PLLs

Zero clock rate doesn't make sense for PLLs and tegra-clk driver enters
into infinite loop on trying to calculate PLL parameters for zero rate.
Make code to error out if requested rate is zero.

Originally this trouble was found by Robert Yang while he was trying to
bring up upstream kernel on Samsung Galaxy Tab, which happened due to a
bug in Tegra DRM driver that erroneously sets PLL rate to zero. This
issues came over again recently during of kernel bring up on ASUS TF700T.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

show more ...

clk: tegra: Ensure that PLLU configuration is applied properly

The PLLU (USB) consists of the PLL configuration itself and configuration
of the PLLU outputs. The PLLU programming is inconsistent on

clk: tegra: Ensure that PLLU configuration is applied properly

The PLLU (USB) consists of the PLL configuration itself and configuration
of the PLLU outputs. The PLLU programming is inconsistent on T30 vs T114,
where T114 immediately bails out if PLLU is enabled and T30 re-enables
a potentially already enabled PLL (left after bootloader) and then fully
reprograms it, which could be unsafe to do. The correct way should be to
skip enabling of the PLL if it's already enabled and then apply
configuration to the outputs. This patch doesn't fix any known problems,
it's a minor improvement.

Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

show more ...

clk: tegra: Don't enable PLLE HW sequencer at init

PLLE hardware power sequencer references PEX/SATA UPHY PLL hardware
power sequencers' output to enable/disable PLLE. PLLE hardware power
sequencer

clk: tegra: Don't enable PLLE HW sequencer at init

PLLE hardware power sequencer references PEX/SATA UPHY PLL hardware
power sequencers' output to enable/disable PLLE. PLLE hardware power
sequencer has to be enabled only after PEX/SATA UPHY PLL's sequencers
are enabled.

Signed-off-by: JC Kuo <jckuo@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>

show more ...

clk: tegra: Ensure that PLLU configuration is applied properly

[ Upstream commit a7196048cd5168096c2c4f44a3939d7a6dcd06b9 ]

The PLLU (USB) consists of the PLL configuration itself and configuration

clk: tegra: Ensure that PLLU configuration is applied properly

[ Upstream commit a7196048cd5168096c2c4f44a3939d7a6dcd06b9 ]

The PLLU (USB) consists of the PLL configuration itself and configuration
of the PLLU outputs. The PLLU programming is inconsistent on T30 vs T114,
where T114 immediately bails out if PLLU is enabled and T30 re-enables
a potentially already enabled PLL (left after bootloader) and then fully
reprograms it, which could be unsafe to do. The correct way should be to
skip enabling of the PLL if it's already enabled and then apply
configuration to the outputs. This patch doesn't fix any known problems,
it's a minor improvement.

Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

clk: tegra: Always program PLL_E when enabled

Commit bff1cef5f23a ("clk: tegra: Don't enable already enabled PLLs")
added checks to avoid enabling PLLs that have already been enabled by
the bootload

clk: tegra: Always program PLL_E when enabled

Commit bff1cef5f23a ("clk: tegra: Don't enable already enabled PLLs")
added checks to avoid enabling PLLs that have already been enabled by
the bootloader. However, the PLL_E configuration inherited from the
bootloader isn't necessarily the one that is needed for the kernel.

This can cause SATA to fail like this:

[ 5.310270] phy phy-sata.6: phy poweron failed --> -110
[ 5.315604] tegra-ahci 70027000.sata: failed to power on AHCI controller: -110
[ 5.323022] tegra-ahci: probe of 70027000.sata failed with error -110

Fix this by always programming the PLL_E. This ensures that any mis-
configuration by the bootloader will be overwritten by the kernel.

Fixes: bff1cef5f23a ("clk: tegra: Don't enable already enabled PLLs")
Reported-by: LABBE Corentin <clabbe@baylibre.com>
Tested-by: Corentin Labbe <clabbe@baylibre.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

show more ...

clk: tegra: Capitalization fixes

HW, XUSB and PLL are abbreviations and should be all-uppercase.

Signed-off-by: Thierry Reding <treding@nvidia.com>

clk: tegra: pll: Improve PLLM enable-state detection

Power Management Controller (PMC) can override the PLLM clock settings,
including the enable-state. Although PMC could only act as a second level

clk: tegra: pll: Improve PLLM enable-state detection

Power Management Controller (PMC) can override the PLLM clock settings,
including the enable-state. Although PMC could only act as a second level
gate, meaning that PLLM needs to be enabled by the Clock and Reset
Controller (CaR) anyways if we want it to be enabled. Hence, when PLLM is
overridden by PMC, it needs to be enabled by CaR and ungated by PMC in
order to be functional. Please note that this patch doesn't fix any known
problem, and thus, it's merely a minor improvement.

Link: https://lore.kernel.org/linux-arm-kernel/20191210120909.GA2703785@ulmo/T/
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20200709172057.13951-1-digetx@gmail.com
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>

show more ...

clk: tegra: pll: Add pre/post rate-change hooks

There is a need to temporarily re-parent CCLK away from PLLX if PLLX's
rate is about to change. The newly introduced PLL pre/post rate-change
hooks al

clk: tegra: pll: Add pre/post rate-change hooks

There is a need to temporarily re-parent CCLK away from PLLX if PLLX's
rate is about to change. The newly introduced PLL pre/post rate-change
hooks allow to handle such case.

Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Tested-by: Peter Geis <pgwipeout@gmail.com>
Tested-by: Marcel Ziswiler <marcel@ziswiler.com>
Tested-by: Jasper Korten <jja2000@gmail.com>
Tested-by: David Heidelberg <david@ixit.cz>
Tested-by: Nicolas Chauvet <kwizart@gmail.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

show more ...

clk: tegra: pll: Save and restore pll context

This patch implements save and restore of PLL context.

During system suspend, core power goes off and looses the settings
of the Tegra CAR controller r

clk: tegra: pll: Save and restore pll context

This patch implements save and restore of PLL context.

During system suspend, core power goes off and looses the settings
of the Tegra CAR controller registers.

So during resume, pll context is restored based on cached rate
and state.

Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

show more ...

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 201

Based on 1 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms and c

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 201

Based on 1 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms and conditions of the gnu general public license
version 2 as published by the free software foundation this program
is distributed in the hope it will be useful but without any
warranty without even the implied warranty of merchantability or
fitness for a particular purpose see the gnu general public license
for more details you should have received a copy of the gnu general
public license along with this program if not see http www gnu org
licenses

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

has been chosen to replace the boilerplate/reference in 228 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Steve Winslow <swinslow@gmail.com>
Reviewed-by: Richard Fontana <rfontana@redhat.com>
Reviewed-by: Alexios Zavras <alexios.zavras@intel.com>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190528171438.107155473@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

clk: tegra: Fix PLLM programming on Tegra124+ when PMC overrides divider

There are wrongly set parenthesis in the code that are resulting in a
wrong configuration being programmed for PLLM. The orig

clk: tegra: Fix PLLM programming on Tegra124+ when PMC overrides divider

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: Steev Klimaszewski <steev@kali.org>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Acked-By: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>

show more ...

clk: tegra: Don't enable already enabled PLLs

Initially Common Clock Framework isn't aware of the clock-enable status,
this results in enabling of clocks that were enabled by bootloader. This
is not

clk: tegra: Don't enable already enabled PLLs

Initially Common Clock Framework isn't aware of the clock-enable status,
this results in enabling of clocks that were enabled by bootloader. This
is not a big deal for a regular clock-gates, but for PLL's it may have
some unpleasant consequences. Thus re-enabling PLLX (the main CPU parent
clock) may result in extra long period of PLL re-locking.

Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>

show more ...

clk: tegra: Return the exact clock rate from clk_round_rate

The current behavior is that clk_round_rate would return the same clock
rate passed to it for valid PLL configurations. This change will r

clk: tegra: Return the exact clock rate from clk_round_rate

The current behavior is that clk_round_rate would return the same clock
rate passed to it for valid PLL configurations. This change will return
the exact rate the PLL will provide in accordance with clk API.

Signed-off-by: Robert Yang <decatf@gmail.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>

show more ...

clk: tegra: Fix pll_u rate configuration

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/c

clk: tegra: Fix pll_u rate configuration

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: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

show more ...

clk: tegra: Fix T210 PLLRE registration

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 P

clk: tegra: Fix T210 PLLRE registration

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: Alex Frid <afrid@nvidia.com>
Reviewed-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Reviewed-by: Jon Mayo <jmayo@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>

show more ...

clk: tegra: Update T210 PLLSS (D2/DP) registration

Remove from Tegra210 PLLSS registration code sections that
- attempt to set PLL minimum rate (unnecessary, and dangerous if PLL
is already enable

clk: tegra: Update T210 PLLSS (D2/DP) registration

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: Alex Frid <afrid@nvidia.com>
Reviewed-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>

show more ...

clk: tegra: Re-factor T210 PLLX registration

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.
Simpli

clk: tegra: Re-factor T210 PLLX registration

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: Peter De Schrijver <pdeschrijver@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>

show more ...

clk: tegra: change post IDDQ release delay to 5us

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

based on work by Alex Frid <afrid@nvidia.com>

Signed-off-by: Peter De Schrijv

clk: tegra: change post IDDQ release delay to 5us

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

based on work by Alex Frid <afrid@nvidia.com>

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

show more ...

clk: tegra: Init cfg structure in _get_pll_mnp

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 s

clk: tegra: Init cfg structure in _get_pll_mnp

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: Peter De Schrijver <pdeschrijver@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>

show more ...

clk: tegra: Enable PLL_SS for Tegra210

Make sure the pll_ss ops are compiled even when only building for Tegra210.

Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Reviewed-by: Shreshtha

clk: tegra: Enable PLL_SS for Tegra210

Make sure the pll_ss ops are compiled even when only building for Tegra210.

Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Reviewed-by: Shreshtha Sahu <ssahu@nvidia.com>
Tested-by: Shreshtha Sahu <ssahu@nvidia.com>
Reviewed-by: Jon Mayo <jmayo@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>

show more ...

clk: tegra: fix SS control on PLL enable/disable

PLL SS was only controlled when setting the PLL rate, not when the PLL itself
is enabled or disabled.

Signed-off-by: Peter De Schrijver <pdeschrijve

clk: tegra: fix SS control on PLL enable/disable

PLL SS was only controlled when setting the PLL rate, not when the PLL itself
is enabled or disabled.

Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Reviewed-by: Jon Mayo <jmayo@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>

show more ...

clk: tegra: Rework pll_u

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 softwa

clk: tegra: Rework pll_u

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: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

show more ...

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

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>

show more ...

clk: tegra: Fix pllre Tegra210 and add pll_re_out1

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

clk: tegra: Fix pllre Tegra210 and add pll_re_out1

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: Rhyland Klein <rklein@nvidia.com>
[treding@nvidia.com: define PLLRE_OUT1 register offset]
Signed-off-by: Thierry Reding <treding@nvidia.com>

show more ...