28 Oct, 2015
3 commits
-
The cpufreq sysfs interface had been a bit inconsistent as one of the
CPUs for a policy had a real directory within its sysfs 'cpuX' directory
and all other CPUs had links to it. That also made the code a bit
complex as we need to take care of moving the sysfs directory if the CPU
containing the real directory is getting physically hot-unplugged.Solve this by creating 'policyX' directories (per-policy) in
/sys/devices/system/cpu/cpufreq/ directory, where X is the CPU for which
the policy was first created.This also removes the need of keeping kobj_cpu and we can remove it now.
Suggested-by: Saravana Kannan
Signed-off-by: Viresh Kumar
Reviewed-by: Saravana Kannan
Acked-by: is more of a general agreement from the person that he is
Reviewed-by: is a more strict tag and implies that the reviewer has
Signed-off-by: Rafael J. Wysocki -
They don't do anything special now, remove the unnecessary wrapper.
Reviewed-by: Saravana Kannan
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
Later patches will need to create policy specific directories in
/sys/devices/system/cpu/cpufreq/ directory and so the cpufreq directory
wouldn't be ever empty.And so no fun creating/destroying it on need basis anymore. Create it
once on system boot.Reviewed-by: Saravana Kannan
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
16 Sep, 2015
1 commit
-
cpufreq_cpu_get() called by get_cur_freq_on_cpu() is overkill,
because the ->get() callback is always invoked in a context in
which all of the conditions checked by cpufreq_cpu_get() are
guaranteed to be satisfied.Use cpufreq_cpu_get_raw() instead of it and drop the
corresponding cpufreq_cpu_put() from get_cur_freq_on_cpu().Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar
01 Sep, 2015
5 commits
-
* pm-opp:
PM / OPP: Drop unlikely before IS_ERR(_OR_NULL)
PM / OPP: Fix static checker warning (broken 64bit big endian systems)
PM / OPP: Free resources and properly return error on failure
cpufreq-dt: make scaling_boost_freqs sysfs attr available when boost is enabled
cpufreq: dt: Add support for turbo/boost mode
cpufreq: dt: Add support for operating-points-v2 bindings
cpufreq: Allow drivers to enable boost support after registering driver
cpufreq: Update boost flag while initializing freq table from OPPs
PM / OPP: add dev_pm_opp_is_turbo() helper
PM / OPP: Add helpers for initializing CPU OPPs
PM / OPP: Add support for opp-suspend
PM / OPP: Add OPP sharing information to OPP library
PM / OPP: Add clock-latency-ns support
PM / OPP: Add support to parse "operating-points-v2" bindings
PM / OPP: Break _opp_add_dynamic() into smaller functions
PM / OPP: Allocate dev_opp from _add_device_opp()
PM / OPP: Create _remove_device_opp() for freeing dev_opp
PM / OPP: Relocate few routines
PM / OPP: Create a directory for opp bindings
PM / OPP: Update bindings to make opp-hz a 64 bit value -
Its all about caching min/max freq requested by userspace, and
the name 'cpufreq_real_policy' doesn't fit that well. Rename it to
cpufreq_user_policy.Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
Its always same as policy->policy, and there is no need to keep another
copy of it. Remove it.Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
Its always same as policy->governor, and there is no need to keep
another copy of it. Remove it.Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
What's being done from CPUFREQ_INCOMPATIBLE, can also be done with
CPUFREQ_ADJUST. There is nothing special with CPUFREQ_INCOMPATIBLE
notifier.Kill CPUFREQ_INCOMPATIBLE and fix its usage sites.
This also updates the numbering of notifier events to remove holes.
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
08 Aug, 2015
1 commit
-
Make scaling_boost_freqs sysfs attribute is available when
cpufreq-dt driver is used and boost support is enabled.Suggested-by: Viresh Kumar
Acked-by: Viresh Kumar
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Rafael J. Wysocki
07 Aug, 2015
1 commit
-
In some cases it wouldn't be known at time of driver registration, if
the driver needs to support boost frequencies.For example, while getting boost information from DT with opp-v2
bindings, we need to parse the bindings for all the CPUs to know if
turbo/boost OPPs are supported or not.One way out to do that efficiently is to delay supporting boost mode
(i.e. creating /sys/devices/system/cpu/cpufreq/boost file), until the
time OPP bindings are parsed.At that point, the driver can enable boost support. This can be done at
->init(), where the frequency table is created.To do that, the driver requires few APIs from cpufreq core that let him
do this. This patch provides these APIs.Signed-off-by: Viresh Kumar
Reviewed-by: Stephen Boyd
Signed-off-by: Rafael J. Wysocki
28 Jul, 2015
1 commit
-
After commit 87549141d516 (cpufreq: Stop migrating sysfs files on
hotplug) there is a problem with CPUs that share cpufreq policy
objects with other CPUs and are initially offline.Say CPU1 shares a policy with CPU0 which is online and is registered
first. As part of the registration process, cpufreq_add_dev() is
called for it. It creates the policy object and a symbolic link
to it from the CPU1's sysfs directory. If CPU1 is registered
subsequently and it is offline at that time, cpufreq_add_dev() will
attempt to create a symbolic link to the policy object for it, but
that link is present already, so a warning about that will be
triggered.To avoid that warning, make cpufreq use an additional CPU mask
containing related CPUs that are actually present for each policy
object. That mask is initialized when the policy object is populated
after its creation (for the first online CPU using it) and it includes
CPUs from the "policy CPUs" mask returned by the cpufreq driver's
->init() callback that are physically present at that time. Symbolic
links to the policy are created only for the CPUs in that mask.If cpufreq_add_dev() is invoked for an offline CPU, it checks the
new mask and only creates the symlink if the CPU was not in it (the
CPU is added to the mask at the same time).In turn, cpufreq_remove_dev() drops the given CPU from the new mask,
removes its symlink to the policy object and returns, unless it is
the CPU owning the policy object. In that case, the policy object
is moved to a new CPU's sysfs directory or deleted if the CPU being
removed was the last user of the policy.While at it, notice that cpufreq_remove_dev() can't fail, because
its return value is ignored, so make it ignore return values from
__cpufreq_remove_dev_prepare() and __cpufreq_remove_dev_finish()
and prevent these functions from aborting on errors returned by
__cpufreq_governor(). Also drop the now unused sif argument from
them.Fixes: 87549141d516 (cpufreq: Stop migrating sysfs files on hotplug)
Signed-off-by: Rafael J. Wysocki
Reported-and-tested-by: Russell King
Acked-by: Viresh Kumar
23 May, 2015
1 commit
-
In order to prepare for the next few commits, that will stop migrating
sysfs files on cpu hotplug, this patch starts managing sysfs-cpu
separately.The behavior is still the same as we are still migrating sysfs files on
hotplug, later commits would change that.Signed-off-by: Saravana Kannan
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
15 May, 2015
1 commit
-
History of which governor was used last is common to all CPUs within a
policy and maintaining it per-cpu isn't the best approach for sure.Apart from wasting memory, this also increases the complexity of
managing this data structure as it has to be updated for all CPUs.To make that somewhat simpler, lets store this information in a new
field 'last_governor' in struct cpufreq_policy and update it on removal
of last cpu of a policy.As a side-effect it also solves an old problem, consider a system with
two clusters 0 & 1. And there is one policy per cluster.Cluster 0: CPU0 and 1.
Cluster 1: CPU2 and 3.- CPU2 is first brought online, and governor is set to performance
(default as cpufreq_cpu_governor wasn't set).
- Governor is changed to ondemand.
- CPU2 is taken offline and cpufreq_cpu_governor is updated for CPU2.
- CPU3 is brought online.
- Because cpufreq_cpu_governor wasn't set for CPU3, the default governor
performance is picked for CPU3.This patch fixes the bug as we now have a single variable to update for
policy.Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
24 Jan, 2015
3 commits
-
CPUFREQ_UPDATE_POLICY_CPU notifications were used only from cpufreq-stats which
doesn't use it anymore. Remove them.This also decrements values of other notification macros defined after
CPUFREQ_UPDATE_POLICY_CPU by 1 to remove gaps. Hopefully all users are using
macro's instead of direct numbers and so they wouldn't break as macro values are
changed now.Reviewed-by: Prarit Bhargava
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
'last_cpu' was used only from cpufreq-stats and isn't used anymore. Get rid of
it.Reviewed-by: Prarit Bhargava
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
All CPUs sharing a cpufreq policy share stats too. For this reason,
add a stats pointer to struct cpufreq_policy and drop per-CPU variable
cpufreq_stats_table used for accessing cpufreq stats so as to reduce
code complexity.Reviewed-by: Prarit Bhargava
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
30 Nov, 2014
2 commits
-
Currently there is no callback for cpufreq drivers which is called once the
policy is ready to be used. There are some requirements where such a callback is
required.One of them is registering a cooling device with the help of
of_cpufreq_cooling_register(). This routine tries to get 'struct cpufreq_policy'
for CPUs which isn't yet initialed at the time ->init() is called and so we face
issues while registering the cooling device.Because we can't register cooling device from ->init(), we need a callback that
is called after the policy is ready to be used and hence we introduce ->ready()
callback.Signed-off-by: Viresh Kumar
Reviewed-by: Eduardo Valentin
Tested-by: Eduardo Valentin
Reviewed-by: Lukasz Majewski
Signed-off-by: Rafael J. Wysocki -
Adding any new callback to 'struct cpufreq_driver' gives following checkpatch
warning:WARNING: Unnecessary space before function pointer arguments
+ void (*ready) (struct cpufreq_policy *policy);This is because we have been using a tab spacing between function pointer name
and its arguments and the new one tried to follow that.Though we normally don't try to fix every checkpatch warning, specially around
formatting issues as that creates unnecessary noise over lists. But I thought we
better fix this so that new additions don't generate these warnings plus it
looks far better/symmetric now.So, remove these tab spacing issues in 'struct cpufreq_driver' only + fix
alignment of all members.Signed-off-by: Viresh Kumar
Reviewed-by: Eduardo Valentin
Tested-by: Eduardo Valentin
Signed-off-by: Rafael J. Wysocki
21 Oct, 2014
1 commit
-
This commit extends the cpufreq_driver structure with an additional
'void *driver_data' field that can be filled by the ->probe() function
of a cpufreq driver to pass additional custom information to the
driver itself.A new function called cpufreq_get_driver_data() is added to allow a
cpufreq driver to retrieve those driver data, since they are typically
needed from a cpufreq_policy->init() callback, which does not have
access to the cpufreq_driver structure. This function call is similar
to the existing cpufreq_get_current_driver() function call.Signed-off-by: Thomas Petazzoni
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
09 Sep, 2014
1 commit
-
Drivers supporting multiple clusters or multiple 'struct cpufreq_policy'
instances may need to keep per-policy data. If the core doesn't provide support
for that, they might do it in the most unoptimized way: 'per-cpu' data.This patch adds another field in struct cpufreq_policy: 'driver_data'. It isn't
accessed by core and is for driver's internal use only.Tested-by: Stephen Boyd
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
21 Jul, 2014
1 commit
-
Introduce CPUFREQ_RELATION_C for frequency selection.
It selects the frequency with the minimum euclidean distance to target.
In case of equal distance between 2 frequencies, it will select the
greater frequency.Signed-off-by: Stratos Karafotis
Signed-off-by: Rafael J. Wysocki
18 Jul, 2014
1 commit
-
Commit 5eeaf1f18973 (cpufreq: Fix build error on some platforms that
use cpufreq_for_each_*) moved function cpufreq_next_valid() to a public
header. Warnings are now generated when objects including that header
are built with -Wsign-compare (as an out-of-tree module might be):.../include/linux/cpufreq.h: In function ‘cpufreq_next_valid’:
.../include/linux/cpufreq.h:519:27: warning: comparison between signed
and unsigned integer expressions [-Wsign-compare]
while ((*pos)->frequency != CPUFREQ_TABLE_END)
^
.../include/linux/cpufreq.h:520:25: warning: comparison between signed
and unsigned integer expressions [-Wsign-compare]
if ((*pos)->frequency != CPUFREQ_ENTRY_INVALID)
^Constants CPUFREQ_ENTRY_INVALID and CPUFREQ_TABLE_END are signed, but
are used with unsigned member 'frequency' of cpufreq_frequency_table.
Update the macro definitions to be explicitly unsigned to match their
use.This also corrects potentially wrong behavior of clk_rate_table_iter()
if unsigned long is wider than usigned int.Fixes: 5eeaf1f18973 (cpufreq: Fix build error on some platforms that use cpufreq_for_each_*)
Signed-off-by: Brian W Hart
Reviewed-by: Simon Horman
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
06 Jun, 2014
1 commit
-
Douglas Anderson, recently pointed out an interesting problem due to which
udelay() was expiring earlier than it should.While transitioning between frequencies few platforms may temporarily switch to
a stable frequency, waiting for the main PLL to stabilize.For example: When we transition between very low frequencies on exynos, like
between 200MHz and 300MHz, we may temporarily switch to a PLL running at 800MHz.
No CPUFREQ notification is sent for that. That means there's a period of time
when we're running at 800MHz but loops_per_jiffy is calibrated at between 200MHz
and 300MHz. And so udelay behaves badly.To get this fixed in a generic way, introduce another set of callbacks
get_intermediate() and target_intermediate(), only for drivers with
target_index() and CPUFREQ_ASYNC_NOTIFICATION unset.get_intermediate() should return a stable intermediate frequency platform wants
to switch to, and target_intermediate() should set CPU to that frequency,
before jumping to the frequency corresponding to 'index'. Core will take care of
sending notifications and driver doesn't have to handle them in
target_intermediate() or target_index().NOTE: ->target_index() should restore to policy->restore_freq in case of
failures as core would send notifications for that.Tested-by: Stephen Warren
Signed-off-by: Viresh Kumar
Reviewed-by: Doug Anderson
Signed-off-by: Rafael J. Wysocki
08 May, 2014
1 commit
-
On platforms that use cpufreq_for_each_* macros, build fails if
CONFIG_CPU_FREQ=n, e.g. ARM/shmobile/koelsch/non-multiplatform:drivers/built-in.o: In function `clk_round_parent':
clkdev.c:(.text+0xcf168): undefined reference to `cpufreq_next_valid'
drivers/built-in.o: In function `clk_rate_table_find':
clkdev.c:(.text+0xcf820): undefined reference to `cpufreq_next_valid'
make[3]: *** [vmlinux] Error 1Fix this making cpufreq_next_valid function inline and move it to
cpufreq.h.Fixes: 27e289dce297 (cpufreq: Introduce macros for cpufreq_frequency_table iteration)
Reported-and-tested-by: Geert Uytterhoeven
Signed-off-by: Stratos Karafotis
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
07 May, 2014
2 commits
-
CPUFreq specific helper functions for OPP (Operating Performance Points)
now use generic OPP functions that allow CPUFreq to be be moved back
into CPUFreq framework. This allows for independent modifications
or future enhancements as needed isolated to just CPUFreq framework
alone.Here, we just move relevant code and documentation to make this part of
CPUFreq infrastructure.Cc: Kevin Hilman
Signed-off-by: Nishanth Menon
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
Some cpufreq drivers were redundantly invoking the _begin() and _end()
APIs around frequency transitions, and this double invocation (one from
the cpufreq core and the other from the cpufreq driver) used to result
in a self-deadlock, leading to system hangs during boot. (The _begin()
API makes contending callers wait until the previous invocation is
complete. Hence, the cpufreq driver would end up waiting on itself!).Now all such drivers have been fixed, but debugging this issue was not
very straight-forward (even lockdep didn't catch this). So let us add a
debug infrastructure to the cpufreq core to catch such issues more easily
in the future.We add a new field called 'transition_task' to the policy structure, to keep
track of the task which is performing the frequency transition. Using this
field, we make note of this task during _begin() and print a warning if we
find a case where the same task is calling _begin() again, before completing
the previous frequency transition using the corresponding _end().We have left out ASYNC_NOTIFICATION drivers from this debug infrastructure
for 2 reasons:1. At the moment, we have no way to avoid a particular scenario where this
debug infrastructure can emit false-positive warnings for such drivers.
The scenario is depicted below:Task A Task B
/* 1st freq transition */
Invoke _begin() {
...
...
}Change the frequency
/* 2nd freq transition */
Invoke _begin() {
... //waiting for B to
... //finish _end() for
... //the 1st transition
... | Got interrupt for successful
... | change of frequency (1st one).
... |
... | /* 1st freq transition */
... | Invoke _end() {
... | ...
... V }
...
...
}This scenario is actually deadlock-free because, once Task A changes the
frequency, it is Task B's responsibility to invoke the corresponding
_end() for the 1st frequency transition. Hence it is perfectly legal for
Task A to go ahead and attempt another frequency transition in the meantime.
(Of course it won't be able to proceed until Task B finishes the 1st _end(),
but this doesn't cause a deadlock or a hang).The debug infrastructure cannot handle this scenario and will treat it as
a deadlock and print a warning. To avoid this, we exclude such drivers
from the purview of this code.2. Luckily, we don't _need_ this infrastructure for ASYNC_NOTIFICATION drivers
at all! The cpufreq core does not automatically invoke the _begin() and
_end() APIs during frequency transitions in such drivers. Thus, the driver
alone is responsible for invoking _begin()/_end() and hence there shouldn't
be any conflicts which lead to double invocations. So, we can skip these
drivers, since the probability that such drivers will hit this problem is
extremely low, as outlined above.Signed-off-by: Srivatsa S. Bhat
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
30 Apr, 2014
1 commit
-
Many cpufreq drivers need to iterate over the cpufreq_frequency_table
for various tasks.This patch introduces two macros which can be used for iteration over
cpufreq_frequency_table keeping a common coding style across drivers:- cpufreq_for_each_entry: iterate over each entry of the table
- cpufreq_for_each_valid_entry: iterate over each entry that contains
a valid frequency.It should have no functional changes.
Signed-off-by: Stratos Karafotis
Acked-by: Lad, Prabhakar
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
07 Apr, 2014
1 commit
-
Currently cpufreq frequency table has two fields: frequency and driver_data.
driver_data is only for drivers' internal use and cpufreq core shouldn't use
it at all. But with the introduction of BOOST frequencies, this assumption
was broken and we started using it as a flag instead.There are two problems due to this:
- It is against the description of this field, as driver's data is used by
the core now.
- if drivers fill it with -3 for any frequency, then those frequencies are
never considered by cpufreq core as it is exactly same as value of
CPUFREQ_BOOST_FREQ, i.e. ~2.The best way to get this fixed is by creating another field flags which
will be used for such flags. This patch does that. Along with that various
drivers need modifications due to the change of struct cpufreq_frequency_table.Reviewed-by: Gautham R Shenoy
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
26 Mar, 2014
2 commits
-
cpufreq_notify_transition() and cpufreq_notify_post_transition() shouldn't be
called directly by cpufreq drivers anymore and so these should be marked static.Reviewed-by: Srivatsa S. Bhat
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
Whenever we change the frequency of a CPU, we call the PRECHANGE and POSTCHANGE
notifiers. They must be serialized, i.e. PRECHANGE and POSTCHANGE notifiers
should strictly alternate, thereby preventing two different sets of PRECHANGE or
POSTCHANGE notifiers from interleaving arbitrarily.The following examples illustrate why this is important:
Scenario 1:
-----------
A thread reading the value of cpuinfo_cur_freq, will call
__cpufreq_cpu_get()->cpufreq_out_of_sync()->cpufreq_notify_transition()The ondemand governor can decide to change the frequency of the CPU at the same
time and hence it can end up sending the notifications via ->target().If the notifiers are not serialized, the following sequence can occur:
- PRECHANGE Notification for freq A (from cpuinfo_cur_freq)
- PRECHANGE Notification for freq B (from target())
- Freq changed by target() to B
- POSTCHANGE Notification for freq B
- POSTCHANGE Notification for freq AWe can see from the above that the last POSTCHANGE Notification happens for freq
A but the hardware is set to run at freq B.Where would we break then?: adjust_jiffies() in cpufreq.c & cpufreq_callback()
in arch/arm/kernel/smp.c (which also adjusts the jiffies). All the
loops_per_jiffy calculations will get messed up.Scenario 2:
-----------
The governor calls __cpufreq_driver_target() to change the frequency. At the
same time, if we change scaling_{min|max}_freq from sysfs, it will end up
calling the governor's CPUFREQ_GOV_LIMITS notification, which will also call
__cpufreq_driver_target(). And hence we end up issuing concurrent calls to
->target().Typically, platforms have the following logic in their ->target() routines:
(Eg: cpufreq-cpu0, omap, exynos, etc)A. If new freq is more than old: Increase voltage
B. Change freq
C. If new freq is less than old: decrease voltageNow, if the two concurrent calls to ->target() are X and Y, where X is trying to
increase the freq and Y is trying to decrease it, we get the following race
condition:X.A: voltage gets increased for larger freq
Y.A: nothing happens
Y.B: freq gets decreased
Y.C: voltage gets decreased
X.B: freq gets increased
X.C: nothing happensThus we can end up setting a freq which is not supported by the voltage we have
set. That will probably make the clock to the CPU unstable and the system might
not work properly anymore.This patch introduces a set of synchronization primitives to serialize frequency
transitions, which are to be used as shown below:cpufreq_freq_transition_begin();
//Perform the frequency change
cpufreq_freq_transition_end();
The _begin() call sends the PRECHANGE notification whereas the _end() call sends
the POSTCHANGE notification. Also, all the necessary synchronization is handled
within these calls. In particular, even drivers which set the ASYNC_NOTIFICATION
flag can also use these APIs for performing frequency transitions (ie., you can
call _begin() from one task, and call the corresponding _end() from a different
task).The actual synchronization underneath is not that complicated:
The key challenge is to allow drivers to begin the transition from one thread
and end it in a completely different thread (this is to enable drivers that do
asynchronous POSTCHANGE notification from bottom-halves, to also use the same
interface).To achieve this, a 'transition_ongoing' flag, a 'transition_lock' spinlock and a
wait-queue are added per-policy. The flag and the wait-queue are used in
conjunction to create an "uninterrupted flow" from _begin() to _end(). The
spinlock is used to ensure that only one such "flow" is in flight at any given
time. Put together, this provides us all the necessary synchronization.Signed-off-by: Srivatsa S. Bhat
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
20 Mar, 2014
1 commit
-
This callback allows the driver to do clean up before the CPU is
completely down and its state cannot be modified. This is used
by the intel_pstate driver to reduce the requested P state prior to
the core going away. This is required because the requested P state
of the offline core is used to select the package P state. This
effectively sets the floor package P state to the requested P state on
the offline core.Signed-off-by: Dirk Brandewie
[rjw: Minor modifications]
Signed-off-by: Rafael J. Wysocki
19 Mar, 2014
1 commit
-
Two cpufreq notifiers CPUFREQ_RESUMECHANGE and CPUFREQ_SUSPENDCHANGE have
not been used for some time, so remove them to clean up code a bit.Signed-off-by: Viresh Kumar
Reviewed-by: Srivatsa S. Bhat
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki
12 Mar, 2014
2 commits
-
cpufreq_generic_exit() is empty now and can be deleted.
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
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
06 Mar, 2014
2 commits
-
Multiple platforms need to set CPUs to a particular frequency before
suspending the system, so provide a common infrastructure for them.Those platforms only need to point their ->suspend callback pointers
to the generic routine.Tested-by: Stephen Warren
Signed-off-by: Viresh Kumar
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki -
This patch adds cpufreq suspend/resume calls to dpm_{suspend|resume}()
for handling suspend/resume of cpufreq governors.Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found an issue where the
tunables configuration for clusters/sockets with non-boot CPUs was
lost after system suspend/resume, as we were notifying governors with
CPUFREQ_GOV_POLICY_EXIT on removal of the last CPU for that policy
which caused the tunables memory to be freed.This is fixed by preventing any governor operations from being
carried out between the device suspend and device resume stages of
system suspend and resume, respectively.We could have added these callbacks at dpm_{suspend|resume}_noirq()
level, but there is an additional problem that the majority of I/O
devices is already suspended at that point and if cpufreq drivers
want to change the frequency before suspending, then that not be
possible on some platforms (which depend on peripherals like i2c,
regulators, etc).Reported-and-tested-by: Lan Tianyu
Reported-by: Jinhyuk Choi
Signed-off-by: Viresh Kumar
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki
17 Jan, 2014
3 commits
-
This commit adds boost frequency support in cpufreq core (Hardware &
Software). Some SoCs (like Exynos4 - e.g. 4x12) allow setting frequency
above its normal operation limits. Such mode shall be only used for a
short time.Overclocking (boost) support is essentially provided by platform
dependent cpufreq driver.This commit unifies support for SW and HW (Intel) overclocking solutions
in the core cpufreq driver. Previously the "boost" sysfs attribute was
defined in the ACPI processor driver code. By default boost is disabled.
One global attribute is available at: /sys/devices/system/cpu/cpufreq/boost.It only shows up when cpufreq driver supports overclocking.
Under the hood frequencies dedicated for boosting are marked with a
special flag (CPUFREQ_BOOST_FREQ) at driver's frequency table.
It is the user's concern to enable/disable overclocking with a proper call
to sysfs.The cpufreq_boost_trigger_state() function is defined non static on purpose.
It is used later with thermal subsystem to provide automatic enable/disable
of the BOOST feature.Signed-off-by: Lukasz Majewski
Signed-off-by: Myungjoo Ham
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
CPUFreq drivers that use clock frameworks interface,i.e. clk_get_rate(),
to get CPUs clk rate, have similar sort of code used in most of them.This patch adds a generic ->get() which will do the same thing for them.
All those drivers are required to now is to set .get to cpufreq_generic_get()
and set their clk pointer in policy->clk during ->init().Acked-by: Hans-Christian Egtvedt
Acked-by: Shawn Guo
Acked-by: Linus Walleij
Acked-by: Shawn Guo
Acked-by: Stephen Warren
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
There are several problems with cpufreq stats in the way it handles
cpufreq_unregister_driver() and suspend/resume..- We must not lose data collected so far when suspend/resume happens
and so stats directories must not be removed/allocated during these
operations, which is done currently.- cpufreq_stat has registered notifiers with both cpufreq and hotplug.
It adds sysfs stats directory with a cpufreq notifier: CPUFREQ_NOTIFY
and removes this directory with a notifier from hotplug core.In case cpufreq_unregister_driver() is called (on rmmod cpufreq driver),
stats directories per cpu aren't removed as CPUs are still online. The
only call cpufreq_stats gets is cpufreq_stats_update_policy_cpu() for
all CPUs except the last of each policy. And pointer to stat information
is stored in the entry for last CPU in the per-cpu cpufreq_stats_table.
But policy structure would be freed inside cpufreq core and so that will
result in memory leak inside cpufreq stats (as we are never freeing
memory for stats).Now if we again insert the module cpufreq_register_driver() will be
called and we will again allocate stats data and put it on for first
CPU of every policy. In case we only have a single CPU per policy, we
will return with a error from cpufreq_stats_create_table() due to this
code:if (per_cpu(cpufreq_stats_table, cpu))
return -EBUSY;And so probably cpufreq stats directory would not show up anymore (as
it was added inside last policies->kobj which doesn't exist anymore).
I haven't tested it, though. Also the values in stats files wouldn't
be refreshed as we are using the earlier stats structure.- CPUFREQ_NOTIFY is called from cpufreq_set_policy() which is called for
scenarios where we don't really want cpufreq_stat_notifier_policy() to get
called. For example whenever we are changing anything related to a policy:
min/max/current freq, etc. cpufreq_set_policy() is called and so cpufreq
stats is notified. Where we don't do any useful stuff other than simply
returning with -EBUSY from cpufreq_stats_create_table(). And so this
isn't the right notifier that cpufreq stats..Due to all above reasons this patch does following changes:
- Add new notifiers CPUFREQ_CREATE_POLICY and CPUFREQ_REMOVE_POLICY,
which are only called when policy is created/destroyed. They aren't
called for suspend/resume paths..
- Use these notifiers in cpufreq_stat_notifier_policy() to create/destory
stats sysfs entries. And so cpufreq_unregister_driver() or suspend/resume
shouldn't be a problem for cpufreq_stats.
- Return early from cpufreq_stat_cpu_callback() for suspend/resume sequence,
so that we don't free stats structure.Acked-by: Nicolas Pitre
Tested-by: Nicolas Pitre
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
