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

cpufreq: OMAP: Fix compilation error 'r & ret undeclared'

2013-11-13T23:52:48+00:00

With a recent change "d4019f0 cpufreq: move freq change notifications to cpufreq
core" few variables (r & ret) are removed by mistake and hence these warnings:

drivers/cpufreq/omap-cpufreq.c: In function omap_target:
drivers/cpufreq/omap-cpufreq.c:64:2: error: ret undeclared (first use in this function)
drivers/cpufreq/omap-cpufreq.c:64:2: note: each undeclared identifier is reported only once for each function it appears in
drivers/cpufreq/omap-cpufreq.c:94:3: error: r undeclared (first use in this function)
drivers/cpufreq/omap-cpufreq.c:116:1: warning: control reaches end of non-void function [-Wreturn-type]

Lets fix them by declaring those variables again.

Fixes: d4019f0a92ab (cpufreq: move freq change notifications to cpufreq core)
Reported-by: Sebastian Capella 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

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

Merge back earlier 'pm-cpufreq' material.

2013-10-25T20:36:40+00:00

Conflicts:
	drivers/cpufreq/omap-cpufreq.c

PM / OPP: rename header to linux/pm_opp.h

2013-10-25T20:33:23+00:00

Since Operating Performance Points (OPP) functions are specific
to device specific power management, be specific and rename opp.h
to pm_opp.h

Reported-by: Randy Dunlap 
Signed-off-by: Nishanth Menon 
Signed-off-by: Rafael J. Wysocki

PM / OPP: rename data structures to dev_pm equivalents

2013-10-25T20:33:23+00:00

Since Operating Performance Points (OPP) data structures are specific
to device specific power management, be specific and rename opp_* data
structures in OPP library with dev_pm_opp_* equivalent.

Affected structures are:
 struct opp
 enum opp_event

Minor checkpatch warning resulting of this change was fixed as well.

Reported-by: Randy Dunlap 
Signed-off-by: Nishanth Menon 
Signed-off-by: Rafael J. Wysocki

PM / OPP: rename functions to dev_pm_opp*

2013-10-25T20:33:23+00:00

Since Operating Performance Points (OPP) functions are specific to
device specific power management, be specific and rename opp_*
accessors in OPP library with dev_pm_opp_* equivalent.

Affected functions are:
 opp_get_voltage
 opp_get_freq
 opp_get_opp_count
 opp_find_freq_exact
 opp_find_freq_floor
 opp_find_freq_ceil
 opp_add
 opp_enable
 opp_disable
 opp_get_notifier
 opp_init_cpufreq_table
 opp_free_cpufreq_table

Reported-by: Randy Dunlap 
Signed-off-by: Nishanth Menon 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: omap: use cpufreq_generic_init()

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

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

This also rearranges the code a bit to make it more sensible. Also removes some
unnecessary checks.

Cc: Santosh Shilimkar 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

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

2013-10-15T22:50:31+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: Santosh Shilimkar 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: omap: Use generic cpufreq routines

2013-10-15T22:50:26+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 OMAP driver.

Cc: Santosh Shilimkar 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki