| Message ID | 20220504130540.5902-1-rex-bc.chen@mediatek.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | cpufreq: mediatek: Cleanup and support MT8183 and MT8186 | expand |
On 04-05-22, 21:05, Rex-BC Chen wrote: > From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com> > > >From this opp notifier, cpufreq should listen to opp notification and do What happened with the extra ">" here ? > static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu) > { > struct device *cpu_dev; > @@ -396,6 +458,17 @@ 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); > > + info->opp_cpu = cpu; > + info->opp_nb.notifier_call = mtk_cpufreq_opp_notifier; > + ret = dev_pm_opp_register_notifier(cpu_dev, &info->opp_nb); > + if (ret) { > + dev_err(cpu_dev, "cpu%d: failed to register opp notifier\n", cpu); > + goto out_disable_inter_clock; > + } > + > + mutex_init(&info->reg_lock); You should always initialize a resource before its users. The notifier callback, which can get called right after dev_pm_opp_register_notifier() returns, will use this mutex. > + info->opp_freq = clk_get_rate(info->cpu_clk); > + > /* > * If SRAM regulator is present, software "voltage tracking" is needed > * for this CPU power domain. > @@ -451,6 +524,9 @@ static void mtk_cpu_dvfs_info_release(struct mtk_cpu_dvfs_info *info) > } > > dev_pm_opp_of_cpumask_remove_table(&info->cpus); > + > + if (!IS_ERR_OR_NULL(info->cpu_dev)) cpu_dev can never be error here. > + dev_pm_opp_unregister_notifier(info->cpu_dev, &info->opp_nb); > } > > static int mtk_cpufreq_init(struct cpufreq_policy *policy) I also asked you last time to stack things in a order so they are easier for me to apply. Bugfixes, followed by simple cleanups, which don't make behavioral changes, followed by real patches. Now you have sent this patch at an early stage, which blocks me from applying anything after this. I can see the earlier comments weren't all considered, and it doesn't look nice.
On 04-05-22, 21:05, Rex-BC Chen wrote: > arm64: dts: mediatek: Add opp table and clock property for MT8183 > cpufreq > arm64: dts: mediatek: Add MediaTek CCI node for MT8183 > arm64: dts: mediatek: Add mediatek,cci property for MT8183 cpufreq I guess these would also go through my tree? Please get them acked by SoC maintainers. I would also need an Ack from Rob for the binding patch.
On Thu, 2022-05-05 at 14:23 +0530, Viresh Kumar wrote: > On 04-05-22, 21:05, Rex-BC Chen wrote: > > arm64: dts: mediatek: Add opp table and clock property for MT8183 > > cpufreq > > arm64: dts: mediatek: Add MediaTek CCI node for MT8183 > > arm64: dts: mediatek: Add mediatek,cci property for MT8183 > > cpufreq > > I guess these would also go through my tree? Please get them acked by > SoC maintainers. > > I would also need an Ack from Rob for the binding patch. > Hello Viresh, I also mail to Matthias who is mediatek soc maintainer. As for binding, I think we need to wait for the review from Rob or Krzysztof. BRs, Rex
Cpufreq is a DVFS driver used for power saving to scale the clock frequency and supply the voltage for CPUs. This series do some cleanup for MediaTek cpufreq drivers and add support for MediaTek SVS[2] and MediaTek CCI devfreq[3] which are supported in MT8183 and MT8186. Changes for v5: 1. Modify the description for the reason we need to use mediatek,cci. 2. Drop [07/14] cpufreq: mediatek: Add .get function. Changes for V4: 1. Revise drivers from reviewers' suggestion. 2. Fix name of opp table issue. Changes for V3: 1. Rebased to linux-next-20220414. 2. Drop accepted patches. 3. Drop "cpufreq: mediatek: Use maximum voltage in init stage" because we make sure the voltage we set is safe for both mediatek cci and cpufreq. 4. Rename cci property to mediatek,cci. 5. Adjust order of cleanup patches. 6. Add new patches for cleanup, handle infinite loop and MT8183 dts. 7. Revise drivers from reviewers' suggestion. 8. Revise commit message of some patches to avoid confusion and misunderstand. 9. Revise "cpufreq: mediatek: Link CCI device to CPU". We do not return successful to pretend we set the target frequency done when cci is not ready. Instead, we find and set a safe voltage so that we can set the target cpufrequency. Changes for V2: 1. Drop the modification of transforming cpufreq-mediatek into yaml and only add the MediaTek CCI property for MediaTek cpufreq. 2. Split the original patches into several patches. Reference series: [1]: V1 of this series is present by Jia-Wei Chang. https://lore.kernel.org/all/20220307122151.11666-1-jia-wei.chang@mediatek.com/ [2]: The MediaTek CCI devfreq driver is introduced in another series. https://lore.kernel.org/all/20220425125546.4129-1-johnson.wang@mediatek.com/ [3]: The MediaTek SVS driver is introduced in another series. https://lore.kernel.org/all/20220420102044.10832-1-roger.lu@mediatek.com/ Andrew-sh.Cheng (1): cpufreq: mediatek: Add opp notification support Jia-Wei Chang (3): cpufreq: mediatek: Move voltage limits to platform data cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking() cpufreq: mediatek: Add support for MT8186 Rex-BC Chen (5): dt-bindings: cpufreq: mediatek: Add MediaTek CCI property cpufreq: mediatek: Link CCI device to CPU arm64: dts: mediatek: Add opp table and clock property for MT8183 cpufreq arm64: dts: mediatek: Add MediaTek CCI node for MT8183 arm64: dts: mediatek: Add mediatek,cci property for MT8183 cpufreq .../bindings/cpufreq/cpufreq-mediatek.txt | 7 + arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 36 ++ .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 4 + arch/arm64/boot/dts/mediatek/mt8183.dtsi | 285 +++++++++++++ drivers/cpufreq/mediatek-cpufreq.c | 399 ++++++++++++------ 5 files changed, 608 insertions(+), 123 deletions(-)