linux-stable.git/drivers/cpufreq/cppc_cpufreq.c, branch v5.12.2

cppc_cpufreq: replace per-cpu data array with a list

2020-12-15T18:19:32+00:00

The cppc_cpudata per-cpu storage was inefficient (1) additional to causing
functional issues (2) when CPUs are hotplugged out, due to per-cpu data
being improperly initialised.

(1) The amount of information needed for CPPC performance control in its
    cpufreq driver depends on the domain (PSD) coordination type:

    ANY:    One set of CPPC control and capability data (e.g desired
            performance, highest/lowest performance, etc) applies to all
            CPUs in the domain.

    ALL:    Same as ANY. To be noted that this type is not currently
            supported. When supported, information about which CPUs
            belong to a domain is needed in order for frequency change
            requests to be sent to each of them.

    HW:     It's necessary to store CPPC control and capability
            information for all the CPUs. HW will then coordinate the
            performance state based on their limitations and requests.

    NONE:   Same as HW. No HW coordination is expected.

    Despite this, the previous initialisation code would indiscriminately
    allocate memory for all CPUs (all_cpu_data) and unnecessarily
    duplicate performance capabilities and the domain sharing mask and type
    for each possible CPU.

(2) With the current per-cpu structure, when having ANY coordination,
    the cppc_cpudata cpu information is not initialised (will remain 0)
    for all CPUs in a policy, other than policy->cpu. When policy->cpu is
    hotplugged out, the driver will incorrectly use the uninitialised (0)
    value of the other CPUs when making frequency changes. Additionally,
    the previous values stored in the perf_ctrls.desired_perf will be
    lost when policy->cpu changes.

Therefore replace the array of per cpu data with a list. The memory for
each structure is allocated at policy init, where a single structure
can be allocated per policy, not per cpu. In order to accommodate the
struct list_head node in the cppc_cpudata structure, the now unused cpu
and cur_policy variables are removed.

For example, on a arm64 Juno platform with 6 CPUs: (0, 1, 2, 3) in PSD1,
(4, 5) in PSD2 - ANY coordination, the memory allocation comparison shows:

Before patch:

 - ANY coordination:
   total    slack      req alloc/free  caller
       0        0        0     0/1     _kernel_size_le_hi32+0x0xffff800008ff7810
       0        0        0     0/6     _kernel_size_le_hi32+0x0xffff800008ff7808
     128       80       48     1/0     _kernel_size_le_hi32+0x0xffff800008ffc070
     768        0      768     6/0     _kernel_size_le_hi32+0x0xffff800008ffc0e4

After patch:

 - ANY coordination:
    total    slack      req alloc/free  caller
     256        0      256     2/0     _kernel_size_le_hi32+0x0xffff800008fed410
       0        0        0     0/2     _kernel_size_le_hi32+0x0xffff800008fed274

Additional notes:
 - A pointer to the policy's cppc_cpudata is stored in policy->driver_data
 - Driver registration is skipped if _CPC entries are not present.

Signed-off-by: Ionela Voinescu 
Tested-by: Mian Yousaf Kaukab 
Signed-off-by: Rafael J. Wysocki

cppc_cpufreq: expose information on frequency domains

2020-12-15T18:19:32+00:00

Use the existing sysfs attribute "freqdomain_cpus" to expose
information to userspace about CPUs in the same frequency domain.

Signed-off-by: Ionela Voinescu 
Acked-by: Viresh Kumar 
Tested-by: Mian Yousaf Kaukab 
Signed-off-by: Rafael J. Wysocki

cppc_cpufreq: clarify support for coordination types

2020-12-15T18:19:32+00:00

The previous coordination type handling in the cppc_cpufreq init code
created some confusion: the comment mentioned "Support only SW_ANY for
now" while only the SW_ALL/ALL case resulted in a failure. The other
coordination types (HW_ALL/HW, NONE) were silently supported.

Clarify support for coordination types while describing in comments the
intended behavior.

Signed-off-by: Ionela Voinescu 
Acked-by: Viresh Kumar 
Tested-by: Mian Yousaf Kaukab 
Signed-off-by: Rafael J. Wysocki

cppc_cpufreq: use policy->cpu as driver of frequency setting

2020-12-15T18:19:31+00:00

Considering only the currently supported coordination types (ANY, HW,
NONE), this change only makes a difference for the ANY type, when
policy->cpu is hotplugged out. In that case the new policy->cpu will
be different from ((struct cppc_cpudata *)policy->driver_data)->cpu.

While in this case the controls of *ANY* CPU could be used to drive
frequency changes, it's more consistent to use policy->cpu as the
leading CPU, as used in all other cppc_cpufreq functions. Additionally,
the debug prints in cppc_set_perf() would no longer create confusion
when referring to a CPU that is hotplugged out.

Signed-off-by: Ionela Voinescu 
Acked-by: Viresh Kumar 
Tested-by: Mian Yousaf Kaukab 
Signed-off-by: Rafael J. Wysocki

cppc_cpufreq: simplify use of performance capabilities

2020-11-17T14:57:09+00:00

The CPPC performance capabilities are used significantly throughout
the driver.

Simplify the use of them by introducing a local pointer "caps" to
point to cpu_data->perf_caps, in functions that access performance
capabilities often.

Signed-off-by: Ionela Voinescu 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cppc_cpufreq: clean up cpu, cpu_num and cpunum variable use

2020-11-17T14:57:09+00:00

In order to maintain the typical naming convention in the cpufreq
framework:

 - replace the use of "cpu" variable name for cppc_cpudata pointers
   with "cpu_data"
 - replace variable names "cpu_num" and "cpunum" with "cpu"
 - make cpu variables unsigned int

Where pertinent, also move the initialisation of cpu_data variable to
its declaration and make consistent use of the local "cpu" variable.

Signed-off-by: Ionela Voinescu 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cppc_cpufreq: fix misspelling, code style and readability issues

2020-11-17T14:57:09+00:00

Fix a few trivial issues in the cppc_cpufreq driver:

 - indentation of function arguments
 - consistent use of tabs (vs space) in defines
 - spelling: s/Offest/Offset, s/trasition/transition
 - order of local variables, from long pointers to structures to
   short ret and i (index) variables, to improve readability

Signed-off-by: Ionela Voinescu 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: CPPC: Reuse caps variable in few routines

2020-07-30T05:27:47+00:00

The 'caps' variable has been defined in cppc_cpufreq_khz_to_perf() and
cppc_cpufreq_perf_to_khz() routines, so there is no need to get
'highest_perf' value through 'cpu->caps.highest_perf', we can use
'caps->highest_perf' instead.

Signed-off-by: Xin Hao 
[ Viresh: Updated commit log ]
Signed-off-by: Viresh Kumar

cpufreq: cppc: Reorder code and remove apply_hisi_workaround variable

2020-07-30T05:27:46+00:00

With the current approach we have an extra check in the
cppc_cpufreq_get_rate() callback, which checks if hisilicon's get rate
implementation should be used instead. While it works fine, the approach
isn't very straight forward, over that we have an extra check in the
routine.

Rearrange code and update the cpufreq driver's get() callback pointer
directly for the hisilicon case. This gets the extra variable is removed
and the extra check isn't required anymore as well.

Tested-by: Xiongfeng Wang 
Signed-off-by: Viresh Kumar

cpufreq: CPPC: add SW BOOST support

2020-06-05T12:20:02+00:00

To add SW BOOST support for CPPC, we need to get the max frequency of
boost mode and non-boost mode. ACPI spec 6.2 section 8.4.7.1 describes
the following two CPC registers.

"Highest performance is the absolute maximum performance an individual
processor may reach, assuming ideal conditions. This performance level
may not be sustainable for long durations, and may only be achievable if
other platform components are in a specific state; for example, it may
require other processors be in an idle state.

Nominal Performance is the maximum sustained performance level of the
processor, assuming ideal operating conditions. In absence of an
external constraint (power, thermal, etc.) this is the performance level
the platform is expected to be able to maintain continuously. All
processors are expected to be able to sustain their nominal performance
state simultaneously."

To add SW BOOST support for CPPC, we can use Highest Performance as the
max performance in boost mode and Nominal Performance as the max
performance in non-boost mode. If the Highest Performance is greater
than the Nominal Performance, we assume SW BOOST is supported.

The current CPPC driver does not support SW BOOST and use 'Highest
Performance' as the max performance the CPU can achieve. 'Nominal
Performance' is used to convert 'performance' to 'frequency'. That
means, if firmware enable boost and provide a value for Highest
Performance which is greater than Nominal Performance, boost feature is
enabled by default.

Because SW BOOST is disabled by default, so, after this patch, boost
feature is disabled by default even if boost is enabled by firmware.

Signed-off-by: Xiongfeng Wang 
Suggested-by: Viresh Kumar 
Acked-by: Viresh Kumar 
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki