ARM: OMAP2+: Fix dpll rounding

Printing with unsigned long rates with %ld gives wrong result if the rate is high enough. Fix this by using %lu.

Signed-off-by Tomi Valkeinen <[email protected]>

omap2_dpll_round_rate() doesn't actually round the given rate, even if the name and the description so hints. Instead it only tries to find an exact rate match, or if that fails, return ~0 as an error.

What this basically means is that the user of the clock needs to know what rates the dpll can support, which obviously isn't right.

This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned.

Signed-off-by Tomi Valkeinen <[email protected]>

---
 arch/arm/mach-omap2/clkt_dpll.c | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

arch/arm/mach-omap2/clkt_dpll.c +12 -5

index 1f1708ef77bb..1b4e68dfb713 100644
@@ -298,6 +298,7 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
 	struct dpll_data *dd;
 	unsigned long ref_rate;
 	const char *clk_name;
+	unsigned long diff, closest_diff = ~0;
 
 	if (!clk || !clk->dpll_data)
 		return ~0;

@@ -345,20 +346,26 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
 		pr_debug("clock: %s: m = %d: n = %d: new_rate = %lu\n",
 			 clk_name, m, n, new_rate);
 
-		if (target_rate == new_rate) {
+		diff = max(target_rate, new_rate) - min(target_rate, new_rate);
+
+		if (diff < closest_diff) {
+			closest_diff = diff;
+
 			dd->last_rounded_m = m;
 			dd->last_rounded_n = n;
-			dd->last_rounded_rate = target_rate;
-			break;
+			dd->last_rounded_rate = new_rate;
+
+			if (diff == 0)
+				break;
 		}
 	}
 
-	if (target_rate != new_rate) {
+	if (closest_diff == ~0) {
 		pr_debug("clock: %s: cannot round to rate %lu\n",
 			 clk_name, target_rate);
 		return ~0;
 	}
 
-	return target_rate;
+	return dd->last_rounded_rate;
 }
 

Signature · 1 line

1.8.3.2

Quoted 7 lines · Tomi Valkeinen

omap2_dpll_round_rate() doesn't actually round the given rate, even if the name and the description so hints. Instead it only tries to find an exact rate match, or if that fails, return ~0 as an error.

What this basically means is that the user of the clock needs to know what rates the dpll can support, which obviously isn't right.

Quoted 5 lines

This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned.

Signed-off-by Tomi Valkeinen <[email protected]>

Paul & Tero, please ack if you want me to queue this.

Tony

Quoted 51 lines

---
  arch/arm/mach-omap2/clkt_dpll.c | 17 ++++++++++++-----
  1 file changed, 12 insertions(+), 5 deletions(-)

arch/arm/mach-omap2/clkt_dpll.c +12 -6

index 1f1708ef77bb..1b4e68dfb713 100644
@@ -298,6 +298,7 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
  	struct dpll_data *dd;
  	unsigned long ref_rate;
  	const char *clk_name;
+	unsigned long diff, closest_diff = ~0;
 
  	if (!clk || !clk->dpll_data)
  		return ~0;

@@ -345,20 +346,26 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
  		pr_debug("clock: %s: m = %d: n = %d: new_rate = %lu\n",
  			 clk_name, m, n, new_rate);
 
-		if (target_rate == new_rate) {
+		diff = max(target_rate, new_rate) - min(target_rate, new_rate);
+
+		if (diff < closest_diff) {
+			closest_diff = diff;
+
  			dd->last_rounded_m = m;
  			dd->last_rounded_n = n;
-			dd->last_rounded_rate = target_rate;
-			break;
+			dd->last_rounded_rate = new_rate;
+
+			if (diff == 0)
+				break;
  		}
  	}
 
-	if (target_rate != new_rate) {
+	if (closest_diff == ~0) {
  		pr_debug("clock: %s: cannot round to rate %lu\n",
  			 clk_name, target_rate);
  		return ~0;
  	}
 
-	return target_rate;
+	return dd->last_rounded_rate;
  }
 
--

1.8.3.2

omap2_dpll_round_rate() doesn't actually round the given rate, even if the name and the description so hints. Instead it only tries to find an exact rate match, or if that fails, return ~0 as an error.

What this basically means is that the user of the clock needs to know what rates the dpll can support, which obviously isn't right.

This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned.

Quoted 3 lines · Tomi Valkeinen

This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned.

So that's one possible rounding policy; maybe it works fine for a display interface PLL, at least for some values of "closest rate". But another might be "only allow a selection from a set of pre-determined rates characterized by the silicon validation team". Or another rounding function might need to select a more distant rate that minimizes jitter, EMI, or power consumption.

Quoted 6 lines · Paul Walmsley

Quoted 3 lines · Tomi Valkeinen

This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned.

Quoted 6 lines

So that's one possible rounding policy; maybe it works fine for a display interface PLL, at least for some values of "closest rate". But another might be "only allow a selection from a set of pre-determined rates characterized by the silicon validation team". Or another rounding function might need to select a more distant rate that minimizes jitter, EMI, or power consumption.

Thought about this some more. Do you only need this for the DSS PLL, or do you need it for one of the core OMAP PLLs?

If the former, then how about modifying your patch to create a separate round_rate function that's only used for the DSS PLL that implements the behavior that you want?

That would eliminate any risk of impacting other users on the system. And would also allow this change to get into the codebase much faster, since there's no need for clk API changes, etc.

Quoted 6 lines · Paul Walmsley

Quoted 3 lines · Tomi Valkeinen

This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned.

Quoted 6 lines

So that's one possible rounding policy; maybe it works fine for a display interface PLL, at least for some values of "closest rate". But another might be "only allow a selection from a set of pre-determined rates characterized by the silicon validation team". Or another rounding function might need to select a more distant rate that minimizes jitter, EMI, or power consumption.

Thought about this some more. Do you only need this for the DSS PLL, or do you need it for one of the core OMAP PLLs?

If the former, then how about modifying your patch to create a separate round_rate function that's only used for the DSS PLL that implements the behavior that you want?

That would eliminate any risk of impacting other users on the system. And would also allow this change to get into the codebase much faster, since there's no need for clk API changes, etc.

From f5a78303411e9192899a6a681acac37f09f4cc3b Mon Sep 17 00:00:00 2001

Quoted 18 lines · Paul Walmsley

Quoted 6 lines · Paul Walmsley

Quoted 3 lines · Tomi Valkeinen

This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned.

Quoted 6 lines

So that's one possible rounding policy; maybe it works fine for a display interface PLL, at least for some values of "closest rate". But another might be "only allow a selection from a set of pre-determined rates characterized by the silicon validation team". Or another rounding function might need to select a more distant rate that minimizes jitter, EMI, or power consumption.

Thought about this some more. Do you only need this for the DSS PLL, or do you need it for one of the core OMAP PLLs?

Quoted 7 lines

If the former, then how about modifying your patch to create a separate round_rate function that's only used for the DSS PLL that implements the behavior that you want?

That would eliminate any risk of impacting other users on the system. And would also allow this change to get into the codebase much faster, since there's no need for clk API changes, etc.

How about this one:

From f5a78303411e9192899a6a681acac37f09f4cc3b Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <[email protected]>
Date: Wed, 15 Jan 2014 11:45:07 +0200
Subject: [PATCH] ARM: OMAP2+: fix dpll round_rate() to actually round

omap2_dpll_round_rate() doesn't actually round the given rate, even if the name and the description so hints. Instead it only tries to find an exact rate match, or if that fails, return ~0 as an error.

What this basically means is that the user of the clock needs to know what rates the dpll can support, which obviously isn't right.

This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned.

However, as it is unclear whether current drivers rely on the current behavior, the rounding functionality not enabled by default, but by setting DPLL_USE_ROUNDED_RATE for the DPLL.

Signed-off-by Tomi Valkeinen <[email protected]>

---
 arch/arm/mach-omap2/clkt_dpll.c | 23 ++++++++++++++++++-----
 drivers/clk/ti/dpll.c           |  3 +++
 include/linux/clk/ti.h          |  1 +
 3 files changed, 22 insertions(+), 5 deletions(-)

arch/arm/mach-omap2/clkt_dpll.c +18 -5

index 2649ce445845..fed7538e1eed 100644
@@ -298,6 +298,8 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
 	struct dpll_data *dd;
 	unsigned long ref_rate;
 	const char *clk_name;
+	unsigned long diff, closest_diff = ~0;
+	bool use_rounding = clk->flags & DPLL_USE_ROUNDED_RATE;
 
 	if (!clk || !clk->dpll_data)
 		return ~0;

@@ -345,20 +347,31 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
 		pr_debug("clock: %s: m = %d: n = %d: new_rate = %lu\n",
 			 clk_name, m, n, new_rate);
 
-		if (target_rate == new_rate) {
+		diff = max(target_rate, new_rate) - min(target_rate, new_rate);
+
+		if ((use_rounding && diff < closest_diff) ||
+			(!use_rounding && diff == 0)) {
+			closest_diff = diff;
+
 			dd->last_rounded_m = m;
 			dd->last_rounded_n = n;
-			dd->last_rounded_rate = target_rate;
-			break;
+			dd->last_rounded_rate = new_rate;
+
+			if (diff == 0)
+				break;
 		}
 	}
 
-	if (target_rate != new_rate) {
+	if (closest_diff == ~0) {
 		pr_debug("clock: %s: cannot round to rate %lu\n",
 			 clk_name, target_rate);
 		return ~0;
 	}
 
-	return target_rate;
+	if (closest_diff > 0)
+		pr_debug("clock: %s: rounded rate %lu to %lu\n",
+			 clk_name, target_rate, dd->last_rounded_rate);
+
+	return dd->last_rounded_rate;
 }
 

drivers/clk/ti/dpll.c +3 -0

index 7e498a44f97d..c5858c46b58c 100644
@@ -265,6 +265,9 @@ static void __init of_ti_dpll_setup(struct device_node *node,
 	if (dpll_mode)
 		dd->modes = dpll_mode;
 
+	if (of_property_read_bool(node, "ti,round-rate"))
+		clk_hw->flags |= DPLL_USE_ROUNDED_RATE;
+
 	ti_clk_register_dpll(&clk_hw->hw, node);
 	return;
 

include/linux/clk/ti.h +1 -0

index 092b64168d7f..c9ed8b6b8513 100644
@@ -155,6 +155,7 @@ struct clk_hw_omap {
 #define INVERT_ENABLE		(1 << 4)	/* 0 enables, 1 disables */
 #define CLOCK_CLKOUTX2		(1 << 5)
 #define MEMMAP_ADDRESSING	(1 << 6)
+#define DPLL_USE_ROUNDED_RATE	(1 << 7)	/* dpll's round_rate() returns rounded rate */
 
 /* CM_CLKEN_PLL*.EN* bit values - not all are available for every DPLL */
 #define DPLL_LOW_POWER_STOP	0x1

Signature · 1 line

1.8.3.2

From f5a78303411e9192899a6a681acac37f09f4cc3b Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <[email protected]>
Date: Wed, 15 Jan 2014 11:45:07 +0200
Subject: [PATCH] ARM: OMAP2+: fix dpll round_rate() to actually round

omap2_dpll_round_rate() doesn't actually round the given rate, even if the name and the description so hints. Instead it only tries to find an exact rate match, or if that fails, return ~0 as an error.

What this basically means is that the user of the clock needs to know what rates the dpll can support, which obviously isn't right.

This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned.

However, as it is unclear whether current drivers rely on the current behavior, the rounding functionality not enabled by default, but by setting DPLL_USE_ROUNDED_RATE for the DPLL.

Signed-off-by Tomi Valkeinen <[email protected]>

---
 arch/arm/mach-omap2/clkt_dpll.c | 23 ++++++++++++++++++-----
 drivers/clk/ti/dpll.c           |  3 +++
 include/linux/clk/ti.h          |  1 +
 3 files changed, 22 insertions(+), 5 deletions(-)

arch/arm/mach-omap2/clkt_dpll.c +18 -5

index 2649ce445845..fed7538e1eed 100644
@@ -298,6 +298,8 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
        struct dpll_data *dd;
        unsigned long ref_rate;
        const char *clk_name;
+       unsigned long diff, closest_diff = ~0;
+       bool use_rounding = clk->flags & DPLL_USE_ROUNDED_RATE;
 
        if (!clk || !clk->dpll_data)
                return ~0;

@@ -345,20 +347,31 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
                pr_debug("clock: %s: m = %d: n = %d: new_rate = %lu\n",
                         clk_name, m, n, new_rate);
 
-               if (target_rate == new_rate) {
+               diff = max(target_rate, new_rate) - min(target_rate, new_rate);
+
+               if ((use_rounding && diff < closest_diff) ||
+                       (!use_rounding && diff == 0)) {
+                       closest_diff = diff;
+
                        dd->last_rounded_m = m;
                        dd->last_rounded_n = n;
-                       dd->last_rounded_rate = target_rate;
-                       break;
+                       dd->last_rounded_rate = new_rate;
+
+                       if (diff == 0)
+                               break;
                }
        }
 
-       if (target_rate != new_rate) {
+       if (closest_diff == ~0) {
                pr_debug("clock: %s: cannot round to rate %lu\n",
                         clk_name, target_rate);
                return ~0;
        }
 
-       return target_rate;
+       if (closest_diff > 0)
+               pr_debug("clock: %s: rounded rate %lu to %lu\n",
+                        clk_name, target_rate, dd->last_rounded_rate);
+
+       return dd->last_rounded_rate;
 }
 

drivers/clk/ti/dpll.c +0 -0

index 7e498a44f97d..c5858c46b58c 100644

drivers/clk/ti/dpll.c +1 -0

+
        ti_clk_register_dpll(&clk_hw->hw, node);
        return;
 

include/linux/clk/ti.h +1 -1

index 092b64168d7f..c9ed8b6b8513 100644
@@ -155,6 +155,7 @@ struct clk_hw_omap {
 #define INVERT_ENABLE          (1 << 4)        /* 0 enables, 1 disables */
 #define CLOCK_CLKOUTX2         (1 << 5)
 #define MEMMAP_ADDRESSING      (1 << 6)
+#define DPLL_USE_ROUNDED_RATE  (1 << 7)        /* dpll's round_rate() returns rounded rate */
 
 /* CM_CLKEN_PLL*.EN* bit values - not all are available for every DPLL */
 #define DPLL_LOW_POWER_STOP    0x1
--

1.8.3.2

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 3 lines · Tomi Valkeinen

omap2_dpll_round_rate() doesn't actually round the given rate, even if the name and the description so hints. Instead it only tries to find an exact rate match, or if that fails, return ~0 as an error.

In the past, we had "rate tolerance" code, which allowed the clock code to return an approximate rate within some margin. See for example commit 241d3a8dca239610d3d991bf58d4fe38c2d86fd5 ("OMAP2+: clock: remove the DPLL rate tolerance code"). The rate tolerance was set at compile-time, but it was set on a per-PLL basis, which in theory allowed PLLs responsible for audio, etc. to have a very low rate tolerance, but PLLs that only drove internal functional blocks to have a high rate tolerance.

Part of the reason why this was removed is because some of the TI hardware guys didn't want any PLL rates used that were not explicitly characterized.

Quoted 2 lines

What this basically means is that the user of the clock needs to know what rates the dpll can support, which obviously isn't right.

In principle I agree with you, but I'm not sure that this rate rounding function is the solution.

Quoted 3 lines

This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned.

So that's one possible rounding policy; maybe it works fine for a display interface PLL, at least for some values of "closest rate". But another might be "only allow a selection from a set of pre-determined rates characterized by the silicon validation team". Or another rounding function might need to select a more distant rate that minimizes jitter, EMI, or power consumption.

Seems to me that there needs to be some way for a clock user to communicate its requirements along these lines to the clock framework for use by the rate rounding code. At the very least, some kind of [min, max] interval seems appropriate.

Also I've often thought that it would be useful for your purposes to be able to query a clock to return a list or some other parametric description of the rates that it can provide.

Quoted 14 lines · Paul Walmsley

Quoted 3 lines · Tomi Valkeinen

omap2_dpll_round_rate() doesn't actually round the given rate, even if the name and the description so hints. Instead it only tries to find an exact rate match, or if that fails, return ~0 as an error.

In the past, we had "rate tolerance" code, which allowed the clock code to return an approximate rate within some margin. See for example commit 241d3a8dca239610d3d991bf58d4fe38c2d86fd5 ("OMAP2+: clock: remove the DPLL rate tolerance code"). The rate tolerance was set at compile-time, but it was set on a per-PLL basis, which in theory allowed PLLs responsible for audio, etc. to have a very low rate tolerance, but PLLs that only drove internal functional blocks to have a high rate tolerance.

Quoted 3 lines

Part of the reason why this was removed is because some of the TI hardware guys didn't want any PLL rates used that were not explicitly characterized.

Ok.

Quoted 17 lines

Quoted 2 lines

What this basically means is that the user of the clock needs to know what rates the dpll can support, which obviously isn't right.

In principle I agree with you, but I'm not sure that this rate rounding function is the solution.

Quoted 3 lines

This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned.

So that's one possible rounding policy; maybe it works fine for a display interface PLL, at least for some values of "closest rate". But another might be "only allow a selection from a set of pre-determined rates characterized by the silicon validation team". Or another rounding function might need to select a more distant rate that minimizes jitter, EMI, or power consumption.

Quoted 8 lines

Seems to me that there needs to be some way for a clock user to communicate its requirements along these lines to the clock framework for use by the rate rounding code. At the very least, some kind of [min, max] interval seems appropriate.

Also I've often thought that it would be useful for your purposes to be able to query a clock to return a list or some other parametric description of the rates that it can provide.

I fully agree with all you said above.

However, I'm not trying to fix the omap clock framework here =). I just want the displays to work properly in mainline kernel.

So, presuming this was merged, and gets display working, how would it affect other users compared to the current state? The patched version returns the same rate than before, if an exact match is found. Rounded rate is only returned as a last option, instead of an error.

Do we have drivers that handle that error somehow, and then do something (what?) to get some other rate?

If the clock path in question also has a divider component after the pll, using clk-divider.c (which I guess is used in all/most of the DPLLs?), things would go badly wrong if there's an error, as clk-divider.c doesn't handle it.

So I can make no guarantees, but I have a hunch that all current users ask for an exact clock, in which case this patch doesn't change their behavior, except for display which it fixes.

omap2_dpll_round_rate() doesn't actually round the given rate, even if the name and the description so hints. Instead it only tries to find an exact rate match, or if that fails, return ~0 as an error.

What this basically means is that the user of the clock needs to know what rates the dpll can support, which obviously isn't right.

This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned.

Signed-off-by Tomi Valkeinen <[email protected]>

Hi,

Quoted 7 lines · Tomi Valkeinen

omap2_dpll_round_rate() doesn't actually round the given rate, even if the name and the description so hints. Instead it only tries to find an exact rate match, or if that fails, return ~0 as an error.

What this basically means is that the user of the clock needs to know what rates the dpll can support, which obviously isn't right.

Quoted 5 lines

This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned.

Signed-off-by Tomi Valkeinen <[email protected]>

Tony, looks like this patch was lost. Are you taking it during the -rc ?

Quoted 14 lines · Felipe Balbi

Hi,

Quoted 11 lines · Tomi Valkeinen

omap2_dpll_round_rate() doesn't actually round the given rate, even if the name and the description so hints. Instead it only tries to find an exact rate match, or if that fails, return ~0 as an error.

What this basically means is that the user of the clock needs to know what rates the dpll can support, which obviously isn't right.

This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned.

Quoted 3 lines

Quoted 1 line

Signed-off-by Tomi Valkeinen <[email protected]>

Tony, looks like this patch was lost. Are you taking it during the -rc ?

Would like to hear what Paul thinks of the updated patch suggested by Tomi first.

Quoted 17 lines · Tony Lindgren

Quoted 16 lines · Felipe Balbi

Hi,

Quoted 12 lines · Tomi Valkeinen

omap2_dpll_round_rate() doesn't actually round the given rate, even if the name and the description so hints. Instead it only tries to find an exact rate match, or if that fails, return ~0 as an error.

What this basically means is that the user of the clock needs to know what rates the dpll can support, which obviously isn't right.

This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned.

Signed-off-by Tomi Valkeinen <[email protected]>

Quoted 4 lines

Quoted 1 line

Tony, looks like this patch was lost. Are you taking it during the -rc ?

Would like to hear what Paul thinks of the updated patch suggested by Tomi first.

Paul, any chance you can review Tomi's v2 ? It'd be very nice to get display working on BBB.

Quoted 18 lines · Felipe Balbi

Quoted 17 lines · Tony Lindgren

Quoted 16 lines · Felipe Balbi

Hi,

Quoted 12 lines · Tomi Valkeinen

omap2_dpll_round_rate() doesn't actually round the given rate, even if the name and the description so hints. Instead it only tries to find an exact rate match, or if that fails, return ~0 as an error.

What this basically means is that the user of the clock needs to know what rates the dpll can support, which obviously isn't right.

This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned.

Signed-off-by Tomi Valkeinen <[email protected]>

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

Tony, looks like this patch was lost. Are you taking it during the -rc ?

Would like to hear what Paul thinks of the updated patch suggested by Tomi first.

Paul, any chance you can review Tomi's v2 ? It'd be very nice to get display working on BBB.

Btw, I'm fine with my v2 patch, but I think the original one is fine also.

It's true that the original patch changes the dpll behavior when an exact match is not found. However, I think our drivers always request an exact match, and in that case the original patch doesn't change the behavior in practice.

In theory it's possible that a driver requests a non-exact clock from the dpll, and when it gets an error, it does something else.

But, if I'm not mistaken, all our dplls have a clk-divider after them. And as clk-divider doesn't handle the error from dpll in any way, and instead returns bogus rates, I presume all our drivers use exact clocks.

Quoted 7 lines

It's true that the original patch changes the dpll behavior when an exact match is not found. However, I think our drivers always request an exact match, and in that case the original patch doesn't change the behavior in practice.

In theory it's possible that a driver requests a non-exact clock from the dpll, and when it gets an error, it does something else.

The path that worries me at the moment is the set-rate path. That calls __clk_round_rate() (if the user hasn't called it already) and silently tries to set the clock to the altered rate.