lkml.org 
[lkml]   [2021]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 1/5] powercap/drivers/dtpm: Encapsulate even more the code
From
Date
Hi Daniel,

On 3/10/21 11:02 AM, Daniel Lezcano wrote:
> In order to increase the self-encapsulation of the dtpm generic code,
> the following changes are adding a power update ops to the dtpm
> ops. That allows the generic code to call directly the dtpm backend
> function to update the power values.
>
> The power update function does compute the power characteristics when
> the function is invoked. In the case of the CPUs, the power
> consumption depends on the number of online CPUs. The online CPUs mask
> is not up to date at CPUHP_AP_ONLINE_DYN state in the tear down
> callback. That is the reason why the online / offline are at separate
> state. As there is already an existing state for DTPM, this one is
> only moved to the DEAD state, so there is no addition of new state
> with these changes. The dtpm node is not removed when the cpu is
> unplugged.
>
> That simplifies the code for the next changes and results in a more
> self-encapsulated code.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
> V2:
> - Updated the changelog with the CPU node not being removed
> - Commented the cpu hotplug callbacks to explain why there are two callbacks
> - Changed 'upt_power_uw' to 'update_power_uw'
> - Removed unused cpumask variable
> ---
> drivers/powercap/dtpm.c | 54 ++++++-------
> drivers/powercap/dtpm_cpu.c | 148 ++++++++++++++++--------------------
> include/linux/cpuhotplug.h | 2 +-
> include/linux/dtpm.h | 3 +-
> 4 files changed, 97 insertions(+), 110 deletions(-)
>

[snip]

> @@ -210,27 +175,20 @@ static int cpuhp_dtpm_cpu_online(unsigned int cpu)
> for_each_cpu(cpu, policy->related_cpus)
> per_cpu(dtpm_per_cpu, cpu) = dtpm;
>
> - sprintf(name, "cpu%d", dtpm_cpu->cpu);
> + sprintf(name, "cpu%d-cpufreq", dtpm_cpu->cpu);

We should be safe in normal platforms, since there is less than
< 300 cores. although, I would use 2x CPUFREQ_NAME_LEN array.

Other than that

Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>

Regards,
Lukasz

\
 
 \ /
  Last update: 2021-03-11 11:16    [W:0.148 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site