linux-toradex.git/drivers/clk, branch v4.4.160

clk: imx6ul: fix missing of_node_put()

2018-09-26T06:35:05+00:00

[ Upstream commit 11177e7a7aaef95935592072985526ebf0a3df43 ]

of_find_compatible_node() is returning a device node with refcount
incremented and must be explicitly decremented after the last use
which is right after the us in of_iomap() here.

Signed-off-by: Nicholas Mc Guire 
Fixes: 787b4271a6a0 ("clk: imx: add imx6ul clk tree support")
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

clk: tegra: Fix PLL_U post divider and initial rate on Tegra30

2018-07-25T08:18:32+00:00

commit 797097301860c64b63346d068ba4fe4992bd5021 upstream.

The post divider value in the frequency table is wrong as it would lead
to the PLL producing an output rate of 960 MHz instead of the desired
480 MHz. This wasn't a problem as nothing used the table to actually
initialize the PLL rate, but the bootloader configuration was used
unaltered.

If the bootloader does not set up the PLL it will fail to come when used
under Linux. To fix this don't rely on the bootloader, but set the
correct rate in the clock driver.

Signed-off-by: Lucas Stach 
Signed-off-by: Thierry Reding 
[jonathanh@nvidia.com: Back-ported to stable v4.4.y]
Signed-off-by: Jon Hunter 
Signed-off-by: Greg Kroah-Hartman

clk: samsung: exynos3250: Fix PLL rates

2018-05-30T05:49:16+00:00

[ Upstream commit a8321e7887410a2b2e80ab89d1ef7b30562658ea ]

Rates declared in PLL rate tables should match exactly rates calculated
from PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate
will return 393216003. If we now attempt to set rate of a PLL's child divider
clock to 393216000/2 its rate will be 131072001, rather than 196608000.
That is, the divider will be set to 3 instead of 2, because 393216003/2 is
greater than 196608000.

To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.

In this patch an erroneous P value for 74176002 output frequency is also
corrected.

Signed-off-by: Andrzej Hajda 
Acked-by: Chanwoo Choi 
Acked-by: Tomasz Figa 
Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

clk: samsung: exynos5250: Fix PLL rates

2018-05-30T05:49:16+00:00

[ Upstream commit 2ac051eeabaa411ef89ae7cd5bb8e60cb41ad780 ]

Rates declared in PLL rate tables should match exactly rates calculated
from PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate
will return 393216003. If we now attempt to set rate of a PLL's child divider
clock to 393216000/2 its rate will be 131072001, rather than 196608000.
That is, the divider will be set to 3 instead of 2, because 393216003/2 is
greater than 196608000.

To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.

Signed-off-by: Andrzej Hajda 
Acked-by: Chanwoo Choi 
Acked-by: Tomasz Figa 
Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

clk: samsung: exynos5433: Fix PLL rates

2018-05-30T05:49:16+00:00

[ Upstream commit ab0447845cffc0fd752df2ccd6b4e34006000ce4 ]

Rates declared in PLL rate tables should match exactly rates calculated from
the PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate
will return 393216003. If we now attempt to set rate of a PLL's child divider
clock to 393216000/2 its rate will be 131072001, rather than 196608000.
That is, the divider will be set to 3 instead of 2, because 393216003/2 is
greater than 196608000.

To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.

Signed-off-by: Andrzej Hajda 
Acked-by: Tomasz Figa 
Acked-by: Chanwoo Choi 
Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

clk: samsung: exynos5260: Fix PLL rates

2018-05-30T05:49:15+00:00

[ Upstream commit cdb68fbd4e7962be742c4f29475220c5bf28d8a5 ]

Rates declared in PLL rate tables should match exactly rates calculated from
the PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate
will return 393216003. If we now attempt to set rate of a PLL's child divider
clock to 393216000/2 its rate will be 131072001, rather than 196608000.
That is, the divider will be set to 3 instead of 2, because 393216003/2 is
greater than 196608000.

To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.

Signed-off-by: Andrzej Hajda 
Acked-by: Tomasz Figa 
Acked-by: Chanwoo Choi 
Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

clk: samsung: s3c2410: Fix PLL rates

2018-05-30T05:49:15+00:00

[ Upstream commit 179db533c08431f509a3823077549773d519358b ]

Rates declared in PLL rate tables should match exactly rates calculated from
the PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate
will return 393216003. If we now attempt to set rate of a PLL's child divider
clock to 393216000/2 its rate will be 131072001, rather than 196608000.
That is, the divider will be set to 3 instead of 2, because 393216003/2 is
greater than 196608000.

To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.

Signed-off-by: Andrzej Hajda 
Acked-by: Tomasz Figa 
Acked-by: Chanwoo Choi 
Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

clk: rockchip: Prevent calculating mmc phase if clock rate is zero

2018-05-30T05:49:14+00:00

[ Upstream commit 4bf59902b50012b1dddeeaa23b217d9c4956cdda ]

The MMC sample and drv clock for rockchip platforms are derived from
the bus clock output to the MMC/SDIO card. So it should never happens
that the clk rate is zero given it should inherits the clock rate from
its parent. If something goes wrong and makes the clock rate to be zero,
the calculation would be wrong but may still make the mmc tuning process
work luckily. However it makes people harder to debug when the following
data transfer is unstable.

Signed-off-by: Shawn Lin 
Signed-off-by: Heiko Stuebner 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

clk: Don't show the incorrect clock phase

2018-05-30T05:49:11+00:00

[ Upstream commit 1f9c63e8de3d7b377c9d74e4a17524cfb60e6384 ]

It's found that the clock phase output from clk_summary is
wrong compared to the actual phase reading from the register.

cat /sys/kernel/debug/clk/clk_summary | grep sdio_sample
sdio_sample     0        1        0 50000000          0 -22

It exposes an issue that clk core, clk_core_get_phase, always
returns the cached core->phase which should be either updated
by calling clk_set_phase or directly from the first place the
clk was registered.

When registering the clk, the core->phase geting from ->get_phase()
may return negative value indicating error. This is quite common
since the clk's phase may be highly related to its parent chain,
but it was temporarily orphan when registered, since its parent
chains hadn't be ready at that time, so the clk drivers decide to
return error in this case. However, if no clk_set_phase is called or
maybe the ->set_phase() isn't even implemented, the core->phase would
never be updated. This is wrong, and we should try to update it when
all its parent chains are settled down, like the way of updating clock
rate for that. But it's not deserved to complicate the code now and
just update it anyway when calling clk_core_get_phase, which would be
much simple and enough.

Signed-off-by: Shawn Lin 
Acked-by: Jerome Brunet 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

clk: bcm2835: De-assert/assert PLL reset signal when appropriate

2018-04-24T07:32:08+00:00

commit 753872373b599384ac7df809aa61ea12d1c4d5d1 upstream.

In order to enable a PLL, not only the PLL has to be powered up and
locked, but you also have to de-assert the reset signal. The last part
was missing. Add it so PLLs that were not enabled by the FW/bootloader
can be enabled from Linux.

Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
Cc: 
Signed-off-by: Boris Brezillon 
Reviewed-by: Eric Anholt 
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman