30 Nov, 2011
11 commits
-
dvfs.h is required by omap cpufreq driver that
lives in drivers folder, so move it to plat/
directory. Also move voltage.h, vc.h & vp.h
similarly to have clean header file inclusionsSigned-off-by: Afzal Mohammed
-
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
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
Release the mpu_clk in fail paths.
Reported-by: Todd Poynor
Signed-off-by: Nishanth Menon
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
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
[khilman@ti.com: changelog edits, and graceful failure mode changes]
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
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
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
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
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia
[afzal@ti.com: use 'omap_device_get_by_hwmod_name' for 'mpu_dev']
Signed-off-by: Afzal Mohammed -
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
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
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
Signed-off-by: Colin Cross
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
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
Acked-by: Santosh Shilimkar
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
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
Signed-off-by: Santosh Shilimkar
[khilman@ti.com: due to overlap/rework, combined original Santosh patch
and Russell's rework]
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia -
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 initSigned-off-by: Santosh Shilimkar
[khilman@ti.com: move to drivers]
Signed-off-by: Kevin Hilman
[vaibhav.bedia@ti.com: Pull in for AM33xx]
Signed-off-by: Vaibhav Bedia
15 Sep, 2011
1 commit
-
per_cpu(processors, n) can be NULL, resulting in:
Loading CPUFreq modules[ 437.661360] BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] pcc_cpufreq_cpu_init+0x74/0x220 [pcc_cpufreq]It's better to avoid the oops by failing the driver, and allowing the
system to boot.Signed-off-by: Naga Chumbalkar
Cc: Dave Jones
Cc: Len Brown
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
27 Jul, 2011
1 commit
-
* 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (135 commits)
drm/radeon/kms: fix DP training for DPEncoderService revision bigger than 1.1
drm/radeon/kms: add missing vddci setting on NI+
drm/radeon: Add a rmb() in IH processing
drm/radeon: ATOM Endian fix for atombios_crtc_program_pll()
drm/radeon: Fix the definition of RADEON_BUF_SWAP_32BIT
drm/radeon: Do an MMIO read on interrupts when not uisng MSIs
drm/radeon: Writeback endian fixes
drm/radeon: Remove a bunch of useless _iomem casts
drm/gem: add support for private objects
DRM: clean up and document parsing of video= parameter
DRM: Radeon: Fix section mismatch.
drm: really make debug levels match in edid failure code
drm/radeon/kms: fix i2c map for rv250/280
drm/nouveau/gr: disable fifo access and idle before suspend ctx unload
drm/nouveau: pass flag to engine fini() method on suspend
drm/nouveau: replace nv04_graph_fifo_access() use with direct reg bashing
drm/nv40/gr: rewrite/split context takedown functions
drm/nouveau: detect disabled device in irq handler and return IRQ_NONE
drm/nouveau: ignore connector type when deciding digital/analog on DVI-I
drm/nouveau: Add a quirk for Gigabyte NX86T
...
26 Jul, 2011
1 commit
-
* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: (99 commits)
drivers/virt: add missing linux/interrupt.h to fsl_hypervisor.c
powerpc/85xx: fix mpic configuration in CAMP mode
powerpc: Copy back TIF flags on return from softirq stack
powerpc/64: Make server perfmon only built on ppc64 server devices
powerpc/pseries: Fix hvc_vio.c build due to recent changes
powerpc: Exporting boot_cpuid_phys
powerpc: Add CFAR to oops output
hvc_console: Add kdb support
powerpc/pseries: Fix hvterm_raw_get_chars to accept < 16 chars, fixing xmon
powerpc/irq: Quieten irq mapping printks
powerpc: Enable lockup and hung task detectors in pseries and ppc64 defeconfigs
powerpc: Add mpt2sas driver to pseries and ppc64 defconfig
powerpc: Disable IRQs off tracer in ppc64 defconfig
powerpc: Sync pseries and ppc64 defconfigs
powerpc/pseries/hvconsole: Fix dropped console output
hvc_console: Improve tty/console put_chars handling
powerpc/kdump: Fix timeout in crash_kexec_wait_realmode
powerpc/mm: Fix output of total_ram.
powerpc/cpufreq: Add cpufreq driver for Momentum Maple boards
powerpc: Correct annotations of pmu registration functions
...Fix up trivial Kconfig/Makefile conflicts in arch/powerpc, drivers, and
drivers/cpufreq
19 Jul, 2011
1 commit
-
Add simple cpufreq driver for Maple-based boards (ppc970fx evaluation
kit and others). Driver is based on a cpufreq driver for 64-bit powermac
boxes with all pmac-dependant features removed and simple cleanup
applied.Signed-off-by: Dmitry Eremin-Solenikov
Signed-off-by: Benjamin Herrenschmidt
14 Jul, 2011
18 commits
-
…t/keithp/linux-2.6 into drm-core-next
* 'drm-intel-next' of ssh://master.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6: (52 commits)
drm/i915: provide module parameter description
drm/i915: add module parameter compiler hints
drm/i915/bios: Avoid temporary allocation whilst searching for downclock
drm/i915: Cache GT fifo count for SandyBridge
i915: Fix opregion notifications
drm/i915: TVDAC_STATE_CHG does not indicate successful load-detect
drm/i915: Select correct pipe during TV detect
drm/i915/ringbuffer: Idling requires waiting for the ring to be empty
Revert "drm/i915: enable rc6 by default"
drm/i915: Clean up i915_driver_load failure path
drm/i915: Enable i915 frame buffer compression by default
drm/i915: Share the common work of disabling active FBC before updating
drm/i915: Perform intel_enable_fbc() from a delayed task
drm/i915: Disable FBC across page-flipping
drm/i915: Set persistent-mode for ILK/SNB framebuffer compression
drm/i915: Use of a CPU fence is mandatory to update FBC regions upon CPU writes
drm/i915: Remove vestigial pitch from post-gen2 FBC control routines
drm/i915: Replace direct calls to vfunc.disable_fbc with intel_disable_fbc()
drm/i915: Only export the generic intel_disable_fbc() interface
drm/i915: Enable GPU reset on Ivybridge.
... -
The following symbols are needlessly defined global:
s5pv210_verify_speed
s5pv210_getspeedMake them static.
Signed-off-by: Axel Lin
Acked-by: Kukjin Kim
Signed-off-by: Dave Jones -
The following symbols are needlessly defined global:
exynos4_verify_speed
exynos4_getspeed
exynos4_set_clkdivMake them static.
Signed-off-by: Axel Lin
Acked-by: Kukjin Kim
Signed-off-by: Dave Jones -
By extension from the 667MHz based clocks currently supported add 100MHz
and 200MHz operating points. Due to a lack of documentation these have not
been confirmed as supported but by extension from the existing frequencies
they should be OK, and I've given them quite a bit of runtime testing.The major risk is synchronization with the non-ARM clocks but as we
can't currently scale the ARM PLL the risk should be relatively low.Signed-off-by: Mark Brown
Acked-by: Kukjin Kim
Signed-off-by: Dave Jones -
When system reboot, the CPUFREQ level should be 800MHz to prevent
system lockup.Signed-off-by: Huisung Kang
Signed-off-by: Jonghwan Choi
Signed-off-by: Kukjin Kim
Signed-off-by: Dave Jones -
Voltage scaling accesses the MAX8998 regulators over bit-banged I2C
with lots of udelays. In the case of decreasing CPU speed, the
number of loops per us for udelay needs to be adjusted prior to
decreasing voltage to avoid delaying for up to 10X too long.Signed-off-by: Todd Poynor
Signed-off-by: Jonghwan Choi
Signed-off-by: Kukjin Kim
Signed-off-by: Dave Jones -
Without this lock the call to change the frequency for suspend could
switch to a new frequency while another thread was still changing the
cpu voltage.Signed-off-by: Arve Hjønnevåg
Signed-off-by: Jonghwan Choi
Signed-off-by: Kukjin Kim
Signed-off-by: Dave Jones -
Minimum 800MHz is needed to enter/exit suspend mode due to voltage mismatch.
Signed-off-by: Huisung Kang
Signed-off-by: Jonghwan Choi
Signed-off-by: Kukjin Kim
Signed-off-by: Dave Jones -
Signed-off-by: Jonghwan Choi
Signed-off-by: Kukjin Kim
Signed-off-by: Dave Jones -
Relation has an additional symantics other than standard.
s5pv310_target funtion have below additional relation.
- DISABLE_FURTHER_CPUFREQ : disable further access to target
- ENABLE_FURTHER_CPUFRER : enable access to targetSigned-off-by: Huisung Kang
Signed-off-by: Jonghwan Choi
Signed-off-by: Kukjin Kim
Signed-off-by: Dave Jones -
The CPUFREQ_POSTCHANGE notification is used to update things that depend on
the system clock rates. Since this may include the interfaces used to talk
to the regulators do the notification before we try to update regulators
to reflect lowered system clock rate.The voltage scaling is just a power optimisation and may not happen at all
so there's no concern about it not having completed.Signed-off-by: Mark Brown
Acked-by: Kukjin Kim
Signed-off-by: Dave Jones -
At least some newer S3C6410 silicon supports operation up to 800MHz rather
than just 667MHz. Unfortunately I don't have access to any of documentation
of this other than some running systems, add a new cpufreq table entry for
this based on the behaviour of those systems.Signed-off-by: Mark Brown
Acked-by: Kukjin Kim
Signed-off-by: Dave Jones -
The successive calls to clk_get each call clk_put in the case of failure,
but this is not done for subsequent error handling code. The calls to
clk_get are moved to the end of the function, and appropriate gotos are
added.A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)//
@r exists@
expression e1,e2;
statement S;
@@e1 = clk_get@p1(...);
... when != e1 = e2
when != clk_put(e1)
when any
if (...) { ... when != clk_put(e1)
when != if (...) { ... clk_put(e1) ... }
* return@p3 ...;
} else S
//Signed-off-by: Julia Lawall
Signed-off-by: Kukjin Kim
Signed-off-by: Dave Jones -
Cc: Mark Brown
Signed-off-by: Kukjin Kim
Signed-off-by: Dave Jones -
According to discussion of the ARM arch subsystem migration,
ARM cpufreq drivers move to drivers/cpufreq. So this patch
adds Kconfig.arm for ARM like x86 and adds Samsung S5PV210
and EXYNOS4210 cpufreq driver compile in there.
As a note, otherw will be moved.Cc: Dave Jones
Signed-off-by: Kukjin Kim
Signed-off-by: Dave Jones -
This is a straight code motion patch, there are no changes to the driver
itself. The Kconfig is left untouched as the ARM CPUfreq Kconfig is all
in one big block in arm/Kconfig and should be moved en masse rather than
being done piecemeal.Signed-off-by: Mark Brown
Signed-off-by: Dave Jones -
acpi-cpufreq checks each CPU for aperf/mperf support, but only sets a
global flag. This will cause errors if some CPUs in the system don't
support the feature. Check boot_cpu_has() instead in order to make sure
that all CPUs support it.Signed-off-by: Matthew Garrett
Signed-off-by: Dave Jones
11 Jul, 2011
1 commit
-
I came across a memory leak during a cyclic cpu-online-offline test.
Signed-off-by: Yu Luming
Cc: Len Brown
Signed-off-by: Andrew Morton
Signed-off-by: Dave Jones
29 Jun, 2011
1 commit
-
This allows drivers and other code to get the max reported CPU frequency.
Initial use is for scaling ring frequency with GPU frequency in the i915
driver.Signed-off-by: Jesse Barnes
Signed-off-by: Keith Packard
17 Jun, 2011
3 commits
-
This patch augments the pstate transition code to error out
(instead of returning 0) when an incorrect pstate is provided.Suggested-by: Borislav Petkov
CC: andre.przywara@amd.com
CC: Mark.Langsdorf@amd.com
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Dave Jones -
Before this patch if we failed the vid transition would still try to
submit the "new" frequencies to cpufreq.
That is incorrect - also we could submit a non-existing frequency value
which would cause cpufreq to crash. The ultimate fix is in cpufreq
to deal with incorrect values, but this patch improves the error
recovery in the AMD powernowk8 driver.The failure that was reported was as follows:
powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3700+ (1 cpu cores) (version 2.20.00)
powernow-k8: fid 0x2 (1000 MHz), vid 0x12
powernow-k8: fid 0xa (1800 MHz), vid 0xa
powernow-k8: fid 0xc (2000 MHz), vid 0x8
powernow-k8: fid 0xe (2200 MHz), vid 0x8
Marking TSC unstable due to cpufreq changes
powernow-k8: fid trans failed, fid 0x2, curr 0x0
BUG: unable to handle kernel paging request at ffff880807e07b78
IP: [] cpufreq_stats_update+0x46/0x5b
...And transition fails and data->currfid ends up with 0. Since
the machine does not support 800Mhz value when the calculation is
done ('find_khz_freq_from_fid(data->currfid);') it reports the
new frequency as 800000 which is bogus. This patch fixes
the issue during target setting.The patch however does not fix the issue in 'powernowk8_cpu_init'
where the pol->cur can also be set with the 800000 value:pol->cur = find_khz_freq_from_fid(data->currfid);
dprintk("policy current frequency %d kHz\n", pol->cur);/* min/max the cpu is capable of */
if (cpufreq_frequency_table_cpuinfo(pol, data->powernow_table)) {The fix for that looks to update cpufreq_frequency_table_cpuinfo to
check pol->cur.... but that would cause an regression in how the
acpi-cpufreq driver works (it sets cpu->cur after calling
cpufreq_frequency_table_cpuinfo). Instead the fix will be to let
cpufreq gracefully handle bogus data (another patch).Acked-by: Borislav Petkov
CC: andre.przywara@amd.com
CC: Mark.Langsdorf@amd.com
Reported-by: Tobias Diedrich
Tested-by: Tobias Diedrich
[v1: Rebased on v3.0-rc2, reduced patch to deal with vid case]
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Dave Jones -
If the driver submitted an non-existing pol>cur value (say it
used the default initialized value of zero), when the cpufreq
stats tries to setup its initial values it incorrectly sets
stat->last_index to -1 (or 0xfffff...). And cpufreq_stats_update
tries to update at that index location and fails.This can be caused by:
stat->last_index = freq_table_get_index(stat, policy->cur);
not finding the appropiate frequency in the table (b/c the policy->cur
is wrong) and we end up crashing. The fix however is
concentrated in the 'cpufreq_stats_update' as the last_index
(and old_index) are updated there. Which means it can reset
the last_index to -1 again and on the next iteration cause a crash.Without this patch, the following crash is observed:
powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3700+ (1 cpu cores) (version 2.20.00)
powernow-k8: fid 0x2 (1000 MHz), vid 0x12
powernow-k8: fid 0xa (1800 MHz), vid 0xa
powernow-k8: fid 0xc (2000 MHz), vid 0x8
powernow-k8: fid 0xe (2200 MHz), vid 0x8
Marking TSC unstable due to cpufreq changes
powernow-k8: fid trans failed, fid 0x2, curr 0x0
BUG: unable to handle kernel paging request at ffff880807e07b78
IP: [] cpufreq_stats_update+0x46/0x5b
.. snip..
Pid: 1, comm: swapper Not tainted 3.0.0-rc2 #45 MICRO-STAR INTERNATIONAL CO., LTD MS-7094/MS-7094
..snip..
Call Trace:
[] cpufreq_stat_notifier_trans+0x48/0x7c
[] notifier_call_chain+0x32/0x5e
[] __srcu_notifier_call_chain+0x47/0x63
[] srcu_notifier_call_chain+0xf/0x11
[] cpufreq_notify_transition+0x111/0x134
[] powernowk8_target+0x53b/0x617
[] __cpufreq_driver_target+0x2e/0x30
[] cpufreq_governor_dbs+0x339/0x356
[] __cpufreq_governor+0xa8/0xe9
[] __cpufreq_set_policy+0x132/0x13e
[] cpufreq_add_dev_interface+0x272/0x28cReported-by: Tobias Diedrich
Tested-by: Tobias Diedrich
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Dave Jones
13 Jun, 2011
1 commit
-
cpufreq_stats leaves behind its sysfs entries, which causes a panic
when something stumbled across them.
(Discovered by unloading cpufreq_stats while powertop was loaded).Signed-off-by: Dave Jones
Cc: stable@kernel.org
25 May, 2011
1 commit
-
Concluding interface update and movement of the driver by making
the DB8500 cpufreq driver compile in the cpufreq subsystem.Cc: Arnd Bergmann
Acked-by: Dave Jones
Signed-off-by: Linus Walleij
