11 Mar, 2016
2 commits
-
Create cpufreq.c under kernel/sched/ and move the cpufreq code
related to the scheduler to that file and to sched.h.Redefine cpufreq_update_util() as a static inline function to avoid
function calls at its call sites in the scheduler code (as suggested
by Peter Zijlstra).Also move the definition of struct update_util_data and declaration
of cpufreq_set_update_util_data() from include/linux/cpufreq.h to
include/linux/sched.h.Signed-off-by: Rafael J. Wysocki
Acked-by: Peter Zijlstra (Intel)
09 Mar, 2016
3 commits
-
The entire sequence of events (like INIT/START or STOP/EXIT) for which
cpufreq_governor() is called, is guaranteed to be protected by
policy->rwsem now.The additional checks that were added earlier (as we were forced to drop
policy->rwsem before calling cpufreq_governor() for EXIT event), aren't
required anymore.Over that, they weren't sufficient really. They just take care of
START/STOP events, but not INIT/EXIT and the state machine was never
maintained properly by them.Kill the unnecessary checks and policy->governor_enabled field.
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
Earlier, when the struct freq-attr was used to represent governor
attributes, the standard cpufreq show/store sysfs attribute callbacks
were applied to the governor tunable attributes and they always acquire
the policy->rwsem lock before carrying out the operation. That could
have resulted in an ABBA deadlock if governor tunable attributes are
removed under policy->rwsem while one of them is being accessed
concurrently (if sysfs attributes removal wins the race, it will wait
for the access to complete with policy->rwsem held while the attribute
callback will block on policy->rwsem indefinitely).We attempted to address this issue by dropping policy->rwsem around
governor tunable attributes removal (that is, around invocations of the
->governor callback with the event arg equal to CPUFREQ_GOV_POLICY_EXIT)
in cpufreq_set_policy(), but that opened up race conditions that had not
been possible with policy->rwsem held all the time.The previous commit, "cpufreq: governor: New sysfs show/store callbacks
for governor tunables", fixed the original ABBA deadlock by adding new
governor specific show/store callbacks.We don't have to drop rwsem around invocations of governor event
CPUFREQ_GOV_POLICY_EXIT anymore, and original fix can be reverted now.Fixes: 955ef4833574 (cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT)
Signed-off-by: Viresh Kumar
Reported-by: Juri Lelli
Tested-by: Juri Lelli
Tested-by: Shilpasri G Bhat
Signed-off-by: Rafael J. Wysocki -
Introduce a mechanism by which parts of the cpufreq subsystem
("setpolicy" drivers or the core) can register callbacks to be
executed from cpufreq_update_util() which is invoked by the
scheduler's update_load_avg() on CPU utilization changes.This allows the "setpolicy" drivers to dispense with their timers
and do all of the computations they need and frequency/voltage
adjustments in the update_load_avg() code path, among other things.The update_load_avg() changes were suggested by Peter Zijlstra.
Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar
Acked-by: Peter Zijlstra (Intel)
Acked-by: Ingo Molnar
27 Feb, 2016
1 commit
-
That macro uses an internal static inline function that is first
totally unnecessary and second hard to read, so simplify it and
get rid of that monster.No functional changes.
Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar
05 Feb, 2016
1 commit
-
The preprocessor magic used for setting the default cpufreq governor
(and for using the performance governor as a fallback one for that
matter) is really nasty, so replace it with __weak functions and
overrides.Signed-off-by: Rafael J. Wysocki
Acked-by: Saravana Kannan
Acked-by: Viresh Kumar
01 Jan, 2016
2 commits
-
Notice that the boost_supported field in struct cpufreq_driver is
redundant, because the driver's ->set_boost callback may be left
unset if "boost" is not supported. Moreover, the only driver
populating the ->set_boost callback is acpi_cpufreq, so make it
avoid populating that callback if "boost" is not supported, rework
the core to check ->set_boost instead of boost_supported to
verify "boost" support and drop boost_supported which isn't
used any more.Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar -
cpufreq_boost_supported() is not used outside of cpufreq.c, so make
it static.While at it, refactor it as a one-liner (which it really is).
Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar
03 Dec, 2015
1 commit
-
For cpufreq drivers which use setpolicy interface, after offline->online
the policy is set to default. This can be reproduced by setting the
default policy of intel_pstate or longrun to ondemand and then change to
"performance". After offline and online, the setpolicy will be called with
the policy=ondemand.For drivers using governors this condition is handled by storing
last_governor, during offline and restoring during online. The same should
be done for drivers using setpolicy interface. Storing last_policy during
offline and restoring during online.Signed-off-by: Srinivas Pandruvada
Signed-off-by: Rafael J. Wysocki
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
1 commit
-
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