These changes are all driver specific and cross over between arm-soc
contents and some other subsystem, in these cases cpufreq, crypto,
dma, pinctrl, mailbox and usb, and the subsystem owners agreed to
have these changes merged through arm-soc. As we proceed to untangle
the dependencies between platform code and driver code, the amount of
changes in this category is fortunately shrinking, for 3.11 we have
16 branches here and 101 non-merge changesets, the majority of which
are for the stedma40 dma engine driver used in the ux500 platform.
Cleaning up that code touches multiple subsystems, but gets rid
of the dependency in the end.
The mailbox code moved out from mach-omap2 to drivers/mailbox
is an intermediate step and is still omap specific at the moment.
Patches exist to generalize the subsystem and add other drivers
with the same API, but those did not make it for 3.11.
Conflicts:
* In cpu-db8500.c results from the removal of the u8500_of_init_devices
function in combination with the split of u8500_auxdata_lookup.
* In arch/arm/mach-omap2/devices.c, the includes got reshuffled.
we need to keep linux/wl12xx.h and linux/platform_data/mailbox-omap.h.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIVAwUAUdLnomCrR//JCVInAQJI/A/9FydsQa9sdnzLFgcdX5BeRRwkXLfDifCM
zDTfUBo+LriKOs7QHblmDg1MnY1UMB2IfrdHD0FsjK7WbZ/91EMAGDPYcI7Fu4+u
pGStxwWi2v+oCT1jjeOkCPT7hdCqogsSpybYq8itSb+zdvdOi6U35dWEKz8xGqz4
vTL9gTZbJP0kowkjIcaryk7FIj7BTIvMCW8n55JZEkDe0BuSJGYn5c3Mntut12ZK
5xM2PeNe2sd3dIdA6XbM2ye/XmYa8xY8Qu4/ijxfH1gnJLvz9Unp96nRXpEbIeMb
BH2Sro8dxsMCaweIQhSRKGnUWMYO/Rh7/+5EqzJ163Ezthx9nvHXJY2ndWuD7uM1
IcGrMxLtqP22TEMtZAVEATDp/5ymxEo5GM+eayUojQDn213wOJjRs5xz5IBsH4KM
8CM/gpadWmLjWku72yEV4lryLcdS0NVQzpTnEbILEGOU4u7qJtxRAp7x7tWBtFg8
4m/eWcSVk/U2SYbXmQHsfukuWgKY0cnZbctPcdnaqXwTP7toJEAK3gxoMtWh49Jq
2M2PVFyFejaaq5b/71wAJ7ePYw56H0N/F3RsGpPE55AY15++gSoQ+3t2Si68hDw8
NtyJMkQYpTvtqJbHXWpQQ3Zfs7pDBe01WDV7i+m4JTNggxUDaO/t1Fqp+fEksm4J
r+luEf5Gcgk=
=mJsI
-----END PGP SIGNATURE-----
Merge tag 'drivers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC driver specific changes from Arnd Bergmann:
"These changes are all driver specific and cross over between arm-soc
contents and some other subsystem, in these cases cpufreq, crypto,
dma, pinctrl, mailbox and usb, and the subsystem owners agreed to have
these changes merged through arm-soc.
As we proceed to untangle the dependencies between platform code and
driver code, the amount of changes in this category is fortunately
shrinking, for 3.11 we have 16 branches here and 101 non-merge
changesets, the majority of which are for the stedma40 dma engine
driver used in the ux500 platform. Cleaning up that code touches
multiple subsystems, but gets rid of the dependency in the end.
The mailbox code moved out from mach-omap2 to drivers/mailbox is an
intermediate step and is still omap specific at the moment. Patches
exist to generalize the subsystem and add other drivers with the same
API, but those did not make it for 3.11."
* tag 'drivers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (101 commits)
crypto: ux500: use dmaengine_submit API
crypto: ux500: use dmaengine_prep_slave_sg API
crypto: ux500: use dmaengine_device_control API
crypto: ux500/crypt: add missing __iomem qualifiers
crypto: ux500/hash: add missing static qualifiers
crypto: ux500/hash: use readl on iomem addresses
dmaengine: ste_dma40: Declare memcpy config as static
ARM: ux500: Remove mop500_snowball_ethernet_clock_enable()
ARM: ux500: Correct the EN_3v3 regulator's on/off GPIO
ARM: ux500: Provide a AB8500 GPIO Device Tree node
gpio: rcar: fix gpio_rcar_of_table
gpio-rcar: Remove #ifdef CONFIG_OF around OF-specific sections
gpio-rcar: Reference core gpio documentation in the DT bindings
clk: exynos5250: Add enum entries for divider clock of i2s1 and i2s2
ARM: dts: Update Samsung I2S documentation
ARM: dts: add clock provider information for i2s controllers in Exynos5250
ARM: dts: add Exynos audio subsystem clock controller node
clk: samsung: register audio subsystem clocks using common clock framework
ARM: dts: use #include for all device trees for Samsung
pinctrl: s3c24xx: use correct header for chained_irq functions
...
Toralf Förster reported that the cpufreq ondemand governor behaves erratically
(doesn't scale well) after a suspend/resume cycle. The problem was that the
cpufreq subsystem's idea of the cpu frequencies differed from the actual
frequencies set in the hardware after a suspend/resume cycle. Toralf bisected
the problem to commit a66b2e5 (cpufreq: Preserve sysfs files across
suspend/resume).
Among other (harmless) things, that commit skipped the call to
cpufreq_update_policy() in the resume path. But cpufreq_update_policy() plays
an important role during resume, because it is responsible for checking if
the BIOS changed the cpu frequencies behind our back and resynchronize the
cpufreq subsystem's knowledge of the cpu frequencies, and update them
accordingly.
So, restore the call to cpufreq_update_policy() in the resume path to fix
the cpufreq regression.
Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Cc: 3.10+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* pm-cpufreq:
cpufreq: don't leave stale policy pointer in cdbs->cur_policy
acpi-cpufreq: Add new sysfs attribute freqdomain_cpus
cpufreq: make sure frequency transitions are serialized
Clear ->cur_policy when stopping a governor, or the ->cur_policy
pointer may be stale on systems with have_governor_per_policy when a
new policy is allocated due to CPU hotplug offline/online.
[rjw: Changelog]
Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Jacob Shin <jacob.shin@amd.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commits fcf8058 (cpufreq: Simplify cpufreq_add_dev()) and aa77a52
(cpufreq: acpi-cpufreq: Don't set policy->related_cpus from .init())
changed the contents of the "related_cpus" sysfs attribute on systems
where acpi-cpufreq is used and user space can't get the list of CPUs
which are in the same hardware coordination CPU domain (provided by
the ACPI AML method _PSD) via "related_cpus" any more.
To make up for that loss add a new sysfs attribute "freqdomian_cpus"
for the acpi-cpufreq driver which exposes the list of CPUs in the
same domain regardless of whether it is coordinated by hardware or
software.
[rjw: Changelog, documentation]
References: https://bugzilla.kernel.org/show_bug.cgi?id=58761
Reported-by: Jean-Philippe Halimi <jean-philippe.halimi@exascale-computing.eu>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Whenever we are changing frequency of a cpu, we are calling PRECHANGE and
POSTCHANGE notifiers. They must be serialized. i.e. PRECHANGE or POSTCHANGE
shouldn't be called twice contiguously.
This can happen due to bugs in users of __cpufreq_driver_target() or actual
cpufreq drivers who are sending these notifiers.
This patch adds some protection against this. Now, we keep track of the last
transaction and see if something went wrong.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When initializing the default powersave_bias value, we need to first
make sure that this policy is running the ondemand governor.
Reported-and-tested-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Jacob Shin <jacob.shin@amd.com>
Signed-off-by: Rafael 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.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
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: Mark Brown <broonie@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
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.
Omap driver was taking care of it well, but wasn't restoring freqs.new to
freqs.old in some cases. I wasn't required to add code for it as moving
PRECHANGE notifier down was a better option, so that we call it just before
starting frequency transition.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
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.
This also moves PRECHANGE notifier down so that we call it just before starting
frequency transition.
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
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: Viresh Kumar <viresh.kumar@linaro.org>
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 <linus.walleij@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
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: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
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.
This also removes code setting policy->cur as this is also done by POSTCHANGE
notifier.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
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.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael 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 the sequence of calling notifiers is complete.
This patch fixes it.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In case we have started PRECHANGE notifier and found an error, we
must call POSTCHANGE notifier with freqs.new = freqs.old.
This driver does take care of it, but the POSTCHANGE is called with
freqs.new on errors too, which is incorrect, so fix it.
[rjw: Changelog]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael 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 the sequence of calling notifiers is complete.
This patch fixes it.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit 5070158804b5 (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: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
__cpufreq_notify_transition() is used only in cpufreq.c,
make it static.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There were a few noticeable formatting issues in core cpufreq code.
This cleans them up to make code look better. The changes include:
- Whitespace cleanup.
- Rearrangements of code.
- Multiline comments fixes.
- Formatting changes to fit 80 columns.
Copyright information in cpufreq.c is also updated to include my name
for 2013.
[rjw: Changelog]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cpufreq governors' stop and start operations should be carried out
in sequence. Otherwise, there will be unexpected behavior, like in
the example below.
Suppose there are 4 CPUs and policy->cpu=CPU0, CPU1/2/3 are linked
to CPU0. The normal sequence is:
1) Current governor is userspace. An application tries to set the
governor to ondemand. It will call __cpufreq_set_policy() in
which it will stop the userspace governor and then start the
ondemand governor.
2) Current governor is userspace. The online of CPU3 runs on CPU0.
It will call cpufreq_add_policy_cpu() in which it will first
stop the userspace governor, and then start it again.
If the sequence of the above two cases interleaves, it becomes:
1) Application stops userspace governor
2) Hotplug stops userspace governor
which is a problem, because the governor shouldn't be stopped twice
in a row. What happens next is:
3) Application starts ondemand governor
4) Hotplug starts a governor
In step 4, the hotplug is supposed to start the userspace governor,
but now the governor has been changed by the application to ondemand,
so the ondemand governor is started once again, which is incorrect.
The solution is to prevent policy governors from being stopped
multiple times in a row. A governor should only be stopped once for
one policy. After it has been stopped, no more governor stop
operations should be executed.
Also add a mutex to serialize governor operations.
[rjw: Changelog. And you owe me a beverage of my choice.]
Signed-off-by: Xiaoguang Chen <chenxg@marvell.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Userspace governor has got more code than what it needs for its
functioning, so simplify it.
Portions of code removed are:
- Extra header files which aren't required anymore (rearrange them
as well).
- cpu_{max|min|cur|set}_freq, as they are always the same as
policy->{max|min|cur}.
- userspace_cpufreq_notifier_block as we don't need to set
cpu_cur_freq anymore.
- cpus_using_userspace_governor as it was for the notifier code.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Correct spelling typo in printk within various drivers.
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This CPUFreq driver uses APIs from freq_table.c and so must select
CPU_FREQ_TABLE.
Acked-by: Jacob Shin <jacob.shin@amd.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
currently Tegra cpufreq driver gets built based on ARCH_TEGRA, which doesn't
depend on nor select CPU_FREQ itself, so:
select CPU_FREQ_TABLE if CPU_FREQ
... isn't guaranteed to fire.
The correct solution seems to be:
* Add CONFIG_ARM_TEGRA_CPUFREQ to drivers/cpufreq/Kconfig.arm.
* Make that Kconfig option selct CPU_FREQ_TABLE.
* Make that Kconfig option be def_bool ARCH_TEGRA.
* Modify drivers/cpufreq/Makefile to build tegra-cpufreq.c based on that.
* Remove all the cpufreq-related stuff from arch/arm/mach-tegra/Kconfig.
That way, tegra-cpufreq.c can't be built if !CPU_FREQ, and Tegra's
cpufreq works the same way as all the other cpufreq drivers.
This patch does it.
Suggested-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
CPUFreq driver of this platform uses APIs from freq_table.c and so must select
CPU_FREQ_TABLE.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
CPUFreq driver of this platform uses APIs from freq_table.c and so must select
CPU_FREQ_TABLE.
Cc: linuxppc-dev@lists.ozlabs.org
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
CPUFreq driver of this platform uses APIs from freq_table.c and so must select
CPU_FREQ_TABLE.
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Highbank cpufreq driver doesn't use any APIs from freq_table.c and so must not
select CPU_FREQ_TABLE.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
CPUFreq driver of this platform uses APIs from freq_table.c and so must select
CPU_FREQ_TABLE.
Cc: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
By mistake blackfin's cpufreq driver is enabled when CONFIG_BLACKFIN was
present, whereas it should have been enabled only when CONFIG_BFIN_CPU_FREQ is
present.
Fix it.
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Move cpufreq driver of powerpc platform to drivers/cpufreq.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After commit ac212b6 (ACPI / processor: Use common hotplug
infrastructure) the acpi-cpufreq module is not loaded automatically
by udev which fails to match it against the x86cpu modalias. Still,
it can be matched against ACPI processor device IDs, which even
makes more sense, because it depends on the ACPI processor driver
that uses those device IDs to bind to processor devices.
For this reason, add ACPI processor device IDs to acpi-cpufreq.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
We need to select CPU_FREQ_TABLE in order to build without
this kind of errors:
drivers/built-in.o: In function `kirkwood_cpufreq_cpu_exit':
/home/zeta/linux-devel/marvell-legacy/drivers/cpufreq/kirkwood-cpufreq.c:145:
undefined reference to `cpufreq_frequency_table_put_attr'
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Like a lot of the other cpufreq drivers, this one needs to
select CONFIG_CPU_FREQ_TABLE to avoid a build error like
built-in.o: In function `bL_cpufreq_set_target':
cpufreq/arm_big_little.c:71: undefined reference to `cpufreq_frequency_table_target'
built-in.o: In function `bL_cpufreq_verify_policy':
cpufreq/arm_big_little.c:55: undefined reference to `cpufreq_frequency_table_verify'
built-in.o: In function `bL_cpufreq_init':
cpufreq/arm_big_little.c:170: undefined reference to `cpufreq_frequency_table_cpuinfo'
cpufreq/arm_big_little.c:178: undefined reference to `cpufreq_frequency_table_get_attr'
built-in.o:(.data+0x5a80c): undefined reference to `cpufreq_freq_attr_scaling_available_freqs'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Like a lot of the other cpufreq drivers, this one needs to
select CONFIG_CPU_FREQ_TABLE to avoid a build error like
drivers/built-in.o: In function `spear_cpufreq_exit':
spear-cpufreq.c:198: undefined reference to `cpufreq_frequency_table_put_attr'
drivers/built-in.o: In function `spear_cpufreq_verify':
spear-cpufreq.c:35: undefined reference to `cpufreq_frequency_table_verify'
drivers/built-in.o: In function `spear_cpufreq_init':
spear-cpufreq.c:181: undefined reference to `cpufreq_frequency_table_cpuinfo'
spear-cpufreq.c:187: undefined reference to `cpufreq_frequency_table_get_attr'
drivers/built-in.o: In function `spear_cpufreq_target':
spear-cpufreq.c:120: undefined reference to `cpufreq_frequency_table_target'
drivers/built-in.o:(.data+0x5e63c): undefined reference to `cpufreq_freq_attr_scaling_available_freqs'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Add cpufreq driver for Freescale e500mc, e5500 and e6500 SoCs
which are capable of changing the CPU frequency dynamically
Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
clk_set_rate() isn't supposed to accept approximate frequencies, instead
a supported frequency should be obtained from clk_round_rate() and then
used to set the clock.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
