linux.git/drivers/clk/tegra, branch v4.12 Linux kernel source tree clk: tegra: Don't reset PLL-CX if it is already enabled 2017-04-04T14:06:05+00:00 Jon Hunter jonathanh@nvidia.com 2017-03-27T11:01:05+00:00 1116d5a7aff205b6d9879a6458788cac20d0cdf3 Commit 8dce89a1c2cf ("clk: tegra: Don't warn for PLL defaults unnecessarily") changed the tegra210_pllcx_set_defaults() function causing the PLL to always be reset regardless of whether it is in-use. This function was changed so that resetting of the PLL will only be skipped if the PLL is enabled AND 'pllcx->params->defaults_set' is not true. However, the 'pllcx->params->defaults_set' is always true and hence, the PLL is now always reset. This causes the boot to fail on the Tegra210 Smaug where the PLL is already enabled and in-use. Fix this by only resetting the PLL if not in-use and only printing the warning that the defaults are not set after we have checked the default settings. Fixes: 8dce89a1c2cf ("clk: tegra: Don't warn for PLL defaults unnecessarily") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Acked-By: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> 
Commit 8dce89a1c2cf ("clk: tegra: Don't warn for PLL defaults
unnecessarily") changed the tegra210_pllcx_set_defaults() function
causing the PLL to always be reset regardless of whether it is in-use.
This function was changed so that resetting of the PLL will only be
skipped if the PLL is enabled AND 'pllcx->params->defaults_set' is not
true. However, the 'pllcx->params->defaults_set' is always true and
hence, the PLL is now always reset. This causes the boot to fail on the
Tegra210 Smaug where the PLL is already enabled and in-use. Fix this by
only resetting the PLL if not in-use and only printing the warning that
the defaults are not set after we have checked the default settings.

Fixes: 8dce89a1c2cf ("clk: tegra: Don't warn for PLL defaults unnecessarily")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Acked-By: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
clk: tegra: Add missing Tegra210 clocks 2017-04-04T14:03:00+00:00 Peter De Schrijver pdeschrijver@nvidia.com 2017-03-22T14:23:16+00:00 88da44c5edb93d58f704fb9ea21962ca357d06a1 iqc1, iqc2, tegra_clk_pll_a_out_adsp, tegra_clk_pll_a_out0_out_adsp, adsp and adsp neon were not modelled. dp2 wasn't modelled for Tegra210. Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> 
iqc1, iqc2, tegra_clk_pll_a_out_adsp, tegra_clk_pll_a_out0_out_adsp, adsp
and adsp neon were not modelled. dp2 wasn't modelled for Tegra210.

Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
clk: tegra: Propagate clk_out_x rate to parent 2017-04-04T14:00:28+00:00 Alex Frid afrid@nvidia.com 2017-03-22T13:38:19+00:00 a63b6186f932e367133b271714d56fd8abaada7a Given that externx can only be used as a parent for clk_out_x, it makes sense to propagate requests to make clk_out_x easier to handle. Signed-off-by: Alex Frid <afrid@nvidia.com> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> 
Given that externx can only be used as a parent for clk_out_x, it makes
sense to propagate requests to make clk_out_x easier to handle.

Signed-off-by: Alex Frid <afrid@nvidia.com>
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
clk: tegra: Fix build warnings on Tegra20/Tegra30 2017-03-20T16:14:14+00:00 Thierry Reding treding@nvidia.com 2017-03-20T16:14:14+00:00 39133505caf993c2d61c7adc8cab753e8a0b815d The recent conversion of proper const usage was only partial and didn't include Tegra20 and Tegra30 support. Fix that up. Signed-off-by: Thierry Reding <treding@nvidia.com> 
The recent conversion of proper const usage was only partial and didn't
include Tegra20 and Tegra30 support. Fix that up.

Signed-off-by: Thierry Reding <treding@nvidia.com>
clk: tegra: Mark TEGRA210_CLK_DBGAPB as always on 2017-03-20T14:16:46+00:00 Peter De Schrijver pdeschrijver@nvidia.com 2017-02-28T15:19:50+00:00 bea1baa1e7722c82631fa263653c1279002dd273 This is needed to make the JTAG debugging interface work. Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com> [treding@nvidia.com: add TODO comment] Signed-off-by: Thierry Reding <treding@nvidia.com> 
This is needed to make the JTAG debugging interface work.

Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
[treding@nvidia.com: add TODO comment]
Signed-off-by: Thierry Reding <treding@nvidia.com>
clk: tegra: Add SATA seq input control 2017-03-20T13:26:03+00:00 Peter De Schrijver pdeschrijver@nvidia.com 2017-03-15T15:42:05+00:00 59af78d78db8bde6a63e09772aa44192f772fa96 This will be used by the powergating driver to ensure proper sequencer state when the SATA domain is powergated. Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> 
This will be used by the powergating driver to ensure proper sequencer
state when the SATA domain is powergated.

Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
clk: tegra: Add Tegra210 special resets 2017-03-20T13:20:42+00:00 Peter De Schrijver pdeschrijver@nvidia.com 2017-03-15T12:59:32+00:00 68d724cedcca8ab86eee824682f7da0af5e6e50d Tegra210 has 2 special resets which don't follow the normal pattern: DVCO and ADSP. Add them in this patch. Changelog: v2: add DT bindings file Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> 
Tegra210 has 2 special resets which don't follow the normal pattern:
DVCO and ADSP. Add them in this patch.

Changelog:

v2: add DT bindings file

Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
clk: tegra: Rework pll_u 2017-03-20T13:18:30+00:00 Peter De Schrijver pdeschrijver@nvidia.com 2017-03-14T14:12:49+00:00 e745f992cf4b030ef73c5cdceecd03d9d3c727e9 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> 
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>
clk: tegra: Implement reset control reset 2017-03-20T13:15:31+00:00 Mikko Perttunen mperttunen@nvidia.com 2017-03-02T14:16:16+00:00 4236e752f19d4dae372336859a18ca8a5bed9374 For completeness, also implement this reset framework API for Tegra. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Reviewed-by: Peter De Schrijver <pdeschrijver@nvidia.com> Reviewed-by: Arto Merilainen <amerilainen@nvidia.com> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> 
For completeness, also implement this reset framework API for Tegra.

Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Reviewed-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Reviewed-by: Arto Merilainen <amerilainen@nvidia.com>
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
clk: tegra: Fix disable unused for clocks sharing enable bit 2017-03-20T13:13:52+00:00 Peter De Schrijver pdeschrijver@nvidia.com 2017-03-02T13:22:05+00:00 9619dba8325fce098bbc9ee2911d1b0150fec0c9 In case 2 clocks share an enable bit and one of them is enabled by a driver and the other one is not, CCF will think it's enabled because it will only look at the HW state. Therefore it will disable the clock and thus also disable the other clock which was enabled. Solve this by reading the initial state of the enable bit and incrementing the refcount if it's set. Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> 
In case 2 clocks share an enable bit and one of them is enabled by a
driver and the other one is not, CCF will think it's enabled because it
will only look at the HW state. Therefore it will disable the clock and
thus also disable the other clock which was enabled. Solve this by
reading the initial state of the enable bit and incrementing the
refcount if it's set.

Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>