20 Oct, 2014
1 commit
-
A platform_driver does not need to set an owner, it will be populated by the
driver core.Signed-off-by: Wolfram Sang
07 Apr, 2014
1 commit
-
Few drivers are using kmalloc() to allocate memory for frequency
tables and since we will have an additional field '.flags' in
'struct cpufreq_frequency_table', these might become unstable.
Better get these fixed by replacing kmalloc() by kzalloc() instead.Along with that we also remove use of .driver_data from SPEAr driver
as it doesn't use it at all. Also, writing zero to .driver_data is not
required for powernow-k8 as it is already zero.Reported-and-reviewed-by: Gautham R. Shenoy
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
12 Mar, 2014
2 commits
-
As multiplatform build is being adopted by more and more
ARM platforms, initcall function should be used very carefully.
For example, when SPEAr cpufreq driver is enabled on a kernel
booted on a non-SPEAr board, we will get following boot time error:spear_cpufreq: Invalid cpufreq_tbl
To eliminate this undesired the effect, the patch changes SPEAr
driver to have it instantiated as a platform_driver. Then it will
only run on platforms that create the platform_device "spear-cpufreq".This patch also creates platform node for SPEAr13xx boards.
Reported-by: Josh Cartwright
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
cpufreq_generic_exit() is empty now and can be deleted.
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
07 Dec, 2013
1 commit
-
Treat both negative and zero return values from clk_round_rate()
as errors. This is needed since subsequent patches will convert
clk_round_rate()'s return value to be an unsigned type, rather
than a signed type, since some clock sources can generate rates
higher than (2^31)-1 Hz.Eventually, when calling clk_round_rate(), only a return value of
zero will be considered a error. All other values will be
considered valid rates. The comparison against values less than
0 is kept to preserve the correct behavior in the meantime.Signed-off-by: Paul Walmsley
Acked-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
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().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 spear driver.
Signed-off-by: Viresh Kumar
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().Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
'clk_round_rate' returns a negative error code upon failure. This
will never get detected by unsigned 'newfreq'. Make it signed.Signed-off-by: Sachin Kamat
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
21 Aug, 2013
1 commit
-
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.This patch removes all DT parsing and uses cpu->of_node instead.
Cc: Deepak Sikri
Acked-by: Viresh Kumar
Signed-off-by: Sudeep KarkadaNagesha
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
02 Feb, 2013
4 commits
-
With following patch, we need to set policy->cpus with mask of all possible cpus
and policy->related_cpus would be filled automatically by the core.commit 4948b355e90080cd5ec1e91189f65a01e4186ef2
Author: Viresh Kumar
Date: Tue Jan 29 14:39:08 2013 +0000cpufreq: Simplify cpufreq_add_dev()
Lets fix it for all single cluster SoCs.
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
SPEAr cpufreq driver supports dual core Cortex-A9 SoC's, where cpus share policy
structure. Whenever we update frequency of a cpu, we must notify all
policy->cpus.Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
Currently cpufreq_add_dev() firsts allocates policy, calls
driver->init() and then checks if this CPU is already managed or not.
And if it is already managed, its policy is freed.We can save all this if we somehow know that CPU is managed or not in
advance. policy->related_cpus contains the list of all valid sibling
CPUs of policy->cpu. We can check this to see if the current CPU is
already managed.From now on, platforms don't really need to set related_cpus from
their init() routines, as the same work is done by core too.If a platform driver needs to set the related_cpus mask with some
additional CPUs, other than CPUs present in policy->cpus, they are
free to do it, though, as we don't override anything.[rjw: Changelog]
Signed-off-by: Viresh Kumar
Tested-by: Shawn Guo
Signed-off-by: Rafael J. Wysocki -
This patch fixes following sparse warning:
drivers/cpufreq/spear-cpufreq.c:33:5: warning: symbol 'spear_cpufreq_verify' was
not declared. Should it be static?Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
27 Nov, 2012
1 commit
-
SPEAr is an ARM based family of SoCs. This patch adds in support of cpufreq
driver for SPEAr SoCs. It is supported via DT only and so bindings are present
in binding document.Signed-off-by: Deepak Sikri
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
