linux-stable.git/drivers/clk, branch v5.4.129

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

2021-06-23T12:41:31+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 5.4.y]
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

clk: exynos7: Mark aclk_fsys1_200 as critical

2021-05-19T08:08:33+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-14T07:44:25+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-14T07:44:25+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: zynqmp: move zynqmp_pll_set_mode out of round_rate callback

2021-05-14T07:44:24+00:00

[ Upstream commit d7fd3f9f53df8bb2212dff70f66f12cae0e1a653 ]

The round_rate callback should only perform rate calculation and not
involve calling zynqmp_pll_set_mode to change the pll mode. So let's
move zynqmp_pll_set_mode out of round_rate and to set_rate callback.

Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver")
Reported-by: Laurent Pinchart 
Signed-off-by: Quanyang Wang 
Link: https://lore.kernel.org/r/20210406154015.602779-1-quanyang.wang@windriver.com
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

media: aspeed: fix clock handling logic

2021-05-14T07:44:23+00:00

[ Upstream commit 3536169f8531c2c5b153921dc7d1ac9fd570cda7 ]

Video engine uses eclk and vclk for its clock sources and its reset
control is coupled with eclk so the current clock enabling sequence works
like below.

 Enable eclk
 De-assert Video Engine reset
 10ms delay
 Enable vclk

It introduces improper reset on the Video Engine hardware and eventually
the hardware generates unexpected DMA memory transfers that can corrupt
memory region in random and sporadic patterns. This issue is observed
very rarely on some specific AST2500 SoCs but it causes a critical
kernel panic with making a various shape of signature so it's extremely
hard to debug. Moreover, the issue is observed even when the video
engine is not actively used because udevd turns on the video engine
hardware for a short time to make a query in every boot.

To fix this issue, this commit changes the clock handling logic to make
the reset de-assertion triggered after enabling both eclk and vclk. Also,
it adds clk_unprepare call for a case when probe fails.

clk: ast2600: fix reset settings for eclk and vclk
Video engine reset setting should be coupled with eclk to match it
with the setting for previous Aspeed SoCs which is defined in
clk-aspeed.c since all Aspeed SoCs are sharing a single video engine
driver. Also, reset bit 6 is defined as 'Video Engine' reset in
datasheet so it should be de-asserted when eclk is enabled. This
commit fixes the setting.

Fixes: d2b4387f3bdf ("media: platform: Add Aspeed Video Engine driver")
Signed-off-by: Jae Hyun Yoo 
Reviewed-by: Joel Stanley 
Reviewed-by: Eddie James 
Fixes: d3d04f6c330a ("clk: Add support for AST2600 SoC")
Reviewed-by: Joel Stanley 
Acked-by: Stephen Boyd 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

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

2021-05-14T07:44:21+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-14T07:44:21+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-14T07:44:21+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-11T12:04:10+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