All of lore.kernel.org
 help / color / mirror / Atom feed
From: tomi.valkeinen@ti.com (Tomi Valkeinen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] clk: divider: fix rate calculation for fractional rates
Date: Wed, 6 Nov 2013 13:48:44 +0200	[thread overview]
Message-ID: <527A2C9C.4080409@ti.com> (raw)
In-Reply-To: <20131106111534.GW16735@n2100.arm.linux.org.uk>

On 2013-11-06 13:15, Russell King - ARM Linux wrote:
> On Wed, Nov 06, 2013 at 01:06:48PM +0200, Tomi Valkeinen wrote:
>> This means that the following code works a bit oddly:
>>
>> rate = clk_round_rate(clk, 123428572);
>> clk_set_rate(clk, rate);
> 
> You're right, but the above sequence is quite a crass thing to do.  Why?

Do you mean that you think the fix is right, but the above example
sequence is silly, or that the fix is not needed either?

> clk_round_rate() returns the clock rate that clk_set_rate() would give
> you if you were to use this sequence:
> 
> 	clk_rate_rate(clk, 123428572);
> 	rate = clk_get_rate(clk);
> 
> The difference is that it doesn't change the actual clock rate itself;
> clk_round_rate() is meant to answer the question:
> 
> 	"If I were to set _this_ rate, what clock rate would
> 	 the clock give me?"
> 
> thereby providing a method for drivers to inquire what the effect would
> be when changing such a clock without actually affecting it.
> 
> So please, don't use clk_round_rate() followed by clk_set_rate().

Ok, if defined like that, then the current behavior is logical.

The comment in clk.h says "adjust a rate to the exact rate a clock can
provide", which does not contradict with what you said, but doesn't
really confirm it either. If I get "the exact rate a clock can provide"
I don't see why I can't use that exact clock rate for clk_set_rate.
Maybe the comment should be improved to state explicitly what it does.

However, how about the following sequence:

	clk_set_rate(clk, 123428572);
	rate = clk_get_rate(clk);
	clk_set_rate(clk, rate);

I didn't test that but it should result in the clock first set to
123428571, and then to 108000000. Obviously pointless if done exactly
like that, but I don't see why the above code sequence is wrong, yet it
gives a bit surprising result.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131106/8ae3124c/attachment.sig>

WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Mike Turquette <mturquette@linaro.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	"Kristo, Tero" <t-kristo@ti.com>
Subject: Re: [PATCH] clk: divider: fix rate calculation for fractional rates
Date: Wed, 6 Nov 2013 13:48:44 +0200	[thread overview]
Message-ID: <527A2C9C.4080409@ti.com> (raw)
In-Reply-To: <20131106111534.GW16735@n2100.arm.linux.org.uk>

[-- Attachment #1: Type: text/plain, Size: 1899 bytes --]

On 2013-11-06 13:15, Russell King - ARM Linux wrote:
> On Wed, Nov 06, 2013 at 01:06:48PM +0200, Tomi Valkeinen wrote:
>> This means that the following code works a bit oddly:
>>
>> rate = clk_round_rate(clk, 123428572);
>> clk_set_rate(clk, rate);
> 
> You're right, but the above sequence is quite a crass thing to do.  Why?

Do you mean that you think the fix is right, but the above example
sequence is silly, or that the fix is not needed either?

> clk_round_rate() returns the clock rate that clk_set_rate() would give
> you if you were to use this sequence:
> 
> 	clk_rate_rate(clk, 123428572);
> 	rate = clk_get_rate(clk);
> 
> The difference is that it doesn't change the actual clock rate itself;
> clk_round_rate() is meant to answer the question:
> 
> 	"If I were to set _this_ rate, what clock rate would
> 	 the clock give me?"
> 
> thereby providing a method for drivers to inquire what the effect would
> be when changing such a clock without actually affecting it.
> 
> So please, don't use clk_round_rate() followed by clk_set_rate().

Ok, if defined like that, then the current behavior is logical.

The comment in clk.h says "adjust a rate to the exact rate a clock can
provide", which does not contradict with what you said, but doesn't
really confirm it either. If I get "the exact rate a clock can provide"
I don't see why I can't use that exact clock rate for clk_set_rate.
Maybe the comment should be improved to state explicitly what it does.

However, how about the following sequence:

	clk_set_rate(clk, 123428572);
	rate = clk_get_rate(clk);
	clk_set_rate(clk, rate);

I didn't test that but it should result in the clock first set to
123428571, and then to 108000000. Obviously pointless if done exactly
like that, but I don't see why the above code sequence is wrong, yet it
gives a bit surprising result.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

  reply	other threads:[~2013-11-06 11:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-06 11:06 [PATCH] clk: divider: fix rate calculation for fractional rates Tomi Valkeinen
2013-11-06 11:06 ` Tomi Valkeinen
2013-11-06 11:15 ` Russell King - ARM Linux
2013-11-06 11:15   ` Russell King - ARM Linux
2013-11-06 11:48   ` Tomi Valkeinen [this message]
2013-11-06 11:48     ` Tomi Valkeinen
2013-11-06 16:19     ` Russell King - ARM Linux
2013-11-06 16:19       ` Russell King - ARM Linux
2014-01-28  8:45       ` Tomi Valkeinen
2014-01-28  8:45         ` Tomi Valkeinen
2014-01-28 10:32         ` Russell King - ARM Linux
2014-01-28 10:32           ` Russell King - ARM Linux
2014-01-28 10:40           ` Tomi Valkeinen
2014-01-28 10:40             ` Tomi Valkeinen
2014-02-11 14:18 ` Tomi Valkeinen
2014-02-11 14:18   ` Tomi Valkeinen

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=527A2C9C.4080409@ti.com \
    --to=tomi.valkeinen@ti.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 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.