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

clk: at91: PLL recalc_rate() now using cached MUL and DIV values

2018-07-03T09:23:13+00:00

commit a982e45dc150da3a08907b6dd676b735391704b4 upstream.

When a USB device is connected to the USB host port on the SAM9N12 then
you get "-62" error which seems to indicate USB replies from the device
are timing out. Based on a logic sniffer, I saw the USB bus was running
at half speed.

The PLL code uses cached MUL and DIV values which get set in set_rate()
and applied in prepare(), but the recalc_rate() function instead
queries the hardware instead of using these cached values. Therefore,
if recalc_rate() is called between a set_rate() and prepare(), the
wrong frequency is calculated and later the USB clock divider for the
SAM9N12 SOC will be configured for an incorrect clock.

In my case, the PLL hardware was set to 96 Mhz before the OHCI
driver loads, and therefore the usb clock divider was being set
to /2 even though the OHCI driver set the PLL to 48 Mhz.

As an alternative explanation, I noticed this was fixed in the past by
87e2ed338f1b ("clk: at91: fix recalc_rate implementation of PLL
driver") but the bug was later re-introduced by 1bdf02326b71 ("clk:
at91: make use of syscon/regmap internally").

Fixes: 1bdf02326b71 ("clk: at91: make use of syscon/regmap internally)
Cc: 
Signed-off-by: Marcin Ziemianowicz 
Acked-by: Boris Brezillon 
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

clk: renesas: cpg-mssr: Stop using printk format %pCr

2018-07-03T09:23:06+00:00

commit ef4b0be62641d296cf4c0ad8f75ab83ab066ed51 upstream.

Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.

Replace it by open-coding the operation.  This is safe here, as the code
runs in task context.

Link: http://lkml.kernel.org/r/1527845302-12159-2-git-send-email-geert+renesas@glider.be
To: Jia-Ju Bai 
To: Jonathan Corbet 
To: Michael Turquette 
To: Stephen Boyd 
To: Zhang Rui 
To: Eduardo Valentin 
To: Eric Anholt 
To: Stefan Wahren 
To: Greg Kroah-Hartman 
Cc: Sergey Senozhatsky 
Cc: Petr Mladek 
Cc: Linus Torvalds 
Cc: Steven Rostedt 
Cc: linux-doc@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Geert Uytterhoeven 
Cc: stable@vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven 
Acked-by: Stephen Boyd 
Signed-off-by: Petr Mladek 
Signed-off-by: Greg Kroah-Hartman

clk: samsung: exynos3250: Fix PLL rates

2018-05-25T14:13:12+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-25T14:13:12+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-25T14:13:11+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-25T14:13:11+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: exynos7: Fix PLL rates

2018-05-25T14:13:11+00:00

[ Upstream commit 7e4db0c2836e892766565965207eee051c8037b9 ]

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-25T14:13:11+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-25T14:13:11+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: tegra: Fix pll_u rate configuration

2018-05-25T14:13:10+00:00

[ Upstream commit c35b518f9ba06c9de79fb3ff62eed7462d804995 ]

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 
Tested-by: Jon Hunter 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman