Message ID | 20220509120337.92472-1-cw00.choi@samsung.com (mailing list archive) |
---|---|
Headers | show |
Series | PM / devfreq: Add cpu based scaling support to passive governor | expand |
On Mon, May 9, 2022 at 8:03 PM Chanwoo Choi <cwchoi00@gmail.com> wrote: > > The devfreq passive governor has already supported the devfreq parent device > for coupling the frequency change if some hardware have the constraints > such as power sharing and so on. > > Add cpu based scaling support to passive governor with required-opp property. > It uses the cpufreq notifier to catch the frequency change timing of cpufreq > and get the next frequency according to new cpu frequency by using required-opp > property. It is based on patch[1] and then just code clean-up by myself. > > Make the common code for both passive_devfreq and passive_cpufreq > parent type to remove the duplicate code. > > [1] [RFC,v2] PM / devfreq: Add cpu based scaling support to passive_governor > - https://lore.kernel.org/patchwork/patch/1101049/ > > Changes from v2: > : https://patchwork.kernel.org/project/linux-pm/cover/20220507150145.531864-1-cw00.choi@samsung.com/ > - Drop the following patch ("PM / devfreq: passive: Update frequency when start governor") > - Move p_data->this initialization into cpufreq_passive_regiser_notifier() > > Changes from v1: > : https://patchwork.kernel.org/project/linux-pm/cover/20210617060546.26933-1-cw00.choi@samsung.com/ > - Rename cpu_data variable to parent_cpu_data to avoid build fail > - Use for_each_possible_cpu macro when register cpufreq transition notifier > - Add missing exception handling when cpufreq_passive_register_notifier is failed > - Keep cpufreq_policy for posible cpus instead of NR_CPU in order to avoid > the memory waste when NR_CPU is too high. > - Add reviewed-by tag of Matthias Kaehlcke for patch1 > > > Chanwoo Choi (3): > PM / devfreq: Export devfreq_get_freq_range symbol within devfreq > PM / devfreq: passive: Reduce duplicate code when passive_devfreq case > PM / devfreq: passive: Keep cpufreq_policy for possible cpus > > Saravana Kannan (1): > PM / devfreq: Add cpu based scaling support to passive governor Tested-by: Chen-Yu Tsai <wenst@chromium.org> on next-20220509 in conjunction with the MediaTek cpufreq [1], CCI devfreq [2] & SVS [3] series, as well as some fix-ups [4]. AFAICT the CCI devfreq device is reacting and making frequency changes. Regards ChenYu [1] https://lore.kernel.org/all/20220422075239.16437-1-rex-bc.chen@mediatek.com/ [2] https://lore.kernel.org/all/20220408052150.22536-1-johnson.wang@mediatek.com/ [3] https://lore.kernel.org/all/20220420102044.10832-1-roger.lu@mediatek.com/ [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test
Hi Chen-Yu, On Tue, May 10, 2022 at 6:00 PM Chen-Yu Tsai <wenst@chromium.org> wrote: > > On Mon, May 9, 2022 at 8:03 PM Chanwoo Choi <cwchoi00@gmail.com> wrote: > > > > The devfreq passive governor has already supported the devfreq parent device > > for coupling the frequency change if some hardware have the constraints > > such as power sharing and so on. > > > > Add cpu based scaling support to passive governor with required-opp property. > > It uses the cpufreq notifier to catch the frequency change timing of cpufreq > > and get the next frequency according to new cpu frequency by using required-opp > > property. It is based on patch[1] and then just code clean-up by myself. > > > > Make the common code for both passive_devfreq and passive_cpufreq > > parent type to remove the duplicate code. > > > > [1] [RFC,v2] PM / devfreq: Add cpu based scaling support to passive_governor > > - https://lore.kernel.org/patchwork/patch/1101049/ > > > > Changes from v2: > > : https://patchwork.kernel.org/project/linux-pm/cover/20220507150145.531864-1-cw00.choi@samsung.com/ > > - Drop the following patch ("PM / devfreq: passive: Update frequency when start governor") > > - Move p_data->this initialization into cpufreq_passive_regiser_notifier() > > > > Changes from v1: > > : https://patchwork.kernel.org/project/linux-pm/cover/20210617060546.26933-1-cw00.choi@samsung.com/ > > - Rename cpu_data variable to parent_cpu_data to avoid build fail > > - Use for_each_possible_cpu macro when register cpufreq transition notifier > > - Add missing exception handling when cpufreq_passive_register_notifier is failed > > - Keep cpufreq_policy for posible cpus instead of NR_CPU in order to avoid > > the memory waste when NR_CPU is too high. > > - Add reviewed-by tag of Matthias Kaehlcke for patch1 > > > > > > Chanwoo Choi (3): > > PM / devfreq: Export devfreq_get_freq_range symbol within devfreq > > PM / devfreq: passive: Reduce duplicate code when passive_devfreq case > > PM / devfreq: passive: Keep cpufreq_policy for possible cpus > > > > Saravana Kannan (1): > > PM / devfreq: Add cpu based scaling support to passive governor > > Tested-by: Chen-Yu Tsai <wenst@chromium.org> > > on next-20220509 in conjunction with the MediaTek cpufreq [1], CCI devfreq [2] > & SVS [3] series, as well as some fix-ups [4]. AFAICT the CCI devfreq device > is reacting and making frequency changes. > > > Regards > ChenYu > > [1] https://lore.kernel.org/all/20220422075239.16437-1-rex-bc.chen@mediatek.com/ > [2] https://lore.kernel.org/all/20220408052150.22536-1-johnson.wang@mediatek.com/ > [3] https://lore.kernel.org/all/20220420102044.10832-1-roger.lu@mediatek.com/ > [4] https://github.com/wens/linux/commits/mt8183-cpufreq-cci-svs-test Thanks for your test.
On Mon, 2022-05-09 at 21:03 +0900, Chanwoo Choi wrote: > The devfreq passive governor has already supported the devfreq parent > device > for coupling the frequency change if some hardware have the > constraints > such as power sharing and so on. > > Add cpu based scaling support to passive governor with required-opp > property. > It uses the cpufreq notifier to catch the frequency change timing of > cpufreq > and get the next frequency according to new cpu frequency by using > required-opp > property. It is based on patch[1] and then just code clean-up by > myself. > > Make the common code for both passive_devfreq and passive_cpufreq > parent type to remove the duplicate code. > > [1] [RFC,v2] PM / devfreq: Add cpu based scaling support to > passive_governor > - https://lore.kernel.org/patchwork/patch/1101049/ > > Changes from v2: > : > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-pm/cover/20220507150145.531864-1-cw00.choi@samsung.com/__;!!CTRNKA9wMg0ARbw!x-hPdV1M41ovWuBCw3cVvayFBaqFZRCtLLqDHeX_iNnzvwmOKQYOVQeD9mBfi7n8okEj$ > > - Drop the following patch ("PM / devfreq: passive: Update frequency > when start governor") > - Move p_data->this initialization into > cpufreq_passive_regiser_notifier() > > Changes from v1: > : > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-pm/cover/20210617060546.26933-1-cw00.choi@samsung.com/__;!!CTRNKA9wMg0ARbw!x-hPdV1M41ovWuBCw3cVvayFBaqFZRCtLLqDHeX_iNnzvwmOKQYOVQeD9mBfiw3rUNcX$ > > - Rename cpu_data variable to parent_cpu_data to avoid build fail > - Use for_each_possible_cpu macro when register cpufreq transition > notifier > - Add missing exception handling when > cpufreq_passive_register_notifier is failed > - Keep cpufreq_policy for posible cpus instead of NR_CPU in order to > avoid > the memory waste when NR_CPU is too high. > - Add reviewed-by tag of Matthias Kaehlcke for patch1 > > > Chanwoo Choi (3): > PM / devfreq: Export devfreq_get_freq_range symbol within devfreq > PM / devfreq: passive: Reduce duplicate code when passive_devfreq > case > PM / devfreq: passive: Keep cpufreq_policy for possible cpus > > Saravana Kannan (1): > PM / devfreq: Add cpu based scaling support to passive governor > > drivers/devfreq/devfreq.c | 20 +- > drivers/devfreq/governor.h | 27 ++ > drivers/devfreq/governor_passive.c | 400 ++++++++++++++++++++++++--- > -- > include/linux/devfreq.h | 17 +- > 4 files changed, 387 insertions(+), 77 deletions(-) > For this serie: Tested-by: Johnson Wang <johnson.wang@mediatek.com> BRs, Johnson Wang