Commit Graph

10 Commits

Author SHA1 Message Date
Nishanth Menon 1c78217fc8 cpufreq: OMAP: fix freq_table leak
We use a single frequency table for multiple CPUs. But, with
OMAP4, since we have multiple CPUs, the cpu_init call for CPU1
causes freq_table previously allocated for CPU0 to be overwritten.
In addition, we dont free the table on exit path.

We solve this by maintaining an atomic type counter to ensure
just a single table exists at a given time.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-11-08 11:42:17 -08:00
Nishanth Menon 11e04fdd98 cpufreq: OMAP: put clk if cpu_init failed
Release the mpu_clk in fail paths.

Reported-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-11-08 11:42:17 -08:00
Nishanth Menon ffe4f0f115 cpufreq: OMAP: only supports OPP library
OMAP2 is the only family using clk_[init|exit]_cpufreq_table, however,
the cpufreq code does not currently use clk_init_cpufreq_table. As a
result, it is unusuable for OMAP2 and only usable only on platforms
using OPP library.

Remove the unbalanced clk_exit_cpufreq_table().  Any platforms where
OPPs are not availble will fail on init because a freq table will not
be properly initialized.

Signed-off-by: Nishanth Menon <nm@ti.com>
[khilman@ti.com: changelog edits, and graceful failure mode changes]
Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-11-08 11:42:17 -08:00
Nishanth Menon bf2a359d50 cpufreq: OMAP: dont support !freq_table
OMAP2+ all have frequency tables, hence the hacks we had for older
silicon do not need to be carried forward. As part of this change,
use cpufreq_frequency_table_target to find the best match for
frequency requested.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-11-08 11:42:17 -08:00
Nishanth Menon a820ffa8fd cpufreq: OMAP: deny initialization if no mpudev
if we do not have mpu_dev we normally fail in cpu_init. It is better
to fail driver registration if the devices are not available.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-11-08 11:42:17 -08:00
Nishanth Menon 08ca3e3b8d cpufreq: OMAP: move clk name decision to init
Clk name does'nt need to dynamically detected during clk init.
move them off to driver initialization, if we dont have a clk name,
there is no point in registering the driver anyways. The actual clk
get and put is left at cpu_init and exit functions.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-11-08 11:42:16 -08:00
Colin Cross 022ac03b45 cpufreq: OMAP: notify even with bad boot frequency
Sometimes, bootloaders starts up with a frequency which is not
in the OPP table. At cpu_init, policy->cur contains the frequency
we pick at boot.  It is possible that system might have fixed
it's boot frequency later on as part of power initialization.
After this condition, the first call to omap_target results in the
following:

omap_getspeed(actual device frequency) != policy->cur(frequency that
cpufreq thinks that the system is at), and it is possible that
freqs.old == freqs.new (because the governor requested a scale down).

We exit without triggering the notifiers in the current code, which
does'nt let code which depends on cpufreq_notify_transition to have
accurate information as to what the system frequency is.

Instead, we do a normal transition if policy->cur is wrong, then,
freqs.old will be the actual cpu frequency, freqs.new will be the
actual new cpu frequency and all required notifiers have the accurate
information.

Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Colin Cross <ccross@google.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-11-08 11:42:16 -08:00
Todd Poynor ed8ce00c52 cpufreq: OMAP: Enable all CPUs in shared policy mask
Enable all CPUs in the shared policy in the CPU init callback.
Otherwise, the governor CPUFREQ_GOV_START event is invoked with
a policy that only includes the first CPU, leaving other CPUs
uninitialized by the governor.

Signed-off-by: Todd Poynor <toddpoynor@google.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-11-08 11:42:16 -08:00
Russell King 46c12216c8 cpufreq: OMAP: Add SMP support for OMAP4+
On OMAP SMP configuartion, both processors share the voltage
and clock. So both CPUs needs to be scaled together and hence
needs software co-ordination.

Also, update lpj with reference value to avoid progressive error.

Adjust _both_ the per-cpu loops_per_jiffy and global lpj. Calibrate
them with with reference to the initial values to avoid a
progressively bigger and bigger error in the value over time.

While at this, re-use the notifiers for UP/SMP since on UP machine or
UP_ON_SMP policy->cpus mask would contain only the boot CPU.

Based on initial SMP support by Santosh Shilimkar.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[khilman@ti.com: due to overlap/rework, combined original Santosh patch
                 and Russell's rework]
Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-11-08 11:42:16 -08:00
Santosh Shilimkar 731e0cc639 cpufreq: OMAP: cleanup for multi-SoC support, move into drivers/cpufreq
Move OMAP cpufreq driver from arch/arm/mach-omap2 into
drivers/cpufreq, along with a few cleanups:

- generalize support for better handling of different SoCs in the OMAP
- use OPP layer instead of OMAP clock internals for frequency table init

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[khilman@ti.com: move to drivers]
Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-11-08 11:42:16 -08:00