All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: "Mike Turquette" <mturquette@baylibre.com>,
	linux-clk@vger.kernel.org, "Jonathan Corbet" <corbet@lwn.net>,
	"Tony Lindgren" <tony@atomide.com>,
	"Ralf Baechle" <ralf@linux-mips.org>,
	"Emilio López" <emilio@elopez.com.ar>,
	"Maxime Ripard" <maxime.ripard@free-electrons.com>,
	"Tero Kristo" <t-kristo@ti.com>,
	"Peter De Schrijver" <pdeschrijver@nvidia.com>,
	"Prashant Gaikwad" <pgaikwad@nvidia.com>,
	"Stephen Warren" <swarren@wwwdotorg.org>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Alexandre Courbot" <gnurou@gmail.com>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
	linux-mips@linux-mips.org, linux-tegra@vger.kernel.org
Subject: Re: [PATCH v5] clk: change clk_ops' ->determine_rate() prototype
Date: Wed, 8 Jul 2015 11:00:05 +0200	[thread overview]
Message-ID: <20150708110005.704c49ff@bbrezillon> (raw)
In-Reply-To: <20150708005748.GG30412@codeaurora.org>

Hi Stephen,

On Tue, 7 Jul 2015 17:57:48 -0700
Stephen Boyd <sboyd@codeaurora.org> 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 <boris.brezillon@free-electrons.com>
> > 
> > CC: Jonathan Corbet <corbet@lwn.net>
> > CC: Tony Lindgren <tony@atomide.com>
> > CC: Ralf Baechle <ralf@linux-mips.org>
> > CC: "Emilio López" <emilio@elopez.com.ar>
> > CC: Maxime Ripard <maxime.ripard@free-electrons.com>
> > CC: Tero Kristo <t-kristo@ti.com>
> > CC: Peter De Schrijver <pdeschrijver@nvidia.com>
> > CC: Prashant Gaikwad <pgaikwad@nvidia.com>
> > CC: Stephen Warren <swarren@wwwdotorg.org>
> > CC: Thierry Reding <thierry.reding@gmail.com>
> > CC: Alexandre Courbot <gnurou@gmail.com>
> > CC: linux-doc@vger.kernel.org
> > CC: linux-kernel@vger.kernel.org
> > CC: linux-arm-kernel@lists.infradead.org
> > CC: linux-omap@vger.kernel.org
> > CC: linux-mips@linux-mips.org
> > CC: linux-tegra@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

WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
To: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: "Mike Turquette"
	<mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
	linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Jonathan Corbet" <corbet-T1hC0tSOHrs@public.gmane.org>,
	"Tony Lindgren" <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>,
	"Ralf Baechle" <ralf-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>,
	"Emilio López" <emilio-0Z03zUJReD5OxF6Tv1QG9Q@public.gmane.org>,
	"Maxime Ripard"
	<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
	"Tero Kristo" <t-kristo-l0cyMroinI0@public.gmane.org>,
	"Peter De Schrijver"
	<pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	"Prashant Gaikwad"
	<pgaikwad-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	"Stephen Warren"
	<swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	"Thierry Reding"
	<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"Alexandre Courbot"
	<gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mips-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v5] clk: change clk_ops' ->determine_rate() prototype
Date: Wed, 8 Jul 2015 11:00:05 +0200	[thread overview]
Message-ID: <20150708110005.704c49ff@bbrezillon> (raw)
In-Reply-To: <20150708005748.GG30412-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

Hi Stephen,

On Tue, 7 Jul 2015 17:57:48 -0700
Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 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 <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > 
> > CC: Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>
> > CC: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > CC: Ralf Baechle <ralf-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>
> > CC: "Emilio López" <emilio-0Z03zUJReD5OxF6Tv1QG9Q@public.gmane.org>
> > CC: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > CC: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
> > CC: Peter De Schrijver <pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > CC: Prashant Gaikwad <pgaikwad-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > CC: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
> > CC: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > CC: Alexandre Courbot <gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > CC: linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > CC: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > CC: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> > CC: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > CC: linux-mips-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org
> > CC: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.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

WARNING: multiple messages have this Message-ID (diff)
From: boris.brezillon@free-electrons.com (Boris Brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5] clk: change clk_ops' ->determine_rate() prototype
Date: Wed, 8 Jul 2015 11:00:05 +0200	[thread overview]
Message-ID: <20150708110005.704c49ff@bbrezillon> (raw)
In-Reply-To: <20150708005748.GG30412@codeaurora.org>

Hi Stephen,

On Tue, 7 Jul 2015 17:57:48 -0700
Stephen Boyd <sboyd@codeaurora.org> 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 <boris.brezillon@free-electrons.com>
> > 
> > CC: Jonathan Corbet <corbet@lwn.net>
> > CC: Tony Lindgren <tony@atomide.com>
> > CC: Ralf Baechle <ralf@linux-mips.org>
> > CC: "Emilio L?pez" <emilio@elopez.com.ar>
> > CC: Maxime Ripard <maxime.ripard@free-electrons.com>
> > CC: Tero Kristo <t-kristo@ti.com>
> > CC: Peter De Schrijver <pdeschrijver@nvidia.com>
> > CC: Prashant Gaikwad <pgaikwad@nvidia.com>
> > CC: Stephen Warren <swarren@wwwdotorg.org>
> > CC: Thierry Reding <thierry.reding@gmail.com>
> > CC: Alexandre Courbot <gnurou@gmail.com>
> > CC: linux-doc at vger.kernel.org
> > CC: linux-kernel at vger.kernel.org
> > CC: linux-arm-kernel at lists.infradead.org
> > CC: linux-omap at vger.kernel.org
> > CC: linux-mips at linux-mips.org
> > CC: linux-tegra at 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

  reply	other threads:[~2015-07-08  9:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-07 18:48 [PATCH v5] clk: change clk_ops' ->determine_rate() prototype Boris Brezillon
2015-07-07 18:48 ` Boris Brezillon
2015-07-08  0:57 ` Stephen Boyd
2015-07-08  0:57   ` Stephen Boyd
2015-07-08  9:00   ` Boris Brezillon [this message]
2015-07-08  9:00     ` Boris Brezillon
2015-07-08  9:00     ` Boris Brezillon
2015-07-08 18:07     ` Stephen Boyd
2015-07-08 18:07       ` Stephen Boyd
2015-07-09 20:39       ` Boris Brezillon
2015-07-09 20:39         ` Boris Brezillon
2015-07-09 20:39         ` Boris Brezillon
2015-07-09 20:39         ` Boris Brezillon
2015-07-09 20:39         ` Boris Brezillon
2015-07-09 20:39         ` Boris Brezillon
2015-07-13 23:02         ` Stephen Boyd
2015-07-13 23:02           ` Stephen Boyd
2015-07-14 10:47           ` Boris Brezillon
2015-07-14 10:47             ` Boris Brezillon
2015-07-13  9:01   ` Tero Kristo
2015-07-13  9:01     ` Tero Kristo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150708110005.704c49ff@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=corbet@lwn.net \
    --cc=emilio@elopez.com.ar \
    --cc=gnurou@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=maxime.ripard@free-electrons.com \
    --cc=mturquette@baylibre.com \
    --cc=pdeschrijver@nvidia.com \
    --cc=pgaikwad@nvidia.com \
    --cc=ralf@linux-mips.org \
    --cc=sboyd@codeaurora.org \
    --cc=swarren@wwwdotorg.org \
    --cc=t-kristo@ti.com \
    --cc=thierry.reding@gmail.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.