Pull clk updates from Stephen Boyd:
"The core framework gained a clk provider helper, a clk consumer
helper, and some unit tests for the assigned clk rates feature in
DeviceTree. On the vendor driver side, we gained a whole pile of SoC
driver support detailed below. The majority in the diffstat is
Qualcomm, but there's also quite a few Samsung and Mediatek clk driver
additions in here as well. The top vendors is quite common, but the
sheer amount of new drivers is uncommon, so I'm anticipating a larger
number of fixes for clk drivers this cycle.
Core:
- devm_clk_bulk_get_all_enabled() to return number of clks acquired
- devm_clk_hw_register_gate_parent_hw() helper to modernize drivers
- KUnit tests for clk-assigned-rates{,-u64}
New Drivers:
- Marvell PXA1908 SoC clks
- Mobileye EyeQ5, EyeQ6L and EyeQ6H clk driver
- TWL6030 clk driver
- Nuvoton Arbel BMC NPCM8XX SoC clks
- MediaTek MT6735 SoC clks
- MediaTek MT7620, MT7628 and MT7688 MMC clks
- Add a driver for gated fixed rate clocks
- Global clock controllers for Qualcomm QCS8300 and IPQ5424 SoCs
- Camera, display and video clock controllers for Qualcomm SA8775P
SoCs
- Global, display, GPU, TCSR, and RPMh clock controllers for Qualcomm
SAR2130P
- Global, camera, display, GPU, and video clock controllers for
Qualcomm SM8475 SoCs
- RTC power domain and Battery Backup Function (VBATTB) clock support
for the Renesas RZ/G3S SoC
- Qualcomm IPQ9574 alpha PLLs
- Support for i.MX91 CCM in the i.MX93 driver
- Microchip LAN969X SoC clks
- Cortex-A55 core clocks and Interrupt Control Unit (ICU) clock and
reset on Renesas RZ/V2H(P)
- Samsung ExynosAutov920 clk drivers for PERIC1, MISC, HSI0 and HSI1
- Samsung Exynos8895 clk drivers for FSYS0/1, PERIC0/1, PERIS and TOP
Updates:
- Convert more clk bindings to YAML
- Various clk driver cleanups: NULL checks, add const, etc.
- Remove END/NUM #defines that count number of clks in various
binding headers
- Continue moving reset drivers to drivers/reset via auxiliary bus"
* tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (162 commits)
clk: clk-loongson2: Fix potential buffer overflow in flexible-array member access
clk: Fix invalid execution of clk_set_rate
clk: clk-loongson2: Fix memory corruption bug in struct loongson2_clk_provider
clk: lan966x: make it selectable for ARCH_LAN969X
clk: eyeq: add EyeQ6H west fixed factor clocks
clk: eyeq: add EyeQ6H central fixed factor clocks
clk: eyeq: add EyeQ5 fixed factor clocks
clk: eyeq: add fixed factor clocks infrastructure
clk: eyeq: require clock index with phandle in all cases
clk: fixed-factor: add clk_hw_register_fixed_factor_index() function
dt-bindings: clock: eyeq: add more Mobileye EyeQ5/EyeQ6H clocks
dt-bindings: soc: mobileye: set `#clock-cells = <1>` for all compatibles
clk: clk-axi-clkgen: make sure to enable the AXI bus clock
dt-bindings: clock: axi-clkgen: include AXI clk
clk: mmp: Add Marvell PXA1908 MPMU driver
clk: mmp: Add Marvell PXA1908 APMU driver
clk: mmp: Add Marvell PXA1908 APBCP driver
clk: mmp: Add Marvell PXA1908 APBC driver
dt-bindings: clock: Add Marvell PXA1908 clock bindings
clk: mmp: Switch to use struct u32_fract instead of custom one
...
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/clk/clk_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/clk/clk-gate_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/clk/clk-fractional-divider_test.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://lore.kernel.org/r/20240602-md-clk-test-v1-1-a6afd4793337@quicinc.com
[sboyd@kernel.org: Reword header and description]
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Transform the existing clk_leaf_mux_set_rate_parent test into a
parameterized test that calls the various determine rate APIs that exist
for clk providers. This ensures that whatever determine rate API is used
by a clk provider will return the correct parent in the best_parent_hw
pointer of the clk_rate_request because clk_rate_requests are forwarded
properly.
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20230912175534.2427862-3-sboyd@kernel.org
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Running this kunit test with lockdep enabled leads to warning splats
about calling clk provider APIs without the clk_prepare lock held. I
proposed adding a wrapper around these APIs to grab the prepare lock so
we can call them from anywhere, and Maxime implemented that approach[1],
but it didn't look great. That's because we had to make more kunit
testing APIs just to call code from a place that isn't a clk provider
when the prepare lock isn't held.
Instead of doing that, let's implement a determine_rate clk_op for a new
leaf clk that is the child of the existing leaf clk. We can call
__clk_determine_rate() on the existing leaf clk from there, and stash
away the clk_rate_request struct to check once the clk_op returns. Drive
that clk_op by calling clk_round_rate() to keep things similar to how it
was before (i.e. nothing actually changes rate, just the new rate is
determined). This silences the warning by driving the test from a
clk_op where we know the prepare lock is held.
While looking at this in more detail, it was determined that the code we
intended to test in commit 262ca38f4b ("clk: Stop forwarding
clk_rate_requests to the parent") wasn't actually tested. The call to
__clk_determine_rate() wasn't actually getting to the newly introduced
code under the CLK_SET_RATE_PARENT if condition in
clk_core_round_rate_nolock() because the parent clk (the mux) could
round rates. We introduce a new leaf and make sure the parent of that
clk has no clk_ops so that we can be certain that the
CLK_SET_RATE_PARENT condition in clk_core_round_rate_nolock() is
evaluated.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Closes: https://lore.kernel.org/linux-clk/2b594e50-2bbf-4a2d-88e6-49fc39f3957a@roeck-us.net/
Reported-by: kernel test robot <yujie.liu@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202301310919.b9d56ee3-yujie.liu@intel.com
Cc: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20230721-clk-fix-kunit-lockdep-v1-0-32cdba4c8fc1@kernel.org [1]
Fixes: 262ca38f4b ("clk: Stop forwarding clk_rate_requests to the parent")
Link: https://lore.kernel.org/r/20230912175534.2427862-2-sboyd@kernel.org
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The single parent clock in our kunit tests implements a mux with a
set_parent hook, but doesn't provide a determine_rate implementation.
This is not entirely unexpected, since its whole purpose it to have a
single parent. When determine_rate is missing, and since
CLK_SET_RATE_PARENT is set for all its instances, the default behaviour
of the framework will be to forward it to the current parent.
This is totally fine as far as the tests are concerned, but we'll start
to mandate a determine_rate implementation when set_parent is set, so
let's fill it with __clk_mux_determine_rate() which will have the same
behavior.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-7-971d5077e7d2@cerno.tech
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
If the clock cannot modify its rate and has CLK_SET_RATE_PARENT,
clk_mux_determine_rate_flags(), clk_core_round_rate_nolock() and a
number of drivers will forward the clk_rate_request to the parent clock.
clk_core_round_rate_nolock() will pass the pointer directly, which means
that we pass a clk_rate_request to the parent that has the rate,
min_rate and max_rate of the child, and the best_parent_rate and
best_parent_hw fields will be relative to the child as well, so will
point to our current clock and its rate. The most common case for
CLK_SET_RATE_PARENT is that the child and parent clock rates will be
equal, so the rate field isn't a worry, but the other fields are.
Similarly, if the parent clock driver ever modifies the best_parent_rate
or best_parent_hw, this will be applied to the child once the call to
clk_core_round_rate_nolock() is done. best_parent_hw is probably not
going to be a valid parent, and best_parent_rate might lead to a parent
rate change different to the one that was initially computed.
clk_mux_determine_rate_flags() and the affected drivers will copy the
request before forwarding it to the parents, so they won't be affected
by the latter issue, but the former is still going to be there and will
lead to erroneous data and context being passed to the various clock
drivers in the same sub-tree.
Let's create two new functions, clk_core_forward_rate_req() and
clk_hw_forward_rate_request() for the framework and the clock providers
that will copy a request from a child clock and update the context to
match the parent's. We also update the relevant call sites in the
framework and drivers to use that new function.
Let's also add a test to make sure we avoid regressions there.
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220816112530.1837489-22-maxime@cerno.tech
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
We will need to know if a clk_core pointer has a given parent in other
functions, so let's create a clk_core_has_parent() function that
clk_has_parent() will call into.
For good measure, let's add some unit tests as well to make sure it
works properly.
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220816112530.1837489-20-maxime@cerno.tech
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
[sboyd@kernel.org: Move tmp declaration, fix conditional to check for
current parent]
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
If a non-rate clock started by default with a parent that never
registered, core->req_rate will be 0. The expectation is that whenever
the parent will be registered, req_rate will be updated with the new
value that has just been computed.
However, if that clock is a mux, clk_set_parent() can also make that
clock no longer orphan. In this case however, we never update req_rate.
The natural solution to this would be to update core->rate and
core->req_rate in clk_reparent() by calling clk_recalc().
However, this doesn't work in all cases. Indeed, clk_recalc() is called
by __clk_set_parent_before(), __clk_set_parent() and
clk_core_reparent(). Both __clk_set_parent_before() and __clk_set_parent
will call clk_recalc() with the enable_lock taken through a call to
clk_enable_lock(), the underlying locking primitive being a spinlock.
clk_recalc() calls the backing driver .recalc_rate hook, and that
implementation might sleep if the underlying device uses a bus with
accesses that might sleep, such as i2c.
In such a situation, we would end up sleeping while holding a spinlock,
and thus in an atomic section.
In order to work around this, we can move the core->rate and
core->req_rate update to the clk_recalc() calling sites, after the
enable_lock has been released if it was taken.
The only situation that could still be problematic is the
clk_core_reparent() -> clk_reparent() case that doesn't have any
locking. clk_core_reparent() is itself called by clk_hw_reparent(),
which is then called by 4 drivers:
* clk-stm32mp1.c, stm32/clk-stm32-core.c and tegra/clk-tegra210-emc.c
use it in their set_parent implementation. The set_parent hook is
only called by __clk_set_parent() and clk_change_rate(), both of
them calling it without the enable_lock taken.
* clk/tegra/clk-tegra124-emc.c calls it as part of its set_rate
implementation. set_rate is only called by clk_change_rate(), again
without the enable_lock taken.
In both cases we can't end up in a situation where the clk_hw_reparent()
caller would hold a spinlock, so it seems like this is a good
workaround.
Let's also add some unit tests to make sure we cover the original bug.
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220816112530.1837489-14-maxime@cerno.tech
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The clock framework supports clocks that can have their rate changed
without the kernel knowing about it using the CLK_GET_RATE_NOCACHE flag.
As its name suggests, this flag turns off the rate caching in the clock
framework, reading out the rate from the hardware any time we need to
read it.
Let's add a couple of tests to make sure it works as intended.
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220816112530.1837489-9-maxime@cerno.tech
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
When clk_put() is called we don't make another clk_set_rate() call to
re-evaluate the rate boundaries. This is unlike clk_set_rate_range()
that evaluates the rate again each time it is called.
However, clk_put() is essentially equivalent to clk_set_rate_range()
since after clk_put() completes the consumer's boundaries shouldn't be
enforced anymore.
Let's add a call to clk_set_rate_range() in clk_put() to make sure those
rate boundaries are dropped and the clock provider drivers can react. In
order to be as non-intrusive as possible, we'll just make that call if
the clock had non-default boundaries.
Also add a few tests to make sure this case is covered.
Fixes: c80ac50cbb ("clk: Always set the rate on clk_set_range_rate")
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220816112530.1837489-3-maxime@cerno.tech
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
When clk_put() is called we don't make another clk_set_rate() call to
re-evaluate the rate boundaries. This is unlike clk_set_rate_range()
that evaluates the rate again each time it is called.
However, clk_put() is essentially equivalent to clk_set_rate_range()
since after clk_put() completes the consumer's boundaries shouldn't be
enforced anymore.
Let's add a call to clk_set_rate_range() in clk_put() to make sure those
rate boundaries are dropped and the clock provider drivers can react.
Also add a few tests to make sure this case is covered.
Fixes: c80ac50cbb ("clk: Always set the rate on clk_set_range_rate")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220325161144.1901695-4-maxime@cerno.tech
[sboyd@kernel.org: Reword commit text]
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
A bug recently affected the Tegra30 where calling clk_set_rate_range()
on a clock would make it change its rate to the minimum.
This was due to the clock in question being a mux that was orphan at
registration, which lead to the clk_core req_rate being 0, and the
clk_set_rate_range() function then calling clk_set_rate() with req_rate,
effectively making that clock running at the minimum rate allowed, even
though the initial rate was within that range.
Make a test suite to create a mux initially orphan, and then make sure
that if our clock rate was initially within a given range, then
enforcing that range won't affect it.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220325161144.1901695-3-maxime@cerno.tech
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
When we change a clock minimum or maximum using clk_set_rate_range(),
clk_set_min_rate() or clk_set_max_rate(), the current code will only
trigger a new rate change if the rate is outside of the new boundaries.
However, a clock driver might want to always keep the clock rate to
one of its boundary, for example the minimum to keep the power
consumption as low as possible.
Since they don't always get called though, clock providers don't have the
opportunity to implement this behaviour.
Let's trigger a clk_set_rate() on the previous requested rate every time
clk_set_rate_range() is called. That way, providers that care about the
new boundaries have a chance to adjust the rate, while providers that
don't care about those new boundaries will return the same rate than
before, which will be ignored by clk_set_rate() and won't result in a
new rate change.
Suggested-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220225143534.405820-7-maxime@cerno.tech
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The current core while setting the min and max rate properly in the
clk_request structure will not make sure that the requested rate is
within these boundaries, leaving it to each and every driver to make
sure it is.
It's not clear if this was on purpose or not, but this introduces some
inconsistencies within the API.
For example, a user setting a range and then calling clk_round_rate()
with a value outside of that range will get the same value back
(ignoring any driver adjustements), effectively ignoring the range that
was just set.
Another one, arguably worse, is that it also makes clk_round_rate() and
clk_set_rate() behave differently if there's a range and the rate being
used for both is outside that range. As we have seen, the rate will be
returned unchanged by clk_round_rate(), but clk_set_rate() will error
out returning -EINVAL.
Let's make sure the framework will always clamp the rate to the current
range found on the clock, which will fix both these inconsistencies.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220225143534.405820-5-maxime@cerno.tech
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
