powercap/drivers/dtpm: Add dtpm devfreq with energy model support
Subsystems (2)
PATCH 1/1 powercap/drivers/dtpm: Add dtpm devfreq with energy model support
Currently the dtpm supports the CPUs via cpufreq and the energy model. This change provides the same for the device which supports devfreq.
Each device supporting devfreq and having an energy model can register themselves in the list of supported devices.
The concept is the same as the cpufreq dtpm support: the QoS is used to aggregate the requests and the energy model gives the value of the instantaneous power consumption ponderated by the load of the device.
--- drivers/powercap/Kconfig | 7 ++ drivers/powercap/Makefile | 1 + drivers/powercap/dtpm_devfreq.c | 198 ++++++++++++++++++++++++++++++++ include/linux/dtpm.h | 13 +++ 4 files changed, 219 insertions(+) create mode 100644 drivers/powercap/dtpm_devfreq.c
drivers/powercap/Kconfig +7 -0
@@ -64,4 +64,11 @@ config DTPM_CPU help This enables support for CPU power limitation based on energy model. + +config DTPM_DEVFREQ + bool "Add device power capping based on the energy model" + depends on DTPM && ENERGY_MODEL + help + This enables support for device power limitation based on + energy model. endif
drivers/powercap/Makefile +1 -0
@@ -2,6 +2,7 @@ obj-$(CONFIG_DTPM) += dtpm.o obj-$(CONFIG_DTPM_CONFIGFS) += dtpm_configfs.o obj-$(CONFIG_DTPM_CPU) += dtpm_cpu.o +obj-$(CONFIG_DTPM_DEVFREQ) += dtpm_devfreq.o obj-$(CONFIG_POWERCAP) += powercap_sys.o obj-$(CONFIG_INTEL_RAPL_CORE) += intel_rapl_common.o obj-$(CONFIG_INTEL_RAPL) += intel_rapl_msr.o
drivers/powercap/dtpm_devfreq.c new file +198 -0
198 lines not on this page · raw message
include/linux/dtpm.h +13 -0
@@ -80,4 +80,17 @@ void dtpm_unregister(const char *name);struct dtpm *dtpm_get (const char *name);void dtpm_put (struct dtpm *dtpm); + +#ifdef CONFIG_DTPM_DEVFREQ + +struct devfreq ; + +int dtpm_register_devfreq (struct devfreq *devfreq); +#else +static inline int dtpm_register_devfreq (struct devfreq *devfreq) +{ +return 0 ; +} +#endif +#endif
Signature · 1 line
2.17.1
Hi Daniel,
Quoted 11 lines · Daniel Lezcano
Currently the dtpm supports the CPUs via cpufreq and the energy model. This change provides the same for the device which supports devfreq.
Each device supporting devfreq and having an energy model can register themselves in the list of supported devices.
The concept is the same as the cpufreq dtpm support: the QoS is used to aggregate the requests and the energy model gives the value of the instantaneous power consumption ponderated by the load of the device.
I've just started the review, but I have a blocking question:
Why there is no unregister function (like 'dtmp_unregister_devfreq')? Do you consider any devfreq drivers to be modules?
The code looks like an API that it's going to be called directly in e.g. GPU driver in it's probe function. In that case probably the module unloading should call dtmp unregister.
Could you explain this to me please? So I can continue the review.
Regards,
Lukasz
Quoted 18 lines · Lukasz Luba
Hi Daniel,
Quoted 11 lines · Daniel Lezcano
Currently the dtpm supports the CPUs via cpufreq and the energy model. This change provides the same for the device which supports devfreq.
Each device supporting devfreq and having an energy model can register themselves in the list of supported devices.
The concept is the same as the cpufreq dtpm support: the QoS is used to aggregate the requests and the energy model gives the value of the instantaneous power consumption ponderated by the load of the device.
I've just started the review, but I have a blocking question:
Quoted 8 lines
Why there is no unregister function (like '
dtmp_unregister_devfreq')? Do you consider any devfreq drivers to be modules?The code looks like an API that it's going to be called directly in e.g. GPU driver in it's probe function. In that case probably the module unloading should call dtmp unregister.
Could you explain this to me please? So I can continue the review.
Just forgot the unregister function :)
Signature · 5 lines
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog
Quoted 18 lines · Lukasz Luba
Hi Daniel,
Quoted 11 lines · Daniel Lezcano
Currently the dtpm supports the CPUs via cpufreq and the energy model. This change provides the same for the device which supports devfreq.
Each device supporting devfreq and having an energy model can register themselves in the list of supported devices.
The concept is the same as the cpufreq dtpm support: the QoS is used to aggregate the requests and the energy model gives the value of the instantaneous power consumption ponderated by the load of the device.
I've just started the review, but I have a blocking question:
Quoted 8 lines
Why there is no unregister function (like '
dtmp_unregister_devfreq')? Do you consider any devfreq drivers to be modules?The code looks like an API that it's going to be called directly in e.g. GPU driver in it's probe function. In that case probably the module unloading should call dtmp unregister.
Could you explain this to me please? So I can continue the review.
BTW, thanks for taking the time to review the patch.
Signature · 5 lines
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog