linux-toradex.git/drivers/cpufreq/sh-cpufreq.c, branch v6.16

cpufreq: sh: Stop setting cpufreq_driver->attr field

2025-02-07T04:15:13+00:00

The cpufreq core now handles this for basic attributes, including boost
frequencies, the driver can skip setting them.

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

cpufreq: Make cpufreq_driver->exit() return void

2024-07-09T03:15:30+00:00

The cpufreq core doesn't check the return type of the exit() callback
and there is not much the core can do on failures at that point. Just
drop the returned value and make it return void.

Signed-off-by: Lizhe 
[ Viresh: Reworked the patches to fix all missing changes together. ]
Signed-off-by: Viresh Kumar 
Reviewed-by: AngeloGioacchino Del Regno  # Mediatek
Acked-by: Sudeep Holla  # scpi, scmi, vexpress
Acked-by: Mario Limonciello  # amd
Reviewed-by: Florian Fainelli  # bmips
Acked-by: Rafael J. Wysocki 
Acked-by: Kevin Hilman  # omap

cpufreq: sh: Remove sh_cpufreq_cpu_ready()

2021-09-02T16:04:17+00:00

The ->ready() callback is going away and since we don't do any important
stuff in sh_cpufreq_cpu_ready(), remove it.

Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: sh: Remove unused linux/sched.h headers

2021-06-07T15:38:26+00:00

Since commit '205dcc1ecbc5(cpufreq/sh: Replace racy task affinity logic)'
the header  is useless in sh-cpufreq.c, so remove it.

Signed-off-by: Hailong Liu 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: Avoid creating excessively large stack frames

2020-01-27T09:33:33+00:00

In the process of modifying a cpufreq policy, the cpufreq core makes
a copy of it including all of the internals which is stored on the
CPU stack.  Because struct cpufreq_policy is relatively large, this
may cause the size of the stack frame to exceed the 2 KB limit and
so the GCC complains when -Wframe-larger-than= is used.

In fact, it is not necessary to copy the entire policy structure
in order to modify it, however.

First, because cpufreq_set_policy() obtains the min and max policy
limits from frequency QoS now, it is not necessary to pass the limits
to it from the callers.  The only things that need to be passed to it
from there are the new governor pointer or (if there is a built-in
governor in the driver) the "policy" value representing the governor
choice.  They both can be passed as individual arguments, though, so
make cpufreq_set_policy() take them this way and rework its callers
accordingly.  This avoids making copies of cpufreq policies in the
callers of cpufreq_set_policy().

Second, cpufreq_set_policy() still needs to pass the new policy
data to the ->verify() callback of the cpufreq driver whose task
is to sanitize the min and max policy limits.  It still does not
need to make a full copy of struct cpufreq_policy for this purpose,
but it needs to pass a few items from it to the driver in case they
are needed (different drivers have different needs in that respect
and all of them have to be covered).  For this reason, introduce
struct cpufreq_policy_data to hold copies of the members of
struct cpufreq_policy used by the existing ->verify() driver
callbacks and pass a pointer to a temporary structure of that
type to ->verify() (instead of passing a pointer to full struct
cpufreq_policy to it).

While at it, notice that intel_pstate and longrun don't really need
to verify the "policy" value in struct cpufreq_policy, so drop those
check from them to avoid copying "policy" into struct
cpufreq_policy_data (which allows it to be slightly smaller).

Also while at it fix up white space in a couple of places and make
cpufreq_set_policy() static (as it can be so).

Fixes: 3000ce3c52f8 ("cpufreq: Use per-policy frequency QoS")
Link: https://lore.kernel.org/linux-pm/CAMuHMdX6-jb1W8uC2_237m8ctCpsnGp=JCxqt8pCWVqNXHmkVg@mail.gmail.com
Reported-by: kbuild test robot 
Reported-by: Geert Uytterhoeven 
Cc: 5.4+  # 5.4+
Signed-off-by: Rafael J. Wysocki 
Acked-by: Viresh Kumar

cpufreq: sh: Don't validate the frequency table twice

2018-03-20T11:07:52+00:00

The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from sh-cpufreq driver.

The driver though prints the min/max frequency values and the same is
done from the ->ready() callback now to keep the behavior unchanged.

Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: Add CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING cpufreq driver flag

2017-07-25T22:15:46+00:00

The policy->transition_latency field is used for multiple purposes
today and its not straight forward at all. This is how it is used:

A. Set the correct transition_latency value.

B. Set it to CPUFREQ_ETERNAL because:
   1. We don't want automatic dynamic switching (with
      ondemand/conservative) to happen at all.
   2. We don't know the transition latency.

This patch handles the B.1. case in a more readable way. A new flag for
the cpufreq drivers is added to disallow use of cpufreq governors which
have dynamic_switching flag set.

All the current cpufreq drivers which are setting transition_latency
unconditionally to CPUFREQ_ETERNAL are updated to use it. They don't
need to set transition_latency anymore.

There shouldn't be any functional change after this patch.

Signed-off-by: Viresh Kumar 
Reviewed-by: Dominik Brodowski 
Signed-off-by: Rafael J. Wysocki

cpufreq/sh: Replace racy task affinity logic

2017-04-15T10:20:55+00:00

The target() callback must run on the affected cpu. This is achieved by
temporarily setting the affinity of the calling thread to the requested CPU
and reset it to the original affinity afterwards.

That's racy vs. concurrent affinity settings for that thread resulting in
code executing on the wrong CPU.

Replace it by work_on_cpu(). All call pathes which invoke the callbacks are
already protected against CPU hotplug.

Signed-off-by: Thomas Gleixner 
Acked-by: Viresh Kumar 
Cc: Fenghua Yu 
Cc: Tony Luck 
Cc: Herbert Xu 
Cc: "Rafael J. Wysocki" 
Cc: Peter Zijlstra 
Cc: Benjamin Herrenschmidt 
Cc: Sebastian Siewior 
Cc: linux-pm@vger.kernel.org
Cc: Lai Jiangshan 
Cc: Michael Ellerman 
Cc: Tejun Heo 
Cc: "David S. Miller" 
Cc: Len Brown 
Link: http://lkml.kernel.org/r/20170412201042.958216363@linutronix.de
Signed-off-by: Thomas Gleixner

cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}

2014-03-26T15:41:41+00:00

CPUFreq core has new infrastructure that would guarantee serialized calls to
target() or target_index() callbacks. These are called
cpufreq_freq_transition_begin() and cpufreq_freq_transition_end().

This patch converts existing drivers to use these new set of routines.

Reviewed-by: Srivatsa S. Bhat 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: add 'freq_table' in struct cpufreq_policy

2014-03-12T00:06:00+00:00

freq table is not per CPU but per policy, so it makes more sense to
keep it within struct cpufreq_policy instead of a per-cpu variable.

This patch does it. Over that, there is no need to set policy->freq_table
to NULL in ->exit(), as policy structure is going to be freed soon.

Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki