From: "Jia-wei Chang (張佳偉)" <Jia-wei.Chang@mediatek.com>
To: "daniel@makrotopia.org" <daniel@makrotopia.org>,
"angelogioacchino.delregno@collabora.com"
<angelogioacchino.delregno@collabora.com>
Cc: "linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"vincent@systemli.org" <vincent@systemli.org>,
"hsinyi@google.com" <hsinyi@google.com>,
"viresh.kumar@linaro.org" <viresh.kumar@linaro.org>,
Project_Global_Chrome_Upstream_Group
<Project_Global_Chrome_Upstream_Group@mediatek.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"khilman@baylibre.com" <khilman@baylibre.com>,
"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
"rafael@kernel.org" <rafael@kernel.org>,
"Rex-BC Chen (陳柏辰)" <Rex-BC.Chen@mediatek.com>,
"error27@gmail.com" <error27@gmail.com>
Subject: Re: [PATCH v2 4/4] cpufreq: mediatek: Raise proc and sram max voltage for MT7622/7623
Date: Wed, 24 May 2023 08:43:31 +0000 [thread overview]
Message-ID: <4e5a8202f7446481def19e5926d1bfd6e6568dd7.camel@mediatek.com> (raw)
In-Reply-To: <3054e2d9-7f77-a22a-293d-382f19494079@collabora.com>
On Wed, 2023-05-24 at 09:28 +0200, AngeloGioacchino Del Regno wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> Il 23/05/23 19:37, Daniel Golle ha scritto:
> > On Tue, May 23, 2023 at 04:56:47PM +0200, AngeloGioacchino Del
> > Regno wrote:
> > > Il 22/05/23 20:03, Daniel Golle ha scritto:
> > > > Hi Jia-Wei,
> > > > Hi AngeloGioacchino,
> > > >
> > > > On Fri, Mar 24, 2023 at 06:11:30PM +0800, jia-wei.chang wrote:
> > > > > From: AngeloGioacchino Del Regno <
> > > > > angelogioacchino.delregno@collabora.com>
> > > > >
> > > > > During the addition of SRAM voltage tracking for CCI scaling,
> > > > > this
> > > > > driver got some voltage limits set for the vtrack algorithm:
> > > > > these
> > > > > were moved to platform data first, then enforced in a later
> > > > > commit
> > > > > 6a17b3876bc8 ("cpufreq: mediatek: Refine
> > > > > mtk_cpufreq_voltage_tracking()")
> > > > > using these as max values for the regulator_set_voltage()
> > > > > calls.
> > > > >
> > > > > In this case, the vsram/vproc constraints for MT7622 and
> > > > > MT7623
> > > > > were supposed to be the same as MT2701 (and a number of other
> > > > > SoCs),
> > > > > but that turned out to be a mistake because the
> > > > > aforementioned two
> > > > > SoCs' maximum voltage for both VPROC and VPROC_SRAM is 1.36V.
> > > > >
> > > > > Fix that by adding new platform data for MT7622/7623
> > > > > declaring the
> > > > > right {proc,sram}_max_volt parameter.
> > > > >
> > > > > Fixes: ead858bd128d ("cpufreq: mediatek: Move voltage limits
> > > > > to platform data")
> > > > > Fixes: 6a17b3876bc8 ("cpufreq: mediatek: Refine
> > > > > mtk_cpufreq_voltage_tracking()")
> > > > > Signed-off-by: AngeloGioacchino Del Regno <
> > > > > angelogioacchino.delregno@collabora.com>
> > > > > Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
> > > > > ---
> > > > > drivers/cpufreq/mediatek-cpufreq.c | 13 +++++++++++--
> > > > > 1 file changed, 11 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/cpufreq/mediatek-cpufreq.c
> > > > > b/drivers/cpufreq/mediatek-cpufreq.c
> > > > > index 764e4fbdd536..9a39a7ccfae9 100644
> > > > > --- a/drivers/cpufreq/mediatek-cpufreq.c
> > > > > +++ b/drivers/cpufreq/mediatek-cpufreq.c
> > > > > @@ -693,6 +693,15 @@ static const struct
> > > > > mtk_cpufreq_platform_data mt2701_platform_data = {
> > > > > .ccifreq_supported = false,
> > > > > };
> > > > > +static const struct mtk_cpufreq_platform_data
> > > > > mt7622_platform_data = {
> > > > > + .min_volt_shift = 100000,
> > > > > + .max_volt_shift = 200000,
> > > > > + .proc_max_volt = 1360000,
> > > > > + .sram_min_volt = 0,
> > > > > + .sram_max_volt = 1360000,
> > > >
> > > > This change breaks cpufreq (with ondemand scheduler) on my BPi
> > > > R64
> > > > board (having MT7622AV SoC with MT6380N PMIC).
> > > > ...
> > > > [ 2.540091] cpufreq: __target_index: Failed to change cpu
> > > > frequency: -22
> > > > [ 2.556985] cpu cpu0: cpu0: failed to scale up voltage!
> > > > ...
> > > > (repeating a lot, every time the highest operating point is
> > > > selected
> > > > by the cpufreq governor)
> > > >
> > > > The reason is that the MT6380N doesn't support 1360000uV on the
> > > > supply
> > > > outputs used for SRAM and processor.
> > > >
> > > > As for some reason cpufreq-mediatek tries to rise the SRAM
> > > > supply
> > > > voltage to the maximum for a short moment (probably a side-
> > > > effect of
> > > > the voltage tracking algorithm), this fails because the PMIC
> > > > only
> > > > supports up to 1350000uV. As the highest operating point is
> > > > anyway
> > > > using only 1310000uV the simple fix is setting 1350000uV as the
> > > > maximum
> > > > instead for both proc_max_volt and sram_max_volt.
> > > >
> > > > A similar situation applies also for BPi R2 (MT7623NI with
> > > > MT6323L
> > > > PMIC), here the maximum supported voltage of the PMIC which
> > > > also only
> > > > supports up to 1350000uV, and the SoC having its highest
> > > > operating
> > > > voltage defined at 1300000uV.
> > > >
> > > > If all agree with the simple fix I will post a patch for that.
> > > >
> > > > However, to me it feels fishy to begin with that the tracking
> > > > algorithm
> > > > tries to rise the voltage above the highest operating point
> > > > defined in
> > > > device tree, see here:
> > > >
> > > > 6a17b3876bc830 drivers/cpufreq/mediatek-cpufreq.c (Jia-Wei
> > > > Chang 2022-05-05 19:52:20 +0800 100) new_vsram
> > > > = clamp(new_vproc + soc_data->min_volt_shift,
> > > > 6a17b3876bc830 drivers/cpufreq/mediatek-cpufreq.c (Jia-Wei
> > > > Chang 2022-05-05 19:52:20 +0800
> > > > 101) soc_data->sram_min_volt, soc_data-
> > > > >sram_max_volt);
> > > >
> > > > However, I did not investigate in depth the purpose of this
> > > > initial rise and can impossibly test my modifications to the
> > > > tracking algorithm on all supported SoCs.
> > > >
> > >
> > > Thanks for actually reporting that, I don't think that there's
> > > any
> > > valid reason why the algorithm should set a voltage higher than
> > > the
> > > maximum votage specified in the fastest OPP.
> > >
> > > Anyway - the logic for the platform data of this driver is to
> > > declare
> > > the maximum voltage that SoC model X supports, regardless of the
> > > actual
> > > board-specific OPPs, so that part is right; to solve this issue,
> > > I guess
> > > that the only way is for this driver to parse the OPPs during
> > > .probe()
> > > and then always use in the algorithm
> > >
> > > vproc_max = max(proc_max_volt, opp_vproc_max);
> > > vsram_max = max(sram_max_volt, vsram_vreg_max);
Hi Daniel, Angelo Sir,
Thanks for the issue report and suggestions.
Is it possible to modify the value of proc_max_volt and sram_max_volt
to 1310000 in mt7622_platform_data as the highest voltage declared in
mt7622.dtsi and then give it a try?
Sorry, I need someone help to check this on mt7622 since I don't have
mt7622 platform..
Thanks.
> >
> > You probably meant to write
> > vproc_max = min(proc_max_volt, opp_vproc_max);
> > vsram_max = min(sram_max_volt, vsram_vreg_max);
> >
> > right?
> >
>
> Apparently, some of my braincells was apparently taking a break. :-)
>
> Yes, I was meaning min(), not max() :-)
>
> Cheers!
>
> > >
> > > Jia-Wei, can you please handle this?
> > >
> > > Thanks,
> > > Angelo
> > >
>
>
>
next prev parent reply other threads:[~2023-05-24 8:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230324101130.14053-1-jia-wei.chang@mediatek.com>
[not found] ` <20230324101130.14053-4-jia-wei.chang@mediatek.com>
2023-03-24 13:11 ` [PATCH v2 3/4] cpufreq: mediatek: raise proc/sram max voltage for MT8516 AngeloGioacchino Del Regno
2023-03-30 3:50 ` [PATCH v2 0/4] Enhance mediatek-cpufreq robustness Viresh Kumar
[not found] ` <20230324101130.14053-5-jia-wei.chang@mediatek.com>
2023-05-22 18:03 ` [PATCH v2 4/4] cpufreq: mediatek: Raise proc and sram max voltage for MT7622/7623 Daniel Golle
2023-05-23 14:56 ` AngeloGioacchino Del Regno
2023-05-23 17:37 ` Daniel Golle
2023-05-24 7:28 ` AngeloGioacchino Del Regno
2023-05-24 8:43 ` Jia-wei Chang (張佳偉) [this message]
2023-05-24 12:42 ` Daniel Golle
2023-05-26 8:27 ` Jia-wei Chang (張佳偉)
2023-05-26 8:37 ` Jia-wei Chang (張佳偉)
2023-05-26 10:27 ` Daniel Golle
2023-05-29 4:12 ` Jia-wei Chang (張佳偉)
2023-06-05 14:18 ` [PATCH] cpufreq: mediatek: correct voltages for MT7622 and MT7623 Daniel Golle
2023-06-06 7:41 ` AngeloGioacchino Del Regno
2023-06-19 4:23 ` Viresh Kumar
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=4e5a8202f7446481def19e5926d1bfd6e6568dd7.camel@mediatek.com \
--to=jia-wei.chang@mediatek.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=Rex-BC.Chen@mediatek.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=daniel@makrotopia.org \
--cc=error27@gmail.com \
--cc=hsinyi@google.com \
--cc=khilman@baylibre.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=rafael@kernel.org \
--cc=vincent@systemli.org \
--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 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®