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: NHans-Christian Egtvedt <egtvedt@samfundet.no>
Acked-by: NJesper Nilsson <jesper.nilsson@axis.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NRussell King <linux@arm.linux.org.uk>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rjw@rjwysocki.net>

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

Cc: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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

Cc: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Most of the users of cpufreq_verify_within_limits() calls it for
limiting with min/max from policy->cpuinfo. We can make that code
simple by introducing another routine which will do this for them
automatically.

This patch adds another routine cpufreq_verify_within_cpu_limits()
and updates others to use it.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Lets use cpufreq_table_validate_and_show() instead of calling
cpufreq_frequency_table_cpuinfo() and cpufreq_frequency_table_get_attr().

Cc: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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.

Davinci driver was taking care of it but frequency isn't restored to freqs.old.

This patch fixes it.
Acked-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

This patch moves cpufreq driver of ARM based davinci platform to
drivers/cpufreq.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Some assignments of policy-> min/max/cur/cpuinfo.min_freq/cpuinfo.max_freq
aren't required as part of it is done by cpufreq driver or cpufreq core.

Remove them.

At some places we merge multiple lines together too.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NSekhar Nori <nsekhar@ti.com>

This fixes:
	arch/arm/mach-davinci/cpufreq.c: In function davinci_target:
	arch/arm/mach-davinci/cpufreq.c:98: warning: passing argument 2 of dev_printk from incompatible pointer type
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

These files all make use of one of the EXPORT_SYMBOL variants
or the THIS_MODULE macro.  So they will need <linux/export.h>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

With dynamic debug having gained the capability to report debug messages
also during the boot process, it offers a far superior interface for
debug messages than the custom cpufreq infrastructure. As a first step,
remove the old cpufreq_debug_printk() function and replace it with a call
to the generic pr_debug() function.

How can dynamic debug be used on cpufreq? You need a kernel which has
CONFIG_DYNAMIC_DEBUG enabled.

To enabled debugging during runtime, mount debugfs and

$ echo -n 'module cpufreq +p' > /sys/kernel/debug/dynamic_debug/control

for debugging the complete "cpufreq" module. To achieve the same goal during
boot, append

	ddebug_query="module cpufreq +p"

as a boot parameter to the kernel of your choice.

For more detailled instructions, please see
Documentation/dynamic-debug-howto.txt
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NDave Jones <davej@redhat.com>

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

Fix below section mismatch warning:
WARNING: vmlinux.o(.data+0x673c): Section mismatch in reference from the variable davinci_driver to the function .init.text:davinci_cpu_init()
The variable davinci_driver references
the function __init davinci_cpu_init()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

On OMAP-L138 SoC, some of the sysclks need not be at a fixed ratio
to CPU clock and can be kept at a relatively constant rate by
adjusting the PLLDIVn ratio even as cpufreq goes ahead and changes
the CPU clock.

This feature can be used to keep the EMIFA (PLL0 SYSCLK3) clock at a
constant rate so that the EMIF timings need not be re-programmed
whenever the CPU frequency changes.

This patch adds the required suppport to cpufreq driver.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Current cpufreq code does not consider errors that can occur while
changing voltage. Code to increase CPU  frequency goes ahead even in
the case the regulator has failed to increase the voltage. This leads
to hard error since lower voltages cannot support increased frequency.

Prevent this by not increasing frequency in case increasing voltage
is not successful.

Also, do not lower the voltage if changing the cpu frequency has failed
for some reason.

Note that we do not return error on failure to decrease voltage as
that is not a hard error.

Build fix for non-cpufreq kernels by Caglar Akyuz.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Cc: Caglar Akyuz <caglar@bilkon-kontrol.com.tr>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Using a device_initcall() for initializing the voltage regulator
on DA850 is not such a good idea because it gets called for all
platforms - even those who do not have a regulator implemented.
This leads to a big fat warning message during boot-up when
regulator cannot be found.

Instead, tie initialization of voltage regulator to cpufreq init.
Define a platform specific init call which in case of DA850 gets
used for initializing the regulator. On other future platforms it
can be used for other purposes.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Adds a basic CPUFreq driver for DaVinci devices registering with the
kernel CPUFreq infrastructure.

Support is added for both frequency and voltage regulation.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>