mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: victorien.vedrine@ophrys.net
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
	mturquette@baylibre.com, Shawn Guo <shawn.guo@linaro.org>
Subject: Re: [PATCH] clk:mxs: Fix bug on frequency divider
Date: Wed, 19 Aug 2015 12:29:58 +0200	[thread overview]
Message-ID: <1718bb213e11d665355c9f0c11c037e6@ophrys.net> (raw)
In-Reply-To: <55BBB1AC.6070102@codeaurora.org>

I'll modify the cast and propose a new version of patch.
This patch is specific for imx28 processor and for this one there is no 
mult_frac()
function. I checked the other functions of imx28 clock part and I didn't 
see a
similar problem.


Le 2015-07-31 19:34, Stephen Boyd a écrit :
> +Shawn
> 
> On 07/31/2015 09:24 AM, Victorien Vedrine wrote:
>> On drivers/clk/mxs/clk-frac.c, the function clk_frac_round_rate 
>> returned a bad
>> result. The division before multiplication computes a wrong value ; 
>> the
>> calculation is inverted to fix the problem. The second issue is that 
>> the exact
>> rate have decimals and they are truncate. The consequence is that the 
>> function
>> clk_frac_set_rate (which use the result of clk_frac_round_rate) 
>> computes a
>> wrong value for the register (the rate generated can be closer to the 
>> desired
>> rate). The correction is : if there is decimal to the result, it is 
>> rounded to
>> the next larger integer.
>> 
>> On drivers/clk/mxs/clk-frac.c, the function clk_frac_recalc_rate 
>> returned
>> a bad result. The multiplication is made before the division to 
>> compute a
>> correct value.
>> 
>> The issue is reproducible by this way : Set the SAIF frequency to 
>> 22579200Hz
>> (it's the appropriate frequency for 44100hz sample rate for SGTL5000 
>> codec).
>> With the divider register (HW_CLKCTRL_SAIF0), the closest lower value 
>> is
>> 22573242.1875Hz (0xC0A on register). The original clk-frac functions 
>> give 0xC09
>> on the divider register.
>> 
>> Signed-off-by: Victorien Vedrine <victorien.vedrine@ophrys.net>
>> ---
>>   drivers/clk/mxs/clk-frac.c | 13 ++++++++++---
>>   1 file changed, 10 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/clk/mxs/clk-frac.c b/drivers/clk/mxs/clk-frac.c
>> index e6aa6b5..d51cf03 100644
>> --- a/drivers/clk/mxs/clk-frac.c
>> +++ b/drivers/clk/mxs/clk-frac.c
>> @@ -42,11 +42,13 @@ static unsigned long clk_frac_recalc_rate(struct 
>> clk_hw *hw,
>>   {
>>   	struct clk_frac *frac = to_clk_frac(hw);
>>   	u32 div;
>> +	u64 tmp_rate;
>>     	div = readl_relaxed(frac->reg) >> frac->shift;
>>   	div &= (1 << frac->width) - 1;
>>   -	return (parent_rate >> frac->width) * div;
>> +	tmp_rate = (u64)parent_rate * (u64)div;
> 
> We shouldn't need to cast both to 64 bits...
> 
>> +	return (unsigned long)(tmp_rate >> frac->width);
> 
> Isn't the cast implicit by means of the return type of this function?
> 
>>   }
>>     static long clk_frac_round_rate(struct clk_hw *hw, unsigned long 
>> rate,
>> @@ -55,7 +57,7 @@ static long clk_frac_round_rate(struct clk_hw *hw, 
>> unsigned long rate,
>>   	struct clk_frac *frac = to_clk_frac(hw);
>>   	unsigned long parent_rate = *prate;
>>   	u32 div;
>> -	u64 tmp;
>> +	u64 tmp, tmp_rate, result;
>>     	if (rate > parent_rate)
>>   		return -EINVAL;
>> @@ -68,7 +70,12 @@ static long clk_frac_round_rate(struct clk_hw *hw, 
>> unsigned long rate,
>>   	if (!div)
>>   		return -EINVAL;
>>   -	return (parent_rate >> frac->width) * div;
>> +	tmp_rate = (u64)parent_rate * (u64)div;
>> +	result = (u64)(tmp_rate >> frac->width);
> 
> Cast looks useless here too.
> 
>> +	if ((result << frac->width) < tmp_rate)
>> +		return result + 1;
>> +	else
>> +		return result;
> 
> The else could be dropped and just be return result. Also, have you
> see mult_frac()? I suppose we're doing shifts with width because it's
> a power-of-2 denominator?


  reply	other threads:[~2015-08-19 10:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-31 16:24 Victorien Vedrine
2015-07-31 17:34 ` Stephen Boyd
2015-08-19 10:29   ` victorien.vedrine [this message]
2015-08-31  8:45   ` [PATCH v2] " Victorien Vedrine
2015-09-16 14:16     ` Stefan Wahren
2015-09-18  7:21     ` Stefan Wahren
2015-09-24 12:17       ` Shawn Guo
2015-10-01 22:25     ` Stephen Boyd

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=1718bb213e11d665355c9f0c11c037e6@ophrys.net \
    --to=victorien.vedrine@ophrys.net \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@codeaurora.org \
    --cc=shawn.guo@linaro.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

all inboxes | Powered by JetHome®