kernel/linux.git/drivers/clk/clk_test.c, branch v6.6.148

clk: test: Add a determine_rate hook

2023-06-09T01:39:25+00:00

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 Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-7-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd

clk: Introduce clk_hw_determine_rate_no_reparent()

2023-06-09T01:39:25+00:00

Some clock drivers do not want to allow any reparenting on a given clock, but usually do so by not providing any determine_rate implementation. Whenever we call clk_round_rate() or clk_set_rate(), this leads to clk_core_can_round() returning false and thus the rest of the function either forwarding the rate request to its current parent if CLK_SET_RATE_PARENT is set, or just returning the current clock rate. This behaviour happens implicitly, and as we move forward to making a determine_rate implementation required for muxes, we need some way to explicitly opt-in for that behaviour. Fortunately, this is exactly what the clk_core_determine_rate_no_reparent() function is doing, so we can simply make it available to drivers. Cc: Abel Vesa Cc: Alessandro Zummo Cc: Alexandre Belloni Cc: Alexandre Torgue Cc: "Andreas Färber" Cc: AngeloGioacchino Del Regno Cc: Baolin Wang Cc: Charles Keepax Cc: Chen-Yu Tsai Cc: Chen-Yu Tsai Cc: Chunyan Zhang Cc: Claudiu Beznea Cc: Daniel Vetter Cc: David Airlie Cc: David Lechner Cc: Dinh Nguyen Cc: Fabio Estevam Cc: Geert Uytterhoeven Cc: Jaroslav Kysela Cc: Jernej Skrabec Cc: Jonathan Hunter Cc: Kishon Vijay Abraham I Cc: Liam Girdwood Cc: Linus Walleij Cc: Luca Ceresoli Cc: Manivannan Sadhasivam Cc: Mark Brown Cc: Markus Schneider-Pargmann Cc: Max Filippov Cc: Maxime Coquelin Cc: Mikko Perttunen Cc: Miles Chen Cc: Nicolas Ferre Cc: Orson Zhai Cc: Paul Cercueil Cc: Peng Fan Cc: Peter De Schrijver Cc: Prashant Gaikwad Cc: Richard Fitzgerald Cc: Samuel Holland Cc: Sascha Hauer Cc: Sekhar Nori Cc: Shawn Guo Cc: Takashi Iwai Cc: Thierry Reding Cc: Ulf Hansson Cc: Vinod Koul Cc: dri-devel@lists.freedesktop.org Cc: linux-actions@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mips@vger.kernel.org Cc: linux-phy@lists.infradead.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rtc@vger.kernel.org Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-sunxi@lists.linux.dev Cc: linux-tegra@vger.kernel.org Cc: NXP Linux Team Cc: patches@opensource.cirrus.com Cc: Pengutronix Kernel Team Signed-off-by: Stephen Boyd Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-4-971d5077e7d2@cerno.tech | Reported-by: kernel test robot :

clk: test: Fix type sign of rounded rate variables

2023-06-09T01:01:05+00:00

clk_round_rate() may return a negative error code, but most of the variables we defined to store its returned value are unsigned. This obviously leads to issues on error. Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-2-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd

clk: tests: Add tests for notifiers

2022-10-11T03:37:50+00:00

We're recently encountered a regression due to the rates reported through the clk_notifier_data being off when changing parents. Let's add a test suite and a test to make sure that we do get notified and with the proper rates. Suggested-by: Stephen Boyd Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20221010-rpi-clk-fixes-again-v1-2-d87ba82ac404@cerno.tech Tested-by: Marek Szyprowski Signed-off-by: Stephen Boyd

clk: tests: Add missing test case for ranges

2022-09-15T16:32:34+00:00

Let's add a test on the rate range after a reparenting. This fails for now, but it's worth having it to document the corner cases we don't support yet. Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20220816112530.1837489-26-maxime@cerno.tech Tested-by: Naresh Kamboju Tested-by: Linux Kernel Functional Testing Signed-off-by: Stephen Boyd

clk: Stop forwarding clk_rate_requests to the parent

2022-09-15T16:32:11+00:00

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 # imx8mp Tested-by: Marek Szyprowski # exynos4210, meson g12b Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20220816112530.1837489-22-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing Tested-by: Naresh Kamboju Signed-off-by: Stephen Boyd

clk: Introduce clk_core_has_parent()

2022-09-15T16:31:58+00:00

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 # imx8mp Tested-by: Marek Szyprowski # exynos4210, meson g12b Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20220816112530.1837489-20-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing Tested-by: Naresh Kamboju [sboyd@kernel.org: Move tmp declaration, fix conditional to check for current parent] Signed-off-by: Stephen Boyd

clk: Set req_rate on reparenting

2022-09-15T16:31:09+00:00

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 # imx8mp Tested-by: Marek Szyprowski # exynos4210, meson g12b Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20220816112530.1837489-14-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing Tested-by: Naresh Kamboju Signed-off-by: Stephen Boyd

clk: Take into account uncached clocks in clk_set_rate_range()

2022-09-15T16:31:05+00:00

clk_set_rate_range() will use the last requested rate for the clock when it calls into the driver set_rate hook. However, if CLK_GET_RATE_NOCACHE is set on that clock, the last requested rate might not be matching the current rate of the clock. In such a case, let's read out the rate from the hardware and use that in our set_rate instead. Tested-by: Alexander Stein # imx8mp Tested-by: Marek Szyprowski # exynos4210, meson g12b Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20220816112530.1837489-13-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing Tested-by: Naresh Kamboju Signed-off-by: Stephen Boyd

clk: tests: Add some tests for orphan with multiple parents

2022-09-15T16:31:01+00:00

Let's leverage the dummy mux with multiple parents we have to create a mux whose default parent will never be registered, and thus will always be orphan by default. We can then create some tests to make sure that the clock API behaves properly in such a case, and that the transition to a non-orphan clock when we change the parent is done properly. Tested-by: Alexander Stein # imx8mp Tested-by: Marek Szyprowski # exynos4210, meson g12b Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20220816112530.1837489-12-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing Tested-by: Naresh Kamboju Signed-off-by: Stephen Boyd