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

Revert "cpufreq: CPPC: Add support for frequency invariance"

2021-06-14T13:55:02+00:00

This reverts commit 4c38f2df71c8e33c0b64865992d693f5022eeaad.

There are few races in the frequency invariance support for CPPC driver,
namely the driver doesn't stop the kthread_work and irq_work on policy
exit during suspend/resume or CPU hotplug.

A proper fix won't be possible for the 5.13-rc, as it requires a lot of
changes. Lets revert the patch instead for now.

Fixes: 4c38f2df71c8 ("cpufreq: CPPC: Add support for frequency invariance")
Reported-by: Qian Cai 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: cppc: simplify default delay_us setting

2021-03-22T03:25:41+00:00

Simplify case when setting default in cppc_cpufreq_get_transition_delay_us.

Signed-off-by: Tom Saeger 
Signed-off-by: Viresh Kumar

cpufreq: CPPC: Add support for frequency invariance

2021-03-22T03:25:28+00:00

The Frequency Invariance Engine (FIE) is providing a frequency scaling
correction factor that helps achieve more accurate load-tracking.

Normally, this scaling factor can be obtained directly with the help of
the cpufreq drivers as they know the exact frequency the hardware is
running at. But that isn't the case for CPPC cpufreq driver.

Another way of obtaining that is using the arch specific counter
support, which is already present in kernel, but that hardware is
optional for platforms.

This patch updates the CPPC driver to register itself with the topology
core to provide its own implementation (cppc_scale_freq_tick()) of
topology_scale_freq_tick() which gets called by the scheduler on every
tick. Note that the arch specific counters have higher priority than
CPPC counters, if available, though the CPPC driver doesn't need to have
any special handling for that.

On an invocation of cppc_scale_freq_tick(), we schedule an irq work
(since we reach here from hard-irq context), which then schedules a
normal work item and cppc_scale_freq_workfn() updates the per_cpu
arch_freq_scale variable based on the counter updates since the last
tick.

To allow platforms to disable this CPPC counter-based frequency
invariance support, this is all done under CONFIG_ACPI_CPPC_CPUFREQ_FIE,
which is enabled by default.

This also exports sched_setattr_nocheck() as the CPPC driver can be
built as a module.

Cc: linux-acpi@vger.kernel.org
Reviewed-by: Ionela Voinescu 
Tested-by: Ionela Voinescu 
Tested-by: Vincent Guittot 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Viresh Kumar

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