clk: More clock rate fixes and tests
Subsystems (8)
v5 cover clk: More clock rate fixes and tests
Hi,
Thanks to the feedback I got on the previous series, I found and fixed a number of bugs in the clock framework and how it deals with rates, especially when it comes to orphan clocks.
In order to make sure this doesn't pop up again as a regression, I've extended the number of tests.
The first patch reintroduces the clk_set_rate_range call on clk_put, but this time will only do so if there was a range set on that clock to begin with. It should be less intrusive, and reduce the number of potential side effects considerably.
We then have a fix for the qcom rcg2 issue that has been reported recently, and two patches to address a regression with the RaspberryPi4.
All the other patches should be probably be flagged as fixes, but they've never seem to have shown any real-world issues until now, and they aren't all really trivial to backport either, so I'm not sure it's worth it.
There's also some documentation improvements for recalc_rate and clk_get_rate to hopefully make the documentation less ambiguous and acknowledge that recalc_rate() returning 0 on error is fine.
Let me know what you think,
Maxime
Changes from v4:
- Fix build breakage on SAM9x60
Changes from v3:
- constness warning fix in clk_core_forward_rate_req
Changes from v2:
- Rebased on top of current next
- Fixed locking issue in clk_get_rate_range
Changes from v1:
- Rebased on top of next-20220428
- Dropped the patch to prevent non-orphan clocks from registering if their recalc_rate hook returns 0
- Added some patches to clarify the clk_get_rate and recalc_rate documentation
- Dropped the patch to skip the range setup on an orphan clock that was introducing a regression on RaspberryPi3 when a monitor wasn't connected at boot
- Added a patch to skip the rate clamping in clk_round_rate() when
min_rate == max_rate == 0
- Added a new set of functions to query the clk boundaries and fix a regression with the RaspberryPi4
- Fixed all the drivers hand-crafting their clk_rate_request
- Reworded the test suite descriptions
- Reordered a few patches to ease the review
- Reworded some commit logs to better explain the issues they address
- Collected the Tested-by of Alexander and Marek
- More tests
Maxime Ripard (28):
clk: Drop the rate range on clk_put()
clk: Skip clamping when rounding if there's no boundaries
clk: Introduce clk_get_rate_range()
drm/vc4: hdmi: Rework hdmi_enable_4kp60 detection
clk: Mention that .recalc_rate can return 0 on error
clk: Clarify clk_get_rate() expectations
clk: tests: Add test suites description
clk: tests: Add reference to the orphan mux bug report
clk: tests: Add tests for uncached clock
clk: tests: Add tests for single parent mux
clk: tests: Add tests for mux with multiple parents
clk: tests: Add some tests for orphan with multiple parents
clk: Take into account uncached clocks in clk_set_rate_range()
clk: Fix clk_get_parent() documentation
clk: Set req_rate on reparenting
clk: Change clk_core_init_rate_req prototype
clk: Move clk_core_init_rate_req() from clk_core_round_rate_nolock()
to its caller
clk: Introduce clk_hw_init_rate_request()
clk: Add our request boundaries in clk_core_init_rate_req
clk: Switch from __clk_determine_rate to clk_core_round_rate_nolock
clk: Introduce clk_core_has_parent()
clk: Stop forwarding clk_rate_requests to the parent
clk: Zero the clk_rate_request structure
clk: Test the clock pointer in clk_hw_get_name()
clk: Introduce the clk_hw_get_rate_range function
clk: qcom: clk-rcg2: Take clock boundaries into consideration for
gfx3d
clk: tests: Add some tests for clk_get_rate_range()
clk: tests: Add missing test case for ranges
drivers/clk/at91/clk-generated.c | 5 +- drivers/clk/at91/clk-master.c | 9 +- drivers/clk/at91/clk-peripheral.c | 4 +- drivers/clk/clk-composite.c | 6 +- drivers/clk/clk-divider.c | 20 +- drivers/clk/clk.c | 304 ++++-- drivers/clk/clk_test.c | 1465 ++++++++++++++++++++++++++++- drivers/clk/qcom/clk-rcg2.c | 9 + drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +- include/linux/clk-provider.h | 18 +- include/linux/clk.h | 64 +- 11 files changed, 1814 insertions(+), 92 deletions(-)
Signature · 1 line
2.36.1
PATCH v5 1/28 clk: Drop the rate range on clk_put()
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.
--- drivers/clk/clk.c | 45 +++++++++++------ drivers/clk/clk_test.c | 108 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 139 insertions(+), 14 deletions(-)
drivers/clk/clk.c +31 -14
@@ -2325,19 +2325,15 @@ int clk_set_rate_exclusive(struct clk *clk, unsigned long rate) }EXPORT_SYMBOL_GPL (clk_set_rate_exclusive); -/** -* clk_set_rate_range - set a rate range for a clock source -* @clk: clock source -* @min: desired minimum clock rate in Hz, inclusive -* @max: desired maximum clock rate in Hz, inclusive -* -* Returns success (0) or negative errno. -*/ -int clk_set_rate_range (struct clk *clk,unsigned long min,unsigned long max) +static int clk_set_rate_range_nolock (struct clk *clk, +unsigned long min, +unsigned long max) {int ret =0 ;unsigned long old_min, old_max, rate; +lockdep_assert_held (&prepare_lock); +if (!clk)return 0 ;
@@ -2350,8 +2346,6 @@ int clk_set_rate_range(struct clk *clk, unsigned long min, unsigned long max)return -EINVAL ; } -clk_prepare_lock (); -if (clk->exclusive_count)clk_core_rate_unprotect (clk->core);
@@ -2395,6 +2389,28 @@ int clk_set_rate_range(struct clk *clk, unsigned long min, unsigned long max)if (clk->exclusive_count)clk_core_rate_protect (clk->core); +return ret; +} + +/** +* clk_set_rate_range - set a rate range for a clock source +* @clk: clock source +* @min: desired minimum clock rate in Hz, inclusive +* @max: desired maximum clock rate in Hz, inclusive +* +* Return: 0 for success or negative errno on failure. +*/ +int clk_set_rate_range (struct clk *clk,unsigned long min,unsigned long max) +{ +int ret; + +if (!clk) +return 0 ; + +clk_prepare_lock (); + + ret =clk_set_rate_range_nolock (clk, min, max); +clk_prepare_unlock ();return ret;
@@ -4396,9 +4412,10 @@ void __clk_put(struct clk *clk) }hlist_del (&clk->clks_node); -if (clk->min_rate > clk->core->req_rate || - clk->max_rate < clk->core->req_rate) -clk_core_set_rate_nolock (clk->core, clk->core->req_rate); + +/* If we had any boundaries on that clock, let's drop them. */ +if (clk->min_rate >0 || clk->max_rate <ULONG_MAX ) +clk_set_rate_range_nolock (clk,0 ,ULONG_MAX ); owner = clk->core->owner;kref_put (&clk->core->ref, __clk_release);
drivers/clk/clk_test.c +108 -0
126 lines not on this page · raw message
Signature · 1 line
2.36.1
PATCH v5 2/28 clk: Skip clamping when rounding if there's no boundaries
In reply to Maxime RipardCommit 948fb0969eae ("clk: Always clamp the rounded rate") recently started to clamp the request rate in the clk_rate_request passed as an argument of clk_core_determine_round_nolock() with the min_rate and max_rate fields of that same request.
While the clk_rate_requests created by the framework itself always have those fields set, some drivers will create it themselves and don't always fill min_rate and max_rate.
In such a case, we end up clamping the rate with a minimum and maximum of 0, thus always rounding the rate to 0.
Let's skip the clamping if both min_rate and max_rate are set to 0 and complain so that it gets fixed.
--- drivers/clk/clk.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)
drivers/clk/clk.c +13 -1
@@ -1341,7 +1341,19 @@ static int clk_core_determine_round_nolock(struct clk_core *core,if (!core)return 0 ; - req->rate =clamp (req->rate, req->min_rate, req->max_rate); +/* +* Some clock providers hand-craft their clk_rate_requests and +* might not fill min_rate and max_rate. +* +* If it's the case, clamping the rate is equivalent to setting +* the rate to 0 which is bad. Skip the clamping but complain so +* that it gets fixed, hopefully. +*/ +if (!req->min_rate && !req->max_rate) +pr_warn ("%s: %s: clk_rate_request has initialized min or max rate.\n" , + __func__, core->name); +else + req->rate =clamp (req->rate, req->min_rate, req->max_rate);/* * At this point, core protection will be disabled
Signature · 1 line
2.36.1
Stephen Boyd
maintainerRe: [PATCH v5 02/28] clk: Skip clamping when rounding if there's no boundaries
Quoting Maxime Ripard (2022-05-16 06:25:01)
Quoted 31 lines
Commit
948fb0969eae("clk: Always clamp the rounded rate") recently started to clamp the request rate in theclk_rate_requestpassed as an argument ofclk_core_determine_round_nolock()with themin_rateandmax_ratefields of that same request.While the
clk_rate_requestscreated by the framework itself always have those fields set, some drivers will create it themselves and don't always fillmin_rateandmax_rate.In such a case, we end up clamping the rate with a minimum and maximum of 0, thus always rounding the rate to 0.
Let's skip the clamping if both
min_rateandmax_rateare set to 0 and complain so that it gets fixed.Fixes 948fb0969eae ("clk: Always clamp the rounded rate")Signed-off-by Maxime Ripard <[email protected]>--- drivers/clk/clk.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)drivers/clk/clk.c +1
-1@@ -1341,7 +1341,19 @@ static int clk_core_determine_round_nolock(struct clk_core *core,if (!core)return 0 ; - req->rate =clamp (req->rate, req->min_rate, req->max_rate); +/*
drivers/clk/clk.c static int clk_core_determine_round_nolock(struct clk_core *core, · line 1354
Quoted 10 lines
drivers/clk/clk.c +10
-0+* Some clock providers hand-craft their clk_rate_requests and +* might not fill min_rate and max_rate. +* +* If it's the case, clamping the rate is equivalent to setting +* the rate to 0 which is bad. Skip the clamping but complain so +* that it gets fixed, hopefully. +*/ +if (!req->min_rate && !req->max_rate) +pr_warn ("%s: %s: clk_rate_request has initialized min or max rate.\n" , + __func__, core->name);
Is this going to trigger anytime soon? I'd prefer we return an error from here if the min/max is 0. The warning can stay. Also probably needs to be a pr_warn_once() or ratelimited because sometimes rate setting code is called very often.
Re: [PATCH v5 02/28] clk: Skip clamping when rounding if there's no boundaries
Hi Stephen,
Thanks for reviewing these patches
Quoted 30 lines · Stephen Boyd
Quoting Maxime Ripard (2022-05-16 06:25:01)
Quoted 29 lines
Commit
948fb0969eae("clk: Always clamp the rounded rate") recently started to clamp the request rate in theclk_rate_requestpassed as an argument ofclk_core_determine_round_nolock()with themin_rateandmax_ratefields of that same request.While the
clk_rate_requestscreated by the framework itself always have those fields set, some drivers will create it themselves and don't always fillmin_rateandmax_rate.In such a case, we end up clamping the rate with a minimum and maximum of 0, thus always rounding the rate to 0.
Let's skip the clamping if both
min_rateandmax_rateare set to 0 and complain so that it gets fixed.Fixes 948fb0969eae ("clk: Always clamp the rounded rate")Signed-off-by Maxime Ripard <[email protected]>--- drivers/clk/clk.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)drivers/clk/clk.c +0
-0@@ -1341,7 +1341,19 @@ static int clk_core_determine_round_nolock(struct clk_core *core,if (!core)return 0 ;
Quoted 14 lines
drivers/clk/clk.c static int clk_core_determine_round_nolock(struct clk_core *core, · line 1354
Quoted 12 lines
drivers/clk/clk.c +11
-1- req->rate =clamp (req->rate, req->min_rate, req->max_rate); +/* +* Some clock providers hand-craft their clk_rate_requests and +* might not fill min_rate and max_rate. +* +* If it's the case, clamping the rate is equivalent to setting +* the rate to 0 which is bad. Skip the clamping but complain so +* that it gets fixed, hopefully. +*/ +if (!req->min_rate && !req->max_rate) +pr_warn ("%s: %s: clk_rate_request has initialized min or max rate.\n" , + __func__, core->name);Is this going to trigger anytime soon?
drivers/clk/qcom/clk-rcg2.c was in this situation before
https://lore.kernel.org/all/[email protected]/
Other than this one, there's a few other drivers doing this too:
* drivers/clk/clk-divider.c
https://elixir.bootlin.com/linux/latest/source/drivers/clk/clk-divider.c#L389
https://elixir.bootlin.com/linux/latest/source/drivers/clk/clk-divider.c#L411
That one isn't really critical. divider_ro_round_rate_parent isn't used by anyone (as of 5.19-rc4), and divider_round_rate_parent is only used by drivers/clk/sunxi-ng/ccu_div.c.
This is then used by virtually all the Allwinner SoCs supported, but only for either internal bus clocks that are very unlikely to change their rate, DSI, CSI or I2S clocks. Fortunately for us, these are all fairly unusual on Allwinner devices. So the situation is likely to occur on those systems, but should still be fairly rare.
* drivers/clk/clk-composite.c
drivers/clk/at91/clk-generated.c
drivers/clk/at91/clk-master.c
drivers/clk/at91/clk-peripheral.c
All those will copy the request being passed. Since it comes from the framework, the boundaries are likely to be set but possibly wrong since they are the boundaries of the child clock, not the parent one.
That part is addressed later in this series:
https://lore.kernel.org/linux-clk/[email protected]/
So all in all, the impact should be fairly minimal, but it could still happen.
Quoted 3 lines
I'd prefer we return an error from here if the min/max is 0. The warning can stay. Also probably needs to be a
pr_warn_once()or ratelimited because sometimes rate setting code is called very often.
Yeah, that makes sense, I'll change it
Thanks!
Maxime
PATCH v5 3/28 clk: Introduce clk_get_rate_range()
In reply to Maxime RipardWith the recent introduction of clock drivers that will force their clock rate to either the minimum or maximum boundaries, it becomes harder for clock users to discover either boundary of their clock.
Indeed, the best way to do that previously was to call clk_round_rate() on either 0 or ULONG_MAX and count on the driver to clamp the rate to the current boundary, but that won't work anymore.
Since any other alternative (calling clk_set_rate_range() and looking at the returned value, calling clk_round_rate() still, or just doing nothing) depends on how the driver will behaves, we actually are punching a hole through the abstraction provided by the clock framework.
In order to avoid any abstraction violation, let's create a bunch of accessors that will return the current minimum and maximum for a given clock.
--- drivers/clk/clk.c | 20 +++++++++++++++ include/linux/clk.h | 59 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 79 insertions(+)
drivers/clk/clk.c +20 -0
@@ -2465,6 +2465,26 @@ int clk_set_max_rate(struct clk *clk, unsigned long rate) }EXPORT_SYMBOL_GPL (clk_set_max_rate); +/** +* clk_get_rate_range - returns the clock rate range for a clock source +* @clk: clock source +* @min: Pointer to the variable that will hold the minimum +* @max: Pointer to the variable that will hold the maximum +* +* Fills the @min and @max variables with the minimum and maximum that +* the clock source can reach. +*/ +void clk_get_rate_range (struct clk *clk,unsigned long *min,unsigned long *max) +{ +if (!clk || !min || !max) +return ; + +clk_prepare_lock (); +clk_core_get_boundaries (clk->core, min, max); +clk_prepare_unlock (); +} +EXPORT_SYMBOL_GPL (clk_get_rate_range); +/** * clk_get_parent - return the parent of a clk * @clk: the clk whose parent gets returned
include/linux/clk.h +59 -0
77 lines not on this page · raw message
Signature · 1 line
2.36.1
Stephen Boyd
maintainerRe: [PATCH v5 03/28] clk: Introduce clk_get_rate_range()
Quoting Maxime Ripard (2022-05-16 06:25:02)
Quoted 8 lines
With the recent introduction of clock drivers that will force their clock rate to either the minimum or maximum boundaries, it becomes harder for clock users to discover either boundary of their clock.
Indeed, the best way to do that previously was to call
clk_round_rate()on either 0 orULONG_MAXand count on the driver to clamp the rate to the current boundary, but that won't work anymore.
Quoted 8 lines
Since any other alternative (calling
clk_set_rate_range()and looking at the returned value, callingclk_round_rate()still, or just doing nothing) depends on how the driver will behaves, we actually are punching a hole through the abstraction provided by the clock framework.In order to avoid any abstraction violation, let's create a bunch of accessors that will return the current minimum and maximum for a given clock.
Why does a clk consumer need to know the rate range? I don't see any information in the commit text about that.
PATCH v5 4/28 drm/vc4: hdmi: Rework hdmi_enable_4kp60 detection
In reply to Maxime RipardIn order to support higher HDMI frequencies, users have to set the hdmi_enable_4kp60 parameter in their config.txt file.
We were detecting this so far by calling clk_round_rate() on the core clock with the frequency we're supposed to run at when one of those modes is enabled. Whether or not the parameter was enabled could then be inferred by the returned rate since the maximum clock rate reported by the firmware was one of the side effect of setting that parameter.
However, the recent clock rework we did changed what clk_round_rate() was returning to always return the minimum allowed, and thus this test wasn't reliable anymore.
Let's use the new clk_get_max_rate() function to reliably determine the maximum rate allowed on that clock and fix the 4k@60Hz output.
--- drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/vc4/vc4_hdmi.c +1 -1
@@ -2891,7 +2891,7 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data)if (variant->max_pixel_clock ==600000000 ) {struct vc4_dev *vc4 =to_vc4_dev (drm); -long max_rate =clk_round_rate (vc4->hvs->core_clk,550000000 ); +unsigned long max_rate =clk_get_max_rate (vc4->hvs->core_clk);if (max_rate <550000000 ) vc4_hdmi->disable_4kp60 = true;
Signature · 1 line
2.36.1
Stephen Boyd
maintainerRe: [PATCH v5 04/28] drm/vc4: hdmi: Rework hdmi_enable_4kp60 detection
Quoting Maxime Ripard (2022-05-16 06:25:03)
Quoted 27 lines
In order to support higher HDMI frequencies, users have to set the
hdmi_enable_4kp60parameter in their config.txt file.We were detecting this so far by calling
clk_round_rate()on the core clock with the frequency we're supposed to run at when one of those modes is enabled. Whether or not the parameter was enabled could then be inferred by the returned rate since the maximum clock rate reported by the firmware was one of the side effect of setting that parameter.However, the recent clock rework we did changed what
clk_round_rate()was returning to always return the minimum allowed, and thus this test wasn't reliable anymore.Let's use the new
clk_get_max_rate()function to reliably determine the maximum rate allowed on that clock and fix the 4k@60Hz output.Fixes e9d6cea2af1c ("clk: bcm: rpi: Run some clocks at the minimum rate allowed")Signed-off-by Maxime Ripard <[email protected]>--- drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/gpu/drm/vc4/vc4_hdmi.c +0
-0
drivers/gpu/drm/vc4/vc4_hdmi.c static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data) · line 2894
Quoted 5 lines
drivers/gpu/drm/vc4/vc4_hdmi.c +1
-1@@ -2891,7 +2891,7 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data)if (variant->max_pixel_clock ==600000000 ) {struct vc4_dev *vc4 =to_vc4_dev (drm); -long max_rate =clk_round_rate (vc4->hvs->core_clk,550000000 ); +unsigned long max_rate =clk_get_max_rate (vc4->hvs->core_clk);
Ok, so this driver must want the new API.
What is happening here though? The driver is setting 'disable_4kp60' at bind/probe time based on a clk_round_rate() returning a frequency. That returned value could change at runtime though based on rate constraints, or simply because the clk driver decides that the wind is blowing differently today and thus calling clk_set_rate() with that frequency will cause the clk to be wildly different than before.
I don't understand how we can decide to disable 4kp60 at probe time. Why doesn't the driver try to set the rate it wants (or the rate range it wants) and then if that succeeds it knows 4kp60 is achievable and if not then it rejects the attempt by userspace to set such a resolution.
Re: [PATCH v5 04/28] drm/vc4: hdmi: Rework hdmi_enable_4kp60 detection
Hi,
Quoted 36 lines · Stephen Boyd
Quoting Maxime Ripard (2022-05-16 06:25:03)
Quoted 27 lines
In order to support higher HDMI frequencies, users have to set the
hdmi_enable_4kp60parameter in their config.txt file.We were detecting this so far by calling
clk_round_rate()on the core clock with the frequency we're supposed to run at when one of those modes is enabled. Whether or not the parameter was enabled could then be inferred by the returned rate since the maximum clock rate reported by the firmware was one of the side effect of setting that parameter.However, the recent clock rework we did changed what
clk_round_rate()was returning to always return the minimum allowed, and thus this test wasn't reliable anymore.Let's use the new
clk_get_max_rate()function to reliably determine the maximum rate allowed on that clock and fix the 4k@60Hz output.Fixes e9d6cea2af1c ("clk: bcm: rpi: Run some clocks at the minimum rate allowed")Signed-off-by Maxime Ripard <[email protected]>--- drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/gpu/drm/vc4/vc4_hdmi.c +0
-0drivers/gpu/drm/vc4/vc4_hdmi.c static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data) · line 2894
Quoted 5 lines
drivers/gpu/drm/vc4/vc4_hdmi.c +1
-1@@ -2891,7 +2891,7 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data)if (variant->max_pixel_clock ==600000000 ) {struct vc4_dev *vc4 =to_vc4_dev (drm); -long max_rate =clk_round_rate (vc4->hvs->core_clk,550000000 ); +unsigned long max_rate =clk_get_max_rate (vc4->hvs->core_clk);Ok, so this driver must want the new API.
Quoted 2 lines
What is happening here though? The driver is setting '
disable_4kp60' at bind/probe time based on aclk_round_rate()returning a frequency.
The main issue that we're trying to address is that whether or not HDMI modes with a rate over 340MHz (so most likely 4k/60Hz but others are affected) need a bootloader parameter to be set. If it isn't set, we can't output those modes.
Since it's a bootloader parameter though the kernel can't access it. The main hint that we can use to figure out whether it's been enabled is that the maximum clock frequency reported by the firmware will be higher. So this code will try to round a frequency higher than the maximum allowed when that setting isn't there, and thus figure out whether it's enabled or not.
If it's not, we prevent any of these modes from being exposed to userspace or being used.
Quoted 4 lines
That returned value could change at runtime though based on rate constraints, or simply because the clk driver decides that the wind is blowing differently today and thus calling
clk_set_rate()with that frequency will cause the clk to be wildly different than before.
Yeah, that's true
Quoted 1 line
I don't understand how we can decide to disable 4kp60 at probe time.
We're trying to infer a bootloader/firmware parameter, so the only way it can change is through a reboot.
Quoted 4 lines
Why doesn't the driver try to set the rate it wants (or the rate range it wants) and then if that succeeds it knows 4kp60 is achievable and if not then it rejects the attempt by userspace to set such a resolution.
We can't really do that. The clock here drives the HDMI output so it can only change when we change the mode. However, because of the atomic commits in KMS, we can't fail when we actually change the mode, we have to fail beforehand when we check that the new state is sane.
We also can't change the clock rate then, because there's no guarantee that the state being checked is actually going to be committed, and because we still have the hardware running when we check it so we would modify the clock while the hardware is running.
I had another go in the RaspberryPi downstream kernel for this:
https://github.com/raspberrypi/linux/commit/df368502ecbe1de26cf02a9b7837da9e967d64ca
Would that be preferable?
Maxime
Stephen Boyd
maintainerRe: [PATCH v5 04/28] drm/vc4: hdmi: Rework hdmi_enable_4kp60 detection
Quoting Maxime Ripard (2022-06-28 02:47:53)
Quoted 14 lines
Hi,
Quoted 5 lines · Stephen Boyd
Ok, so this driver must want the new API.
What is happening here though? The driver is setting '
disable_4kp60' at bind/probe time based on aclk_round_rate()returning a frequency.The main issue that we're trying to address is that whether or not HDMI modes with a rate over 340MHz (so most likely 4k/60Hz but others are affected) need a bootloader parameter to be set. If it isn't set, we can't output those modes.
Quoted 6 lines
Since it's a bootloader parameter though the kernel can't access it. The main hint that we can use to figure out whether it's been enabled is that the maximum clock frequency reported by the firmware will be higher. So this code will try to round a frequency higher than the maximum allowed when that setting isn't there, and thus figure out whether it's enabled or not.
So the kernel is at least able to ask for the max frequency during rounding and figure out that the frequency can't be larger than that. Is that right?
Quoted 9 lines
If it's not, we prevent any of these modes from being exposed to userspace or being used.
Quoted 4 lines
That returned value could change at runtime though based on rate constraints, or simply because the clk driver decides that the wind is blowing differently today and thus calling
clk_set_rate()with that frequency will cause the clk to be wildly different than before.
Quoted 6 lines
Yeah, that's true
Quoted 1 line
I don't understand how we can decide to disable 4kp60 at probe time.
We're trying to infer a bootloader/firmware parameter, so the only way it can change is through a reboot.
Got it.
Quoted 10 lines
Quoted 5 lines
Why doesn't the driver try to set the rate it wants (or the rate range it wants) and then if that succeeds it knows 4kp60 is achievable and if not then it rejects the attempt by userspace to set such a resolution.
We can't really do that. The clock here drives the HDMI output so it can only change when we change the mode. However, because of the atomic commits in KMS, we can't fail when we actually change the mode, we have to fail beforehand when we check that the new state is sane.
Alright. I feel like we've discussed this before.
Quoted 9 lines
We also can't change the clock rate then, because there's no guarantee that the state being checked is actually going to be committed, and because we still have the hardware running when we check it so we would modify the clock while the hardware is running.
I had another go in the RaspberryPi downstream kernel for this:
https://github.com/raspberrypi/linux/commit/df368502ecbe1de26cf02a9b7837da9e967d64ca
It really looks to me like we're trying to hide the firmware API behind the clk API. When the clk API doesn't provide what's needed, we add an API to expose internal clk details that the clk consumer should already know because it sets them. That's my main concern here. The driver is querying an OPP table through the clk framework.
Why can't we either expose the firmware API directly to this driver or have the firmware driver probe and populate/trim an OPP table for this display device so that it can query the OPP table at probe time to determine the maximum frequency supported. The clk framework isn't in the business of exposing OPP tables, that's what the OPP framework is for.
Re: [PATCH v5 04/28] drm/vc4: hdmi: Rework hdmi_enable_4kp60 detection
Quoted 22 lines · Stephen Boyd
Quoting Maxime Ripard (2022-06-28 02:47:53)
Quoted 14 lines
Hi,
Quoted 5 lines · Stephen Boyd
Ok, so this driver must want the new API.
What is happening here though? The driver is setting '
disable_4kp60' at bind/probe time based on aclk_round_rate()returning a frequency.The main issue that we're trying to address is that whether or not HDMI modes with a rate over 340MHz (so most likely 4k/60Hz but others are affected) need a bootloader parameter to be set. If it isn't set, we can't output those modes.
Quoted 6 lines
Since it's a bootloader parameter though the kernel can't access it. The main hint that we can use to figure out whether it's been enabled is that the maximum clock frequency reported by the firmware will be higher. So this code will try to round a frequency higher than the maximum allowed when that setting isn't there, and thus figure out whether it's enabled or not.
Quoted 3 lines
So the kernel is at least able to ask for the max frequency during rounding and figure out that the frequency can't be larger than that. Is that right?
Yes, the firmware has a call that allows to query the boundaries of a given clock it manages, and we then used whatever value it returns to set the clk_hw rate range.
See https://elixir.bootlin.com/linux/latest/source/drivers/clk/bcm/clk-raspberrypi.c#L287
Quoted 36 lines
Quoted 8 lines
If it's not, we prevent any of these modes from being exposed to userspace or being used.
Quoted 4 lines
That returned value could change at runtime though based on rate constraints, or simply because the clk driver decides that the wind is blowing differently today and thus calling
clk_set_rate()with that frequency will cause the clk to be wildly different than before.Quoted 6 lines
Yeah, that's true
Quoted 1 line
I don't understand how we can decide to disable 4kp60 at probe time.
We're trying to infer a bootloader/firmware parameter, so the only way it can change is through a reboot.
Got it.
Quoted 10 lines
Quoted 5 lines
Why doesn't the driver try to set the rate it wants (or the rate range it wants) and then if that succeeds it knows 4kp60 is achievable and if not then it rejects the attempt by userspace to set such a resolution.
We can't really do that. The clock here drives the HDMI output so it can only change when we change the mode. However, because of the atomic commits in KMS, we can't fail when we actually change the mode, we have to fail beforehand when we check that the new state is sane.
Alright. I feel like we've discussed this before.
Quoted 6 lines
We also can't change the clock rate then, because there's no guarantee that the state being checked is actually going to be committed, and because we still have the hardware running when we check it so we would modify the clock while the hardware is running.
Quoted 8 lines
Quoted 3 lines
I had another go in the RaspberryPi downstream kernel for this:
https://github.com/raspberrypi/linux/commit/df368502ecbe1de26cf02a9b7837da9e967d64caIt really looks to me like we're trying to hide the firmware API behind the clk API. When the clk API doesn't provide what's needed, we add an API to expose internal clk details that the clk consumer should already know because it sets them.
That would work for me
Quoted 9 lines
That's my main concern here. The driver is querying an OPP table through the clk framework.
Why can't we either expose the firmware API directly to this driver or have the firmware driver probe and populate/trim an OPP table for this display device so that it can query the OPP table at probe time to determine the maximum frequency supported. The clk framework isn't in the business of exposing OPP tables, that's what the OPP framework is for.
Is it really an OPP?
My understanding at least is that an OPP table is a discrete set of frequencies that a device can operate at, but you still need the frequency generator somewhere else?
What we're discussing here definitely looks more like a clock to me:
it's is the frequency generator, and can expose a continuous set of frequencies between a range. It just turns out that depending on a parameter that range changes a bit, and it then affect our capabilities.
Maxime
PATCH v5 5/28 clk: Mention that .recalc_rate can return 0 on error
In reply to Maxime RipardMultiple platforms (amlogic, imx8) return 0 when the clock rate cannot be determined properly by the recalc_rate hook. Mention in the documentation that the framework is ok with that.
--- include/linux/clk-provider.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
include/linux/clk-provider.h +3 -2
@@ -118,8 +118,9 @@ struct clk_duty {* * @recalc_rate Recalculate the rate of this clock, by querying hardware. The * parent rate is an input parameter. It is up to the caller to -* ensure that the prepare_mutex is held across this call. -* Returns the calculated rate. Optional, but recommended - if +* ensure that the prepare_mutex is held across this call. If the +* driver cannot figure out a rate for this clock, it must return +* 0. Returns the calculated rate. Optional, but recommended - if * this op is not set then clock rate will be initialized to 0. * * @round_rate: Given a target rate as input, returns the closest rate actually
Signature · 1 line
2.36.1
PATCH v5 6/28 clk: Clarify clk_get_rate() expectations
In reply to Maxime RipardAs shown by a number of clock users already, clk_get_rate() can be called whether or not the clock is enabled.
Similarly, a number of clock drivers will return a rate of 0 whenever the rate cannot be figured out.
Since it was a bit ambiguous before, let's make it clear in the clk_get_rate() documentation.
--- drivers/clk/clk.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/clk/clk.c +3 -2
@@ -1672,8 +1672,9 @@ static unsigned long clk_core_get_rate_recalc(struct clk_core *core)* @clk: the clk whose rate is being returned * * Simply returns the cached rate of the clk, unless CLK_GET_RATE_NOCACHE flag -* is set, which means a recalc_rate will be issued. -* If clk is NULL then returns 0. +* is set, which means a recalc_rate will be issued. Can be called regardless of +* the clock enabledness. If clk is NULL, or if an error occurred, then returns +* 0. */ unsigned long clk_get_rate (struct clk *clk) {
Signature · 1 line
2.36.1
PATCH v5 7/28 clk: tests: Add test suites description
In reply to Maxime RipardWe start to have a few test suites, and we'll add more, so it will get pretty confusing to figure out what is supposed to be tested in what suite.
Let's add some comments to explain what setup they create, and what we should be testing in every suite.
--- drivers/clk/clk_test.c | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
drivers/clk/clk_test.c +33 -0
@@ -250,6 +250,11 @@ static struct kunit_case clk_test_cases[] = { {} }; +/* +* Test suite for a basic rate clock, without any parent. +* +* These tests exercise the rate API with simple scenarios +*/ static struct kunit_suite clk_test_suite = { .name ="clk-test" , .init = clk_test_init,
@@ -336,6 +341,14 @@ static struct kunit_case clk_orphan_transparent_single_parent_mux_test_cases[] = {} }; +/* +* Test suite for a basic mux clock with one parent. The parent is +* registered after its child. The clock will thus be an orphan when +* registered, but will no longer be when the tests run. +* +* These tests make sure a clock that used to be orphan has a sane, +* consistent, behaviour. +*/ static struct kunit_suite clk_orphan_transparent_single_parent_test_suite = { .name ="clk-orphan-transparent-single-parent-test" , .init = clk_orphan_transparent_single_parent_mux_test_init,
@@ -645,6 +658,12 @@ static struct kunit_case clk_range_test_cases[] = { {} }; +/* +* Test suite for a basic rate clock, without any parent. +* +* These tests exercise the rate range API: clk_set_rate_range(), +* clk_set_min_rate(), clk_set_max_rate(), clk_drop_range(). +*/ static struct kunit_suite clk_range_test_suite = { .name ="clk-range-test" , .init = clk_test_init,
@@ -822,6 +841,13 @@ static struct kunit_case clk_range_maximize_test_cases[] = { {} }; +/* +* Test suite for a basic rate clock, without any parent. +* +* These tests exercise the rate range API: clk_set_rate_range(), +* clk_set_min_rate(), clk_set_max_rate(), clk_drop_range(), with a +* driver that will always try to run at the highest possible rate. +*/ static struct kunit_suite clk_range_maximize_test_suite = { .name ="clk-range-maximize-test" , .init = clk_maximize_test_init,
@@ -991,6 +1017,13 @@ static struct kunit_case clk_range_minimize_test_cases[] = { {} }; +/* +* Test suite for a basic rate clock, without any parent. +* +* These tests exercise the rate range API: clk_set_rate_range(), +* clk_set_min_rate(), clk_set_max_rate(), clk_drop_range(), with a +* driver that will always try to run at the lowest possible rate. +*/ static struct kunit_suite clk_range_minimize_test_suite = { .name ="clk-range-minimize-test" , .init = clk_minimize_test_init,
Signature · 1 line
2.36.1
PATCH v5 8/28 clk: tests: Add reference to the orphan mux bug report
In reply to Maxime RipardSome more context might be useful for unit-tests covering a previously reported bug, so let's add a link to the discussion for that bug.
--- drivers/clk/clk_test.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/clk/clk_test.c +3 -0
@@ -314,6 +314,9 @@ static void clk_orphan_transparent_single_parent_mux_test_exit(struct kunit *tes/* * Test that a mux-only clock, with an initial rate within a range, * will still have the same rate after the range has been enforced. +* +* See: +* https://lore.kernel.org/linux-clk/[email protected]/ */ static void clk_test_orphan_transparent_parent_mux_set_range (struct kunit *test) {
Signature · 1 line
2.36.1
PATCH v5 9/28 clk: tests: Add tests for uncached clock
In reply to Maxime RipardThe 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.
--- drivers/clk/clk_test.c | 88 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 87 insertions(+), 1 deletion(-)
drivers/clk/clk_test.c +87 -1
@@ -262,6 +262,91 @@ static struct kunit_suite clk_test_suite = { .test_cases = clk_test_cases, }; +static int clk_uncached_test_init (struct kunit *test) +{ +struct clk_dummy_context *ctx; +int ret; + + ctx =kunit_kzalloc (test,sizeof (*ctx),GFP_KERNEL ); +if (!ctx) +return -ENOMEM ; + test->priv = ctx; + + ctx->rate =DUMMY_CLOCK_INIT_RATE ; + ctx->hw.init =CLK_HW_INIT_NO_PARENT ("test-clk" , + &clk_dummy_rate_ops, +CLK_GET_RATE_NOCACHE ); + + ret =clk_hw_register (NULL , &ctx->hw); +if (ret) +return ret; + +return 0 ; +} + +/* +* Test that for an uncached clock, the clock framework doesn't cache +* the rate and clk_get_rate() will return the underlying clock rate +* even if it changed. +*/ +static void clk_test_uncached_get_rate (struct kunit *test) +{ +struct clk_dummy_context *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +unsigned long rate; + + rate =clk_get_rate (clk); +KUNIT_ASSERT_GT (test, rate,0 ); +KUNIT_EXPECT_EQ (test, rate,DUMMY_CLOCK_INIT_RATE ); + + ctx->rate =DUMMY_CLOCK_RATE_1 ; + rate =clk_get_rate (clk); +KUNIT_ASSERT_GT (test, rate,0 ); +KUNIT_EXPECT_EQ (test, rate,DUMMY_CLOCK_RATE_1 ); +} + +/* +* Test that for an uncached clock, clk_set_rate_range() will work +* properly if the rate hasn't changed. +*/ +static void clk_test_uncached_set_range (struct kunit *test) +{ +struct clk_dummy_context *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +unsigned long rate; + +KUNIT_ASSERT_EQ (test, +clk_set_rate_range (clk, +DUMMY_CLOCK_RATE_1 , +DUMMY_CLOCK_RATE_2 ), +0 ); + + rate =clk_get_rate (clk); +KUNIT_ASSERT_GT (test, rate,0 ); +KUNIT_EXPECT_GE (test, rate,DUMMY_CLOCK_RATE_1 ); +KUNIT_EXPECT_LE (test, rate,DUMMY_CLOCK_RATE_2 ); +} + +static struct kunit_case clk_uncached_test_cases[] = { +KUNIT_CASE (clk_test_uncached_get_rate), +KUNIT_CASE (clk_test_uncached_set_range), + {} +}; + +/* +* Test suite for a basic, uncached, rate clock, without any parent. +* +* These tests exercise the rate API with simple scenarios +*/ +static struct kunit_suite clk_uncached_test_suite = { + .name ="clk-uncached-test" , + .init = clk_uncached_test_init, + .exit = clk_test_exit, + .test_cases = clk_uncached_test_cases, +}; +struct clk_single_parent_ctx {struct clk_dummy_context parent_ctx;struct clk_hw hw;
@@ -1039,6 +1124,7 @@ kunit_test_suites( &clk_orphan_transparent_single_parent_test_suite, &clk_range_test_suite, &clk_range_maximize_test_suite, - &clk_range_minimize_test_suite + &clk_range_minimize_test_suite, + &clk_uncached_test_suite );MODULE_LICENSE ("GPL v2" );
Signature · 1 line
2.36.1
PATCH v5 10/28 clk: tests: Add tests for single parent mux
In reply to Maxime RipardWe have a few tests for a mux with a single parent, testing the case where it used to be orphan.
Let's leverage most of the code but register the clock properly to test a few trivial things.
--- drivers/clk/clk_test.c | 186 +++++++++++++++++++++++++++++++++++++++-- 1 file changed, 177 insertions(+), 9 deletions(-)
drivers/clk/clk_test.c +177 -9
@@ -352,6 +352,181 @@ struct clk_single_parent_ctx {struct clk_hw hw; }; +static int clk_single_parent_mux_test_init (struct kunit *test) +{ +struct clk_single_parent_ctx *ctx; +int ret; + + ctx =kunit_kzalloc (test,sizeof (*ctx),GFP_KERNEL ); +if (!ctx) +return -ENOMEM ; + test->priv = ctx; + + ctx->parent_ctx.rate =DUMMY_CLOCK_INIT_RATE ; + ctx->parent_ctx.hw.init = +CLK_HW_INIT_NO_PARENT ("parent-clk" , + &clk_dummy_rate_ops, +0 ); + + ret =clk_hw_register (NULL , &ctx->parent_ctx.hw); +if (ret) +return ret; + + ctx->hw.init =CLK_HW_INIT ("test-clk" ,"parent-clk" , + &clk_dummy_single_parent_ops, +CLK_SET_RATE_PARENT ); + + ret =clk_hw_register (NULL , &ctx->hw); +if (ret) +return ret; + +return 0 ; +} + +static void +clk_single_parent_mux_test_exit (struct kunit *test) +{ +struct clk_single_parent_ctx *ctx = test->priv; + +clk_hw_unregister (&ctx->hw); +clk_hw_unregister (&ctx->parent_ctx.hw); +} + +/* +* Test that for a clock with a single parent, clk_get_parent() actually +* returns the parent. +*/ +static void +clk_test_single_parent_mux_get_parent (struct kunit *test) +{ +struct clk_single_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +struct clk *parent; + + parent =clk_get_parent (clk); +KUNIT_EXPECT_TRUE (test,clk_is_match (parent, ctx->parent_ctx.hw.clk)); +} + +/* +* Test that for a clock that can't modify its rate and with a single +* parent, if we set disjoints range on the parent and then the child, +* the second will return an error. +* +* FIXME: clk_set_rate_range() only considers the current clock when +* evaluating whether ranges are disjoints and not the upstream clocks +* ranges. +*/ +static void +clk_test_single_parent_mux_set_range_disjoint_child_last (struct kunit *test) +{ +struct clk_single_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +struct clk *parent; +int ret; + +kunit_skip (test,"This needs to be fixed in the core." ); + + parent =clk_get_parent (clk); +KUNIT_ASSERT_PTR_NE (test, parent,NULL ); + + ret =clk_set_rate_range (parent,1000 ,2000 ); +KUNIT_ASSERT_EQ (test, ret,0 ); + + ret =clk_set_rate_range (clk,3000 ,4000 ); +KUNIT_EXPECT_LT (test, ret,0 ); +} + +/* +* Test that for a clock that can't modify its rate and with a single +* parent, if we set disjoints range on the child and then the parent, +* the second will return an error. +* +* FIXME: clk_set_rate_range() only considers the current clock when +* evaluating whether ranges are disjoints and not the downstream clocks +* ranges. +*/ +static void +clk_test_single_parent_mux_set_range_disjoint_parent_last (struct kunit *test) +{ +struct clk_single_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +struct clk *parent; +int ret; + +kunit_skip (test,"This needs to be fixed in the core." ); + + parent =clk_get_parent (clk); +KUNIT_ASSERT_PTR_NE (test, parent,NULL ); + + ret =clk_set_rate_range (clk,1000 ,2000 ); +KUNIT_ASSERT_EQ (test, ret,0 ); + + ret =clk_set_rate_range (parent,3000 ,4000 ); +KUNIT_EXPECT_LT (test, ret,0 ); +} + +/* +* Test that for a clock that can't modify its rate and with a single +* parent, if we set a range on the parent and a more restrictive one on +* the child, and then call clk_round_rate(), the boundaries of the +* two clocks are taken into account. +*/ +static void +clk_test_single_parent_mux_set_range_round_rate_child_smaller (struct kunit *test) +{ +struct clk_single_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +struct clk *parent; +unsigned long rate; +int ret; + + parent =clk_get_parent (clk); +KUNIT_ASSERT_PTR_NE (test, parent,NULL ); + + ret =clk_set_rate_range (parent,DUMMY_CLOCK_RATE_1 ,DUMMY_CLOCK_RATE_2 ); +KUNIT_ASSERT_EQ (test, ret,0 ); + + ret =clk_set_rate_range (clk,DUMMY_CLOCK_RATE_1 +1000 ,DUMMY_CLOCK_RATE_2 -1000 ); +KUNIT_ASSERT_EQ (test, ret,0 ); + + rate =clk_round_rate (clk,DUMMY_CLOCK_RATE_1 -1000 ); +KUNIT_ASSERT_GT (test, rate,0 ); +KUNIT_EXPECT_GE (test, rate,DUMMY_CLOCK_RATE_1 +1000 ); +KUNIT_EXPECT_LE (test, rate,DUMMY_CLOCK_RATE_2 -1000 ); + + rate =clk_round_rate (clk,DUMMY_CLOCK_RATE_2 +1000 ); +KUNIT_ASSERT_GT (test, rate,0 ); +KUNIT_EXPECT_GE (test, rate,DUMMY_CLOCK_RATE_1 +1000 ); +KUNIT_EXPECT_LE (test, rate,DUMMY_CLOCK_RATE_2 -1000 ); +} + +static struct kunit_case clk_single_parent_mux_test_cases[] = { +KUNIT_CASE (clk_test_single_parent_mux_get_parent), +KUNIT_CASE (clk_test_single_parent_mux_set_range_disjoint_child_last), +KUNIT_CASE (clk_test_single_parent_mux_set_range_disjoint_parent_last), +KUNIT_CASE (clk_test_single_parent_mux_set_range_round_rate_child_smaller), + {} +}; + +/* +* Test suite for a basic mux clock with one parent, with +* CLK_SET_RATE_PARENT on the child. +* +* These tests exercise the consumer API and check that the state of the +* child and parent are sane and consistent. +*/ +static struct kunit_suite +clk_single_parent_mux_test_suite = { + .name ="clk-single-parent-mux-test" , + .init = clk_single_parent_mux_test_init, + .exit = clk_single_parent_mux_test_exit, + .test_cases = clk_single_parent_mux_test_cases, +}; +static int clk_orphan_transparent_single_parent_mux_test_init (struct kunit *test) {struct clk_single_parent_ctx *ctx;
@@ -388,14 +563,6 @@ static int clk_orphan_transparent_single_parent_mux_test_init(struct kunit *testreturn 0 ; } -static void clk_orphan_transparent_single_parent_mux_test_exit (struct kunit *test) -{ -struct clk_single_parent_ctx *ctx = test->priv; - -clk_hw_unregister (&ctx->hw); -clk_hw_unregister (&ctx->parent_ctx.hw); -} -/* * Test that a mux-only clock, with an initial rate within a range, * will still have the same rate after the range has been enforced.
@@ -440,7 +607,7 @@ static struct kunit_case clk_orphan_transparent_single_parent_mux_test_cases[] =static struct kunit_suite clk_orphan_transparent_single_parent_test_suite = { .name ="clk-orphan-transparent-single-parent-test" , .init = clk_orphan_transparent_single_parent_mux_test_init, - .exit = clk_orphan_transparent_single_parent_mux_test_exit, + .exit = clk_single_parent_mux_test_exit, .test_cases = clk_orphan_transparent_single_parent_mux_test_cases, };
@@ -1125,6 +1292,7 @@ kunit_test_suites( &clk_range_test_suite, &clk_range_maximize_test_suite, &clk_range_minimize_test_suite, + &clk_single_parent_mux_test_suite, &clk_uncached_test_suite );MODULE_LICENSE ("GPL v2" );
Signature · 1 line
2.36.1
PATCH v5 11/28 clk: tests: Add tests for mux with multiple parents
In reply to Maxime RipardWe'll need to test a few corner cases that occur when we have a mux clock whose default parent is missing.
For now, let's create the context structure and the trivial ops, along with a test suite that just tests trivial things for now, without considering the orphan case.
--- drivers/clk/clk_test.c | 119 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 119 insertions(+)
drivers/clk/clk_test.c +119 -0
@@ -108,6 +108,39 @@ static const struct clk_ops clk_dummy_single_parent_ops = { .get_parent = clk_dummy_single_get_parent, }; +struct clk_multiple_parent_ctx { +struct clk_dummy_context parents_ctx[2 ]; +struct clk_hw hw; +u8 current_parent; +}; + +static int clk_multiple_parents_mux_set_parent (struct clk_hw *hw,u8 index) +{ +struct clk_multiple_parent_ctx *ctx = + container_of(hw, struct clk_multiple_parent_ctx, hw); + +if (index >=clk_hw_get_num_parents (hw)) +return -EINVAL ; + + ctx->current_parent = index; + +return 0 ; +} + +static u8 clk_multiple_parents_mux_get_parent (struct clk_hw *hw) +{ +struct clk_multiple_parent_ctx *ctx = + container_of(hw, struct clk_multiple_parent_ctx, hw); + +return ctx->current_parent; +} + +static const struct clk_ops clk_multiple_parents_mux_ops = { + .get_parent = clk_multiple_parents_mux_get_parent, + .set_parent = clk_multiple_parents_mux_set_parent, + .determine_rate = __clk_mux_determine_rate_closest, +}; +static int clk_test_init_with_ops (struct kunit *test,const struct clk_ops *ops) {struct clk_dummy_context *ctx;
@@ -347,6 +380,91 @@ static struct kunit_suite clk_uncached_test_suite = { .test_cases = clk_uncached_test_cases, }; +static int +clk_multiple_parents_mux_test_init (struct kunit *test) +{ +struct clk_multiple_parent_ctx *ctx; +const char *parents[2 ] = {"parent-0" ,"parent-1" }; +int ret; + + ctx =kunit_kzalloc (test,sizeof (*ctx),GFP_KERNEL ); +if (!ctx) +return -ENOMEM ; + test->priv = ctx; + + ctx->parents_ctx[0 ].hw.init =CLK_HW_INIT_NO_PARENT ("parent-0" , + &clk_dummy_rate_ops, +0 ); + ctx->parents_ctx[0 ].rate =DUMMY_CLOCK_RATE_1 ; + ret =clk_hw_register (NULL , &ctx->parents_ctx[0 ].hw); +if (ret) +return ret; + + ctx->parents_ctx[1 ].hw.init =CLK_HW_INIT_NO_PARENT ("parent-1" , + &clk_dummy_rate_ops, +0 ); + ctx->parents_ctx[1 ].rate =DUMMY_CLOCK_RATE_2 ; + ret =clk_hw_register (NULL , &ctx->parents_ctx[1 ].hw); +if (ret) +return ret; + + ctx->current_parent =0 ; + ctx->hw.init =CLK_HW_INIT_PARENTS ("test-mux" , parents, + &clk_multiple_parents_mux_ops, +CLK_SET_RATE_PARENT ); + ret =clk_hw_register (NULL , &ctx->hw); +if (ret) +return ret; + +return 0 ; +} + +static void +clk_multiple_parents_mux_test_exit (struct kunit *test) +{ +struct clk_multiple_parent_ctx *ctx = test->priv; + +clk_hw_unregister (&ctx->hw); +clk_hw_unregister (&ctx->parents_ctx[0 ].hw); +clk_hw_unregister (&ctx->parents_ctx[1 ].hw); +} + +/* +* Test that for a clock with multiple parents, clk_get_parent() +* actually returns the current one. +*/ +static void +clk_test_multiple_parents_mux_get_parent (struct kunit *test) +{ +struct clk_multiple_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +struct clk *parent; + + parent =clk_get_parent (clk); +KUNIT_EXPECT_TRUE (test,clk_is_match (parent, ctx->parents_ctx[0 ].hw.clk)); +} + +static struct kunit_case clk_multiple_parents_mux_test_cases[] = { +KUNIT_CASE (clk_test_multiple_parents_mux_get_parent), + {} +}; + +/* +* Test suite for a basic mux clock with two parents, with +* CLK_SET_RATE_PARENT on the child. +* +* These tests exercise the consumer API and check that the state of the +* child and parents are sane and consistent. +*/ +static struct kunit_suite +clk_multiple_parents_mux_test_suite = { + .name ="clk-multiple-parents-mux-test" , + .init = clk_multiple_parents_mux_test_init, + .exit = clk_multiple_parents_mux_test_exit, + .test_cases = clk_multiple_parents_mux_test_cases, +}; +struct clk_single_parent_ctx {struct clk_dummy_context parent_ctx;struct clk_hw hw;
@@ -1288,6 +1406,7 @@ static struct kunit_suite clk_range_minimize_test_suite = { kunit_test_suites( &clk_test_suite, + &clk_multiple_parents_mux_test_suite, &clk_orphan_transparent_single_parent_test_suite, &clk_range_test_suite, &clk_range_maximize_test_suite,
Signature · 1 line
2.36.1
PATCH v5 12/28 clk: tests: Add some tests for orphan with multiple parents
In reply to Maxime RipardLet'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.
--- drivers/clk/clk_test.c | 210 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 210 insertions(+)
drivers/clk/clk_test.c +210 -0
@@ -465,6 +465,215 @@ clk_multiple_parents_mux_test_suite = { .test_cases = clk_multiple_parents_mux_test_cases, }; +static int +clk_orphan_transparent_multiple_parent_mux_test_init (struct kunit *test) +{ +struct clk_multiple_parent_ctx *ctx; +const char *parents[2 ] = {"missing-parent" ,"proper-parent" }; +int ret; + + ctx =kunit_kzalloc (test,sizeof (*ctx),GFP_KERNEL ); +if (!ctx) +return -ENOMEM ; + test->priv = ctx; + + ctx->parents_ctx[1 ].hw.init =CLK_HW_INIT_NO_PARENT ("proper-parent" , + &clk_dummy_rate_ops, +0 ); + ctx->parents_ctx[1 ].rate =DUMMY_CLOCK_INIT_RATE ; + ret =clk_hw_register (NULL , &ctx->parents_ctx[1 ].hw); +if (ret) +return ret; + + ctx->hw.init =CLK_HW_INIT_PARENTS ("test-orphan-mux" , parents, + &clk_multiple_parents_mux_ops, +CLK_SET_RATE_PARENT ); + ret =clk_hw_register (NULL , &ctx->hw); +if (ret) +return ret; + +return 0 ; +} + +static void +clk_orphan_transparent_multiple_parent_mux_test_exit (struct kunit *test) +{ +struct clk_multiple_parent_ctx *ctx = test->priv; + +clk_hw_unregister (&ctx->hw); +clk_hw_unregister (&ctx->parents_ctx[1 ].hw); +} + +/* +* Test that, for a mux whose current parent hasn't been registered yet, +* calling clk_set_parent() to a valid parent will properly update the +* mux parent and its orphan status. +*/ +static void +clk_test_orphan_transparent_multiple_parent_mux_set_parent (struct kunit *test) +{ +struct clk_multiple_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +struct clk *parent, *new_parent; +int ret; + + parent =clk_hw_get_clk (&ctx->parents_ctx[1 ].hw,NULL ); +KUNIT_ASSERT_NOT_ERR_OR_NULL (test, parent); + + ret =clk_set_parent (clk, parent); +KUNIT_ASSERT_EQ (test, ret,0 ); + + new_parent =clk_get_parent (clk); +KUNIT_ASSERT_NOT_ERR_OR_NULL (test, parent); +KUNIT_EXPECT_TRUE (test,clk_is_match (parent, new_parent)); + +clk_put (parent); +} + +/* +* Test that, for a mux that started orphan but got switched to a valid +* parent, the rate of the mux and its new parent are consistent. +*/ +static void +clk_test_orphan_transparent_multiple_parent_mux_set_parent_get_rate (struct kunit *test) +{ +struct clk_multiple_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +struct clk *parent; +unsigned long parent_rate, rate; +int ret; + + parent =clk_hw_get_clk (&ctx->parents_ctx[1 ].hw,NULL ); +KUNIT_ASSERT_NOT_ERR_OR_NULL (test, parent); + + parent_rate =clk_get_rate (parent); +KUNIT_ASSERT_GT (test, parent_rate,0 ); + + ret =clk_set_parent (clk, parent); +KUNIT_ASSERT_EQ (test, ret,0 ); + + rate =clk_get_rate (clk); +KUNIT_ASSERT_GT (test, rate,0 ); +KUNIT_EXPECT_EQ (test, parent_rate, rate); +} + +/* +* Test that, for a mux that started orphan but got switched to a valid +* parent, calling clk_set_rate_range() will affect the parent state if +* its rate is out of range. +*/ +static void +clk_test_orphan_transparent_multiple_parent_mux_set_parent_set_range_modified (struct kunit *test) +{ +struct clk_multiple_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk, *parent; +unsigned long rate; +int ret; + + parent =clk_hw_get_clk (&ctx->parents_ctx[1 ].hw,NULL ); +KUNIT_ASSERT_NOT_ERR_OR_NULL (test, parent); + + ret =clk_set_parent (clk, parent); +KUNIT_ASSERT_EQ (test, ret,0 ); + + ret =clk_set_rate_range (clk,DUMMY_CLOCK_RATE_1 ,DUMMY_CLOCK_RATE_2 ); +KUNIT_ASSERT_EQ (test, ret,0 ); + + rate =clk_get_rate (clk); +KUNIT_ASSERT_GT (test, rate,0 ); +KUNIT_EXPECT_GE (test, rate,DUMMY_CLOCK_RATE_1 ); +KUNIT_EXPECT_LE (test, rate,DUMMY_CLOCK_RATE_2 ); + +clk_put (parent); +} + +/* +* Test that, for a mux whose current parent hasn't been registered yet, +* calling clk_set_rate_range() will succeed, and will be taken into +* account when rounding a rate. +*/ +static void +clk_test_orphan_transparent_multiple_parent_mux_set_range_round_rate (struct kunit *test) +{ +struct clk_multiple_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +unsigned long rate; +int ret; + + ret =clk_set_rate_range (clk,DUMMY_CLOCK_RATE_1 ,DUMMY_CLOCK_RATE_2 ); +KUNIT_ASSERT_EQ (test, ret,0 ); + + rate =clk_round_rate (clk,DUMMY_CLOCK_RATE_1 -1000 ); +KUNIT_ASSERT_GT (test, rate,0 ); +KUNIT_EXPECT_GE (test, rate,DUMMY_CLOCK_RATE_1 ); +KUNIT_EXPECT_LE (test, rate,DUMMY_CLOCK_RATE_2 ); +} + +/* +* Test that, for a mux that started orphan, was assigned and rate and +* then got switched to a valid parent, its rate is eventually within +* range. +* +* FIXME: Even though we update the rate as part of clk_set_parent(), we +* don't evaluate whether that new rate is within range and needs to be +* adjusted. +*/ +static void +clk_test_orphan_transparent_multiple_parent_mux_set_range_set_parent_get_rate (struct kunit *test) +{ +struct clk_multiple_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk, *parent; +unsigned long rate; +int ret; + +kunit_skip (test,"This needs to be fixed in the core." ); + +clk_hw_set_rate_range (hw,DUMMY_CLOCK_RATE_1 ,DUMMY_CLOCK_RATE_2 ); + + parent =clk_hw_get_clk (&ctx->parents_ctx[1 ].hw,NULL ); +KUNIT_ASSERT_NOT_ERR_OR_NULL (test, parent); + + ret =clk_set_parent (clk, parent); +KUNIT_ASSERT_EQ (test, ret,0 ); + + rate =clk_get_rate (clk); +KUNIT_ASSERT_GT (test, rate,0 ); +KUNIT_EXPECT_GE (test, rate,DUMMY_CLOCK_RATE_1 ); +KUNIT_EXPECT_LE (test, rate,DUMMY_CLOCK_RATE_2 ); + +clk_put (parent); +} + +static struct kunit_case clk_orphan_transparent_multiple_parent_mux_test_cases[] = { +KUNIT_CASE (clk_test_orphan_transparent_multiple_parent_mux_set_parent), +KUNIT_CASE (clk_test_orphan_transparent_multiple_parent_mux_set_parent_get_rate), +KUNIT_CASE (clk_test_orphan_transparent_multiple_parent_mux_set_parent_set_range_modified), +KUNIT_CASE (clk_test_orphan_transparent_multiple_parent_mux_set_range_round_rate), +KUNIT_CASE (clk_test_orphan_transparent_multiple_parent_mux_set_range_set_parent_get_rate), + {} +}; + +/* +* Test suite for a basic mux clock with two parents. The default parent +* isn't registered, only the second parent is. By default, the clock +* will thus be orphan. +* +* These tests exercise the behaviour of the consumer API when dealing +* with an orphan clock, and how we deal with the transition to a valid +* parent. +*/ +static struct kunit_suite clk_orphan_transparent_multiple_parent_mux_test_suite = { + .name ="clk-orphan-transparent-multiple-parent-mux-test" , + .init = clk_orphan_transparent_multiple_parent_mux_test_init, + .exit = clk_orphan_transparent_multiple_parent_mux_test_exit, + .test_cases = clk_orphan_transparent_multiple_parent_mux_test_cases, +}; +struct clk_single_parent_ctx {struct clk_dummy_context parent_ctx;struct clk_hw hw;
@@ -1407,6 +1616,7 @@ static struct kunit_suite clk_range_minimize_test_suite = { kunit_test_suites( &clk_test_suite, &clk_multiple_parents_mux_test_suite, + &clk_orphan_transparent_multiple_parent_mux_test_suite, &clk_orphan_transparent_single_parent_test_suite, &clk_range_test_suite, &clk_range_maximize_test_suite,
Signature · 1 line
2.36.1
PATCH v5 13/28 clk: Take into account uncached clocks in clk_set_rate_range()
In reply to Maxime Ripardclk_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.
--- drivers/clk/clk.c | 6 +++++- drivers/clk/clk_test.c | 28 ++++++++++++++++++++++++++++ 2 files changed, 33 insertions(+), 1 deletion(-)
drivers/clk/clk.c +5 -1
@@ -2373,6 +2373,10 @@ static int clk_set_rate_range_nolock(struct clk *clk, goto out; } + rate = clk->core->req_rate; +if (clk->core->flags &CLK_GET_RATE_NOCACHE ) + rate =clk_core_get_rate_recalc (clk->core); +/* * Since the boundaries have been changed, let's give the * opportunity to the provider to adjust the clock rate based on
@@ -2390,7 +2394,7 @@ static int clk_set_rate_range_nolock(struct clk *clk,* - the determine_rate() callback does not really check for * this corner case when determining the rate */ - rate =clamp (clk->core->req_rate, min, max); + rate =clamp (rate, min, max); ret =clk_core_set_rate_nolock (clk->core, rate);if (ret) {/* rollback the changes */
drivers/clk/clk_test.c +28 -0
@@ -362,9 +362,37 @@ static void clk_test_uncached_set_range(struct kunit *test)KUNIT_EXPECT_LE (test, rate,DUMMY_CLOCK_RATE_2 ); } +/* +* Test that for an uncached clock, clk_set_rate_range() will work +* properly if the rate has changed in hardware. +* +* In this case, it means that if the rate wasn't initially in the range +* we're trying to set, but got changed at some point into the range +* without the kernel knowing about it, its rate shouldn't be affected. +*/ +static void clk_test_uncached_updated_rate_set_range (struct kunit *test) +{ +struct clk_dummy_context *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +unsigned long rate; + + ctx->rate =DUMMY_CLOCK_RATE_1 +1000 ; +KUNIT_ASSERT_EQ (test, +clk_set_rate_range (clk, +DUMMY_CLOCK_RATE_1 , +DUMMY_CLOCK_RATE_2 ), +0 ); + + rate =clk_get_rate (clk); +KUNIT_ASSERT_GT (test, rate,0 ); +KUNIT_EXPECT_EQ (test, rate,DUMMY_CLOCK_RATE_1 +1000 ); +} +static struct kunit_case clk_uncached_test_cases[] = {KUNIT_CASE (clk_test_uncached_get_rate),KUNIT_CASE (clk_test_uncached_set_range), +KUNIT_CASE (clk_test_uncached_updated_rate_set_range), {} };
Signature · 1 line
2.36.1
Stephen Boyd
maintainerRe: [PATCH v5 13/28] clk: Take into account uncached clocks in clk_set_rate_range()
Quoting Maxime Ripard (2022-05-16 06:25:12)
Quoted 14 lines
drivers/clk/clk_test.c +6
-0@@ -362,9 +362,37 @@ static void clk_test_uncached_set_range(struct kunit *test)KUNIT_EXPECT_LE (test, rate,DUMMY_CLOCK_RATE_2 ); } +/* +* Test that for an uncached clock, clk_set_rate_range() will work +* properly if the rate has changed in hardware. +* +* In this case, it means that if the rate wasn't initially in the range +* we're trying to set, but got changed at some point into the range
drivers/clk/clk_test.c static void clk_test_uncached_set_range(struct kunit *test) · line 380
Quoted 10 lines
drivers/clk/clk_test.c +10
-0+* without the kernel knowing about it, its rate shouldn't be affected. +*/ +static void clk_test_uncached_updated_rate_set_range (struct kunit *test) +{ +struct clk_dummy_context *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +unsigned long rate; + + ctx->rate =DUMMY_CLOCK_RATE_1 +1000 ;
Is this where we set the rate behind clk framework's back? Maybe add a comment here to state that.
drivers/clk/clk_test.c static void clk_test_uncached_set_range(struct kunit *test) · line 388
Quoted 8 lines
drivers/clk/clk_test.c +8
-0+KUNIT_ASSERT_EQ (test, +clk_set_rate_range (clk, +DUMMY_CLOCK_RATE_1 , +DUMMY_CLOCK_RATE_2 ), +0 ); + + rate =clk_get_rate (clk); +KUNIT_ASSERT_GT (test, rate,0 );
This will almost always be true because rate is unsigned. Should it be KUNIT_ASSERT_NE() instead?
Is there any benefit at all to this check? We're going to check the rate with an expectation in the next line for what we're actually testing for, so it's not like we need to assert that the rate is non-zero before checking that it is exactly DUMMY_CLOCK_RATE_1 + 1000.
I thought assertions were about checking sanity of the parts of the test that aren't under test. If the assertion fails then our test is so busted the expectation can't be trusted and we shouldn't even try to continue. It's similar to BUG_ON() and WARN_ON().
Quoted 3 lines
drivers/clk/clk_test.c +3
-0+KUNIT_EXPECT_EQ (test, rate,DUMMY_CLOCK_RATE_1 +1000 ); +} +
Re: [PATCH v5 13/28] clk: Take into account uncached clocks in clk_set_rate_range()
Quoted 20 lines · Stephen Boyd
Quoting Maxime Ripard (2022-05-16 06:25:12)
Quoted 19 lines
drivers/clk/clk_test.c +11
-0@@ -362,9 +362,37 @@ static void clk_test_uncached_set_range(struct kunit *test)KUNIT_EXPECT_LE (test, rate,DUMMY_CLOCK_RATE_2 ); } +/* +* Test that for an uncached clock, clk_set_rate_range() will work +* properly if the rate has changed in hardware. +* +* In this case, it means that if the rate wasn't initially in the range +* we're trying to set, but got changed at some point into the range +* without the kernel knowing about it, its rate shouldn't be affected. +*/ +static void clk_test_uncached_updated_rate_set_range (struct kunit *test) +{ +struct clk_dummy_context *ctx = test->priv;
Quoted 8 lines
drivers/clk/clk_test.c static void clk_test_uncached_set_range(struct kunit *test) · line 380
Quoted 5 lines
drivers/clk/clk_test.c +5
-0+struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +unsigned long rate; + + ctx->rate =DUMMY_CLOCK_RATE_1 +1000 ;Is this where we set the rate behind clk framework's back? Maybe add a comment here to state that.
Yes, I'll add a comment
Quoted 17 lines
drivers/clk/clk_test.c static void clk_test_uncached_set_range(struct kunit *test) · line 388
Quoted 8 lines
drivers/clk/clk_test.c +8
-0+KUNIT_ASSERT_EQ (test, +clk_set_rate_range (clk, +DUMMY_CLOCK_RATE_1 , +DUMMY_CLOCK_RATE_2 ), +0 ); + + rate =clk_get_rate (clk); +KUNIT_ASSERT_GT (test, rate,0 );This will almost always be true because rate is unsigned. Should it be
KUNIT_ASSERT_NE()instead?Is there any benefit at all to this check? We're going to check the rate with an expectation in the next line for what we're actually testing for, so it's not like we need to assert that the rate is non-zero before checking that it is exactly
DUMMY_CLOCK_RATE_1+ 1000.
Quoted 4 lines
I thought assertions were about checking sanity of the parts of the test that aren't under test. If the assertion fails then our test is so busted the expectation can't be trusted and we shouldn't even try to continue. It's similar to
BUG_ON()andWARN_ON().
I'm not entirely up to speed on what is our expectations when it comes to unit tests.
clk_get_rate() mentions that it can return 0, and it definitely shouldn't with the setup we are testing here. So it was my impression that we were in "totally busted" territory, but if you feel it's overkill I'll remove it.
Maxime
PATCH v5 14/28 clk: Fix clk_get_parent() documentation
In reply to Maxime RipardThe clk_get_parent() documentation in the header states that it will return a valid pointer, or an error pointer on failure.
However, the documentation in the source file, and the code itself, will return also return NULL if there isn't any parent for that clock. Let's mention it.
An orphan clock should return NULL too, so let's add a test for it.
--- drivers/clk/clk_test.c | 17 +++++++++++++++++ include/linux/clk.h | 5 +++-- 2 files changed, 20 insertions(+), 2 deletions(-)
drivers/clk/clk_test.c +17 -0
@@ -532,6 +532,22 @@ clk_orphan_transparent_multiple_parent_mux_test_exit(struct kunit *test)clk_hw_unregister (&ctx->parents_ctx[1 ].hw); } +/* +* Test that, for a mux whose current parent hasn't been registered yet, +* clk_get_parent() will return NULL. +*/ +static void +clk_test_orphan_transparent_multiple_parent_mux_get_parent (struct kunit *test) +{ +struct clk_multiple_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +struct clk *parent; + + parent =clk_get_parent (clk); +KUNIT_EXPECT_PTR_EQ (test, parent,NULL ); +} +/* * Test that, for a mux whose current parent hasn't been registered yet, * calling clk_set_parent() to a valid parent will properly update the
@@ -678,6 +694,7 @@ clk_test_orphan_transparent_multiple_parent_mux_set_range_set_parent_get_rate(st }static struct kunit_case clk_orphan_transparent_multiple_parent_mux_test_cases[] = { +KUNIT_CASE (clk_test_orphan_transparent_multiple_parent_mux_get_parent),KUNIT_CASE (clk_test_orphan_transparent_multiple_parent_mux_set_parent),KUNIT_CASE (clk_test_orphan_transparent_multiple_parent_mux_set_parent_get_rate),KUNIT_CASE (clk_test_orphan_transparent_multiple_parent_mux_set_parent_set_range_modified),
include/linux/clk.h +3 -2
@@ -755,8 +755,9 @@ int clk_set_parent(struct clk *clk, struct clk *parent);* clk_get_parent - get the parent clock source for this clock * @clk: clock source * -* Returns struct clk corresponding to parent clock source, or -* valid IS_ERR() condition containing errno. +* Returns struct clk corresponding to parent clock source, a NULL +* pointer if it doesn't have a parent, or a valid IS_ERR() condition +* containing errno. */ struct clk *clk_get_parent (struct clk *clk);
Signature · 1 line
2.36.1
Stephen Boyd
maintainerRe: [PATCH v5 14/28] clk: Fix clk_get_parent() documentation
Quoting Maxime Ripard (2022-05-16 06:25:13)
Quoted 5 lines
The
clk_get_parent()documentation in the header states that it will return a valid pointer, or an error pointer on failure.However, the documentation in the source file, and the code itself, will return also return NULL if there isn't any parent for that clock. Let's
s/return//
Quoted 17 lines
mention it.
An orphan clock should return NULL too, so let's add a test for it.
Signed-off-by Maxime Ripard <[email protected]>--- drivers/clk/clk_test.c | 17 +++++++++++++++++ include/linux/clk.h | 5 +++-- 2 files changed, 20 insertions(+), 2 deletions(-)drivers/clk/clk_test.c +0
-0
drivers/clk/clk_test.c clk_orphan_transparent_multiple_parent_mux_test_exit(struct kunit *test) · line 536
Quoted 5 lines
drivers/clk/clk_test.c +2
-0@@ -532,6 +532,22 @@ clk_orphan_transparent_multiple_parent_mux_test_exit(struct kunit *test)clk_hw_unregister (&ctx->parents_ctx[1 ].hw); } +/* +* Test that, for a mux whose current parent hasn't been registered yet,
Mention "orphan" here somehow.
drivers/clk/clk_test.c clk_orphan_transparent_multiple_parent_mux_test_exit(struct kunit *test) · line 548
Quoted 12 lines
drivers/clk/clk_test.c +12
-0+* clk_get_parent() will return NULL. +*/ +static void +clk_test_orphan_transparent_multiple_parent_mux_get_parent (struct kunit *test) +{ +struct clk_multiple_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +struct clk *parent; + + parent =clk_get_parent (clk); +KUNIT_EXPECT_PTR_EQ (test, parent,NULL );
Please put clk_get_parent() into the expectation so that the print on error is more verbose.
drivers/clk/clk_test.c clk_test_orphan_transparent_multiple_parent_mux_set_range_set_parent_get_rate(st · line 700
Quoted 13 lines
drivers/clk/clk_test.c +3
-0+} +/* * Test that, for a mux whose current parent hasn't been registered yet, * calling clk_set_parent() to a valid parent will properly update the @@ -678,6 +694,7 @@ clk_test_orphan_transparent_multiple_parent_mux_set_range_set_parent_get_rate(st }static struct kunit_case clk_orphan_transparent_multiple_parent_mux_test_cases[] = { +KUNIT_CASE (clk_test_orphan_transparent_multiple_parent_mux_get_parent),KUNIT_CASE (clk_test_orphan_transparent_multiple_parent_mux_set_parent),KUNIT_CASE (clk_test_orphan_transparent_multiple_parent_mux_set_parent_get_rate),KUNIT_CASE (clk_test_orphan_transparent_multiple_parent_mux_set_parent_set_range_modified),
Please split the test from the documentation update.
include/linux/clk.h int clk_set_parent(struct clk *clk, struct clk *parent); · line 760
Quoted 13 lines
include/linux/clk.h +3
-2@@ -755,8 +755,9 @@ int clk_set_parent(struct clk *clk, struct clk *parent);* clk_get_parent - get the parent clock source for this clock * @clk: clock source * -* Returns struct clk corresponding to parent clock source, or -* valid IS_ERR() condition containing errno. +* Returns struct clk corresponding to parent clock source, a NULL +* pointer if it doesn't have a parent, or a valid IS_ERR() condition +* containing errno.
I'd rather not update this. A return value of NULL is a 'struct clk corresponding to parent clock source' already, and we don't want to document CCF implementation details in clk.h because there are other implementations of the API.
Re: [PATCH v5 14/28] clk: Fix clk_get_parent() documentation
Hi,
Quoted 10 lines · Stephen Boyd
Quoted 10 lines
include/linux/clk.h +0
-2@@ -755,8 +755,9 @@ int clk_set_parent(struct clk *clk, struct clk *parent);* clk_get_parent - get the parent clock source for this clock * @clk: clock source * -* Returns struct clk corresponding to parent clock source, or -* valid IS_ERR() condition containing errno.
Quoted 8 lines
include/linux/clk.h int clk_set_parent(struct clk *clk, struct clk *parent); · line 760
Quoted 3 lines
include/linux/clk.h +3
-0+* Returns struct clk corresponding to parent clock source, a NULL +* pointer if it doesn't have a parent, or a valid IS_ERR() condition +* containing errno. I'd rather not update this. A return value of NULL is a 'struct clk corresponding to parent clock source' already, and we don't want to document CCF implementation details in
clk.hbecause there are other implementations of the API.
I find it slightly misleading still since using IS_ERR still doesn't get you a safe pointer you can use.
I'll drop it though if you feel like it's too troublesome
Maxime
PATCH v5 15/28 clk: Set req_rate on reparenting
In reply to Maxime RipardIf 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. Let's make sure it's the case for the newly unorphan clock and all its children.
--- drivers/clk/clk.c | 18 ++++ drivers/clk/clk_test.c | 231 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 249 insertions(+)
drivers/clk/clk.c +18 -0
@@ -1765,6 +1765,23 @@ static void clk_core_update_orphan_status(struct clk_core *core, bool is_orphan)clk_core_update_orphan_status (child, is_orphan); } +/* +* Update the orphan rate and req_rate of @core and all its children. +*/ +static void clk_core_update_orphan_child_rates (struct clk_core *core) +{ +struct clk_core *child; +unsigned long parent_rate =0 ; + +if (core->parent) + parent_rate = core->parent->rate; + + core->rate = core->req_rate =clk_recalc (core, parent_rate); + +hlist_for_each_entry (child, &core->children, child_node) +clk_core_update_orphan_child_rates (child); +} +static void clk_reparent (struct clk_core *core,struct clk_core *new_parent) {bool was_orphan = core->orphan;
@@ -1789,6 +1806,7 @@ static void clk_reparent(struct clk_core *core, struct clk_core *new_parent) } core->parent = new_parent; +clk_core_update_orphan_child_rates (core); } static struct clk_core *__clk_set_parent_before(struct clk_core *core,
drivers/clk/clk_test.c +231 -0
269 lines not on this page · raw message
Signature · 1 line
2.36.1
PATCH v5 16/28 clk: Change clk_core_init_rate_req prototype
In reply to Maxime RipardThe expectation is that a clk_rate_request structure is supposed to be initialized using clk_core_init_rate_req(), yet the rate we want to request still needs to be set by hand.
Let's just pass the rate as a function argument so that callers don't have any extra work to do.
--- drivers/clk/clk.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/clk/clk.c +6 -4
@@ -1380,13 +1380,16 @@ static int clk_core_determine_round_nolock(struct clk_core *core, }static void clk_core_init_rate_req (struct clk_core *const core, -struct clk_rate_request *req) +struct clk_rate_request *req, +unsigned long rate) {struct clk_core *parent;if (WARN_ON (!core || !req))return ; + req->rate = rate; + parent = core->parent;if (parent) { req->best_parent_hw = parent->hw;
@@ -1412,7 +1415,7 @@ static int clk_core_round_rate_nolock(struct clk_core *core,return 0 ; } -clk_core_init_rate_req (core, req); +clk_core_init_rate_req (core, req, req->rate);if (clk_core_can_round (core))return clk_core_determine_round_nolock (core, req);
@@ -2001,11 +2004,10 @@ static struct clk_core *clk_calc_new_rates(struct clk_core *core,if (clk_core_can_round (core)) {struct clk_rate_request req; - req.rate = rate; req.min_rate = min_rate; req.max_rate = max_rate; -clk_core_init_rate_req (core, &req); +clk_core_init_rate_req (core, &req, rate); ret =clk_core_determine_round_nolock (core, &req);if (ret <0 )
Signature · 1 line
2.36.1
PATCH v5 17/28 clk: Move clk_core_init_rate_req() from clk_core_round_rate_nolock() to its caller
In reply to Maxime RipardThe clk_rate_request structure is used internally as an argument for the clk_core_determine_round_nolock() and clk_core_round_rate_nolock().
In both cases, the clk_core_init_rate_req() function is used to initialize the clk_rate_request structure.
However, the expectation on who gets to call that function is inconsistent between those two functions. Indeed, clk_core_determine_round_nolock() will assume the structure is properly initialized and will just use it.
On the other hand, clk_core_round_rate_nolock() will call clk_core_init_rate_req() itself, expecting the caller to have filled only a minimal set of parameters (rate, min_rate and max_rate).
If we ignore the calling convention inconsistency, this leads to a second inconsistency for drivers:
* If they get called by the framework through clk_core_round_rate_nolock(), the rate, min_rate and max_rate fields will be filled by the caller, and the best_parent_rate and best_parent_hw fields will get filled by clk_core_init_rate_req().
* If they get called by a driver through __clk_determine_rate (and thus clk_core_round_rate_nolock), only best_parent_rate and best_parent_hw are being explicitly set by the framework. Even though we can reasonably expect rate to be set, only one of the 6 in-tree users explicitly set min_rate and max_rate.
* If they get called by the framework through clk_core_determine_round_nolock(), then we have two callpaths. Either it will be called by clk_core_round_rate_nolock() itself, or it will be called by clk_calc_new_rates(), which will properly initialize rate, min_rate, max_rate itself, and best_parent_rate and best_parent_hw through clk_core_init_rate_req().
Even though the first and third case seems equivalent, they aren't when the clock has CLK_SET_RATE_PARENT. Indeed, in such a case clk_core_round_rate_nolock() will call itself on the current parent clock with the same clk_rate_request structure.
The clk_core_init_rate_req() function will then be called on the parent clock, with the child clk_rate_request pointer and will fill the best_parent_rate and best_parent_hw fields with the parent context.
When the whole recursion stops and the call returns, the initial caller will end up with a clk_rate_request structure with some informations of the child clock (rate, min_rate, max_rate) and some others of the last clock up the tree whose child had CLK_SET_RATE_PARENT (best_parent_hw, best_parent_rate).
In the most common case, best_parent_rate is going to be equal on all the parent clocks so it's not a big deal. However, best_parent_hw is going to point to a clock that never has been a valid parent for that clock which is definitely confusing.
In order to fix the calling inconsistency, let's move the clk_core_init_rate_req() calls to the callers, which will also help a bit with the clk_core_round_rate_nolock() recursion.
--- drivers/clk/clk.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
drivers/clk/clk.c +3 -5
@@ -1415,8 +1415,6 @@ static int clk_core_round_rate_nolock(struct clk_core *core,return 0 ; } -clk_core_init_rate_req (core, req, req->rate); -if (clk_core_can_round (core))return clk_core_determine_round_nolock (core, req);else if (core->flags &CLK_SET_RATE_PARENT )
@@ -1464,8 +1462,8 @@ unsigned long clk_hw_round_rate(struct clk_hw *hw, unsigned long rate)int ret;struct clk_rate_request req; +clk_core_init_rate_req (hw->core, &req, rate);clk_core_get_boundaries (hw->core, &req.min_rate, &req.max_rate); - req.rate = rate; ret =clk_core_round_rate_nolock (hw->core, &req);if (ret)
@@ -1497,8 +1495,8 @@ long clk_round_rate(struct clk *clk, unsigned long rate)if (clk->exclusive_count)clk_core_rate_unprotect (clk->core); +clk_core_init_rate_req (clk->core, &req, rate);clk_core_get_boundaries (clk->core, &req.min_rate, &req.max_rate); - req.rate = rate; ret =clk_core_round_rate_nolock (clk->core, &req);
@@ -2206,8 +2204,8 @@ static unsigned long clk_core_req_round_rate_nolock(struct clk_core *core,if (cnt <0 )return cnt; +clk_core_init_rate_req (core, &req, req_rate);clk_core_get_boundaries (core, &req.min_rate, &req.max_rate); - req.rate = req_rate; ret =clk_core_round_rate_nolock (core, &req);
Signature · 1 line
2.36.1
PATCH v5 18/28 clk: Introduce clk_hw_init_rate_request()
In reply to Maxime Ripardclk-divider instantiates clk_rate_request internally for its round_rate implementations to share the code with its determine_rate implementations.
However, it's missing a few fields (min_rate, max_rate) that would be initialized properly if it was using clk_core_init_rate_req().
Let's create the clk_hw_init_rate_request() function for clock providers to be able to share the code to instation clk_rate_requests with the framework. This will also be useful for some tests introduced in later patches.
--- drivers/clk/clk-divider.c | 20 ++++++++++---------- drivers/clk/clk.c | 20 ++++++++++++++++++++ include/linux/clk-provider.h | 6 ++++++ 3 files changed, 36 insertions(+), 10 deletions(-)
drivers/clk/clk-divider.c +10 -10
@@ -386,13 +386,13 @@ long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,const struct clk_div_table *table, u8 width, unsigned long flags) { - struct clk_rate_request req = { - .rate = rate, - .best_parent_rate = *prate, - .best_parent_hw = parent, - }; + struct clk_rate_request req;int ret; +clk_hw_init_rate_request (hw, &req, rate); + req.best_parent_rate = *prate; + req.best_parent_hw = parent; + ret =divider_determine_rate (hw, &req, table, width, flags);if (ret)return ret;
@@ -408,13 +408,13 @@ long divider_ro_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent, const struct clk_div_table *table, u8 width, unsigned long flags, unsigned int val) { - struct clk_rate_request req = { - .rate = rate, - .best_parent_rate = *prate, - .best_parent_hw = parent, - }; + struct clk_rate_request req;int ret; +clk_hw_init_rate_request (hw, &req, rate); + req.best_parent_rate = *prate; + req.best_parent_hw = parent; + ret =divider_ro_determine_rate (hw, &req, table, width, flags, val);if (ret)return ret;
drivers/clk/clk.c +20 -0
@@ -1400,6 +1400,26 @@ static void clk_core_init_rate_req(struct clk_core * const core, } } +/** +* clk_hw_init_rate_request - Initializes a clk_rate_request +* @hw: the clk for which we want to submit a rate request +* @req: the clk_rate_request structure we want to initialise +* @rate: the rate which is to be requested +* +* Initializes a clk_rate_request structure to submit to +* __clk_determine_rate() or similar functions. +*/ +void clk_hw_init_rate_request (const struct clk_hw *hw, +struct clk_rate_request *req, +unsigned long rate) +{ +if (WARN_ON (!hw || !req)) +return ; + +clk_core_init_rate_req (hw->core, req, rate); +} +EXPORT_SYMBOL_GPL (clk_hw_init_rate_request); +static bool clk_core_can_round (struct clk_core *const core) {return core->ops->determine_rate || core->ops->round_rate;
include/linux/clk-provider.h +6 -0
@@ -42,6 +42,8 @@ struct dentry;* struct clk_rate_request - Structure encoding the clk constraints that * a clock user might require. * +* Should be initialized by calling clk_hw_init_rate_request(). +* * @rate: Requested clock rate. This field will be adjusted by * clock drivers according to hardware capabilities. * @min_rate: Minimum rate imposed by clk users.
@@ -60,6 +62,10 @@ struct clk_rate_request {struct clk_hw *best_parent_hw; }; +void clk_hw_init_rate_request (const struct clk_hw *hw, +struct clk_rate_request *req, +unsigned long rate); +/** * struct clk_duty - Struture encoding the duty cycle ratio of a clock *
Signature · 1 line
2.36.1
PATCH v5 19/28 clk: Add our request boundaries in clk_core_init_rate_req
In reply to Maxime RipardThe expectation is that a new clk_rate_request is initialized through a call to clk_core_init_rate_req().
However, at the moment it only fills the parent rate and clk_hw pointer, but omits the other fields such as the clock rate boundaries.
Some users of that function will update them after calling it, but most don't.
As we are passed the clk_core pointer, we have access to those boundaries in clk_core_init_rate_req() however, so let's just fill it there and remove it from the few callers that do it right.
--- drivers/clk/clk.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-)
drivers/clk/clk.c +1 -6
@@ -1389,6 +1389,7 @@ static void clk_core_init_rate_req(struct clk_core * const core,return ; req->rate = rate; +clk_core_get_boundaries (core, &req->min_rate, &req->max_rate); parent = core->parent;if (parent) {
@@ -1483,7 +1484,6 @@ unsigned long clk_hw_round_rate(struct clk_hw *hw, unsigned long rate)struct clk_rate_request req;clk_core_init_rate_req (hw->core, &req, rate); -clk_core_get_boundaries (hw->core, &req.min_rate, &req.max_rate); ret =clk_core_round_rate_nolock (hw->core, &req);if (ret)
@@ -1516,7 +1516,6 @@ long clk_round_rate(struct clk *clk, unsigned long rate)clk_core_rate_unprotect (clk->core);clk_core_init_rate_req (clk->core, &req, rate); -clk_core_get_boundaries (clk->core, &req.min_rate, &req.max_rate); ret =clk_core_round_rate_nolock (clk->core, &req);
@@ -2022,9 +2021,6 @@ static struct clk_core *clk_calc_new_rates(struct clk_core *core,if (clk_core_can_round (core)) {struct clk_rate_request req; - req.min_rate = min_rate; - req.max_rate = max_rate; -clk_core_init_rate_req (core, &req, rate); ret =clk_core_determine_round_nolock (core, &req);
@@ -2225,7 +2221,6 @@ static unsigned long clk_core_req_round_rate_nolock(struct clk_core *core,return cnt;clk_core_init_rate_req (core, &req, req_rate); -clk_core_get_boundaries (core, &req.min_rate, &req.max_rate); ret =clk_core_round_rate_nolock (core, &req);
Signature · 1 line
2.36.1
PATCH v5 20/28 clk: Switch from __clk_determine_rate to clk_core_round_rate_nolock
In reply to Maxime Ripardclk_mux_determine_rate_flags() will call into __clk_determine_rate() with a clk_hw pointer, while it has access to the clk_core pointer already.
This leads to back and forth between clk_hw and clk_core, while __clk_determine_rate will only call clk_core_round_rate_nolock() with the clk_core pointer it retrieved from the clk_hw.
Let's simplify things a bit by calling into clk_core_round_rate_nolock directly.
--- drivers/clk/clk.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
drivers/clk/clk.c +10 -3
@@ -536,6 +536,9 @@ static bool mux_is_better_rate(unsigned long rate, unsigned long now,return now <= rate && now > best; } +static int clk_core_round_rate_nolock (struct clk_core *core, +struct clk_rate_request *req); +int clk_mux_determine_rate_flags (struct clk_hw *hw,struct clk_rate_request *req,unsigned long flags)
@@ -549,8 +552,12 @@ int clk_mux_determine_rate_flags(struct clk_hw *hw,if (core->flags &CLK_SET_RATE_NO_REPARENT ) { parent = core->parent;if (core->flags &CLK_SET_RATE_PARENT ) { - ret =__clk_determine_rate (parent ? parent->hw :NULL , - &parent_req); +if (!parent) { + req->rate =0 ; +return 0 ; + } + + ret =clk_core_round_rate_nolock (parent, &parent_req);if (ret)return ret;
@@ -573,7 +580,7 @@ int clk_mux_determine_rate_flags(struct clk_hw *hw,if (core->flags &CLK_SET_RATE_PARENT ) { parent_req = *req; - ret =__clk_determine_rate (parent->hw, &parent_req); + ret =clk_core_round_rate_nolock (parent, &parent_req);if (ret)continue ; }else {
Signature · 1 line
2.36.1
PATCH v5 21/28 clk: Introduce clk_core_has_parent()
In reply to Maxime RipardWe 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.
--- drivers/clk/clk.c | 36 +++++++++++++++++++++--------------- drivers/clk/clk_test.c | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 53 insertions(+), 15 deletions(-)
drivers/clk/clk.c +21 -15
@@ -539,6 +539,26 @@ static bool mux_is_better_rate(unsigned long rate, unsigned long now,static int clk_core_round_rate_nolock (struct clk_core *core,struct clk_rate_request *req); +static bool clk_core_has_parent (struct clk_core *core,struct clk_core *parent) +{ +unsigned int i; + +/* Optimize for the case where the parent is already the parent. */ +if (core == parent) +return true; + +for (i =0 ; i < core->num_parents; i++) { +struct clk_core *tmp =clk_core_get_parent_by_index (core, i); +if (!tmp) +continue ; + +if (tmp == parent) +return true; + } + +return false; +} +int clk_mux_determine_rate_flags (struct clk_hw *hw,struct clk_rate_request *req,unsigned long flags)
@@ -2590,25 +2610,11 @@ void clk_hw_reparent(struct clk_hw *hw, struct clk_hw *new_parent)*/ bool clk_has_parent (struct clk *clk,struct clk *parent) { -struct clk_core *core, *parent_core; -int i; -/* NULL clocks should be nops, so return success if either is NULL. */ if (!clk || !parent)return true; - core = clk->core; - parent_core = parent->core; - -/* Optimize for the case where the parent is already the parent. */ -if (core->parent == parent_core) -return true; - -for (i =0 ; i < core->num_parents; i++) -if (!strcmp (core->parents[i].name, parent_core->name)) -return true; - -return false; +return clk_core_has_parent (clk->core, parent->core); }EXPORT_SYMBOL_GPL (clk_has_parent);
drivers/clk/clk_test.c +32 -0
@@ -473,8 +473,24 @@ clk_test_multiple_parents_mux_get_parent(struct kunit *test)KUNIT_EXPECT_TRUE (test,clk_is_match (parent, ctx->parents_ctx[0 ].hw.clk)); } +/* +* Test that for a clock with a multiple parents, clk_has_parent() +* actually reports all of them as parents. +*/ +static void +clk_test_multiple_parents_mux_has_parent (struct kunit *test) +{ +struct clk_multiple_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; + +KUNIT_EXPECT_TRUE (test,clk_has_parent (clk, ctx->parents_ctx[0 ].hw.clk)); +KUNIT_EXPECT_TRUE (test,clk_has_parent (clk, ctx->parents_ctx[1 ].hw.clk)); +} +static struct kunit_case clk_multiple_parents_mux_test_cases[] = {KUNIT_CASE (clk_test_multiple_parents_mux_get_parent), +KUNIT_CASE (clk_test_multiple_parents_mux_has_parent), {} };
@@ -884,6 +900,21 @@ clk_test_single_parent_mux_get_parent(struct kunit *test)KUNIT_EXPECT_TRUE (test,clk_is_match (parent, ctx->parent_ctx.hw.clk)); } +/* +* Test that for a clock with a single parent, clk_has_parent() actually +* reports it as a parent. +*/ +static void +clk_test_single_parent_mux_has_parent (struct kunit *test) +{ +struct clk_single_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +struct clk *parent = ctx->parent_ctx.hw.clk; + +KUNIT_EXPECT_TRUE (test,clk_has_parent (clk, parent)); +} +/* * Test that for a clock that can't modify its rate and with a single * parent, if we set disjoints range on the parent and then the child,
@@ -982,6 +1013,7 @@ clk_test_single_parent_mux_set_range_round_rate_child_smaller(struct kunit *teststatic struct kunit_case clk_single_parent_mux_test_cases[] = {KUNIT_CASE (clk_test_single_parent_mux_get_parent), +KUNIT_CASE (clk_test_single_parent_mux_has_parent),KUNIT_CASE (clk_test_single_parent_mux_set_range_disjoint_child_last),KUNIT_CASE (clk_test_single_parent_mux_set_range_disjoint_parent_last),KUNIT_CASE (clk_test_single_parent_mux_set_range_round_rate_child_smaller),
Signature · 1 line
2.36.1
Stephen Boyd
maintainerRe: [PATCH v5 21/28] clk: Introduce clk_core_has_parent()
Quoting Maxime Ripard (2022-05-16 06:25:20)
Quoted 20 lines
We will need to know if a
clk_corepointer has a given parent in other functions, so let's create aclk_core_has_parent()function thatclk_has_parent()will call into.For good measure, let's add some unit tests as well to make sure it works properly.
Signed-off-by Maxime Ripard <[email protected]>--- drivers/clk/clk.c | 36 +++++++++++++++++++++--------------- drivers/clk/clk_test.c | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 53 insertions(+), 15 deletions(-)drivers/clk/clk.c +0
-0
drivers/clk/clk.c static bool mux_is_better_rate(unsigned long rate, unsigned long now, · line 542
Quoted 4 lines
drivers/clk/clk.c +1
-0@@ -539,6 +539,26 @@ static bool mux_is_better_rate(unsigned long rate, unsigned long now,static int clk_core_round_rate_nolock (struct clk_core *core,struct clk_rate_request *req); +static bool clk_core_has_parent (struct clk_core *core,struct clk_core *parent)
const parent please. Sadly core isn't const though because we may fill the cache in clk_core_get_parent_by_index().
Quoted 23 lines
drivers/clk/clk.c +19
-0+{ +unsigned int i; + +/* Optimize for the case where the parent is already the parent. */ +if (core == parent) +return true; + +for (i =0 ; i < core->num_parents; i++) { +struct clk_core *tmp =clk_core_get_parent_by_index (core, i); +if (!tmp) +continue ; + +if (tmp == parent) +return true; + } + +return false; +} +int clk_mux_determine_rate_flags (struct clk_hw *hw,struct clk_rate_request *req,unsigned long flags)
drivers/clk/clk.c void clk_hw_reparent(struct clk_hw *hw, struct clk_hw *new_parent) · line 2611
Quoted 2 lines
drivers/clk/clk.c +0
-0@@ -2590,25 +2610,11 @@ void clk_hw_reparent(struct clk_hw *hw, struct clk_hw *new_parent)*/ bool clk_has_parent (struct clk *clk,struct clk *parent)
Doesn't need to be done in this patch but we should probably mark both clk and parent as const to indicate we're not going to modify them.
Quoted 58 lines
drivers/clk/clk.c +1
-15{ -struct clk_core *core, *parent_core; -int i; -/* NULL clocks should be nops, so return success if either is NULL. */ if (!clk || !parent)return true; - core = clk->core; - parent_core = parent->core; - -/* Optimize for the case where the parent is already the parent. */ -if (core->parent == parent_core) -return true; - -for (i =0 ; i < core->num_parents; i++) -if (!strcmp (core->parents[i].name, parent_core->name)) -return true; - -return false; +return clk_core_has_parent (clk->core, parent->core); }EXPORT_SYMBOL_GPL (clk_has_parent);drivers/clk/clk_test.c +17
-0@@ -473,8 +473,24 @@ clk_test_multiple_parents_mux_get_parent(struct kunit *test)KUNIT_EXPECT_TRUE (test,clk_is_match (parent, ctx->parents_ctx[0 ].hw.clk)); } +/* +* Test that for a clock with a multiple parents, clk_has_parent() +* actually reports all of them as parents. +*/ +static void +clk_test_multiple_parents_mux_has_parent (struct kunit *test) +{ +struct clk_multiple_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; + +KUNIT_EXPECT_TRUE (test,clk_has_parent (clk, ctx->parents_ctx[0 ].hw.clk)); +KUNIT_EXPECT_TRUE (test,clk_has_parent (clk, ctx->parents_ctx[1 ].hw.clk)); +} +static struct kunit_case clk_multiple_parents_mux_test_cases[] = {KUNIT_CASE (clk_test_multiple_parents_mux_get_parent), +KUNIT_CASE (clk_test_multiple_parents_mux_has_parent), {} };@@ -884,6 +900,21 @@ clk_test_single_parent_mux_get_parent(struct kunit *test)KUNIT_EXPECT_TRUE (test,clk_is_match (parent, ctx->parent_ctx.hw.clk)); } +/*
drivers/clk/clk_test.c clk_test_single_parent_mux_get_parent(struct kunit *test) · line 913
Quoted 10 lines
drivers/clk/clk_test.c +10
-0+* Test that for a clock with a single parent, clk_has_parent() actually +* reports it as a parent. +*/ +static void +clk_test_single_parent_mux_has_parent (struct kunit *test) +{ +struct clk_single_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +struct clk *parent = ctx->parent_ctx.hw.clk;
Instead of using hw.clk directly can we use clk_hw_get_clk() and then clk_put() it later? Eventually we want to remove the clk pointer inside clk_hw, so every new use means more work later.
Quoted 18 lines
drivers/clk/clk_test.c +5
-0+ +KUNIT_EXPECT_TRUE (test,clk_has_parent (clk, parent)); +} +/* * Test that for a clock that can't modify its rate and with a single * parent, if we set disjoints range on the parent and then the child, @@ -982,6 +1013,7 @@ clk_test_single_parent_mux_set_range_round_rate_child_smaller(struct kunit *teststatic struct kunit_case clk_single_parent_mux_test_cases[] = {KUNIT_CASE (clk_test_single_parent_mux_get_parent), +KUNIT_CASE (clk_test_single_parent_mux_has_parent),KUNIT_CASE (clk_test_single_parent_mux_set_range_disjoint_child_last),KUNIT_CASE (clk_test_single_parent_mux_set_range_disjoint_parent_last),KUNIT_CASE (clk_test_single_parent_mux_set_range_round_rate_child_smaller),Signature · 1 line
2.36.1
PATCH v5 22/28 clk: Stop forwarding clk_rate_requests to the parent
In reply to Maxime RipardIf 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.
--- drivers/clk/at91/clk-generated.c | 5 +- drivers/clk/at91/clk-master.c | 9 +- drivers/clk/at91/clk-peripheral.c | 4 +- drivers/clk/clk-composite.c | 6 +- drivers/clk/clk.c | 84 ++++++++++++-- drivers/clk/clk_test.c | 176 ++++++++++++++++++++++++++++++ include/linux/clk-provider.h | 5 + 7 files changed, 273 insertions(+), 16 deletions(-)
drivers/clk/at91/clk-generated.c +3 -2
@@ -132,7 +132,6 @@ static int clk_generated_determine_rate(struct clk_hw *hw, {struct clk_generated *gck =to_clk_generated (hw);struct clk_hw *parent =NULL ; -struct clk_rate_request req_parent = *req;long best_rate = -EINVAL ;unsigned long min_rate, parent_rate;int best_diff =-1 ;
@@ -188,7 +187,9 @@ static int clk_generated_determine_rate(struct clk_hw *hw, goto end;for (div =1 ; div <GENERATED_MAX_DIV +2 ; div++) { - req_parent.rate = req->rate * div; +struct clk_rate_request req_parent; + +clk_hw_forward_rate_request (hw, req, parent, &req_parent, req->rate * div);if (__clk_determine_rate (parent, &req_parent))continue ; clk_generated_best_diff(req, parent, req_parent.rate, div,
drivers/clk/at91/clk-master.c +6 -3
@@ -581,7 +581,6 @@ static int clk_sama7g5_master_determine_rate(struct clk_hw *hw, struct clk_rate_request *req) {struct clk_master *master =to_clk_master (hw); -struct clk_rate_request req_parent = *req;struct clk_hw *parent;long best_rate =LONG_MIN , best_diff =LONG_MIN ;unsigned long parent_rate;
@@ -618,11 +617,15 @@ static int clk_sama7g5_master_determine_rate(struct clk_hw *hw, goto end;for (div =0 ; div <MASTER_PRES_MAX +1 ; div++) { +struct clk_rate_request req_parent; +unsigned long req_rate; +if (div ==MASTER_PRES_MAX ) - req_parent.rate = req->rate *3 ; + req_rate = req->rate *3 ;else - req_parent.rate = req->rate << div; + req_rate = req->rate << div; +clk_hw_forward_rate_request (hw, req, parent, &req_parent, req_rate);if (__clk_determine_rate (parent, &req_parent))continue ;
drivers/clk/at91/clk-peripheral.c +2 -2
@@ -269,7 +269,6 @@ static int clk_sam9x5_peripheral_determine_rate(struct clk_hw *hw, {struct clk_sam9x5_peripheral *periph =to_clk_sam9x5_peripheral (hw);struct clk_hw *parent =clk_hw_get_parent (hw); -struct clk_rate_request req_parent = *req;unsigned long parent_rate =clk_hw_get_rate (parent);unsigned long tmp_rate;long best_rate =LONG_MIN ;
@@ -302,8 +301,9 @@ static int clk_sam9x5_peripheral_determine_rate(struct clk_hw *hw, goto end;for (shift =0 ; shift <=PERIPHERAL_MAX_SHIFT ; shift++) { - req_parent.rate = req->rate << shift; +struct clk_rate_request req_parent; +clk_hw_forward_rate_request (hw, req, parent, &req_parent, req->rate << shift);if (__clk_determine_rate (parent, &req_parent))continue ;
drivers/clk/clk-composite.c +4 -2
@@ -85,10 +85,11 @@ static int clk_composite_determine_rate(struct clk_hw *hw, req->best_parent_hw =NULL ;if (clk_hw_get_flags (hw) &CLK_SET_RATE_NO_REPARENT ) { -struct clk_rate_request tmp_req = *req; +struct clk_rate_request tmp_req; parent =clk_hw_get_parent (mux_hw); +clk_hw_forward_rate_request (hw, req, parent, &tmp_req, req->rate); ret = clk_composite_determine_rate_for_parent(rate_hw, &tmp_req, parent,
@@ -104,12 +105,13 @@ static int clk_composite_determine_rate(struct clk_hw *hw, }for (i =0 ; i <clk_hw_get_num_parents (mux_hw); i++) { -struct clk_rate_request tmp_req = *req; +struct clk_rate_request tmp_req; parent =clk_hw_get_parent_by_index (mux_hw, i);if (!parent)continue ; +clk_hw_forward_rate_request (hw, req, parent, &tmp_req, req->rate); ret = clk_composite_determine_rate_for_parent(rate_hw, &tmp_req, parent,
drivers/clk/clk.c +77 -7
149 lines not on this page · raw message
drivers/clk/clk_test.c +176 -0
201 lines not on this page · raw message
include/linux/clk-provider.h +5 -0
@@ -65,6 +65,11 @@ struct clk_rate_request {void clk_hw_init_rate_request (const struct clk_hw *hw,struct clk_rate_request *req,unsigned long rate); +void clk_hw_forward_rate_request (const struct clk_hw *core, +const struct clk_rate_request *old_req, +const struct clk_hw *parent, +struct clk_rate_request *req, +unsigned long parent_rate);/** * struct clk_duty - Struture encoding the duty cycle ratio of a clock
Signature · 1 line
2.36.1
PATCH v5 23/28 clk: Zero the clk_rate_request structure
In reply to Maxime RipardIn order to make sure we don't carry anything over from an already existing clk_rate_request pointer we would pass to clk_core_init_rate_req(), let's zero the entire structure before initializing it.
--- drivers/clk/clk.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/clk/clk.c +2 -0
@@ -1446,6 +1446,8 @@ static void clk_core_init_rate_req(struct clk_core * const core,if (WARN_ON (!core || !req))return ; +memset (req,0 ,sizeof (*req)); + req->rate = rate;clk_core_get_boundaries (core, &req->min_rate, &req->max_rate);
Signature · 1 line
2.36.1
PATCH v5 24/28 clk: Test the clock pointer in clk_hw_get_name()
In reply to Maxime RipardUnlike __clk_get_name(), clk_hw_get_name() doesn't test wether passed clk_hw pointer is NULL or not and dereferences it directly. This can then lead to NULL pointer dereference.
Let's make sure the pointer isn't NULL before dereferencing it.
--- drivers/clk/clk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/clk.c +1 -1
@@ -262,7 +262,7 @@ EXPORT_SYMBOL_GPL(__clk_get_name);const char *clk_hw_get_name (const struct clk_hw *hw) { -return hw->core->name; +return !hw ?NULL : hw->core->name; }EXPORT_SYMBOL_GPL (clk_hw_get_name);
Signature · 1 line
2.36.1
Stephen Boyd
maintainerRe: [PATCH v5 24/28] clk: Test the clock pointer in clk_hw_get_name()
Quoting Maxime Ripard (2022-05-16 06:25:23)
Quoted 3 lines
Unlike
__clk_get_name(),clk_hw_get_name()doesn't test wether passedclk_hwpointer is NULL or not and dereferences it directly. This can then lead to NULL pointer dereference.
Why do you have a NULL clk_hw pointer? Is there some caller that is simplified with this patch?
Re: [PATCH v5 24/28] clk: Test the clock pointer in clk_hw_get_name()
Hi,
Quoted 7 lines · Stephen Boyd
Quoting Maxime Ripard (2022-05-16 06:25:23)
Quoted 3 lines
Unlike
__clk_get_name(),clk_hw_get_name()doesn't test wether passedclk_hwpointer is NULL or not and dereferences it directly. This can then lead to NULL pointer dereference.Why do you have a NULL
clk_hwpointer? Is there some caller that is simplified with this patch?
I encountered it while debugging the clock tree and assumed it would be a good idea, but I don't another reason.
I'll drop it
Maxime
PATCH v5 25/28 clk: Introduce the clk_hw_get_rate_range function
In reply to Maxime RipardSome clock providers are hand-crafting their clk_rate_request, and need to figure out the current boundaries of their clk_hw to fill it properly.
Let's create such a function for clock providers.
--- drivers/clk/clk.c | 16 ++++++++++++++++ include/linux/clk-provider.h | 2 ++ 2 files changed, 18 insertions(+)
drivers/clk/clk.c +16 -0
@@ -683,6 +683,22 @@ static void clk_core_get_boundaries(struct clk_core *core, *max_rate =min (*max_rate, clk_user->max_rate); } +/* +* clk_hw_get_rate_range() - returns the clock rate range for a hw clk +* @hw: the hw clk we want to get the range from +* @min_rate: pointer to the variable that will hold the minimum +* @max_rate: pointer to the variable that will hold the maximum +* +* Fills the @min_rate and @max_rate variables with the minimum and +* maximum that clock can reach. +*/ +void clk_hw_get_rate_range (struct clk_hw *hw,unsigned long *min_rate, +unsigned long *max_rate) +{ +clk_core_get_boundaries (hw->core, min_rate, max_rate); +} +EXPORT_SYMBOL_GPL (clk_hw_get_rate_range); +static bool clk_core_check_boundaries (struct clk_core *core,unsigned long min_rate,unsigned long max_rate)
include/linux/clk-provider.h +2 -0
@@ -1235,6 +1235,8 @@ int clk_mux_determine_rate_flags(struct clk_hw *hw,struct clk_rate_request *req, unsigned long flags);void clk_hw_reparent (struct clk_hw *hw,struct clk_hw *new_parent); +void clk_hw_get_rate_range (struct clk_hw *hw,unsigned long *min_rate, +unsigned long *max_rate);void clk_hw_set_rate_range (struct clk_hw *hw,unsigned long min_rate,unsigned long max_rate);
Signature · 1 line
2.36.1
PATCH v5 26/28 clk: qcom: clk-rcg2: Take clock boundaries into consideration for gfx3d
In reply to Maxime RipardThe gfx3d clock is hand-crafting its own clk_rate_request in clk_gfx3d_determine_rate to pass to the parent of that clock.
However, since the clk_rate_request is zero'd at creation, it will have a max_rate of 0 which will break any code depending on the clock boundaries.
That includes the recent commit 948fb0969eae ("clk: Always clamp the rounded rate") which will clamp the rate given to clk_round_rate() to the current clock boundaries.
For the gfx3d clock, it means that since both the min_rate and max_rate fields are set at zero, clk_round_rate() now always return 0.
Let's initialize the min_rate and max_rate fields properly for that clock.
--- drivers/clk/qcom/clk-rcg2.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/clk/qcom/clk-rcg2.c +9 -0
@@ -868,6 +868,15 @@ static int clk_gfx3d_determine_rate(struct clk_hw *hw, req->best_parent_hw = p2; } +clk_hw_get_rate_range (req->best_parent_hw, + &parent_req.min_rate, &parent_req.max_rate); + +if (req->min_rate > parent_req.min_rate) + parent_req.min_rate = req->min_rate; + +if (req->max_rate < parent_req.max_rate) + parent_req.max_rate = req->max_rate; + ret =__clk_determine_rate (req->best_parent_hw, &parent_req);if (ret)return ret;
Signature · 1 line
2.36.1
PATCH v5 27/28 clk: tests: Add some tests for clk_get_rate_range()
In reply to Maxime RipardLet's introduce a bunch of unit tests to make sure the values returned by clk_get_rate_range() are sane.
--- drivers/clk/clk_test.c | 182 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 182 insertions(+)
drivers/clk/clk_test.c +182 -0
@@ -900,6 +900,109 @@ clk_test_single_parent_mux_get_parent(struct kunit *test)KUNIT_EXPECT_TRUE (test,clk_is_match (parent, ctx->parent_ctx.hw.clk)); } +/* +* Test that for a clock with a single parent and CLK_SET_RATE_PARENT, +* if we set a range on both the child clock and its parent, with a +* smaller range on the child, the rate range returned by +* clk_get_rate_range() is aggregate of both ranges. +*/ +static void +clk_test_single_parent_mux_get_range_both_child_smaller (struct kunit *test) +{ +struct clk_single_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +struct clk *parent; +unsigned long min, max; +int ret; + + parent =clk_get_parent (clk); +KUNIT_ASSERT_PTR_NE (test, parent,NULL ); + + ret =clk_set_rate_range (parent,DUMMY_CLOCK_RATE_1 ,DUMMY_CLOCK_RATE_2 ); +KUNIT_ASSERT_EQ (test, ret,0 ); + + ret =clk_set_rate_range (clk, +DUMMY_CLOCK_RATE_1 +1000 , +DUMMY_CLOCK_RATE_2 -1000 ); +KUNIT_ASSERT_EQ (test, ret,0 ); + +clk_get_rate_range (clk, &min, &max); +KUNIT_EXPECT_EQ (test, min,DUMMY_CLOCK_RATE_1 +1000 ); +KUNIT_EXPECT_EQ (test, max,DUMMY_CLOCK_RATE_2 -1000 ); +} + +/* +* Test that for a clock with a single parent and CLK_SET_RATE_PARENT, +* if we set a range on both the child clock and its parent, with a +* smaller range on the parent, the rate range returned by +* clk_get_rate_range() is aggregate of both ranges. +* +* FIXME: clk_get_rate_range() (and clk_core_get_boundaries() in +* particular) doesn't take the parent range into account when the clock +* has CLK_SET_RATE_PARENT. +*/ +static void +clk_test_single_parent_mux_get_range_both_parent_smaller (struct kunit *test) +{ +struct clk_single_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +struct clk *parent; +unsigned long min, max; +int ret; + +kunit_skip (test,"This needs to be fixed in the core." ); + + parent =clk_get_parent (clk); +KUNIT_ASSERT_PTR_NE (test, parent,NULL ); + + ret =clk_set_rate_range (parent, +DUMMY_CLOCK_RATE_1 +1000 , +DUMMY_CLOCK_RATE_2 -1000 ); +KUNIT_ASSERT_EQ (test, ret,0 ); + + ret =clk_set_rate_range (clk,DUMMY_CLOCK_RATE_1 ,DUMMY_CLOCK_RATE_2 ); +KUNIT_ASSERT_EQ (test, ret,0 ); + +clk_get_rate_range (clk, &min, &max); +KUNIT_EXPECT_EQ (test, min,DUMMY_CLOCK_RATE_1 +1000 ); +KUNIT_EXPECT_EQ (test, min,DUMMY_CLOCK_RATE_2 -1000 ); +} + +/* +* Test that for a clock with a single parent and CLK_SET_RATE_PARENT, +* if we set a range on the parent clock only, the rate range returned +* by clk_get_rate_range() on the children clock matches the parent +* range. +* +* FIXME: clk_get_rate_range() (and clk_core_get_boundaries() in +* particular) doesn't take the parent range into account when the clock +* has CLK_SET_RATE_PARENT. +*/ +static void +clk_test_single_parent_mux_get_range_parent_only (struct kunit *test) +{ +struct clk_single_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +struct clk *parent; +unsigned long min, max; +int ret; + +kunit_skip (test,"This needs to be fixed in the core." ); + + parent =clk_get_parent (clk); +KUNIT_ASSERT_PTR_NE (test, parent,NULL ); + + ret =clk_set_rate_range (parent,DUMMY_CLOCK_RATE_1 ,DUMMY_CLOCK_RATE_2 ); +KUNIT_ASSERT_EQ (test, ret,0 ); + +clk_get_rate_range (clk, &min, &max); +KUNIT_EXPECT_EQ (test, min,DUMMY_CLOCK_RATE_1 ); +KUNIT_EXPECT_EQ (test, min,DUMMY_CLOCK_RATE_2 ); +} +/* * Test that for a clock with a single parent, clk_has_parent() actually * reports it as a parent.
@@ -1077,6 +1180,9 @@ clk_test_single_parent_mux_set_range_round_rate_parent_smaller(struct kunit *tesstatic struct kunit_case clk_single_parent_mux_test_cases[] = {KUNIT_CASE (clk_test_single_parent_mux_get_parent), +KUNIT_CASE (clk_test_single_parent_mux_get_range_both_child_smaller), +KUNIT_CASE (clk_test_single_parent_mux_get_range_both_parent_smaller), +KUNIT_CASE (clk_test_single_parent_mux_get_range_parent_only),KUNIT_CASE (clk_test_single_parent_mux_has_parent),KUNIT_CASE (clk_test_single_parent_mux_set_range_disjoint_child_last),KUNIT_CASE (clk_test_single_parent_mux_set_range_disjoint_parent_last),
@@ -1311,6 +1417,79 @@ clk_orphan_two_level_root_last_test_suite = { .test_cases = clk_orphan_two_level_root_last_test_cases, }; +/* +* Test that clk_set_rate_range() and clk_get_rate_range() are +* consistent on a simple clock without any parent. +*/ +static void clk_range_test_get_range (struct kunit *test) +{ +struct clk_dummy_context *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +unsigned long min, max; +int ret; + + ret =clk_set_rate_range (clk,DUMMY_CLOCK_RATE_1 ,DUMMY_CLOCK_RATE_2 ); +KUNIT_ASSERT_EQ (test, ret,0 ); + +clk_get_rate_range (clk, &min, &max); +KUNIT_EXPECT_EQ (test, min,DUMMY_CLOCK_RATE_1 ); +KUNIT_EXPECT_EQ (test, max,DUMMY_CLOCK_RATE_2 ); +} + +/* +* Test that, on a simple clock without any parent, if a rate range is +* set on a clk, it's properly reported by clk_get_rate_range() on all +* the clk structure of that clock. +*/ +static void clk_range_test_get_range_multiple_clk (struct kunit *test) +{ +struct clk_dummy_context *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *user1, *user2; +unsigned long min, max; +int ret; + + user1 =clk_hw_get_clk (hw,NULL ); +KUNIT_ASSERT_NOT_ERR_OR_NULL (test, user1); + + user2 =clk_hw_get_clk (hw,NULL ); +KUNIT_ASSERT_NOT_ERR_OR_NULL (test, user2); + + ret =clk_set_rate_range (user1, +DUMMY_CLOCK_RATE_1 , +DUMMY_CLOCK_RATE_2 ); +KUNIT_ASSERT_EQ (test, ret,0 ); + +clk_get_rate_range (user2, &min, &max); +KUNIT_EXPECT_EQ (test, min,DUMMY_CLOCK_RATE_1 ); +KUNIT_EXPECT_EQ (test, max,DUMMY_CLOCK_RATE_2 ); +} + +/* +* Test that, on a simple clock without any parent, if a rate range is +* set on struct clk_hw, it's properly reported by clk_get_rate_range(). +*/ +static void clk_range_test_get_range_with_hw (struct kunit *test) +{ +struct clk_dummy_context *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +unsigned long min, max; +int ret; + +clk_hw_set_rate_range (hw,DUMMY_CLOCK_RATE_1 ,DUMMY_CLOCK_RATE_2 ); + + ret =clk_set_rate_range (clk, +DUMMY_CLOCK_RATE_1 +1000 , +DUMMY_CLOCK_RATE_2 -1000 ); +KUNIT_ASSERT_EQ (test, ret,0 ); + +clk_get_rate_range (clk, &min, &max); +KUNIT_EXPECT_EQ (test, min,DUMMY_CLOCK_RATE_1 +1000 ); +KUNIT_EXPECT_EQ (test, max,DUMMY_CLOCK_RATE_2 -1000 ); +} +/* * Test that clk_set_rate_range won't return an error for a valid range * and that it will make sure the rate of the clock is within the
@@ -1599,6 +1778,9 @@ static void clk_range_test_set_range_get_rate_lowered(struct kunit *test) }static struct kunit_case clk_range_test_cases[] = { +KUNIT_CASE (clk_range_test_get_range), +KUNIT_CASE (clk_range_test_get_range_with_hw), +KUNIT_CASE (clk_range_test_get_range_multiple_clk),KUNIT_CASE (clk_range_test_set_range),KUNIT_CASE (clk_range_test_set_range_invalid),KUNIT_CASE (clk_range_test_multiple_disjoints_range),
Signature · 1 line
2.36.1
PATCH v5 28/28 clk: tests: Add missing test case for ranges
In reply to Maxime RipardLet'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.
--- drivers/clk/clk_test.c | 52 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+)
drivers/clk/clk_test.c +52 -0
@@ -488,9 +488,61 @@ clk_test_multiple_parents_mux_has_parent(struct kunit *test)KUNIT_EXPECT_TRUE (test,clk_has_parent (clk, ctx->parents_ctx[1 ].hw.clk)); } +/* +* Test that for a clock with a multiple parents, if we set a range on +* that clock and the parent is changed, its rate after the reparenting +* is still within the range we asked for. +* +* FIXME: clk_set_parent() only does the reparenting but doesn't +* reevaluate whether the new clock rate is within its boundaries or +* not. +*/ +static void +clk_test_multiple_parents_mux_set_range_set_parent_get_rate (struct kunit *test) +{ +struct clk_multiple_parent_ctx *ctx = test->priv; +struct clk_hw *hw = &ctx->hw; +struct clk *clk = hw->clk; +struct clk *parent1, *parent2; +unsigned long rate; +int ret; + +kunit_skip (test,"This needs to be fixed in the core." ); + + parent1 =clk_hw_get_clk (&ctx->parents_ctx[0 ].hw,NULL ); +KUNIT_ASSERT_NOT_ERR_OR_NULL (test, parent1); +KUNIT_ASSERT_TRUE (test,clk_is_match (clk_get_parent (clk), parent1)); + + parent2 =clk_hw_get_clk (&ctx->parents_ctx[1 ].hw,NULL ); +KUNIT_ASSERT_NOT_ERR_OR_NULL (test, parent2); + + ret =clk_set_rate (parent1,DUMMY_CLOCK_RATE_1 ); +KUNIT_ASSERT_EQ (test, ret,0 ); + + ret =clk_set_rate (parent2,DUMMY_CLOCK_RATE_2 ); +KUNIT_ASSERT_EQ (test, ret,0 ); + + ret =clk_set_rate_range (clk, +DUMMY_CLOCK_RATE_1 -1000 , +DUMMY_CLOCK_RATE_1 +1000 ); +KUNIT_ASSERT_EQ (test, ret,0 ); + + ret =clk_set_parent (clk, parent2); +KUNIT_ASSERT_EQ (test, ret,0 ); + + rate =clk_get_rate (clk); +KUNIT_ASSERT_GT (test, rate,0 ); +KUNIT_EXPECT_GE (test, rate,DUMMY_CLOCK_RATE_1 -1000 ); +KUNIT_EXPECT_LE (test, rate,DUMMY_CLOCK_RATE_1 +1000 ); + +clk_put (parent2); +clk_put (parent1); +} +static struct kunit_case clk_multiple_parents_mux_test_cases[] = {KUNIT_CASE (clk_test_multiple_parents_mux_get_parent),KUNIT_CASE (clk_test_multiple_parents_mux_has_parent), +KUNIT_CASE (clk_test_multiple_parents_mux_set_range_set_parent_get_rate), {} };
Signature · 1 line
2.36.1