linux/drivers/powercap, branch v5.17

Merge back earlier power capping changes for v5.17

2021-12-27T15:51:12Z

powercap/drivers/dtpm: Reduce trace verbosity

2021-12-23T15:57:36Z

The traces when registering a powerzone is at the pr_info level and should be changed to pr_debug as requested by Greg-KH. Cc: Greg KH Reviewed-by: Greg Kroah-Hartman Link: https://lkml.kernel.org/r/YGAnRx8SiZHFPpY6@kroah.com Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20211123101601.2433340-2-daniel.lezcano@linaro.org

powercap: fix typo in a comment in idle_inject.c

2021-12-17T15:30:19Z

Drop superfluous "the" from the comment in line 15. Signed-off-by: Jason Wang [ rjw: Subject edit, new changelog ] Signed-off-by: Rafael J. Wysocki

powercap: intel_rapl: support new layout of Psys PowerLimit Register on SPR

2021-12-17T15:13:14Z

On Sapphire Rapids, the layout of the Psys domain Power Limit Register is different from from what it was before. Enhance the code to support the new Psys PL register layout. Signed-off-by: Zhang Rui Reported-and-tested-by: Alkattan Dana [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki

powercap: DTPM: Drop unused local variable from init_dtpm()

2021-12-03T16:51:59Z

The dtpm_descr variable in init_dtpm() is not used after commit f751db8adaea ("powercap/drivers/dtpm: Disable DTPM at boot time"), so drop it. Fixes: f751db8adaea ("powercap/drivers/dtpm: Disable DTPM at boot time") Reported-by: Stephen Rothwell Signed-off-by: Rafael J. Wysocki

powercap/drivers/dtpm: Disable DTPM at boot time

2021-12-01T18:55:34Z

The DTPM framework misses a mechanism to set it up. That is currently under review but will come after the next cycle. As the distro are enabling all the kernel options, the DTPM framework is enabled on platforms where the energy model is not implemented, thus making the framework inconsistent and disrupting the CPU frequency scaling service. Remove the initialization at boot time as a hot fix. Fixes: 7a89d7eacf8e ("powercap/drivers/dtpm: Simplify the dtpm table") Signed-off-by: Daniel Lezcano Reported-By: Doug Smythies Tested-By: Doug Smythies Signed-off-by: Rafael J. Wysocki

powercap: DTPM: Fix suspend failure and kernel warning

2021-11-10T20:18:14Z

When the ENERGY_MODEL and DTPM_CPU are enabled but actually without any energy model, at cpu hotplug time, the dead cpuhp callback fails leading to the warning. Actually, the check could be simplified and we only do an action if the dtpm cpu is enabled, otherwise we bail out without error. Fixes: 7a89d7eacf8e ("powercap/drivers/dtpm: Simplify the dtpm table") Reported-by: Kenneth R. Crudup Tested-by: Kenneth R. Crudup Reported-by: kernel test robot Signed-off-by: Daniel Lezcano Signed-off-by: Rafael J. Wysocki

powercap/drivers/dtpm: Fix power limit initialization

2021-10-21T14:03:31Z

When a DTPM node is registered its power limit must be initialized to the power max. Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210318205238.21937-1-daniel.lezcano@linaro.org

powercap/drivers/dtpm: Scale the power with the load

2021-10-21T14:03:31Z

Currently the power consumption is based on the current OPP power assuming the entire performance domain is fully loaded. That gives very gross power estimation and we can do much better by using the load to scale the power consumption. Use the utilization to normalize and scale the power usage over the max possible power. Tested on a rock960 with 2 big CPUS, the power consumption estimation conforms with the expected one. Before this change: ~$ ~/dhrystone -t 1 -l 10000& ~$ cat /sys/devices/virtual/powercap/dtpm/dtpm:0/dtpm:0:1/constraint_0_max_power_uw 2260000 After this change: ~$ ~/dhrystone -t 1 -l 10000& ~$ cat /sys/devices/virtual/powercap/dtpm/dtpm:0/dtpm:0:1/constraint_0_max_power_uw 1130000 ~$ ~/dhrystone -t 2 -l 10000& ~$ cat /sys/devices/virtual/powercap/dtpm/dtpm:0/dtpm:0:1/constraint_0_max_power_uw 2260000 Signed-off-by: Daniel Lezcano Reviewed-by: Lukasz Luba Link: https://lore.kernel.org/r/20210312130411.29833-5-daniel.lezcano@linaro.org

powercap/drivers/dtpm: Use container_of instead of a private data field

2021-10-21T14:03:31Z

The dtpm framework provides an API to allocate a dtpm node. However when a backend dtpm driver needs to allocate a dtpm node it must define its own structure and store the pointer of this structure in the private field of the dtpm structure. It is more elegant to use the container_of macro and add the dtpm structure inside the dtpm backend specific structure. The code will be able to deal properly with the dtpm structure as a generic entity, making all this even more self-encapsulated. The dtpm_alloc() function does no longer make sense as the dtpm structure will be allocated when allocating the device specific dtpm structure. The dtpm_init() is provided instead. Signed-off-by: Daniel Lezcano Reviewed-by: Lukasz Luba Link: https://lore.kernel.org/r/20210312130411.29833-4-daniel.lezcano@linaro.org