From: Vincent Guittot <vincent.guittot@linaro.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-pm@vger.kernel.org, Rex-BC Chen <rex-bc.chen@mediatek.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] cpufreq: Avoid unnecessary frequency updates due to mismatch
Date: Thu, 5 May 2022 11:40:28 +0200 [thread overview]
Message-ID: <CAKfTPtCfKBiQkghY6gw+sSYYOXFRWMZNXsr64Vn5G-Oo1HF8ew@mail.gmail.com> (raw)
In-Reply-To: <20220505082801.oks7ko2sbqazyenn@vireshk-i7>
On Thu, 5 May 2022 at 10:28, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 05-05-22, 10:21, Vincent Guittot wrote:
> > Part of your problem is that cpufreq use khz whereas clock uses hz
>
> Not in this case at least as the value mentioned in OPP table DT is in
> Hz.
But dev_pm_opp_init_cpufreq_table make it kHz anyway
>
> > Would it be better to do something like below in cpufreq_generic_get
> >
> > (clk_get_rate(policy->clk) + 500) / 1000
> >
> > so you round to closest instead of always floor rounding
>
> That would be a fine thing to do anyway, though I am not sure if it
> will fix the problem at hand.
>
> If the hardware returns 499,999,499 Hz, we will still have the
> problem.
But in this case, cpufreq table should use 499,999Khz IMO. We already
have OPP/cpufreq table being updated at boot with actual value.
>
> --
> viresh
WARNING: multiple messages have this Message-ID (diff)
From: Vincent Guittot <vincent.guittot@linaro.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-pm@vger.kernel.org, Rex-BC Chen <rex-bc.chen@mediatek.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] cpufreq: Avoid unnecessary frequency updates due to mismatch
Date: Thu, 5 May 2022 11:40:28 +0200 [thread overview]
Message-ID: <CAKfTPtCfKBiQkghY6gw+sSYYOXFRWMZNXsr64Vn5G-Oo1HF8ew@mail.gmail.com> (raw)
In-Reply-To: <20220505082801.oks7ko2sbqazyenn@vireshk-i7>
On Thu, 5 May 2022 at 10:28, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 05-05-22, 10:21, Vincent Guittot wrote:
> > Part of your problem is that cpufreq use khz whereas clock uses hz
>
> Not in this case at least as the value mentioned in OPP table DT is in
> Hz.
But dev_pm_opp_init_cpufreq_table make it kHz anyway
>
> > Would it be better to do something like below in cpufreq_generic_get
> >
> > (clk_get_rate(policy->clk) + 500) / 1000
> >
> > so you round to closest instead of always floor rounding
>
> That would be a fine thing to do anyway, though I am not sure if it
> will fix the problem at hand.
>
> If the hardware returns 499,999,499 Hz, we will still have the
> problem.
But in this case, cpufreq table should use 499,999Khz IMO. We already
have OPP/cpufreq table being updated at boot with actual value.
>
> --
> viresh
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Vincent Guittot <vincent.guittot@linaro.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-pm@vger.kernel.org, Rex-BC Chen <rex-bc.chen@mediatek.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] cpufreq: Avoid unnecessary frequency updates due to mismatch
Date: Thu, 5 May 2022 11:40:28 +0200 [thread overview]
Message-ID: <CAKfTPtCfKBiQkghY6gw+sSYYOXFRWMZNXsr64Vn5G-Oo1HF8ew@mail.gmail.com> (raw)
In-Reply-To: <20220505082801.oks7ko2sbqazyenn@vireshk-i7>
On Thu, 5 May 2022 at 10:28, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 05-05-22, 10:21, Vincent Guittot wrote:
> > Part of your problem is that cpufreq use khz whereas clock uses hz
>
> Not in this case at least as the value mentioned in OPP table DT is in
> Hz.
But dev_pm_opp_init_cpufreq_table make it kHz anyway
>
> > Would it be better to do something like below in cpufreq_generic_get
> >
> > (clk_get_rate(policy->clk) + 500) / 1000
> >
> > so you round to closest instead of always floor rounding
>
> That would be a fine thing to do anyway, though I am not sure if it
> will fix the problem at hand.
>
> If the hardware returns 499,999,499 Hz, we will still have the
> problem.
But in this case, cpufreq table should use 499,999Khz IMO. We already
have OPP/cpufreq table being updated at boot with actual value.
>
> --
> viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-05-05 9:40 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-04 8:21 [PATCH] cpufreq: Avoid unnecessary frequency updates due to mismatch Viresh Kumar
2022-05-04 8:21 ` Viresh Kumar
2022-05-04 8:21 ` Viresh Kumar
2022-05-04 12:06 ` Rex-BC Chen
2022-05-04 12:06 ` Rex-BC Chen
2022-05-04 12:06 ` Rex-BC Chen
2022-05-05 7:28 ` Vincent Guittot
2022-05-05 7:28 ` Vincent Guittot
2022-05-05 7:28 ` Vincent Guittot
2022-05-05 7:44 ` Viresh Kumar
2022-05-05 7:44 ` Viresh Kumar
2022-05-05 7:44 ` Viresh Kumar
2022-05-05 8:21 ` Vincent Guittot
2022-05-05 8:21 ` Vincent Guittot
2022-05-05 8:21 ` Vincent Guittot
2022-05-05 8:28 ` Viresh Kumar
2022-05-05 8:28 ` Viresh Kumar
2022-05-05 8:28 ` Viresh Kumar
2022-05-05 9:40 ` Vincent Guittot [this message]
2022-05-05 9:40 ` Vincent Guittot
2022-05-05 9:40 ` Vincent Guittot
2022-05-05 9:45 ` Viresh Kumar
2022-05-05 9:45 ` Viresh Kumar
2022-05-05 9:45 ` Viresh Kumar
2022-05-05 13:31 ` Matthias Brugger
2022-05-05 13:31 ` Matthias Brugger
2022-05-05 13:31 ` Matthias Brugger
2022-05-06 18:57 ` Rafael J. Wysocki
2022-05-06 18:57 ` Rafael J. Wysocki
2022-05-06 18:57 ` Rafael J. Wysocki
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=CAKfTPtCfKBiQkghY6gw+sSYYOXFRWMZNXsr64Vn5G-Oo1HF8ew@mail.gmail.com \
--to=vincent.guittot@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=rafael@kernel.org \
--cc=rex-bc.chen@mediatek.com \
--cc=rjw@rjwysocki.net \
--cc=viresh.kumar@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 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.