linux/drivers/cpufreq, branch v3.0.39

powernow-k8: Fix indexing issue

2012-02-13T19:06:13Z

commit a8eb28480e9b637cc78b9aa5e08612ba97e1317a upstream. The driver uses the pstate number from the status register as index in its table of ACPI pstates (powernow_table). This is wrong as this is not a 1-to-1 mapping. For example we can have _PSS information to just utilize Pstate 0 and Pstate 4, ie. powernow-k8: Core Performance Boosting: on. powernow-k8: 0 : pstate 0 (2200 MHz) powernow-k8: 1 : pstate 4 (1400 MHz) In this example the driver's powernow_table has just 2 entries. Using the pstate number (4) as index into this table is just plain wrong. Signed-off-by: Andreas Herrmann Signed-off-by: Dave Jones Signed-off-by: Greg Kroah-Hartman

powernow-k8: Avoid Pstate MSR accesses on systems supporting CPB

2012-02-13T19:06:13Z

commit 201bf0f129e1715a33568d1563d9a75b840ab4d3 upstream. Due to CPB we can't directly map SW Pstates to Pstate MSRs. Get rid of the paranoia check. (assuming that the ACPI Pstate information is correct.) Signed-off-by: Andreas Herrmann Signed-off-by: Dave Jones Signed-off-by: Greg Kroah-Hartman

drivers/cpufreq/pcc-cpufreq.c: avoid NULL pointer dereference

2011-10-03T18:40:31Z

commit e71f5cc402ecb42b407ae52add7b173bf1c53daa upstream. 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 Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

[CPUFREQ] fix cpumask memory leak in acpi-cpufreq on cpu hotplug.

2011-07-10T21:03:04Z

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

[CPUFREQ] powernow-k8: Don't try to transition if the pstate is incorrect

2011-06-16T20:31:13Z

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

[CPUFREQ] powernow-k8: Don't notify of successful transition if we failed (vid case).

2011-06-16T20:31:13Z

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

[CPUFREQ] Don't set stat->last_index to -1 if the pol->cur has incorrect value.

2011-06-16T20:31:12Z

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/0x28c Reported-by: Tobias Diedrich Tested-by: Tobias Diedrich Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Dave Jones

[CPUFREQ] Remove cpufreq_stats sysfs entries on module unload.

2011-06-12T20:36:52Z

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

cpufreq: make DB8500 cpufreq driver compile

2011-05-24T20:20:14Z

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

cpufreq: update DB8500 cpufreq driver

2011-05-24T20:20:05Z

This updates the ux500 cpufreq driver to the new interface from the updated DB8500 PRCMU Cc: Arnd Bergmann Acked-by: Dave Jones Signed-off-by: Linus Walleij