Commit: e725d26c provided possibility to
use device tree to asses if cpu can be used as cooling device. Since the
code was somewhat awkward, simpler approach has been proposed.

Test HW: Exynos 4412 - Odroid U3.
Suggested-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLukasz Majewski <l.majewski@samsung.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>

With thermal subsystem rework it is necessary to tune current cpufreq code
to use cpu frequency change as a potential cooling device.

Now the cpu cooling device is registered only when proper nodes and properties
are available in device tree. Lack of them, however, will not prevent
cpufreq for normal operation.
Signed-off-by: NLukasz Majewski <l.majewski@samsung.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Currently Exynos cpufreq drivers rely on globally mapped
clock controller registers to configure frequency of CPU
cores. This is obviously wrong and will be removed in near
future, but to enable support for multi-platform builds
without introducing a regression it needs to be worked
around.

This patch hacks the code to look for clock controller node
in device tree and map its registers using of_iomap(),
instead of relying on global mapping, so dependencies on
platform headers are removed and the driver can compile
again with multiplatform support.
Signed-off-by: NTomasz Figa <t.figa@samsung.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from
plat to mach") which lands in samsung tree causes build breakage
for cpufreq-exynos like following:

drivers/cpufreq/exynos-cpufreq.c: In function 'exynos_cpufreq_probe':
drivers/cpufreq/exynos-cpufreq.c:166:2: error: implicit declaration of function 'soc_is_exynos4210'
[-Werror=implicit-function-declaration]
drivers/cpufreq/exynos-cpufreq.c:168:2: error: implicit declaration of function 'soc_is_exynos4212'
[-Werror=implicit-function-declaration]
drivers/cpufreq/exynos-cpufreq.c:168:2: error: implicit declaration of function 'soc_is_exynos4412'
[-Werror=implicit-function-declaration]
drivers/cpufreq/exynos-cpufreq.c:170:2: error: implicit declaration of function 'soc_is_exynos5250'
[-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1
make[2]: *** Waiting for unfinished jobs....
drivers/cpufreq/exynos4x12-cpufreq.c: In function 'exynos4x12_set_clkdiv':
drivers/cpufreq/exynos4x12-cpufreq.c:118:2: error: implicit declaration of function 'soc_is_exynos4212'
[-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[2]: *** [drivers/cpufreq/exynos4x12-cpufreq.o] Error 1
make[1]: *** [drivers/cpufreq] Error 2

This fixes above error with getting SoC information via
of_machine_is_compatible() instead of soc_is_exynosXXXX().
Suggested-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NJonghwan Choi <jhbird.choi@samsung.com>
[kgene.kim@samsung.com: fixed typo and modified as per Viresh's suggestion]
[kgene.kim@samsung.com: Rafael agreed]
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

This patch uses dev_err/info function to show accurate log message
with device name instead of pr_err/info function.
Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NStratos Karafotis <stratosk@semaphore.gr>
Acked-by: NLad, Prabhakar <prabhakar.csengg@gmail.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

cpufreq_generic_exit() is empty now and can be deleted.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The cpufreq core now supports suspending and resuming of cpufreq
drivers and governors during systems suspend and resume, so use
the common infrastructure instead of defining special PM notifiers
for the same thing.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
[rjw: Changelog]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The cpufreq_driver's boost_supported flag is true only when boost
support is explicitly enabled. Boost related attributes are exported
only under the same condition.
Signed-off-by: NLukasz Majewski <l.majewski@samsung.com>
Signed-off-by: NMyungjoo Ham <myungjoo.ham@samsung.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NHans-Christian Egtvedt <egtvedt@samfundet.no>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

To make the driver multiplatform-friendly, unconditional initialization
in an initcall is replaced with a platform driver probed only if
respective platform device is registered.

Tested at: Exynos4210 (TRATS) and Exynos4412 (TRATS2)
Signed-off-by: NLukasz Majewski <l.majewski@samsung.com>
Signed-off-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: NSachin Kamat <sachin.kamat@linaro.org>
Tested-by: NSachin Kamat <sachin.kamat@linaro.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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

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: 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: NStephen Warren <swarren@nvidia.com>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Tested-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Reviewed-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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>

Currently, code checks false return value from "regulator_set_voltage"
to show failure message. Modify the code to check proper return
value from "regulator_set_voltage".
Signed-off-by: NManish Badarkhe <badarkhe.manish@gmail.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Use generic cpufreq_generic_init() routine instead of replicating the same code
here.
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().
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-By: NAmit Daniel Kachhap <amit.daniel@samsung.com>
Acked-by: NKukjin Kim <kgene.kim@samsung.com>
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 exynos driver.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-By: NAmit Daniel Kachhap <amit.daniel@samsung.com>
Acked-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Signed-off-by: NLABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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

Cc: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

* remove superfluous pr_debug() call from exynos_cpufreq_init()
  (init errors are always logged anyway)
* add dummy per-SoC type init functions to exynos-cpufreq.h
* make per-SoC type cpufreq config options selectable
* make CONFIG_ARM_EXYNOS_CPUFREQ config option invisible to user and
  automatically enable it when needed

This patch fixes following issues:
* EXYNOS per-SoC type cpufreq support (i.e. exynos4210-cpufreq.c) being
  always built if given SoC support was enabled (i.e. CPU_EXYNOS4210),
  even if common EXYNOS cpufreq support was disabled
* inability to select cpufreq for each SoC type separately (it could
  be only enabled/disabled for all SoCs for which support was enabled)
* EXYNOS5440 cpufreq support was always enabled when EXYNOS5440
  support was enabled and couldn't be disabled
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

Chapter 14 of Documentation/CodingStyle says:

The preferred form for passing a size of a struct is the following:

	p = kmalloc(sizeof(*p), ...);

The alternative form where struct name is spelled out hurts
readability and introduces an opportunity for a bug when the pointer
variable type is changed but the corresponding sizeof that is passed
to a memory allocator is not.

This wasn't followed consistently in drivers/cpufreq, let's make it
more consistent by always following this rule.
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.

This patch fixes it.

Cc: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

This patch helps to have single binary for exynos5440 and previous
exynos soc's. This change is needed for adding exynos5440 cpufreq driver
which does not uses exynos-cpufreq common file and adds it own driver.
Signed-off-by: NAmit Daniel Kachhap <amit.daniel@samsung.com>
Acked-by: NKukjin Kim <kgene.kim@samsung.com>
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>

With the recent changes in cpufreq core, we just need to set mask of all
possible cpus into policy->cpus. Rest would be done by core.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

When pm handler set freq & voltage, frequency mismatch occurred.
Because freqs.new isn't set in pm handler.
Signed-off-by: NJonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

'ret' is undefined when the function returns from the first
'if' condition. Without this patch we get the following warning:

drivers/cpufreq/exynos-cpufreq.c: In function 'exynos_target':
drivers/cpufreq/exynos-cpufreq.c:182:2: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
Suggested-by: NJonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

exynos_cpufreq_scale function returns signed value which was
assigned to an unsigned variable and checked for negative value which
is always false. Hence make it signed.

Fixes the following smatch warnings:
drivers/cpufreq/exynos-cpufreq.c:83 exynos_cpufreq_scale() warn: unsigned 'old_index' is never less than zero.
drivers/cpufreq/exynos-cpufreq.c:89 exynos_cpufreq_scale() warn: unsigned 'index' is never less than zero.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Boot_freq is for saving booting freq. But exynos_cpufreq_cpu_init
is called in hotplug. If boot_freq is existed in exynos_cpufreq_cpu_init,
boot_freq could be changed.
Signed-off-by: NJonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Add freq_attr attribute to show list of available frequencies.
Signed-off-by: NDonggeun Kim <dg77.kim@samsung.com>
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NKyungMin Park <kyungmin.park@samsung.com>
Signed-off-by: NInderpal Singh <inderpal.singh@linaro.org>
Reviewed-by: Amit Daniel Kachhap<amit.daniel@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Split exynos_target function into exynos_target & exynos_cpufreq_scale.
The exynos_cpufreq_scale changes the voltage & frequency.
Signed-off-by: NJonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

If old & new freq have the same frequency, no need to call
cpufreq notifier & regulator function.
Signed-off-by: NJonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

The variable 'max_support_idx, min_support_idx, pm_lock_idx"
are never used, so remove the unused variable.
Signed-off-by: NJonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Fixes following sparse error.
drivers/cpufreq/exynos-cpufreq.c:34:5: warning: symbol
'exynos_verify_speed' was not declared. Should it be static?
drivers/cpufreq/exynos-cpufreq.c:40:14: warning: symbol
'exynos_getspeed' was not declared. Should it be static?
Signed-off-by: NTushar Behera <tushar.behera@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

On Exynos SoCs all cores share the same frequency setting, so changing
frequency of one core will affect rest of cores.

This patch modifies the exynos-cpufreq driver to inform cpufreq core
about this behavior and broadcast frequency change notifications for all
cores.
Signed-off-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The policy might have been changed since last call of target().
Thus, using cpufreq_frequency_table_target(), which depends on
policy to find the corresponding index from a frequency, may return
inconsistent index for freqs.old. Thus, old_index should be
calculated not based on the current policy.

We have been observing such issue when scaling_min/max_freq were
updated and sometimes cuased system lockups deu to incorrectly
configured voltages.
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

This patch adds support cpufreq for EXYNOS5250 SoC. Basically,
the exynos-cpufreq.c is used commonly and exynos5250-cpufreq.c
is used for EXYNOS5250(two Cortex-A15 cores) SoC.
Signed-off-by: NJaecheol Lee <jc.lee@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NDave Jones <davej@redhat.com>