linux-toradex.git/drivers/cpufreq/longhaul.c, branch v3.18.3

Merge branch 'cpufreq-macros' into pm-cpufreq

2014-04-30T22:50:47+00:00

cpufreq: Use cpufreq_for_each_* macros for frequency table iteration

2014-04-29T22:06:21+00:00

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

cpufreq: longhaul: Fix double invocation of cpufreq_freq_transition_begin/end

2014-04-28T23:22:52+00:00

During frequency transitions, the cpufreq core takes the responsibility of
invoking cpufreq_freq_transition_begin() and cpufreq_freq_transition_end()
for those cpufreq drivers that define the ->target_index callback but don't
set the ASYNC_NOTIFICATION flag.

The longhaul cpufreq driver falls under this category, but this driver was
invoking the _begin() and _end() APIs itself around frequency transitions,
which led to double invocation of the _begin() API. The _begin API makes
contending callers wait until the previous invocation is complete. Hence,
the longhaul driver ended up waiting on itself, leading to system hangs
during boot.

Fix this by removing the calls to the _begin() and _end() APIs from the
longhaul driver, since they rightly belong to the cpufreq core.

(Note that during module_exit(), the longhaul driver sets the frequency
 without any help from the cpufreq core. So add explicit calls to the
 _begin() and _end() APIs around that frequency transition alone, to take
 care of that special case.)

Fixes: 12478cf0c55e (cpufreq: Make sure frequency transitions are serialized)
Reported-and-tested-by: Meelis Roos 
Signed-off-by: Srivatsa S. Bhat 
Signed-off-by: Rafael J. Wysocki

cpufreq: use kzalloc() to allocate memory for cpufreq_frequency_table

2014-04-07T12:43:49+00:00

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

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: Remove cpufreq_generic_exit()

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

cpufreq_generic_exit() is empty now and can be deleted.

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

cpufreq: Implement light weight ->target_index() routine

2013-10-25T20:42:24+00:00

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

cpufreq: longhaul: don't initialize part of policy set by core

2013-10-15T22:50:30+00:00

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

cpufreq: longhaul: Use generic cpufreq routines

2013-10-15T22:50:25+00:00

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 longhaul driver.

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

cpufreq: longhaul: use cpufreq_table_validate_and_show()

2013-09-30T18:18:42+00:00

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