linux-toradex.git/drivers/cpufreq/dbx500-cpufreq.c, branch v3.13.5

cpufreq: move freq change notifications to cpufreq core

2013-10-30T23:11:08+00:00

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

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: dbx500: use cpufreq_generic_init()

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

Use generic cpufreq_generic_init() routine instead of replicating the same code
here.

Signed-off-by: Viresh Kumar 
Acked-by: Linus Walleij 
Signed-off-by: Rafael J. Wysocki

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

2013-10-15T22:50:29+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().

Cc: Linus Walleij 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: dbx500: Use generic cpufreq routines

2013-10-15T22:50:24+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 for in the dbx500 driver.

Cc: Linus Walleij 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: dbx500: 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().

Acked-by: Linus Walleij 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: delete __cpuinit usage from all cpufreq files

2013-07-14T23:36:57+00:00

The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

This removes all the drivers/cpufreq uses of the __cpuinit macros
from all C files.

[1] https://lkml.org/lkml/2013/5/20/589

[v2: leave 2nd lines of args misaligned as requested by Viresh]
Cc: "Rafael J. Wysocki" 
Cc: Viresh Kumar 
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Acked-by: Dirk Brandewie 
Acked-by: Viresh Kumar 
Signed-off-by: Paul Gortmaker

cpufreq: dbx500: call CPUFREQ_POSTCHANGE notfier in error cases

2013-06-24T12:48:59+00:00

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.

Acked-by: Linus Walleij 
Signed-off-by: Viresh Kumar

cpufreq: dbx500: Round to closest available freq

2013-04-11T21:23:57+00:00

When reading the cpu speed, round it to the closest available
frequency from the table.

Signed-off-by: Mats Fagerstrom 
Signed-off-by: Ulf Hansson 
Acked-by: Linus Walleij 
Signed-off-by: Rafael J. Wysocki

cpufreq: drivers: don't check range of target freq in .target()

2013-04-02T13:26:32+00:00

Cpufreq core checks the range of target_freq before calling driver->target() and
so we don't need to do it again.

Remove it.

Signed-off-by: Viresh Kumar 
Acked-by: Linus Walleij 
Signed-off-by: Rafael J. Wysocki