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().

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>

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 s3cx4xx driver.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NKukjin Kim <kgene.kim@samsung.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: 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>

We don't need to set .owner = THIS_MODULE any more in cpufreq drivers
as this field isn't used any more by the cpufreq core.

This patch removes it and updates all dependent drivers accordingly.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 50701588 (cpufreq: rename index as driver_data in
cpufreq_frequency_table) renamed the index field to driver_data.

But it seems some uses in the s3c2416 driver were forgotten.

So convert the last index users to read driver_data.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

Correct spelling typo in printk within various drivers.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The "index" field of struct cpufreq_frequency_table was never an
index and isn't used at all by the cpufreq core.  It only is useful
for cpufreq drivers for their internal purposes.

Many people nowadays blindly set it in ascending order with the
assumption that the core will use it, which is a mistake.

Rename it to "driver_data" as that's what its purpose is. All of its
users are updated accordingly.

[rjw: Changelog]
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>
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>

Correct spelling typo in cpufreq driver.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The S3C2416/S3C2450 SoCs support two sources for the armclk.

The first source is the so called armdiv which divides the msysclk down
to provide necessary cpu rates. In this mode the core voltage must be
always at 1.3V. The frequency from the armdiv is not allowed to be
lower than the hclk frequency.

In the second mode the armclk can be sourced directly from the hclk in
the so called "dynamic voltags scaling" (dvs) mode. Here the armdiv
isn't used at all. Also in this mode the core voltage may be lowered.
Existing hardware and tests with it suggest 1.0V as sufficient.

When changing the clock source to the armdiv from the hclk, the SoC
shows stability issues if the new frequency is higher than the current
hclk frequency. Hence the driver always forces the armdiv to the hclk
frequency before the source change and lets the cpufreq issue another
set_target call for higher frequencies.

To mark the hclk frequency as lower as the corresponding armdiv
frequency it is set 1MHz below the real frequency. This lets the cpufreq
framework change between 133MHz based on hclk and 133MHz based on armdiv
at will.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NAndrey Gusakov <dron0gus@gmail.com>
Signed-off-by: NDave Jones <davej@redhat.com>