From: jamie@jamieiles.com (Jamie Iles)
To: linux-arm-kernel@lists.infradead.org
Subject: Clock API and "maximum rate"
Date: Thu, 12 Jan 2012 18:37:28 +0000 [thread overview]
Message-ID: <20120112183728.GA13991@page> (raw)
In-Reply-To: <CAKGA1bnT+OK1sUGXpHmmBQqt5iqpaPCaRWvB40XLuE5Zt13GPw@mail.gmail.com>
On Thu, Jan 12, 2012 at 08:48:11AM -0600, Matt Sealey wrote:
> On Thu, Jan 12, 2012 at 8:11 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Thu, Jan 12, 2012 at 07:49:35AM -0600, Matt Sealey wrote:
> >> On Wed, Jan 11, 2012 at 10:58 AM, Jamie Iles <jamie@jamieiles.com> wrote:
> >> > Hi Matt,
> >> >
> >> > On Wed, Jan 11, 2012 at 10:30:15AM -0600, Matt Sealey wrote:
> >> >> Just a curious question, is there any safe way in the current API or
> >> >> even by peeking a little behind the scenes to find out what the
> >> >> maximum clock rate would be for a given named clock or struct clk?
> >> >
> >> > How about:
> >> >
> >> > ? ? ? ?long max = clk_round_rate(clk, ~0LU);
> >> >
> >> > clk_round_rate() is one of the optional API calls though.
> >>
> >> Luckily implemented in this case :) Seems to do the trick, thanks.
> >
> > If it's not implemented, but there is an implemented clk_set_rate(), feel
> > free to complain at whoever created the implementation.
> >
> > If there's a clk_set_rate() implementation, then there's _already_ an
> > implementation of clk_round_rate() internally doing the rounding for the
> > set_rate function, so there's really no excuse not to expose that via
> > clk_round_rate().
> >
> > clk_round_rate() is supposed to tell you what you end up with if you
> > ask clk_set_rate() to set the exact same value you passed in - but
> > clk_round_rate() won't modify the hardware.
> >
> > So, clk_round_rate/clk_set_rate really should be thought of being
> > implemented as this:
> >
> > long clk_round_rate(struct clk *clk, unsigned long rate)
> > {
> > ? ? ? ?return __clk_round_rate(clk, rate);
> > }
> >
> > int clk_set_rate(struct clk *clk, unsigned long rate)
> > {
> > ? ? ? ?long rate = __clk_round_rate(clk, rate);
> >
> > ? ? ? ?if (rate < 0)
> > ? ? ? ? ? ? ? ?return rate;
> >
> > ? ? ? ?return __clk_set_rate(clk, rate);
> > }
>
> Right. On i.MX it seems not to round first, but to assume you passed a
> rounded rate? I assume the upper level clk API does the above, so the
> low level doesn't have to?
Well each platform implements the whole clock API itself at the moment
so I guess the higher layer is in plat-mxc? If so then something like
the (untested) patch below may do the trick. clk_round_rate() for this
platform returns 0 when it fails though and that's not right from the
API:
/**
* clk_round_rate - adjust a rate to the exact rate a clock can provide
* @clk: clock source
* @rate: desired clock rate in Hz
*
* Returns rounded clock rate in Hz, or negative errno.
*/
Jamie
8<---
diff --git a/arch/arm/plat-mxc/clock.c b/arch/arm/plat-mxc/clock.c
index 2ed3ab1..64f679b 100644
--- a/arch/arm/plat-mxc/clock.c
+++ b/arch/arm/plat-mxc/clock.c
@@ -134,7 +134,7 @@ EXPORT_SYMBOL(clk_get_rate);
long clk_round_rate(struct clk *clk, unsigned long rate)
{
if (clk == NULL || IS_ERR(clk) || !clk->round_rate)
- return 0;
+ return -EOPNOTSUPP;
return clk->round_rate(clk, rate);
}
@@ -146,12 +146,17 @@ EXPORT_SYMBOL(clk_round_rate);
int clk_set_rate(struct clk *clk, unsigned long rate)
{
int ret = -EINVAL;
+ long rounded_rate;
if (clk == NULL || IS_ERR(clk) || clk->set_rate == NULL || rate == 0)
return ret;
+ rounded_rate = clock_round_rate(clk, rate);
+ if (rounded_rate < 0)
+ return rounded_rate;
+
mutex_lock(&clocks_mutex);
- ret = clk->set_rate(clk, rate);
+ ret = clk->set_rate(clk, rounded_rate);
mutex_unlock(&clocks_mutex);
return ret;
prev parent reply other threads:[~2012-01-12 18:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-11 16:30 Clock API and "maximum rate" Matt Sealey
2012-01-11 16:58 ` Jamie Iles
2012-01-12 13:49 ` Matt Sealey
2012-01-12 14:11 ` Russell King - ARM Linux
2012-01-12 14:48 ` Matt Sealey
2012-01-12 18:37 ` Jamie Iles [this message]
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=20120112183728.GA13991@page \
--to=jamie@jamieiles.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox