linux-stable.git/drivers/clk, branch v6.6.76

clk: analogbits: Fix incorrect calculation of vco rate delta

2025-02-08T08:52:02+00:00

[ Upstream commit d7f12857f095ef38523399d47e68787b357232f6 ]

In wrpll_configure_for_rate() we try to determine the best PLL
configuration for a target rate. However, in the loop where we try
values of R, we should compare the derived `vco` with `target_vco_rate`.
However, we were in fact comparing it with `target_rate`, which is
actually after Q shift. This is incorrect, and sometimes can result in
suboptimal clock rates. Fix it.

Fixes: 7b9487a9a5c4 ("clk: analogbits: add Wide-Range PLL library")
Signed-off-by: Bo Gan 
Link: https://lore.kernel.org/r/20240830061639.2316-1-ganboing@gmail.com
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

clk: ralink: mtmips: remove duplicated 'xtal' clock for Ralink SoC RT3883

2025-02-08T08:51:58+00:00

[ Upstream commit 830d8062d25581cf0beaa334486eea06834044da ]

Ralink SoC RT3883 has already 'xtal' defined as a base clock so there is no
need to redefine it again in fixed clocks section. Hence, remove the duplicate
one from there.

Fixes: d34db686a3d7 ("clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs")
Signed-off-by: Sergio Paracuellos 
Link: https://lore.kernel.org/r/20250108093636.265033-1-sergio.paracuellos@gmail.com
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

clk: qcom: gcc-sdm845: Do not use shared clk_ops for QUPs

2025-02-08T08:51:56+00:00

[ Upstream commit f760a4bb5e927a133dcd75f7b69ccae2a331e42c ]

Similar to the earlier fixes meant for sm8x50 and x1e platforms,
we have to stop using the shared clk ops for sdm845 QUPs as well.

As Stephen Boyd pointed out in earlier fixes, there wasn't a problem
to mark QUP clks shared until we started parking shared RCGs at clk
registration time in commit 01a0a6cc8cfd ("clk: qcom: Park shared RCGs
upon registration"). Parking at init is actually harmful to the UART
when earlycon is used. If the device is pumping out data while the
frequency changes and we see garbage on the serial console until the
driver can probe and actually set a proper frequency.

This patch reverts the QUP clk sharing ops part of commit 06391eddb60a
("clk: qcom: Add Global Clock controller (GCC) driver for SDM845"), so
that the QUPs on sdm845 don't get parked during clk registration and
break UART operations.

Fixes: 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration")
Signed-off-by: Amit Pundir 
Link: https://lore.kernel.org/r/20241209174912.2526928-1-amit.pundir@linaro.org
Signed-off-by: Bjorn Andersson 
Signed-off-by: Sasha Levin

clk: sunxi-ng: a64: stop force-selecting PLL-MIPI as TCON0 parent

2025-02-08T08:51:55+00:00

[ Upstream commit 383ca7bee8a93be9ff5a072936981c2710d2856b ]

Stop force-selecting PLL-MIPI as TCON0 parent, since it breaks video
output on Pinebook that uses RGB to eDP bridge.

Partially revert commit ca1170b69968 ("clk: sunxi-ng: a64: force
select PLL_MIPI in TCON0 mux"), while still leaving
CLK_SET_RATE_NO_REPARENT flag set, since we do not want the clock to
be reparented.

The issue is that apparently different TCON0 outputs require a different
clock, or the mux might be selecting the output type.

I did an experiment: I manually configured PLL_MIPI and PLL_VIDEO0_2X
to the same clock rate and flipped the switch with devmem. Experiment
clearly showed that whenever PLL_MIPI is selected as TCON0 clock parent,
the video output stops working.

Therefore, TCON0 clock parent corresponding to the output type must be
assigned in the device tree.

Fixes: ca1170b69968 ("clk: sunxi-ng: a64: force select PLL_MIPI in TCON0 mux")
Reviewed-by: Dragan Simic 
Reviewed-by: Chen-Yu Tsai 
Tested-by: Frank Oltmanns  # on PinePhone
Tested-by: Stuart Gathman  # on OG Pinebook
Signed-off-by: Vasily Khoruzhick 
Link: https://patch.msgid.link/20250104074035.1611136-5-anarsoul@gmail.com
Signed-off-by: Chen-Yu Tsai 
Signed-off-by: Sasha Levin

clk: sunxi-ng: a64: drop redundant CLK_PLL_VIDEO0_2X and CLK_PLL_MIPI

2025-02-08T08:51:55+00:00

[ Upstream commit 0f368cb7ef103f284f75e962c4c89da5aa8ccec7 ]

Drop redundant CLK_PLL_VIDEO0_2X and CLK_PLL.MIPI. These are now
defined in dt-bindings/clock/sun50i-a64-ccu.h

Fixes: ca1170b69968 ("clk: sunxi-ng: a64: force select PLL_MIPI in TCON0 mux")
Reviewed-by: Dragan Simic 
Reviewed-by: Chen-Yu Tsai 
Tested-by: Frank Oltmanns  # on pinephone
Tested-by: Stuart Gathman  # on OG pinebook
Signed-off-by: Vasily Khoruzhick 
Link: https://patch.msgid.link/20250104074035.1611136-3-anarsoul@gmail.com
Signed-off-by: Chen-Yu Tsai 
Signed-off-by: Sasha Levin

clk: imx8mp: Fix clkout1/2 support

2025-02-08T08:51:54+00:00

[ Upstream commit a9b7c84d22fb1687d63ca2a386773015cf59436b ]

The CLKOUTn may be fed from PLL1/2/3, but the PLL1/2/3 has to be enabled
first by setting PLL_CLKE bit 11 in CCM_ANALOG_SYS_PLLn_GEN_CTRL register.
The CCM_ANALOG_SYS_PLLn_GEN_CTRL bit 11 is modeled by plln_out clock. Fix
the clock tree and place the clkout1/2 under plln_sel instead of plain plln
to let the clock subsystem correctly control the bit 11 and enable the PLL
in case the CLKOUTn is supplied by PLL1/2/3.

Fixes: 43896f56b59e ("clk: imx8mp: add clkout1/2 support")
Signed-off-by: Marek Vasut 
Reviewed-by: Peng Fan 
Link: https://lore.kernel.org/r/20241112013718.333771-1-marex@denx.de
Signed-off-by: Abel Vesa 
Signed-off-by: Sasha Levin

clk: fix an OF node reference leak in of_clk_get_parent_name()

2025-02-08T08:51:51+00:00

[ Upstream commit 28fa3291cad1c201967ef93edc6e7f8ccc9afbc0 ]

Current implementation of of_clk_get_parent_name() leaks an OF node
reference on error path. Add a of_node_put() call before returning an
error.

This bug was found by an experimental static analysis tool that I am
developing.

Fixes: 8da411cc1964 ("clk: let of_clk_get_parent_name() fail for invalid clock-indices")
Signed-off-by: Joe Hattori 
Link: https://lore.kernel.org/r/20241210130913.3615205-1-joe@pf.is.s.u-tokyo.ac.jp
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

of: remove internal arguments from of_property_for_each_u32()

2025-02-08T08:51:51+00:00

[ Upstream commit 9722c3b66e21ff08aec570d02a97d331087fd70f ]

The of_property_for_each_u32() macro needs five parameters, two of which
are primarily meant as internal variables for the macro itself (in the
for() clause). Yet these two parameters are used by a few drivers, and this
can be considered misuse or at least bad practice.

Now that the kernel uses C11 to build, these two parameters can be avoided
by declaring them internally, thus changing this pattern:

  struct property *prop;
  const __be32 *p;
  u32 val;

  of_property_for_each_u32(np, "xyz", prop, p, val) { ... }

to this:

  u32 val;

  of_property_for_each_u32(np, "xyz", val) { ... }

However two variables cannot be declared in the for clause even with C11,
so declare one struct that contain the two variables we actually need. As
the variables inside this struct are not meant to be used by users of this
macro, give the struct instance the noticeable name "_it" so it is visible
during code reviews, helping to avoid new code to use it directly.

Most usages are trivially converted as they do not use those two
parameters, as expected. The non-trivial cases are:

 - drivers/clk/clk.c, of_clk_get_parent_name(): easily doable anyway
 - drivers/clk/clk-si5351.c, si5351_dt_parse(): this is more complex as the
   checks had to be replicated in a different way, making code more verbose
   and somewhat uglier, but I refrained from a full rework to keep as much
   of the original code untouched having no hardware to test my changes

All the changes have been build tested. The few for which I have the
hardware have been runtime-tested too.

Reviewed-by: Andre Przywara  # drivers/clk/sunxi/clk-simple-gates.c, drivers/clk/sunxi/clk-sun8i-bus-gates.c
Acked-by: Bartosz Golaszewski  # drivers/gpio/gpio-brcmstb.c
Acked-by: Nicolas Ferre  # drivers/irqchip/irq-atmel-aic-common.c
Acked-by: Jonathan Cameron  # drivers/iio/adc/ti_am335x_adc.c
Acked-by: Uwe Kleine-König  # drivers/pwm/pwm-samsung.c
Acked-by: Richard Leitner  # drivers/usb/misc/usb251xb.c
Acked-by: Mark Brown  # sound/soc/codecs/arizona.c
Reviewed-by: Richard Fitzgerald  # sound/soc/codecs/arizona.c
Acked-by: Michael Ellerman  # arch/powerpc/sysdev/xive/spapr.c
Acked-by: Stephen Boyd  # clk
Signed-off-by: Luca Ceresoli 
Acked-by: Lee Jones 
Link: https://lore.kernel.org/r/20240724-of_property_for_each_u32-v3-1-bea82ce429e2@bootlin.com
Signed-off-by: Rob Herring (Arm) 
Stable-dep-of: 28fa3291cad1 ("clk: fix an OF node reference leak in of_clk_get_parent_name()")
Signed-off-by: Sasha Levin

clk: si5351: allow PLLs to be adjusted without reset

2025-02-08T08:51:50+00:00

[ Upstream commit b2adbc9cea752539f6421e9d4642408f666c1251 ]

Introduce a new PLL reset mode flag which controls whether or not to
reset a PLL after adjusting its rate. The mode can be configured through
platform data or device tree.

Since commit 6dc669a22c77 ("clk: si5351: Add PLL soft reset"), the
driver unconditionally resets a PLL whenever its rate is adjusted.
The rationale was that a PLL reset was required to get three outputs
working at the same time. Before this change, the driver never reset the
PLLs.

Commit b26ff127c52c ("clk: si5351: Apply PLL soft reset before enabling
the outputs") subsequently introduced an option to reset the PLL when
enabling a clock output that sourced it. Here, the rationale was that
this is required to get a deterministic phase relationship between
multiple output clocks.

This clearly shows that it is useful to reset the PLLs in applications
where multiple clock outputs are used. However, the Si5351 also allows
for glitch-free rate adjustment of its PLLs if one avoids resetting the
PLL. In our audio application where a single Si5351 clock output is used
to supply a runtime adjustable bit clock, this unconditional PLL reset
behaviour introduces unwanted glitches in the clock output.

It would appear that the problem being solved in the former commit
may be solved by using the optional device tree property introduced in
the latter commit, obviating the need for an unconditional PLL reset
after rate adjustment. But it's not OK to break the default behaviour of
the driver, and it cannot be assumed that all device trees are using the
property introduced in the latter commit. Hence, the new behaviour is
made opt-in.

Cc: Sebastian Hesselbarth 
Cc: Rabeeh Khoury 
Cc: Jacob Siverskog 
Cc: Sergej Sawazki 
Signed-off-by: Alvin Šipraga 
Acked-by: Sebastian Hesselbarth 
Link: https://lore.kernel.org/r/20231124-alvin-clk-si5351-no-pll-reset-v6-3-69b82311cb90@bang-olufsen.dk
Signed-off-by: Stephen Boyd 
Stable-dep-of: 28fa3291cad1 ("clk: fix an OF node reference leak in of_clk_get_parent_name()")
Signed-off-by: Sasha Levin

clk: qcom: clk-alpha-pll: Add NSS HUAYRA ALPHA PLL support for ipq9574

2025-01-09T12:31:44+00:00

[ Upstream commit 79dfed29aa3f714e0a94a39b2bfe9ac14ce19a6a ]

Add support for NSS Huayra alpha pll found on ipq9574 SoCs.
Programming sequence is the same as that of Huayra type Alpha PLL,
so we can re-use the same.

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Devi Priya 
Link: https://lore.kernel.org/r/20241028060506.246606-2-quic_srichara@quicinc.com
Signed-off-by: Bjorn Andersson 
Signed-off-by: Sasha Levin