From: Rex-BC Chen <rex-bc.chen@mediatek.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: <rafael@kernel.org>, <robh+dt@kernel.org>, <krzk+dt@kernel.org>,
<matthias.bgg@gmail.com>, <jia-wei.chang@mediatek.com>,
<roger.lu@mediatek.com>, <hsinyi@google.com>,
<khilman@baylibre.com>, <angelogioacchino.delregno@collabora.com>,
<linux-pm@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>,
<Project_Global_Chrome_Upstream_Group@mediatek.com>
Subject: Re: [PATCH V4 07/14] cpufreq: mediatek: Add .get function
Date: Tue, 26 Apr 2022 19:13:26 +0800 [thread overview]
Message-ID: <078b1f9b39690da98cbd3c4528ba28374a097083.camel@mediatek.com> (raw)
In-Reply-To: <20220425100058.4kbvmpi63ygni6k5@vireshk-i7>
On Mon, 2022-04-25 at 15:30 +0530, Viresh Kumar wrote:
> On 25-04-22, 17:34, Rex-BC Chen wrote:
> > We found that the pulses of cpu voltage could be observed when
> > frequency is fixed (scaling_max_freq == scaling_min_freq) if using
> > cpufreq_generic_get as '.get' callback in MT8186.
> > cpufreq framework will constantly (~ 1 sec) call 'update' if the
> > policy
>
> Which function gets called here in that case ? I would expect
> cpufreq_driver_target() to not make a call to MTK driver in that
> case, after it
> finds that new and old frequency are same (it will check the
> corresponding freq
> from cpufreq table).
>
> > frequency is NOT equal to hardware frequency in
> > cpufreq_verify_current_freq.
> > The problem is that there might be a tiny difference between the
> > policy
> > frequency and the hardware frequency even they are very close.
> > e.g. policy frequency is 500,000,000 Hz however, hardware frequency
> > is
> > 499,999,726 Hz for MT8186 opp15.
> >
> > To prevent the voltage pulses, we currently use the software cached
> > values as you pointed out.
> > I wonder is it possible to add a tolerence for checking difference
> > between policy frequency and hardware frequency in cpufreq
> > framework so
> > that we can use cpufreq_generic_get as callback without pulse
> > issue.
> > Or any suggestion would be appreciated.
>
>
Hello Viresh,
We have a non-upstream driver which tries to get frequency by
'cpufreq_get'.
When we use that non-upstream driver, 'cpufreq_verify_current_freq'
will be further invoked by 'cpufreq_get' and it would cause voltage
pulse issue as I described previously.
Therefore, we apply the solution in this series.
Recently, we found that using 'cpufreq_generic_get' directly in our
non-upstream driver can do the same thing without pulse issue.
It can meet your request as well.
So here, for cpufreq, I think it is proper to drop this patch and I
will do it in the next version.
Thanks for your review.
BRs,
Rex
WARNING: multiple messages have this Message-ID (diff)
From: Rex-BC Chen <rex-bc.chen@mediatek.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: <rafael@kernel.org>, <robh+dt@kernel.org>, <krzk+dt@kernel.org>,
<matthias.bgg@gmail.com>, <jia-wei.chang@mediatek.com>,
<roger.lu@mediatek.com>, <hsinyi@google.com>,
<khilman@baylibre.com>, <angelogioacchino.delregno@collabora.com>,
<linux-pm@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>,
<Project_Global_Chrome_Upstream_Group@mediatek.com>
Subject: Re: [PATCH V4 07/14] cpufreq: mediatek: Add .get function
Date: Tue, 26 Apr 2022 19:13:26 +0800 [thread overview]
Message-ID: <078b1f9b39690da98cbd3c4528ba28374a097083.camel@mediatek.com> (raw)
In-Reply-To: <20220425100058.4kbvmpi63ygni6k5@vireshk-i7>
On Mon, 2022-04-25 at 15:30 +0530, Viresh Kumar wrote:
> On 25-04-22, 17:34, Rex-BC Chen wrote:
> > We found that the pulses of cpu voltage could be observed when
> > frequency is fixed (scaling_max_freq == scaling_min_freq) if using
> > cpufreq_generic_get as '.get' callback in MT8186.
> > cpufreq framework will constantly (~ 1 sec) call 'update' if the
> > policy
>
> Which function gets called here in that case ? I would expect
> cpufreq_driver_target() to not make a call to MTK driver in that
> case, after it
> finds that new and old frequency are same (it will check the
> corresponding freq
> from cpufreq table).
>
> > frequency is NOT equal to hardware frequency in
> > cpufreq_verify_current_freq.
> > The problem is that there might be a tiny difference between the
> > policy
> > frequency and the hardware frequency even they are very close.
> > e.g. policy frequency is 500,000,000 Hz however, hardware frequency
> > is
> > 499,999,726 Hz for MT8186 opp15.
> >
> > To prevent the voltage pulses, we currently use the software cached
> > values as you pointed out.
> > I wonder is it possible to add a tolerence for checking difference
> > between policy frequency and hardware frequency in cpufreq
> > framework so
> > that we can use cpufreq_generic_get as callback without pulse
> > issue.
> > Or any suggestion would be appreciated.
>
>
Hello Viresh,
We have a non-upstream driver which tries to get frequency by
'cpufreq_get'.
When we use that non-upstream driver, 'cpufreq_verify_current_freq'
will be further invoked by 'cpufreq_get' and it would cause voltage
pulse issue as I described previously.
Therefore, we apply the solution in this series.
Recently, we found that using 'cpufreq_generic_get' directly in our
non-upstream driver can do the same thing without pulse issue.
It can meet your request as well.
So here, for cpufreq, I think it is proper to drop this patch and I
will do it in the next version.
Thanks for your review.
BRs,
Rex
_______________________________________________
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: Rex-BC Chen <rex-bc.chen@mediatek.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: <rafael@kernel.org>, <robh+dt@kernel.org>, <krzk+dt@kernel.org>,
<matthias.bgg@gmail.com>, <jia-wei.chang@mediatek.com>,
<roger.lu@mediatek.com>, <hsinyi@google.com>,
<khilman@baylibre.com>, <angelogioacchino.delregno@collabora.com>,
<linux-pm@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>,
<Project_Global_Chrome_Upstream_Group@mediatek.com>
Subject: Re: [PATCH V4 07/14] cpufreq: mediatek: Add .get function
Date: Tue, 26 Apr 2022 19:13:26 +0800 [thread overview]
Message-ID: <078b1f9b39690da98cbd3c4528ba28374a097083.camel@mediatek.com> (raw)
In-Reply-To: <20220425100058.4kbvmpi63ygni6k5@vireshk-i7>
On Mon, 2022-04-25 at 15:30 +0530, Viresh Kumar wrote:
> On 25-04-22, 17:34, Rex-BC Chen wrote:
> > We found that the pulses of cpu voltage could be observed when
> > frequency is fixed (scaling_max_freq == scaling_min_freq) if using
> > cpufreq_generic_get as '.get' callback in MT8186.
> > cpufreq framework will constantly (~ 1 sec) call 'update' if the
> > policy
>
> Which function gets called here in that case ? I would expect
> cpufreq_driver_target() to not make a call to MTK driver in that
> case, after it
> finds that new and old frequency are same (it will check the
> corresponding freq
> from cpufreq table).
>
> > frequency is NOT equal to hardware frequency in
> > cpufreq_verify_current_freq.
> > The problem is that there might be a tiny difference between the
> > policy
> > frequency and the hardware frequency even they are very close.
> > e.g. policy frequency is 500,000,000 Hz however, hardware frequency
> > is
> > 499,999,726 Hz for MT8186 opp15.
> >
> > To prevent the voltage pulses, we currently use the software cached
> > values as you pointed out.
> > I wonder is it possible to add a tolerence for checking difference
> > between policy frequency and hardware frequency in cpufreq
> > framework so
> > that we can use cpufreq_generic_get as callback without pulse
> > issue.
> > Or any suggestion would be appreciated.
>
>
Hello Viresh,
We have a non-upstream driver which tries to get frequency by
'cpufreq_get'.
When we use that non-upstream driver, 'cpufreq_verify_current_freq'
will be further invoked by 'cpufreq_get' and it would cause voltage
pulse issue as I described previously.
Therefore, we apply the solution in this series.
Recently, we found that using 'cpufreq_generic_get' directly in our
non-upstream driver can do the same thing without pulse issue.
It can meet your request as well.
So here, for cpufreq, I think it is proper to drop this patch and I
will do it in the next version.
Thanks for your review.
BRs,
Rex
_______________________________________________
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-04-26 11:13 UTC|newest]
Thread overview: 141+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-22 7:52 [PATCH V4 00/14] cpufreq: mediatek: Cleanup and support MT8183 and MT8186 Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` [PATCH V4 01/14] dt-bindings: cpufreq: mediatek: Add MediaTek CCI property Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 8:21 ` AngeloGioacchino Del Regno
2022-04-22 8:21 ` AngeloGioacchino Del Regno
2022-04-22 8:21 ` AngeloGioacchino Del Regno
2022-04-22 17:26 ` Krzysztof Kozlowski
2022-04-22 17:26 ` Krzysztof Kozlowski
2022-04-22 17:26 ` Krzysztof Kozlowski
2022-04-22 17:34 ` Krzysztof Kozlowski
2022-04-22 17:34 ` Krzysztof Kozlowski
2022-04-22 17:34 ` Krzysztof Kozlowski
2022-04-25 6:19 ` Rex-BC Chen
2022-04-25 6:19 ` Rex-BC Chen
2022-04-25 6:19 ` Rex-BC Chen
2022-04-25 8:55 ` Krzysztof Kozlowski
2022-04-25 8:55 ` Krzysztof Kozlowski
2022-04-25 8:55 ` Krzysztof Kozlowski
2022-04-25 10:20 ` Rex-BC Chen
2022-04-25 10:20 ` Rex-BC Chen
2022-04-25 10:20 ` Rex-BC Chen
2022-04-25 10:52 ` Krzysztof Kozlowski
2022-04-25 10:52 ` Krzysztof Kozlowski
2022-04-25 10:52 ` Krzysztof Kozlowski
2022-04-26 8:26 ` Rex-BC Chen
2022-04-26 8:26 ` Rex-BC Chen
2022-04-26 8:26 ` Rex-BC Chen
2022-04-22 7:52 ` [PATCH V4 02/14] cpufreq: mediatek: Use device print to show logs Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-25 5:10 ` Viresh Kumar
2022-04-25 5:10 ` Viresh Kumar
2022-04-25 5:10 ` Viresh Kumar
2022-04-22 7:52 ` [PATCH V4 03/14] cpufreq: mediatek: Replace old_* with pre_* Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-25 5:11 ` Viresh Kumar
2022-04-25 5:11 ` Viresh Kumar
2022-04-25 5:11 ` Viresh Kumar
2022-04-22 7:52 ` [PATCH V4 04/14] cpufreq: mediatek: Record previous target vproc value Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 8:21 ` AngeloGioacchino Del Regno
2022-04-22 8:21 ` AngeloGioacchino Del Regno
2022-04-22 8:21 ` AngeloGioacchino Del Regno
2022-04-25 5:12 ` Viresh Kumar
2022-04-25 5:12 ` Viresh Kumar
2022-04-25 5:12 ` Viresh Kumar
2022-04-22 7:52 ` [PATCH V4 05/14] cpufreq: mediatek: Add opp notification support Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-25 5:20 ` Viresh Kumar
2022-04-25 5:20 ` Viresh Kumar
2022-04-25 5:20 ` Viresh Kumar
2022-04-25 7:28 ` Rex-BC Chen
2022-04-25 7:28 ` Rex-BC Chen
2022-04-25 10:38 ` Rex-BC Chen
2022-04-25 10:38 ` Rex-BC Chen
2022-04-22 7:52 ` [PATCH V4 06/14] cpufreq: mediatek: Move voltage limits to platform data Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` [PATCH V4 07/14] cpufreq: mediatek: Add .get function Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 8:21 ` AngeloGioacchino Del Regno
2022-04-22 8:21 ` AngeloGioacchino Del Regno
2022-04-22 8:21 ` AngeloGioacchino Del Regno
2022-04-25 5:35 ` Viresh Kumar
2022-04-25 5:35 ` Viresh Kumar
2022-04-25 5:35 ` Viresh Kumar
2022-04-25 9:34 ` Rex-BC Chen
2022-04-25 9:34 ` Rex-BC Chen
2022-04-25 9:34 ` Rex-BC Chen
2022-04-25 10:00 ` Viresh Kumar
2022-04-25 10:00 ` Viresh Kumar
2022-04-25 10:00 ` Viresh Kumar
2022-04-26 11:13 ` Rex-BC Chen [this message]
2022-04-26 11:13 ` Rex-BC Chen
2022-04-26 11:13 ` Rex-BC Chen
2022-04-27 3:11 ` Viresh Kumar
2022-04-27 3:11 ` Viresh Kumar
2022-04-27 3:11 ` Viresh Kumar
2022-04-28 11:16 ` Rex-BC Chen
2022-04-28 11:16 ` Rex-BC Chen
2022-04-28 11:16 ` Rex-BC Chen
2022-04-28 11:48 ` Viresh Kumar
2022-04-28 11:48 ` Viresh Kumar
2022-04-28 11:48 ` Viresh Kumar
2022-05-03 11:33 ` Rex-BC Chen
2022-05-03 11:33 ` Rex-BC Chen
2022-05-03 11:33 ` Rex-BC Chen
2022-05-04 8:22 ` Viresh Kumar
2022-05-04 8:22 ` Viresh Kumar
2022-05-04 8:22 ` Viresh Kumar
2022-05-04 11:57 ` Rex-BC Chen
2022-05-04 11:57 ` Rex-BC Chen
2022-05-04 11:57 ` Rex-BC Chen
2022-05-04 11:58 ` Viresh Kumar
2022-05-04 11:58 ` Viresh Kumar
2022-05-04 11:58 ` Viresh Kumar
2022-05-04 12:03 ` Rex-BC Chen
2022-05-04 12:03 ` Rex-BC Chen
2022-05-04 12:03 ` Rex-BC Chen
2022-04-22 7:52 ` [PATCH V4 08/14] cpufreq: mediatek: Make sram regulator optional Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-25 5:36 ` Viresh Kumar
2022-04-25 5:36 ` Viresh Kumar
2022-04-25 5:36 ` Viresh Kumar
2022-04-22 7:52 ` [PATCH V4 09/14] cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking() Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 8:20 ` AngeloGioacchino Del Regno
2022-04-22 8:20 ` AngeloGioacchino Del Regno
2022-04-22 8:20 ` AngeloGioacchino Del Regno
2022-04-22 7:52 ` [PATCH V4 10/14] cpufreq: mediatek: Link CCI device to CPU Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` [PATCH V4 11/14] cpufreq: mediatek: Add support for MT8186 Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` [PATCH V4 12/14] arm64: dts: mediatek: Add opp table and clock property for MT8183 cpufreq Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 8:20 ` AngeloGioacchino Del Regno
2022-04-22 8:20 ` AngeloGioacchino Del Regno
2022-04-22 8:20 ` AngeloGioacchino Del Regno
2022-04-22 7:52 ` [PATCH V4 13/14] arm64: dts: mediatek: Add MediaTek CCI node for MT8183 Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 7:52 ` [PATCH V4 14/14] arm64: dts: mediatek: Add mediatek,cci property for MT8183 cpufreq Rex-BC Chen
2022-04-22 7:52 ` [PATCH V4 14/14] arm64: dts: mediatek: Add mediatek, cci " Rex-BC Chen
2022-04-22 7:52 ` Rex-BC Chen
2022-04-22 17:23 ` [PATCH V4 00/14] cpufreq: mediatek: Cleanup and support MT8183 and MT8186 Krzysztof Kozlowski
2022-04-22 17:23 ` Krzysztof Kozlowski
2022-04-22 17:23 ` Krzysztof Kozlowski
2022-04-25 6:20 ` Rex-BC Chen
2022-04-25 6:20 ` Rex-BC Chen
2022-04-25 6:20 ` Rex-BC Chen
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=078b1f9b39690da98cbd3c4528ba28374a097083.camel@mediatek.com \
--to=rex-bc.chen@mediatek.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=hsinyi@google.com \
--cc=jia-wei.chang@mediatek.com \
--cc=khilman@baylibre.com \
--cc=krzk+dt@kernel.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=robh+dt@kernel.org \
--cc=roger.lu@mediatek.com \
--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.