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

 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(-)

-- 
2.25.1

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

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.

-- 
Best Regards,
Chanwoo Choi