linux-stable.git/drivers/clk, branch v4.19.201

clk: tegra: Ensure that PLLU configuration is applied properly

2021-07-20T14:16:00+00:00

[ 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 
Signed-off-by: Dmitry Osipenko 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin

clk: renesas: r8a77995: Add ZA2 clock

2021-07-20T14:16:00+00:00

[ Upstream commit 790c06cc5df263cdaff748670cc65958c81b0951 ]

R-Car D3 ZA2 clock is from PLL0D3 or S0,
and it can be controlled by ZA2CKCR.
It is needed for R-Car Sound, but is not used so far.
Using default settings is very enough at this point.
This patch adds it by DEF_FIXED().

Signed-off-by: Kuninori Morimoto 
Link: https://lore.kernel.org/r/87pmxclrmy.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Sasha Levin

clocksource/drivers/timer-ti-dm: Handle dra7 timer wrap errata i940

2021-07-11T10:49:32+00:00

commit 25de4ce5ed02994aea8bc111d133308f6fd62566 upstream.

There is a timer wrap issue on dra7 for the ARM architected timer.
In a typical clock configuration the timer fails to wrap after 388 days.

To work around the issue, we need to use timer-ti-dm percpu timers instead.

Let's configure dmtimer3 and 4 as percpu timers by default, and warn about
the issue if the dtb is not configured properly.

For more information, please see the errata for "AM572x Sitara Processors
Silicon Revisions 1.1, 2.0":

https://www.ti.com/lit/er/sprz429m/sprz429m.pdf

The concept is based on earlier reference patches done by Tero Kristo and
Keerthy.

Cc: Daniel Lezcano 
Cc: Keerthy 
Cc: Tero Kristo 
[tony@atomide.com: backported to 4.19.y]
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

clk: exynos7: Mark aclk_fsys1_200 as critical

2021-05-22T08:59:47+00:00

commit 34138a59b92c1a30649a18ec442d2e61f3bc34dd upstream.

This clock must be always enabled to allow access to any registers in
fsys1 CMU. Until proper solution based on runtime PM is applied
(similar to what was done for Exynos5433), mark that clock as critical
so it won't be disabled.

It was observed on Samsung Galaxy S6 device (based on Exynos7420), where
UFS module is probed before pmic used to power that device.
In this case defer probe was happening and that clock was disabled by
UFS driver, causing whole boot to hang on next CMU access.

Fixes: 753195a749a6 ("clk: samsung: exynos7: Correct CMU_FSYS1 clocks names")
Signed-off-by: Paweł Chmiel 
Acked-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/linux-clk/20201024154346.9589-1-pawel.mikolaj.chmiel@gmail.com
[s.nawrocki: Added comment in the code]
Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Greg Kroah-Hartman

clk: uniphier: Fix potential infinite loop

2021-05-22T08:59:33+00:00

[ Upstream commit f6b1340dc751a6caa2a0567b667d0f4f4172cd58 ]

The for-loop iterates with a u8 loop counter i and compares this
with the loop upper limit of num_parents that is an int type.
There is a potential infinite loop if num_parents is larger than
the u8 loop counter. Fix this by making the loop counter the same
type as num_parents.  Also make num_parents an unsigned int to
match the return type of the call to clk_hw_get_num_parents.

Addresses-Coverity: ("Infinite loop")
Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver")
Signed-off-by: Colin Ian King 
Reviewed-by: Masahiro Yamada 
Link: https://lore.kernel.org/r/20210409090104.629722-1-colin.king@canonical.com
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

clk: qcom: a53-pll: Add missing MODULE_DEVICE_TABLE

2021-05-22T08:59:33+00:00

[ Upstream commit 790b516ada10a4dcc0f0a56dc0ced475d86d5820 ]

CONFIG_QCOM_A53PLL is tristate option and therefore this driver can be
compiled as a module. This patch adds missing MODULE_DEVICE_TABLE
definition which generates correct modalias for automatic loading of
this driver when it is built as an external module.

Fixes: 0c6ab1b8f894 ("clk: qcom: Add A53 PLL support")
Signed-off-by: Chen Hui 
Reviewed-by: Manivannan Sadhasivam 
Link: https://lore.kernel.org/r/20210409082352.233810-3-clare.chenhui@huawei.com
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

clk: mvebu: armada-37xx-periph: Fix workaround for switching from L1 to L0

2021-05-22T08:59:31+00:00

[ Upstream commit e93033aff684641f71a436ca7a9d2a742126baaf ]

When CPU frequency is at 250 MHz and set_rate() is called with 500 MHz (L1)
quickly followed by a call with 1 GHz (L0), the CPU does not necessarily
stay in L1 for at least 20ms as is required by Marvell errata.

This situation happens frequently with the ondemand cpufreq governor and
can be also reproduced with userspace governor. In most cases it causes CPU
to crash.

This change fixes the above issue and ensures that the CPU always stays in
L1 for at least 20ms when switching from any state to L0.

Signed-off-by: Marek Behún 
Signed-off-by: Pali Rohár 
Acked-by: Stephen Boyd 
Acked-by: Gregory CLEMENT 
Tested-by: Tomasz Maciej Nowak 
Tested-by: Anders Trier Olesen 
Tested-by: Philip Soares 
Fixes: 61c40f35f5cd ("clk: mvebu: armada-37xx-periph: Fix switching CPU rate from 300Mhz to 1.2GHz")
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

clk: mvebu: armada-37xx-periph: Fix switching CPU freq from 250 Mhz to 1 GHz

2021-05-22T08:59:31+00:00

[ Upstream commit 4decb9187589f61fe9fc2bc4d9b01160b0a610c5 ]

It was observed that the workaround introduced by commit 61c40f35f5cd
("clk: mvebu: armada-37xx-periph: Fix switching CPU rate from 300Mhz to
1.2GHz") when base CPU frequency is 1.2 GHz is also required when base
CPU frequency is 1 GHz. Otherwise switching CPU frequency directly from
L2 (250 MHz) to L0 (1 GHz) causes a crash.

When base CPU frequency is just 800 MHz no crashed were observed during
switch from L2 to L0.

Signed-off-by: Pali Rohár 
Acked-by: Stephen Boyd 
Acked-by: Gregory CLEMENT 
Tested-by: Tomasz Maciej Nowak 
Tested-by: Anders Trier Olesen 
Tested-by: Philip Soares 
Fixes: 2089dc33ea0e ("clk: mvebu: armada-37xx-periph: add DVFS support for cpu clocks")
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

clk: mvebu: armada-37xx-periph: remove .set_parent method for CPU PM clock

2021-05-22T08:59:31+00:00

[ Upstream commit 4e435a9dd26c46ac018997cc0562d50b1a96f372 ]

Remove the .set_parent method in clk_pm_cpu_ops.

This method was supposed to be needed by the armada-37xx-cpufreq driver,
but was never actually called due to wrong assumptions in the cpufreq
driver. After this was fixed in the cpufreq driver, this method is not
needed anymore.

Signed-off-by: Marek Behún 
Acked-by: Stephen Boyd 
Acked-by: Gregory CLEMENT 
Tested-by: Pali Rohár 
Tested-by: Tomasz Maciej Nowak 
Tested-by: Anders Trier Olesen 
Tested-by: Philip Soares 
Fixes: 2089dc33ea0e ("clk: mvebu: armada-37xx-periph: add DVFS support for cpu clocks")
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

clk: socfpga: arria10: Fix memory leak of socfpga_clk on error return

2021-05-22T08:59:17+00:00

[ Upstream commit 657d4d1934f75a2d978c3cf2086495eaa542e7a9 ]

There is an error return path that is not kfree'ing socfpga_clk leading
to a memory leak. Fix this by adding in the missing kfree call.

Addresses-Coverity: ("Resource leak")
Signed-off-by: Colin Ian King 
Link: https://lore.kernel.org/r/20210406170115.430990-1-colin.king@canonical.com
Acked-by: Dinh Nguyen 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin