21 Dec, 2016
1 commit
-
s3c64xx_cpufreq_config_regulator is incorrectly annotated
as __init, since the caller is also not init:WARNING: vmlinux.o(.text+0x92fe1c): Section mismatch in reference from the function s3c64xx_cpufreq_driver_init() to the function .init.text:s3c64xx_cpufreq_config_regulator()
With modern gcc versions, the function gets inline, so we don't
see the warning, this only happens with gcc-4.6 and older.Signed-off-by: Arnd Bergmann
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Rafael J. Wysocki
30 Apr, 2014
1 commit
-
The cpufreq core now supports the cpufreq_for_each_entry and
cpufreq_for_each_valid_entry macros helpers for iteration over the
cpufreq_frequency_table, so use them.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
17 Jan, 2014
1 commit
-
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
06 Jan, 2014
1 commit
-
Sometimes boot loaders set CPU frequency to a value outside of frequency table
present with cpufreq core. In such cases CPU might be unstable if it has to run
on that frequency for long duration of time and so its better to set it to a
frequency which is specified in frequency table.On some systems we can't really say what frequency we're running at the moment
and so for these we shouldn't check if we are running at a frequency present in
frequency table. And so we really can't force this for all the cpufreq drivers.Hence we are created another flag here: CPUFREQ_NEED_INITIAL_FREQ_CHECK that
will be marked by platforms which want to go for this check at boot time.Initially this is done for all ARM platforms but others may follow if required.
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
31 Oct, 2013
1 commit
-
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.There are few special cases though, like exynos5440, which doesn't do everything
on the call to ->target_index() routine and call some kind of bottom halves for
doing this work, work/tasklet/etc..They may continue doing notification from their own code as flag:
CPUFREQ_ASYNC_NOTIFICATION is already set for them.All drivers are also modified in this patch to avoid breaking 'git bisect', as
double notification would happen otherwise.Acked-by: Hans-Christian Egtvedt
Acked-by: Jesper Nilsson
Acked-by: Linus Walleij
Acked-by: Russell King
Acked-by: Stephen Warren
Tested-by: Andrew Lunn
Tested-by: Nicolas Pitre
Reviewed-by: Lan Tianyu
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
26 Oct, 2013
2 commits
-
Currently, the prototype of cpufreq_drivers target routines is:
int target(struct cpufreq_policy *policy, unsigned int target_freq,
unsigned int relation);And most of the drivers call cpufreq_frequency_table_target() to get a valid
index of their frequency table which is closest to the target_freq. And they
don't use target_freq and relation after that.So, it makes sense to just do this work in cpufreq core before calling
cpufreq_frequency_table_target() and simply pass index instead. But this can be
done only with drivers which expose their frequency table with cpufreq core. For
others we need to stick with the old prototype of target() until those drivers
are converted to expose frequency tables.This patch implements the new light weight prototype for target_index() routine.
It looks like this:int target_index(struct cpufreq_policy *policy, unsigned int index);
CPUFreq core will call cpufreq_frequency_table_target() before calling this
routine and pass index to it. Because CPUFreq core now requires to call routines
present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time.This also marks target() interface as deprecated. So, that new drivers avoid
using it. And Documentation is updated accordingly.It also converts existing .target() to newly defined light weight
.target_index() routine for many driver.Acked-by: Hans-Christian Egtvedt
Acked-by: Jesper Nilsson
Acked-by: Linus Walleij
Acked-by: Russell King
Acked-by: David S. Miller
Tested-by: Andrew Lunn
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
Conflicts:
drivers/cpufreq/omap-cpufreq.c
17 Oct, 2013
1 commit
-
The index field of cpufreq_frequency_table has been renamed to
driver_data by commit 5070158 (cpufreq: rename index as driver_data
in cpufreq_frequency_table).This patch updates the s3c64xx driver to match.
Signed-off-by: Charles Keepax
Cc: 3.11+ # 3.11+
Signed-off-by: Rafael J. Wysocki
16 Oct, 2013
3 commits
-
Use generic cpufreq_generic_init() routine instead of replicating the same code
here.Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
Many common initializations of struct policy are moved to core now and hence
this driver doesn't need to do it. This patch removes such code.Most recent of those changes is to call ->get() in the core after calling
->init().Cc: Kukjin Kim
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.This patch uses these generic routines in the s3cx4xx driver.
Signed-off-by: Viresh Kumar
Acked-by: Kukjin Kim
Signed-off-by: Rafael J. Wysocki
01 Oct, 2013
2 commits
-
Lets use cpufreq_table_validate_and_show() instead of calling
cpufreq_frequency_table_cpuinfo() and cpufreq_frequency_table_get_attr().Cc: Kukjin Kim
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
This exposes frequency table of driver to cpufreq core and is required for core
to guess what the index for a target frequency is, when it calls
cpufreq_frequency_table_target(). And so this driver needs to expose it.Cc: Kukjin Kim
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
10 Aug, 2013
1 commit
-
We don't need to set .owner = THIS_MODULE any more in cpufreq drivers
as this field isn't used any more by the cpufreq core.This patch removes it and updates all dependent drivers accordingly.
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
28 Jun, 2013
1 commit
-
* pm-cpufreq-arm:
cpufreq: tegra: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: s3c64xx: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: omap: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: imx6q: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: exynos: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: dbx500: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: davinci: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: arm-big-little: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: s3c2416: fix forgotten driver_data conversions
24 Jun, 2013
1 commit
-
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both
should be called or both shouldn't be.In case we have started PRECHANGE notifier and found an error, we must call
POSTCHANGE notifier with freqs.new = freqs.old to guarantee that sequence of
calling notifiers is complete.This patch fixes it.
Cc: Mark Brown
Signed-off-by: Viresh Kumar
04 Jun, 2013
1 commit
-
The "index" field of struct cpufreq_frequency_table was never an
index and isn't used at all by the cpufreq core. It only is useful
for cpufreq drivers for their internal purposes.Many people nowadays blindly set it in ascending order with the
assumption that the core will use it, which is a mistake.Rename it to "driver_data" as that's what its purpose is. All of its
users are updated accordingly.[rjw: Changelog]
Signed-off-by: Viresh Kumar
Acked-by: Simon Horman
Signed-off-by: Rafael J. Wysocki
02 Apr, 2013
1 commit
-
policy->cpus contains all online cpus that have single shared clock line. And
their frequencies are always updated together.Many SMP system's cpufreq drivers take care of this in individual drivers but
the best place for this code is in cpufreq core.This patch modifies cpufreq_notify_transition() to notify frequency change for
all cpus in policy->cpus and hence updates all users of this API.Signed-off-by: Viresh Kumar
Acked-by: Stephen Warren
Tested-by: Stephen Warren
Signed-off-by: Rafael J. Wysocki
01 Mar, 2012
1 commit
-
We don't have any of the other code for VDDINT, including the variable
declaration, so don't try to get it as we can't build.Signed-off-by: Mark Brown
Signed-off-by: Dave Jones
09 Dec, 2011
1 commit
-
They're already consistent but it saves remembering to do so.
Signed-off-by: Mark Brown
Signed-off-by: Dave Jones
01 Nov, 2011
1 commit
-
The header change has removed an implicit include of module.h, breaking
the build due to the use of THIS_MODULE. Fix that.Signed-off-by: Mark Brown
Signed-off-by: Paul Gortmaker
14 Jul, 2011
4 commits
-
By extension from the 667MHz based clocks currently supported add 100MHz
and 200MHz operating points. Due to a lack of documentation these have not
been confirmed as supported but by extension from the existing frequencies
they should be OK, and I've given them quite a bit of runtime testing.The major risk is synchronization with the non-ARM clocks but as we
can't currently scale the ARM PLL the risk should be relatively low.Signed-off-by: Mark Brown
Acked-by: Kukjin Kim
Signed-off-by: Dave Jones -
The CPUFREQ_POSTCHANGE notification is used to update things that depend on
the system clock rates. Since this may include the interfaces used to talk
to the regulators do the notification before we try to update regulators
to reflect lowered system clock rate.The voltage scaling is just a power optimisation and may not happen at all
so there's no concern about it not having completed.Signed-off-by: Mark Brown
Acked-by: Kukjin Kim
Signed-off-by: Dave Jones -
At least some newer S3C6410 silicon supports operation up to 800MHz rather
than just 667MHz. Unfortunately I don't have access to any of documentation
of this other than some running systems, add a new cpufreq table entry for
this based on the behaviour of those systems.Signed-off-by: Mark Brown
Acked-by: Kukjin Kim
Signed-off-by: Dave Jones -
Cc: Mark Brown
Signed-off-by: Kukjin Kim
Signed-off-by: Dave Jones
