| Message ID | 20220408045908.21671-13-rex-bc.chen@mediatek.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | cpufreq: mediatek: Cleanup and support MT8183 and MT8186 | expand |
Il 08/04/22 06:59, Rex-BC Chen ha scritto: > From: Jia-Wei Chang <jia-wei.chang@mediatek.com> > > Two or more clients may use the same regulator, and it could cause the > issue of high-freqeuncy-low-voltage. > To prevent this, we use maximum voltage in mtk_cpu_dvfs_info_init(). > > Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> Is this happening for proc-supply (proc_reg)? ...because it looks like it is, so you should send this commit separately and with an appropriate Fixes: tag.
On Fri, 2022-04-08 at 15:37 +0200, AngeloGioacchino Del Regno wrote: > Il 08/04/22 06:59, Rex-BC Chen ha scritto: > > From: Jia-Wei Chang <jia-wei.chang@mediatek.com> > > > > Two or more clients may use the same regulator, and it could cause > > the > > issue of high-freqeuncy-low-voltage. > > To prevent this, we use maximum voltage in > > mtk_cpu_dvfs_info_init(). > > > > Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> > > Is this happening for proc-supply (proc_reg)? > ...because it looks like it is, so you should send this commit > separately > and with an appropriate Fixes: tag. Hello Angelo, The commit message is not clear. The clients are cpufreq and mediatek cci. I think there is no any error before introducing mediatek cci into cpufreq. The order of this patch should be after "cpufreq: mediatek: Link CCI device to CPU". If so, I will also correct the commit message in next version. BRs, Rex
On Fri, 2022-04-08 at 15:37 +0200, AngeloGioacchino Del Regno wrote: > Il 08/04/22 06:59, Rex-BC Chen ha scritto: > > From: Jia-Wei Chang <jia-wei.chang@mediatek.com> > > > > Two or more clients may use the same regulator, and it could cause > > the > > issue of high-freqeuncy-low-voltage. > > To prevent this, we use maximum voltage in > > mtk_cpu_dvfs_info_init(). > > > > Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> > > Is this happening for proc-supply (proc_reg)? > ...because it looks like it is, so you should send this commit > separately > and with an appropriate Fixes: tag. Hello all, If we use the value of max(booting voltage, target cpufreq voltage) when cci is not ready, I think we don't need this patch to prevent high frequenc low voltage issue. (mentioned in [1]) I will drop this patch in next version. Thanks. [1]:https://patchwork.kernel.org/comment/24816091/ BRs, Rex
diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c index e69b16a6541e..b08ab7c14818 100644 --- a/drivers/cpufreq/mediatek-cpufreq.c +++ b/drivers/cpufreq/mediatek-cpufreq.c @@ -333,7 +333,7 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu) { struct device *cpu_dev; struct dev_pm_opp *opp; - unsigned long rate; + unsigned long rate, opp_volt; int ret; cpu_dev = get_cpu_device(cpu); @@ -417,6 +417,24 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu) info->intermediate_voltage = dev_pm_opp_get_voltage(opp); dev_pm_opp_put(opp); + /* Use highest opp voltage in the init stage */ + rate = U32_MAX; + opp = dev_pm_opp_find_freq_floor(info->cpu_dev, &rate); + if (IS_ERR(opp)) { + ret = PTR_ERR(opp); + dev_err(cpu_dev, "cpu%d: failed to get opp\n", info->opp_cpu); + goto out_disable_inter_clock; + } + + opp_volt = dev_pm_opp_get_voltage(opp); + dev_pm_opp_put(opp); + ret = mtk_cpufreq_set_voltage(info, opp_volt); + if (ret) { + dev_err(cpu_dev, "cpu%d: failed to scale to highest voltage %lu in proc_reg\n", + info->opp_cpu, opp_volt); + goto out_disable_inter_clock; + } + info->opp_cpu = cpu; info->opp_nb.notifier_call = mtk_cpufreq_opp_notifier; ret = dev_pm_opp_register_notifier(cpu_dev, &info->opp_nb);