summaryrefslogtreecommitdiff
path: root/drivers/cpufreq/powernow-k8.c
AgeCommit message (Collapse)Author
2013-02-02powernow-k8: Cleanup init functionBorislav Petkov
Make it hotplug-safe and cleanup formatting. Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-02powernow-k8: Cleanup module requestBorislav Petkov
Check whether we've actually already loaded acpi-cpufreq before requesting it. Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-21cpufreq: remove use of __devexitBill Pemberton
CONFIG_HOTPLUG is going away as an option so __devexit is no longer needed. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-21cpufreq: remove use of __devexit_pBill Pemberton
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-10-31cpufreq / powernow-k8: Change maintainer's email addressAndreas Herrmann
Change the Andreas' email address in drivers/cpufreq/powernow-k8.c. Signed-off-by: Andreas Herrmann <herrmann.der.user@googlemail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-10-23cpufreq / powernow-k8: Remove usage of smp_processor_id() in preemptible codeAndreas Herrmann
Commit 6889125b8b4e09c5e53e6ecab3433bed1ce198c9 (cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU) causes powernow-k8 to trigger a preempt warning, e.g.: BUG: using smp_processor_id() in preemptible [00000000] code: cpufreq/3776 caller is powernowk8_target+0x20/0x49 Pid: 3776, comm: cpufreq Not tainted 3.6.0 #9 Call Trace: [<ffffffff8125b447>] debug_smp_processor_id+0xc7/0xe0 [<ffffffff814877e7>] powernowk8_target+0x20/0x49 [<ffffffff81482b02>] __cpufreq_driver_target+0x82/0x8a [<ffffffff81484fc6>] cpufreq_governor_performance+0x4e/0x54 [<ffffffff81482c50>] __cpufreq_governor+0x8c/0xc9 [<ffffffff81482e6f>] __cpufreq_set_policy+0x1a9/0x21e [<ffffffff814839af>] store_scaling_governor+0x16f/0x19b [<ffffffff81484f16>] ? cpufreq_update_policy+0x124/0x124 [<ffffffff8162b4a5>] ? _raw_spin_unlock_irqrestore+0x2c/0x49 [<ffffffff81483640>] store+0x60/0x88 [<ffffffff811708c0>] sysfs_write_file+0xf4/0x130 [<ffffffff8111243b>] vfs_write+0xb5/0x151 [<ffffffff811126e0>] sys_write+0x4a/0x71 [<ffffffff816319a9>] system_call_fastpath+0x16/0x1b Fix this by by always using work_on_cpu(). Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-10-02Merge tag 'pm-for-3.7-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management updates from Rafael J Wysocki: - Improved system suspend/resume and runtime PM handling for the SH TMU, CMT and MTU2 clock event devices (also used by ARM/shmobile). - Generic PM domains framework extensions related to cpuidle support and domain objects lookup using names. - ARM/shmobile power management updates including improved support for the SH7372's A4S power domain containing the CPU core. - cpufreq changes related to AMD CPUs support from Matthew Garrett, Andre Przywara and Borislav Petkov. - cpu0 cpufreq driver from Shawn Guo. - cpufreq governor fixes related to the relaxing of limit from Michal Pecio. - OMAP cpufreq updates from Axel Lin and Richard Zhao. - cpuidle ladder governor fixes related to the disabling of states from Carsten Emde and me. - Runtime PM core updates related to the interactions with the system suspend core from Alan Stern and Kevin Hilman. - Wakeup sources modification allowing more helper functions to be called from interrupt context from John Stultz and additional diagnostic code from Todd Poynor. - System suspend error code path fix from Feng Hong. Fixed up conflicts in cpufreq/powernow-k8 that stemmed from the workqueue fixes conflicting fairly badly with the removal of support for hardware P-state chips. The changes were independent but somewhat intertwined. * tag 'pm-for-3.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (76 commits) Revert "PM QoS: Use spinlock in the per-device PM QoS constraints code" PM / Runtime: let rpm_resume() succeed if RPM_ACTIVE, even when disabled, v2 cpuidle: rename function name "__cpuidle_register_driver", v2 cpufreq: OMAP: Check IS_ERR() instead of NULL for omap_device_get_by_hwmod_name cpuidle: remove some empty lines PM: Prevent runtime suspend during system resume PM QoS: Use spinlock in the per-device PM QoS constraints code PM / Sleep: use resume event when call dpm_resume_early cpuidle / ACPI : move cpuidle_device field out of the acpi_processor_power structure ACPI / processor: remove pointless variable initialization ACPI / processor: remove unused function parameter cpufreq: OMAP: remove loops_per_jiffy recalculate for smp sections: fix section conflicts in drivers/cpufreq cpufreq: conservative: update frequency when limits are relaxed cpufreq / ondemand: update frequency when limits are relaxed properly __init-annotate pm_sysrq_init() cpufreq: Add a generic cpufreq-cpu0 driver PM / OPP: Initialize OPP table from device tree ARM: add cpufreq transiton notifier to adjust loops_per_jiffy for smp cpufreq: Remove support for hardware P-state chips from powernow-k8 ...
2012-09-19cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPUTejun Heo
powernowk8_target() runs off a per-cpu work item and if the cpufreq_policy->cpu is different from the current one, it migrates the kworker to the target CPU by manipulating current->cpus_allowed. The function migrates the kworker back to the original CPU but this is still broken. Workqueue concurrency management requires the kworkers to stay on the same CPU and powernowk8_target() ends up triggerring BUG_ON(rq != this_rq()) in try_to_wake_up_local() if it contends on fidvid_mutex and sleeps. It is unclear why this bug is being reported now. Duncan says it appeared to be a regression of 3.6-rc1 and couldn't reproduce it on 3.5. Bisection seemed to point to 63d95a91 "workqueue: use @pool instead of @gcwq or @cpu where applicable" which is an non-functional change. Given that the reproduce case sometimes took upto days to trigger, it's easy to be misled while bisecting. Maybe something made contention on fidvid_mutex more likely? I don't know. This patch fixes the bug by using work_on_cpu() instead if @pol->cpu isn't the same as the current one. The code assumes that cpufreq_policy->cpu is kept online by the caller, which Rafael tells me is the case. stable: ed48ece27c ("workqueue: reimplement work_on_cpu() using system_wq") should be applied before this; otherwise, the behavior could be horrible. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Duncan <1i5t5.duncan@cox.net> Tested-by: Duncan <1i5t5.duncan@cox.net> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: stable@vger.kernel.org Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47301
2012-09-09cpufreq: Remove support for hardware P-state chips from powernow-k8Matthew Garrett
These chips are now supported by acpi-cpufreq, so we can delete all the code handling them. Andre: Tighten the deprecation warning message. Trigger load of acpi-cpufreq and let the load of the module finally fail. This avoids the problem of users ending up without any cpufreq support after the transition. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-09-09powernow-k8: delay info messages until initialization has succeededAndre Przywara
powernow-k8 is quite prematurely crying Hooray and outputs diagnostic messages, although the actual initialization can still fail. Since now we may have acpi-cpufreq already loaded, we move the messages at the end of the init routine to avoid confusing output if the loading of powernow-k8 should not succeed. Signed-off-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-09-09cpufreq: Add warning message to powernow-k8Andre Przywara
cpufreq modules are often loaded from init scripts that assume that all recent AMD systems will use powernow-k8. To inform the user of the change of support and ease the transition to acpi-cpufreq, emit a warning message. Signed-off-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-09-05cpufreq / powernow-k8: Fixup missing _PSS objects messageBorislav Petkov
_PSS objects can also be missing if Cool'N'Quiet is disabled in the BIOS. Add that to the FW_BUG message for the user to try before updating her BIOS. Fix formatting while at it. Acked-by: Mark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: Borislav Petkov <borislav.petkov@amd.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-01-26cpufreq: Add support for x86 cpuinfo auto loading v4Andi Kleen
This marks all the x86 cpuinfo tables to the CPU specific device drivers, to allow auto loading by udev. This should simplify the distribution startup scripts for this greatly. I didn't add MODULE_DEVICE_IDs to the centrino and p4-clockmod drivers, because those probably shouldn't be auto loaded and the acpi driver be used instead (not fully sure on that, would appreciate feedback) The old nforce drivers autoload based on the PCI ID. ACPI cpufreq is autoloaded in another patch. v3: Autoload gx based on PCI IDs only. Remove cpu check (Dave Jones) v4: Use newly introduce HW_PSTATE feature for powernow-k8 loading Cc: Dave Jones <davej@redhat.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Thomas Renninger <trenn@suse.de> Acked-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-06[CPUFREQ] powernow-k8: Update copyright, maintainer and documentation ↵Andreas Herrmann
information Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: Dave Jones <davej@redhat.com>
2012-01-06[CPUFREQ] powernow-k8: Fix indexing issueAndreas Herrmann
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 <andreas.herrmann3@amd.com> Signed-off-by: Dave Jones <davej@redhat.com>
2012-01-06[CPUFREQ] powernow-k8: Avoid Pstate MSR accesses on systems supporting CPBAndreas Herrmann
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 <andreas.herrmann3@amd.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-06-16[CPUFREQ] powernow-k8: Don't try to transition if the pstate is incorrectKonrad Rzeszutek Wilk
This patch augments the pstate transition code to error out (instead of returning 0) when an incorrect pstate is provided. Suggested-by: Borislav Petkov <bp@alien8.de> CC: andre.przywara@amd.com CC: Mark.Langsdorf@amd.com Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-06-16[CPUFREQ] powernow-k8: Don't notify of successful transition if we failed ↵Konrad Rzeszutek Wilk
(vid case). 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: [<ffffffff81479163>] 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 <bp@alien8.de> CC: andre.przywara@amd.com CC: Mark.Langsdorf@amd.com Reported-by: Tobias Diedrich <ranma+xen@tdiedrich.de> Tested-by: Tobias Diedrich <ranma+xen@tdiedrich.de> [v1: Rebased on v3.0-rc2, reduced patch to deal with vid case] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-05-19[CPUFREQ] Move x86 drivers to drivers/cpufreq/Dave Jones
Signed-off-by: Dave Jones <davej@redhat.com>