Re: [PATCH v5] clk: change clk_ops' ->determine_rate() prototype
On Mon, 13 Jul 2015 16:02:18 -0700
Stephen Boyd wrote:
> On 07/09, Boris Brezillon wrote:
> > Hi Stephen,
> >
> > On Wed, 08 Jul 2015 11:07:42 -0700
> > Stephen Boyd wrote:
> >
> > > On 07/08/2015 02:00 AM, Boris Brezillon wrote:
> > > > Hi Stephen,
> > > >
> > > > On Tue, 7 Jul 2015 17:57:48 -0700
> > > > Stephen Boyd wrote:
> > > >
> > > >> On 07/07, Boris Brezillon wrote:
> > > >>>
> > > >>> } else {
> > > >>> pr_err("clk: clk_composite_determine_rate function
> > > >>> called, but no mux or rate callback set!\n");
> > > >>> + req->rate = 0;
> > > >>> return 0;
> > > >> Shouldn't this return an error now? And then assigning req->rate
> > > >> wouldn't be necessary. Sorry I must have missed this last round.
> > > >>
> > > > Actually I wanted to keep the existing behavior: return a 0 rate (not
> > > > an error) when there is no mux or rate ops.
> > > >
> > > > That's something we can change afterwards, but it might reveals
> > > > new bugs if some users are checking for a 0 rate to detect errors.
> > > >
> > >
> > > Ok. Care to send the patch now to do that while we're thinking about it?
> > > We can test it out for a month or two.
> > >
> >
> > Here is a patch modifying a few drivers to return errors instead of a 0
> > rate. Feel free to squash it in the previous one if you think this is
> > better.
> >
> > Best Regards,
> >
> > Boris
> >
> > --- >8 ---
> >
> > From dca9c28301042cf19dad4b1e4555cdb7c1063745 Mon Sep 17 00:00:00 2001
> > From: Boris Brezillon
> > Date: Thu, 9 Jul 2015 12:20:21 +0200
> > Subject: [PATCH] clk: fix some determine_rate implementations
> >
> > Some determine_rate implementations are not returning an error when then
> > failed to adapt the rate according to the rate request.
> > Fix them so that they return an error instead of silently returning 0.
> >
> > Signed-off-by: Boris Brezillon
>
> The linewrap is seriously messed up here. Please fix your mailer
> next time. I had to hand edit the patch to get it to apply. I've
> applied this in top of the original patch as a different commit,
> in case we need to revert it later.
Sorry about that, I forgot to remove the line wrapper when copying the
content of the patch into my mailer :-/.
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] clk: change clk_ops' ->determine_rate() prototype
On 07/09, Boris Brezillon wrote:
> Hi Stephen,
>
> On Wed, 08 Jul 2015 11:07:42 -0700
> Stephen Boyd wrote:
>
> > On 07/08/2015 02:00 AM, Boris Brezillon wrote:
> > > Hi Stephen,
> > >
> > > On Tue, 7 Jul 2015 17:57:48 -0700
> > > Stephen Boyd wrote:
> > >
> > >> On 07/07, Boris Brezillon wrote:
> > >>>
> > >>> } else {
> > >>> pr_err("clk: clk_composite_determine_rate function
> > >>> called, but no mux or rate callback set!\n");
> > >>> + req->rate = 0;
> > >>> return 0;
> > >> Shouldn't this return an error now? And then assigning req->rate
> > >> wouldn't be necessary. Sorry I must have missed this last round.
> > >>
> > > Actually I wanted to keep the existing behavior: return a 0 rate (not
> > > an error) when there is no mux or rate ops.
> > >
> > > That's something we can change afterwards, but it might reveals
> > > new bugs if some users are checking for a 0 rate to detect errors.
> > >
> >
> > Ok. Care to send the patch now to do that while we're thinking about it?
> > We can test it out for a month or two.
> >
>
> Here is a patch modifying a few drivers to return errors instead of a 0
> rate. Feel free to squash it in the previous one if you think this is
> better.
>
> Best Regards,
>
> Boris
>
> --- >8 ---
>
> From dca9c28301042cf19dad4b1e4555cdb7c1063745 Mon Sep 17 00:00:00 2001
> From: Boris Brezillon
> Date: Thu, 9 Jul 2015 12:20:21 +0200
> Subject: [PATCH] clk: fix some determine_rate implementations
>
> Some determine_rate implementations are not returning an error when then
> failed to adapt the rate according to the rate request.
> Fix them so that they return an error instead of silently returning 0.
>
> Signed-off-by: Boris Brezillon
The linewrap is seriously messed up here. Please fix your mailer
next time. I had to hand edit the patch to get it to apply. I've
applied this in top of the original patch as a different commit,
in case we need to revert it later.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] clk: change clk_ops' ->determine_rate() prototype
On 07/08/2015 03:57 AM, Stephen Boyd wrote:
On 07/07, Boris Brezillon wrote:
Clock rates are stored in an unsigned long field, but ->determine_rate()
(which returns a rounded rate from a requested one) returns a long
value (errors are reported using negative error codes), which can lead
to long overflow if the clock rate exceed 2Ghz.
Change ->determine_rate() prototype to return 0 or an error code, and pass
a pointer to a clk_rate_request structure containing the expected target
rate and the rate constraints imposed by clk users.
The clk_rate_request structure might be extended in the future to contain
other kind of constraints like the rounding policy, the maximum clock
inaccuracy or other things that are not yet supported by the CCF
(power consumption constraints ?).
Signed-off-by: Boris Brezillon
CC: Jonathan Corbet
CC: Tony Lindgren
CC: Ralf Baechle
CC: "Emilio López"
CC: Maxime Ripard
CC: Tero Kristo
CC: Peter De Schrijver
CC: Prashant Gaikwad
CC: Stephen Warren
CC: Thierry Reding
CC: Alexandre Courbot
CC: linux-...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: linux-arm-ker...@lists.infradead.org
CC: linux-omap@vger.kernel.org
CC: linux-m...@linux-mips.org
CC: linux-te...@vger.kernel.org
---
I'll throw this patch into -next now to see if any other problems
shake out. I'm hoping we get some more acks though, so it'll be
on it's own branch and become immutable in a week or so. One
question below.
Gave this patch a quick test on the boards I have access to, and didn't
notice any obvious problems.
So, for the TI parts:
Acked-by: Tero Kristo
diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index 616f5ae..9e69f34 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -99,33 +99,33 @@ static long clk_composite_determine_rate(struct clk_hw *hw,
unsigned long rate,
parent_rate = __clk_get_rate(parent);
- tmp_rate = rate_ops->round_rate(rate_hw, rate,
+ tmp_rate = rate_ops->round_rate(rate_hw, req->rate,
&parent_rate);
if (tmp_rate < 0)
continue;
- rate_diff = abs(rate - tmp_rate);
+ rate_diff = abs(req->rate - tmp_rate);
- if (!rate_diff || !*best_parent_p
+ if (!rate_diff || !req->best_parent_hw
|| best_rate_diff > rate_diff) {
- *best_parent_p = __clk_get_hw(parent);
- *best_parent_rate = parent_rate;
+ req->best_parent_hw = __clk_get_hw(parent);
+ req->best_parent_rate = parent_rate;
best_rate_diff = rate_diff;
best_rate = tmp_rate;
}
if (!rate_diff)
- return rate;
+ return 0;
}
- return best_rate;
+ req->rate = best_rate;
+ return 0;
} else if (mux_hw && mux_ops && mux_ops->determine_rate) {
__clk_hw_set_clk(mux_hw, hw);
- return mux_ops->determine_rate(mux_hw, rate, min_rate,
- max_rate, best_parent_rate,
- best_parent_p);
+ return mux_ops->determine_rate(mux_hw, req);
} else {
pr_err("clk: clk_composite_determine_rate function called, but no
mux or rate callback set!\n");
+ req->rate = 0;
return 0;
Shouldn't this return an error now? And then assigning req->rate
wouldn't be necessary. Sorry I must have missed this last round.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] clk: change clk_ops' ->determine_rate() prototype
Hi Stephen,
On Wed, 08 Jul 2015 11:07:42 -0700
Stephen Boyd wrote:
> On 07/08/2015 02:00 AM, Boris Brezillon wrote:
> > Hi Stephen,
> >
> > On Tue, 7 Jul 2015 17:57:48 -0700
> > Stephen Boyd wrote:
> >
> >> On 07/07, Boris Brezillon wrote:
> >>>
> >>> } else {
> >>> pr_err("clk: clk_composite_determine_rate function called, but
> >>> no mux or rate callback set!\n");
> >>> + req->rate = 0;
> >>> return 0;
> >> Shouldn't this return an error now? And then assigning req->rate
> >> wouldn't be necessary. Sorry I must have missed this last round.
> >>
> > Actually I wanted to keep the existing behavior: return a 0 rate (not
> > an error) when there is no mux or rate ops.
> >
> > That's something we can change afterwards, but it might reveals
> > new bugs if some users are checking for a 0 rate to detect errors.
> >
>
> Ok. Care to send the patch now to do that while we're thinking about it?
> We can test it out for a month or two.
>
Here is a patch modifying a few drivers to return errors instead of a 0
rate. Feel free to squash it in the previous one if you think this is
better.
Best Regards,
Boris
--- >8 ---
>From dca9c28301042cf19dad4b1e4555cdb7c1063745 Mon Sep 17 00:00:00 2001
From: Boris Brezillon
Date: Thu, 9 Jul 2015 12:20:21 +0200
Subject: [PATCH] clk: fix some determine_rate implementations
Some determine_rate implementations are not returning an error when then
failed to adapt the rate according to the rate request.
Fix them so that they return an error instead of silently returning 0.
Signed-off-by: Boris Brezillon
---
arch/mips/alchemy/common/clock.c| 4
drivers/clk/clk-composite.c | 3 +--
drivers/clk/clk.c | 15 ++-
drivers/clk/hisilicon/clk-hi3620.c | 2 +-
drivers/clk/mmp/clk-mix.c | 5 -
drivers/clk/sunxi/clk-factors.c | 6 --
drivers/clk/sunxi/clk-sun6i-ar100.c | 3 +++
drivers/clk/sunxi/clk-sunxi.c | 6 --
8 files changed, 27 insertions(+), 17 deletions(-)
diff --git a/arch/mips/alchemy/common/clock.c
b/arch/mips/alchemy/common/clock.c index 0b4cf3e..7cc3eed 100644
--- a/arch/mips/alchemy/common/clock.c
+++ b/arch/mips/alchemy/common/clock.c
@@ -469,9 +469,13 @@ static int alchemy_clk_fgcs_detr(struct clk_hw *hw,
}
}
+ if (br < 0)
+ return br;
+
req->best_parent_rate = bpr;
req->best_parent_hw = __clk_get_hw(bpc);
req->rate = br;
+
return 0;
}
diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index 9e69f34..35ac062 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -125,8 +125,7 @@ static int clk_composite_determine_rate(struct
clk_hw *hw, return mux_ops->determine_rate(mux_hw, req);
} else {
pr_err("clk: clk_composite_determine_rate function
called, but no mux or rate callback set!\n");
- req->rate = 0;
- return 0;
+ return -EINVAL;
}
}
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index c182d8a..d67d9b4 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -447,24 +447,18 @@ clk_mux_determine_rate_flags(struct clk_hw *hw,
struct clk_rate_request *req,
/* if NO_REPARENT flag set, pass through to current parent */
if (core->flags & CLK_SET_RATE_NO_REPARENT) {
- parent = core->parent;
+ best_parent = core->parent;
if (core->flags & CLK_SET_RATE_PARENT) {
- ret = __clk_determine_rate(parent ?
parent->hw : NULL,
+ ret = __clk_determine_rate(best_parent ?
best_parent->hw : NULL, &parent_req);
if (ret)
return ret;
best = parent_req.rate;
- req->best_parent_hw = parent->hw;
- req->best_parent_rate = best;
- } else if (parent) {
+ } else if (best_parent) {
best = clk_core_get_rate_nolock(parent);
- req->best_parent_hw = parent->hw;
- req->best_parent_rate = best;
} else {
best = clk_core_get_rate_nolock(core);
- req->best_parent_hw = NULL;
- req->best_parent_rate = 0;
}
goto out;
@@ -493,6 +487,9 @@ clk_mux_determine_rate_flags(struct clk_hw *hw,
struct clk_rate_request *req, }
}
+ if (!best_parent)
+ return -EINVAL;
+
out:
if (best_parent)
req->best_parent_hw = best_parent->hw;
diff --git a/drivers/clk/hisilicon/clk-hi3620.c
b/drivers/clk/hisilicon/clk-hi3620.c index a0674ba..c84ec86 100644
--- a/drivers/clk/hisilicon/clk-hi3620.c
+++ b/drivers/clk/hisilicon/clk-hi3620.c
@@ -316,7 +316,7 @@ static int mmc_clk_determine_rate(struct clk_hw *hw,
req->
Re: [PATCH v5] clk: change clk_ops' ->determine_rate() prototype
On 07/08/2015 02:00 AM, Boris Brezillon wrote:
> Hi Stephen,
>
> On Tue, 7 Jul 2015 17:57:48 -0700
> Stephen Boyd wrote:
>
>> On 07/07, Boris Brezillon wrote:
>>>
>>> } else {
>>> pr_err("clk: clk_composite_determine_rate function called, but
>>> no mux or rate callback set!\n");
>>> + req->rate = 0;
>>> return 0;
>> Shouldn't this return an error now? And then assigning req->rate
>> wouldn't be necessary. Sorry I must have missed this last round.
>>
> Actually I wanted to keep the existing behavior: return a 0 rate (not
> an error) when there is no mux or rate ops.
>
> That's something we can change afterwards, but it might reveals
> new bugs if some users are checking for a 0 rate to detect errors.
>
Ok. Care to send the patch now to do that while we're thinking about it?
We can test it out for a month or two.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] clk: change clk_ops' ->determine_rate() prototype
Hi Stephen,
On Tue, 7 Jul 2015 17:57:48 -0700
Stephen Boyd wrote:
> On 07/07, Boris Brezillon wrote:
> > Clock rates are stored in an unsigned long field, but ->determine_rate()
> > (which returns a rounded rate from a requested one) returns a long
> > value (errors are reported using negative error codes), which can lead
> > to long overflow if the clock rate exceed 2Ghz.
> >
> > Change ->determine_rate() prototype to return 0 or an error code, and pass
> > a pointer to a clk_rate_request structure containing the expected target
> > rate and the rate constraints imposed by clk users.
> >
> > The clk_rate_request structure might be extended in the future to contain
> > other kind of constraints like the rounding policy, the maximum clock
> > inaccuracy or other things that are not yet supported by the CCF
> > (power consumption constraints ?).
> >
> > Signed-off-by: Boris Brezillon
> >
> > CC: Jonathan Corbet
> > CC: Tony Lindgren
> > CC: Ralf Baechle
> > CC: "Emilio López"
> > CC: Maxime Ripard
> > CC: Tero Kristo
> > CC: Peter De Schrijver
> > CC: Prashant Gaikwad
> > CC: Stephen Warren
> > CC: Thierry Reding
> > CC: Alexandre Courbot
> > CC: linux-...@vger.kernel.org
> > CC: linux-ker...@vger.kernel.org
> > CC: linux-arm-ker...@lists.infradead.org
> > CC: linux-omap@vger.kernel.org
> > CC: linux-m...@linux-mips.org
> > CC: linux-te...@vger.kernel.org
> >
> > ---
>
> I'll throw this patch into -next now to see if any other problems
> shake out. I'm hoping we get some more acks though, so it'll be
> on it's own branch and become immutable in a week or so. One
> question below.
>
> > diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> > index 616f5ae..9e69f34 100644
> > --- a/drivers/clk/clk-composite.c
> > +++ b/drivers/clk/clk-composite.c
> > @@ -99,33 +99,33 @@ static long clk_composite_determine_rate(struct clk_hw
> > *hw, unsigned long rate,
> >
> > parent_rate = __clk_get_rate(parent);
> >
> > - tmp_rate = rate_ops->round_rate(rate_hw, rate,
> > + tmp_rate = rate_ops->round_rate(rate_hw, req->rate,
> > &parent_rate);
> > if (tmp_rate < 0)
> > continue;
> >
> > - rate_diff = abs(rate - tmp_rate);
> > + rate_diff = abs(req->rate - tmp_rate);
> >
> > - if (!rate_diff || !*best_parent_p
> > + if (!rate_diff || !req->best_parent_hw
> >|| best_rate_diff > rate_diff) {
> > - *best_parent_p = __clk_get_hw(parent);
> > - *best_parent_rate = parent_rate;
> > + req->best_parent_hw = __clk_get_hw(parent);
> > + req->best_parent_rate = parent_rate;
> > best_rate_diff = rate_diff;
> > best_rate = tmp_rate;
> > }
> >
> > if (!rate_diff)
> > - return rate;
> > + return 0;
> > }
> >
> > - return best_rate;
> > + req->rate = best_rate;
> > + return 0;
> > } else if (mux_hw && mux_ops && mux_ops->determine_rate) {
> > __clk_hw_set_clk(mux_hw, hw);
> > - return mux_ops->determine_rate(mux_hw, rate, min_rate,
> > - max_rate, best_parent_rate,
> > - best_parent_p);
> > + return mux_ops->determine_rate(mux_hw, req);
> > } else {
> > pr_err("clk: clk_composite_determine_rate function called, but
> > no mux or rate callback set!\n");
> > + req->rate = 0;
> > return 0;
>
> Shouldn't this return an error now? And then assigning req->rate
> wouldn't be necessary. Sorry I must have missed this last round.
>
Actually I wanted to keep the existing behavior: return a 0 rate (not
an error) when there is no mux or rate ops.
That's something we can change afterwards, but it might reveals
new bugs if some users are checking for a 0 rate to detect errors.
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] clk: change clk_ops' ->determine_rate() prototype
On 07/07, Boris Brezillon wrote:
> Clock rates are stored in an unsigned long field, but ->determine_rate()
> (which returns a rounded rate from a requested one) returns a long
> value (errors are reported using negative error codes), which can lead
> to long overflow if the clock rate exceed 2Ghz.
>
> Change ->determine_rate() prototype to return 0 or an error code, and pass
> a pointer to a clk_rate_request structure containing the expected target
> rate and the rate constraints imposed by clk users.
>
> The clk_rate_request structure might be extended in the future to contain
> other kind of constraints like the rounding policy, the maximum clock
> inaccuracy or other things that are not yet supported by the CCF
> (power consumption constraints ?).
>
> Signed-off-by: Boris Brezillon
>
> CC: Jonathan Corbet
> CC: Tony Lindgren
> CC: Ralf Baechle
> CC: "Emilio López"
> CC: Maxime Ripard
> CC: Tero Kristo
> CC: Peter De Schrijver
> CC: Prashant Gaikwad
> CC: Stephen Warren
> CC: Thierry Reding
> CC: Alexandre Courbot
> CC: linux-...@vger.kernel.org
> CC: linux-ker...@vger.kernel.org
> CC: linux-arm-ker...@lists.infradead.org
> CC: linux-omap@vger.kernel.org
> CC: linux-m...@linux-mips.org
> CC: linux-te...@vger.kernel.org
>
> ---
I'll throw this patch into -next now to see if any other problems
shake out. I'm hoping we get some more acks though, so it'll be
on it's own branch and become immutable in a week or so. One
question below.
> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> index 616f5ae..9e69f34 100644
> --- a/drivers/clk/clk-composite.c
> +++ b/drivers/clk/clk-composite.c
> @@ -99,33 +99,33 @@ static long clk_composite_determine_rate(struct clk_hw
> *hw, unsigned long rate,
>
> parent_rate = __clk_get_rate(parent);
>
> - tmp_rate = rate_ops->round_rate(rate_hw, rate,
> + tmp_rate = rate_ops->round_rate(rate_hw, req->rate,
> &parent_rate);
> if (tmp_rate < 0)
> continue;
>
> - rate_diff = abs(rate - tmp_rate);
> + rate_diff = abs(req->rate - tmp_rate);
>
> - if (!rate_diff || !*best_parent_p
> + if (!rate_diff || !req->best_parent_hw
> || best_rate_diff > rate_diff) {
> - *best_parent_p = __clk_get_hw(parent);
> - *best_parent_rate = parent_rate;
> + req->best_parent_hw = __clk_get_hw(parent);
> + req->best_parent_rate = parent_rate;
> best_rate_diff = rate_diff;
> best_rate = tmp_rate;
> }
>
> if (!rate_diff)
> - return rate;
> + return 0;
> }
>
> - return best_rate;
> + req->rate = best_rate;
> + return 0;
> } else if (mux_hw && mux_ops && mux_ops->determine_rate) {
> __clk_hw_set_clk(mux_hw, hw);
> - return mux_ops->determine_rate(mux_hw, rate, min_rate,
> -max_rate, best_parent_rate,
> -best_parent_p);
> + return mux_ops->determine_rate(mux_hw, req);
> } else {
> pr_err("clk: clk_composite_determine_rate function called, but
> no mux or rate callback set!\n");
> + req->rate = 0;
> return 0;
Shouldn't this return an error now? And then assigning req->rate
wouldn't be necessary. Sorry I must have missed this last round.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] clk: change clk_ops' ->determine_rate() prototype
Clock rates are stored in an unsigned long field, but ->determine_rate() (which returns a rounded rate from a requested one) returns a long value (errors are reported using negative error codes), which can lead to long overflow if the clock rate exceed 2Ghz. Change ->determine_rate() prototype to return 0 or an error code, and pass a pointer to a clk_rate_request structure containing the expected target rate and the rate constraints imposed by clk users. The clk_rate_request structure might be extended in the future to contain other kind of constraints like the rounding policy, the maximum clock inaccuracy or other things that are not yet supported by the CCF (power consumption constraints ?). Signed-off-by: Boris Brezillon CC: Jonathan Corbet CC: Tony Lindgren CC: Ralf Baechle CC: "Emilio López" CC: Maxime Ripard CC: Tero Kristo CC: Peter De Schrijver CC: Prashant Gaikwad CC: Stephen Warren CC: Thierry Reding CC: Alexandre Courbot CC: linux-...@vger.kernel.org CC: linux-ker...@vger.kernel.org CC: linux-arm-ker...@lists.infradead.org CC: linux-omap@vger.kernel.org CC: linux-m...@linux-mips.org CC: linux-te...@vger.kernel.org --- changes since v4: - remove useless tests in omap drivers - remove useless parent assignment in the hi-3620 driver - fix a compilation error in the clk-mix driver - fix a compilation error in the alchemy clk driver - fix a wrong return code in the qcom pll driver changes since v3: - modify clk-emc driver to match the new prototype - fix __clk_round_rate negative error code return - remove unused variable in clk-hi3620.c - rebased on 4.2-rc1 Changes since v2: - drop the ->round_rate() prototype changes - introduce a clk_rate_request struct to avoid any changes on the prototype in the future Changes since v1: - fix an 'uninitialized variable' bug reported by Heiko - rebased on clk-next --- Documentation/clk.txt | 8 +- arch/arm/mach-omap2/dpll3xxx.c | 29 +++--- arch/arm/mach-omap2/dpll44xx.c | 30 +++--- arch/mips/alchemy/common/clock.c| 61 + drivers/clk/at91/clk-programmable.c | 25 ++--- drivers/clk/at91/clk-usb.c | 28 +++--- drivers/clk/bcm/clk-kona.c | 34 --- drivers/clk/clk-composite.c | 48 +- drivers/clk/clk.c | 176 drivers/clk/hisilicon/clk-hi3620.c | 39 drivers/clk/mmp/clk-mix.c | 20 ++-- drivers/clk/qcom/clk-pll.c | 18 ++-- drivers/clk/qcom/clk-rcg.c | 44 - drivers/clk/qcom/clk-rcg2.c | 78 drivers/clk/sunxi/clk-factors.c | 21 ++--- drivers/clk/sunxi/clk-sun6i-ar100.c | 21 ++--- drivers/clk/sunxi/clk-sunxi.c | 20 ++-- drivers/clk/tegra/clk-emc.c | 28 +++--- include/linux/clk-provider.h| 49 ++ include/linux/clk/ti.h | 16 +--- 20 files changed, 393 insertions(+), 400 deletions(-) diff --git a/Documentation/clk.txt b/Documentation/clk.txt index f463bdc..5c4bc4d 100644 --- a/Documentation/clk.txt +++ b/Documentation/clk.txt @@ -71,12 +71,8 @@ the operations defined in clk.h: long(*round_rate)(struct clk_hw *hw, unsigned long rate, unsigned long *parent_rate); - long(*determine_rate)(struct clk_hw *hw, - unsigned long rate, - unsigned long min_rate, - unsigned long max_rate, - unsigned long *best_parent_rate, - struct clk_hw **best_parent_clk); + int (*determine_rate)(struct clk_hw *hw, + struct clk_rate_request *req); int (*set_parent)(struct clk_hw *hw, u8 index); u8 (*get_parent)(struct clk_hw *hw); int (*set_rate)(struct clk_hw *hw, diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c index 44e57ec..8c57ace 100644 --- a/arch/arm/mach-omap2/dpll3xxx.c +++ b/arch/arm/mach-omap2/dpll3xxx.c @@ -462,43 +462,38 @@ void omap3_noncore_dpll_disable(struct clk_hw *hw) /** * omap3_noncore_dpll_determine_rate - determine rate for a DPLL * @hw: pointer to the clock to determine rate for - * @rate: target rate for the DPLL - * @best_parent_rate: pointer for returning best parent rate - * @best_parent_clk: pointer for returning best parent clock + * @req: target rate request * * Determines which DPLL mode to use for reaching a desired target rate. * Checks whether the DPLL shall be in bypass or locked mode, and if * locked, calculates the M,N values for the DPLL via round-rate. - * Returns a positive clock rate with suc
