From: "Emilio López" <emilio@elopez.com.ar>
To: Jean-Francois Moine <moinejf@free.fr>,
Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Chen-Yu Tsai <wens@csie.org>, Stephen Boyd <sboyd@codeaurora.org>,
linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] clk: sunxi: Accept a greater rate when setting a parent clock
Date: Wed, 30 Mar 2016 17:49:47 -0300 [thread overview]
Message-ID: <56FC3BEB.8030106@elopez.com.ar> (raw)
In-Reply-To: <20160321092549.4e6245e4f02839e29aeb86a9@free.fr>
[Sorry for the delay, I meant to reply to this post a while back but I
forgot]
El 21/03/16 a las 05:25, Jean-Francois Moine escribi=F3:
> On Mon, 21 Mar 2016 08:25:46 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> =
>>> - /* find the parent that can help provide the fastest rate <=3D rate */
>>> + /* find the parent that can help provide the fastest rate */
>>> num_parents =3D clk_hw_get_num_parents(hw);
>>> for (i =3D 0; i < num_parents; i++) {
>>> parent =3D clk_hw_get_parent_by_index(hw, i);
>>> @@ -100,7 +100,7 @@ static int clk_factors_determine_rate(struct clk_hw=
*hw,
>>> child_rate =3D clk_factors_round_rate(hw, req->rate,
>>> &parent_rate);
>>> =
>>> - if (child_rate <=3D req->rate && child_rate > best_child_rate) {
>>> + if (child_rate > best_child_rate) {
>>
>> I'm not sure this would work, since you'll end up picking the fastest
>> rate without considering whether it is the closest or not.
>>
>> I guess what you want here is using the absolute difference between
>> the requested rate and the rate you're evaluating.
>>
>> That being said, we had a similar discussion for SPI around a month
>> ago where we wanted a rate strictly lower than the requested one. I
>> guess it's time to add a flag to tell how you want to round.
> =
> You are right, I just removed half of the constraint, but I still wonder
> why does this sequence introduced by the commit 862b728387aef3a37
> (clk: sunxi: factors: automatic reparenting support) do
> "provide the fastest rate <=3D rate"
> instead of
> "provide the closest rate" ?
> =
> Emilio?
Overclocking components is usually not a good default in my opinion. I
don't recall at the moment if there was some other justification apart
from playing it safe.
Cheers,
Emilio
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: emilio@elopez.com.ar (Emilio López)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] clk: sunxi: Accept a greater rate when setting a parent clock
Date: Wed, 30 Mar 2016 17:49:47 -0300 [thread overview]
Message-ID: <56FC3BEB.8030106@elopez.com.ar> (raw)
In-Reply-To: <20160321092549.4e6245e4f02839e29aeb86a9@free.fr>
[Sorry for the delay, I meant to reply to this post a while back but I
forgot]
El 21/03/16 a las 05:25, Jean-Francois Moine escribi?:
> On Mon, 21 Mar 2016 08:25:46 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
>>> - /* find the parent that can help provide the fastest rate <= rate */
>>> + /* find the parent that can help provide the fastest rate */
>>> num_parents = clk_hw_get_num_parents(hw);
>>> for (i = 0; i < num_parents; i++) {
>>> parent = clk_hw_get_parent_by_index(hw, i);
>>> @@ -100,7 +100,7 @@ static int clk_factors_determine_rate(struct clk_hw *hw,
>>> child_rate = clk_factors_round_rate(hw, req->rate,
>>> &parent_rate);
>>>
>>> - if (child_rate <= req->rate && child_rate > best_child_rate) {
>>> + if (child_rate > best_child_rate) {
>>
>> I'm not sure this would work, since you'll end up picking the fastest
>> rate without considering whether it is the closest or not.
>>
>> I guess what you want here is using the absolute difference between
>> the requested rate and the rate you're evaluating.
>>
>> That being said, we had a similar discussion for SPI around a month
>> ago where we wanted a rate strictly lower than the requested one. I
>> guess it's time to add a flag to tell how you want to round.
>
> You are right, I just removed half of the constraint, but I still wonder
> why does this sequence introduced by the commit 862b728387aef3a37
> (clk: sunxi: factors: automatic reparenting support) do
> "provide the fastest rate <= rate"
> instead of
> "provide the closest rate" ?
>
> Emilio?
Overclocking components is usually not a good default in my opinion. I
don't recall at the moment if there was some other justification apart
from playing it safe.
Cheers,
Emilio
next prev parent reply other threads:[~2016-03-30 20:49 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20160310081658.B749246B@mail.free-electrons.com>
2016-03-21 7:25 ` [PATCH] clk: sunxi: Accept a greater rate when setting a parent clock Maxime Ripard
2016-03-21 7:25 ` Maxime Ripard
2016-03-21 8:25 ` Jean-Francois Moine
2016-03-21 8:25 ` Jean-Francois Moine
2016-03-29 9:38 ` Maxime Ripard
2016-03-29 9:38 ` Maxime Ripard
2016-03-29 10:08 ` Jean-Francois Moine
2016-03-29 10:08 ` Jean-Francois Moine
2016-03-30 20:49 ` Emilio López [this message]
2016-03-30 20:49 ` Emilio López
2016-04-14 17:24 ` Maxime Ripard
2016-04-14 17:24 ` Maxime Ripard
2016-04-14 18:14 ` Jean-Francois Moine
2016-04-14 18:14 ` Jean-Francois Moine
2016-04-14 19:31 ` Maxime Ripard
2016-04-14 19:31 ` Maxime Ripard
[not found] <E1advmk-0004Nt-Ba@bombadil.infradead.org>
2016-03-18 7:47 ` Jean-Francois Moine
2016-03-18 7:47 ` Jean-Francois Moine
2016-03-10 7:15 Jean-Francois Moine
-- strict thread matches above, loose matches on Subject: below --
2016-03-10 7:15 Jean-Francois Moine
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=56FC3BEB.8030106@elopez.com.ar \
--to=emilio@elopez.com.ar \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=maxime.ripard@free-electrons.com \
--cc=moinejf@free.fr \
--cc=sboyd@codeaurora.org \
--cc=wens@csie.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.