| e54173b4ed0fca1a5dce9911f54e71f2917d4869 |
|
11-May-2014 |
Stratos Karafotis <stratosk@semaphore.gr> |
cpufreq: powernow-k8: Suppress checkpatch warnings
Suppress the following checkpatch.pl warnings:
- WARNING: Prefer pr_err(... to printk(KERN_ERR ...
- WARNING: Prefer pr_info(... to printk(KERN_INFO ...
- WARNING: Prefer pr_warn(... to printk(KERN_WARNING ...
- WARNING: quoted string split across lines
- WARNING: please, no spaces at the start of a line
Also, define the pr_fmt macro instead of PFX for the module name.
Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| 71508a1f4f2286eea728a5994f1fb14b77340b47 |
|
28-Mar-2014 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: use kzalloc() to allocate memory for cpufreq_frequency_table
Few drivers are using kmalloc() to allocate memory for frequency
tables and since we will have an additional field '.flags' in
'struct cpufreq_frequency_table', these might become unstable.
Better get these fixed by replacing kmalloc() by kzalloc() instead.
Along with that we also remove use of .driver_data from SPEAr driver
as it doesn't use it at all. Also, writing zero to .driver_data is not
required for powernow-k8 as it is already zero.
Reported-and-reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| 8fec051eea736ec1d8060a2c8766bf3a6b32c3d2 |
|
24-Mar-2014 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}
CPUFreq core has new infrastructure that would guarantee serialized calls to
target() or target_index() callbacks. These are called
cpufreq_freq_transition_begin() and cpufreq_freq_transition_end().
This patch converts existing drivers to use these new set of routines.
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| e0b3165ba521c6824b3e9f563f38a701dfa2d8e6 |
|
10-Mar-2014 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: add 'freq_table' in struct cpufreq_policy
freq table is not per CPU but per policy, so it makes more sense to
keep it within struct cpufreq_policy instead of a per-cpu variable.
This patch does it. Over that, there is no need to set policy->freq_table
to NULL in ->exit(), as policy structure is going to be freed soon.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| c3274763bfc3bf1ececa269ed6e6c4d7ec1c3e5e |
|
17-Feb-2014 |
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> |
cpufreq: powernow-k8: Initialize per-cpu data-structures properly
The powernow-k8 driver maintains a per-cpu data-structure called
powernow_data that is used to perform the frequency transitions.
It initializes this data structure only for the policy->cpu. So,
accesses to this data structure by other CPUs results in various
problems because they would have been uninitialized.
Specifically, if a cpu (!= policy->cpu) invokes the drivers' ->get()
function, it returns 0 as the KHz value, since its per-cpu memory
doesn't point to anything valid. This causes problems during
suspend/resume since cpufreq_update_policy() tries to enforce this
(0 KHz) as the current frequency of the CPU, and this madness gets
propagated to adjust_jiffies() as well. Eventually, lots of things
start breaking down, including the r8169 ethernet card, in one
particularly interesting case reported by Pierre Ossman.
Fix this by initializing the per-cpu data-structures of all the CPUs
in the policy appropriately.
References: https://bugzilla.kernel.org/show_bug.cgi?id=70311
Reported-by: Pierre Ossman <pierre@ossman.eu>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Cc: All applicable <stable@vger.kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| ab1b1c4e8223f9ee66aa93aaf64c36e77cadffac |
|
02-Dec-2013 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: send new set of notification for transition failures
In the current code, if we fail during a frequency transition, we
simply send the POSTCHANGE notification with the old frequency. This
isn't enough.
One of the core users of these notifications is the code responsible
for keeping loops_per_jiffy aligned with frequency changes. And mostly
it is written as:
if ((val == CPUFREQ_PRECHANGE && freq->old < freq->new) ||
(val == CPUFREQ_POSTCHANGE && freq->old > freq->new)) {
update-loops-per-jiffy...
}
So, suppose we are changing to a higher frequency and failed during
transition, then following will happen:
- CPUFREQ_PRECHANGE notification with freq-new > freq-old
- CPUFREQ_POSTCHANGE notification with freq-new == freq-old
The first one will update loops_per_jiffy and second one will do
nothing. Even if we send the 2nd notification by exchanging values of
freq-new and old, some users of these notifications might get
unstable.
This can be fixed by simply calling cpufreq_notify_post_transition()
with error code and this routine will take care of sending
notifications in the correct order.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
[rjw: Folded 3 patches into one, rebased unicore2 changes]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| 7dbf694db6ac7c759599316d50d7050efcbd512a |
|
29-Oct-2013 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: distinguish drivers that do asynchronous notifications
There are few special cases like exynos5440 which doesn't send POSTCHANGE
notification from their ->target() routine and call some kind of bottom halves
for doing this work, work/tasklet/etc.. From which they finally send POSTCHANGE
notification.
Its better if we distinguish them from other cpufreq drivers in some way so that
core can handle them specially. So this patch introduces another flag:
CPUFREQ_ASYNC_NOTIFICATION, which will be set by such drivers.
This also changes exynos5440-cpufreq.c and powernow-k8 in order to set this
flag.
Acked-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| 9c0ebcf78fde0ffa348a95a544c6d3f2dac5af65 |
|
25-Oct-2013 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: Implement light weight ->target_index() routine
Currently, the prototype of cpufreq_drivers target routines is:
int target(struct cpufreq_policy *policy, unsigned int target_freq,
unsigned int relation);
And most of the drivers call cpufreq_frequency_table_target() to get a valid
index of their frequency table which is closest to the target_freq. And they
don't use target_freq and relation after that.
So, it makes sense to just do this work in cpufreq core before calling
cpufreq_frequency_table_target() and simply pass index instead. But this can be
done only with drivers which expose their frequency table with cpufreq core. For
others we need to stick with the old prototype of target() until those drivers
are converted to expose frequency tables.
This patch implements the new light weight prototype for target_index() routine.
It looks like this:
int target_index(struct cpufreq_policy *policy, unsigned int index);
CPUFreq core will call cpufreq_frequency_table_target() before calling this
routine and pass index to it. Because CPUFreq core now requires to call routines
present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time.
This also marks target() interface as deprecated. So, that new drivers avoid
using it. And Documentation is updated accordingly.
It also converts existing .target() to newly defined light weight
.target_index() routine for many driver.
Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Russell King <linux@arm.linux.org.uk>
Acked-by: David S. Miller <davem@davemloft.net>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net>
|
| eaf8120e8f9c4efc71475b1e08b8e2d3e421e6ca |
|
03-Oct-2013 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: powernow: don't initialize part of policy set by core
Many common initializations of struct policy are moved to core now and hence
this driver doesn't need to do it. This patch removes such code.
Most recent of those changes is to call ->get() in the core after calling
->init().
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| d63bd27fe953daa402a108e141c36dcc59c6931c |
|
03-Oct-2013 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: powernow: Use generic cpufreq routines
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.
This patch uses these generic routines in the powernow driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| b147405aa8e568750bfa99501c7fa831edef47c9 |
|
16-Sep-2013 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: powernow: use cpufreq_table_validate_and_show()
Lets use cpufreq_table_validate_and_show() instead of calling
cpufreq_frequency_table_cpuinfo() and cpufreq_frequency_table_get_attr().
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| adc97d6a735dbb1e94cb4f1bf0b55f258b349941 |
|
06-Aug-2013 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: Drop the owner field from struct cpufreq_driver
We don't need to set .owner = THIS_MODULE any more in cpufreq drivers
as this field isn't used any more by the cpufreq core.
This patch removes it and updates all dependent drivers accordingly.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| d5b73cd870e2b049ef566aec2791dbf5fd26a7ec |
|
06-Aug-2013 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: Use sizeof(*ptr) convetion for computing sizes
Chapter 14 of Documentation/CodingStyle says:
The preferred form for passing a size of a struct is the following:
p = kmalloc(sizeof(*p), ...);
The alternative form where struct name is spelled out hurts
readability and introduces an opportunity for a bug when the pointer
variable type is changed but the corresponding sizeof that is passed
to a memory allocator is not.
This wasn't followed consistently in drivers/cpufreq, let's make it
more consistent by always following this rule.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| 2760984f6578d5a462155bb4727766d0c8b68387 |
|
19-Jun-2013 |
Paul Gortmaker <paul.gortmaker@windriver.com> |
cpufreq: delete __cpuinit usage from all cpufreq files
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications. For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.
After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out. Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.
This removes all the drivers/cpufreq uses of the __cpuinit macros
from all C files.
[1] https://lkml.org/lkml/2013/5/20/589
[v2: leave 2nd lines of args misaligned as requested by Viresh]
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
Acked-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
| 7f77a563f0c110a633b4ab0fec9f49d41630039a |
|
19-Jun-2013 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: powernow-k8: call CPUFREQ_POSTCHANGE notfier in error cases
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>
|
| 5070158804b5339c71809f5e673cea1cfacd804d |
|
30-Mar-2013 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: rename index as driver_data in cpufreq_frequency_table
The "index" field of struct cpufreq_frequency_table was never an
index and isn't used at all by the cpufreq core. It only is useful
for cpufreq drivers for their internal purposes.
Many people nowadays blindly set it in ascending order with the
assumption that the core will use it, which is a mistake.
Rename it to "driver_data" as that's what its purpose is. All of its
users are updated accordingly.
[rjw: Changelog]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| e9f51837c97d199dfa06ef448797c584755837a8 |
|
01-Apr-2013 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: Don't check if cpu is online/offline for cpufreq callbacks
cpufreq layer doesn't call cpufreq driver's callback for any offline
CPU and so checking that isn't useful.
Lets get rid of it.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| b43a7ffbf33be7e4d3b10b7714ee663ea2c52fe2 |
|
24-Mar-2013 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: Notify all policy->cpus in cpufreq_notify_transition()
policy->cpus contains all online cpus that have single shared clock line. And
their frequencies are always updated together.
Many SMP system's cpufreq drivers take care of this in individual drivers but
the best place for this code is in cpufreq core.
This patch modifies cpufreq_notify_transition() to notify frequency change for
all cpus in policy->cpus and hence updates all users of this API.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| c0939e46a84c6af89d6f093a34c1c9341dfe1d6e |
|
20-Jan-2013 |
Borislav Petkov <bp@suse.de> |
powernow-k8: Cleanup init function
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>
|
| 4827ea6ec9ca1e873a6d387a3ee287f78ea5ee83 |
|
20-Jan-2013 |
Borislav Petkov <bp@suse.de> |
powernow-k8: Cleanup module request
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>
|
| c0e61cb151f2ff8edd02af23b2bd49f625288124 |
|
21-Nov-2012 |
Bill Pemberton <wfp5p@virginia.edu> |
cpufreq: remove use of __devexit
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>
|
| ce2650d40dff23f2c6f9718bb3ec63e12c5c7f27 |
|
21-Nov-2012 |
Bill Pemberton <wfp5p@virginia.edu> |
cpufreq: remove use of __devexit_p
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>
|
| 29c4bcddaa62e2b9fd2ba85668f6718b0b43f0e3 |
|
31-Oct-2012 |
Andreas Herrmann <herrmann.der.user@googlemail.com> |
cpufreq / powernow-k8: Change maintainer's email address
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>
|
| e4df1cbcc1f329e53a1fff7450b2229e0addff20 |
|
23-Oct-2012 |
Andreas Herrmann <andreas.herrmann3@amd.com> |
cpufreq / powernow-k8: Remove usage of smp_processor_id() in preemptible code
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>
|
| 6889125b8b4e09c5e53e6ecab3433bed1ce198c9 |
|
18-Sep-2012 |
Tejun Heo <tj@kernel.org> |
cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU
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
|
| e1f0b8e9b04a262834ed111e605e5d215685dfab |
|
04-Sep-2012 |
Matthew Garrett <mjg@redhat.com> |
cpufreq: Remove support for hardware P-state chips from powernow-k8
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>
|
| a2060958569a8e8e36202c373a55c458ff84856d |
|
04-Sep-2012 |
Andre Przywara <andre.przywara@amd.com> |
powernow-k8: delay info messages until initialization has succeeded
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>
|
| 034be8fd645bb77ca623036dc24c790b6cc803e2 |
|
04-Sep-2012 |
Andre Przywara <andre.przywara@amd.com> |
cpufreq: Add warning message to powernow-k8
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>
|
| 56835e6cc053c29bf1a15a07dbeb78f219a15214 |
|
05-Sep-2012 |
Borislav Petkov <borislav.petkov@amd.com> |
cpufreq / powernow-k8: Fixup missing _PSS objects message
_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>
|
| fa8031aefec0cf7ea6c2387c93610d99d9659aa2 |
|
26-Jan-2012 |
Andi Kleen <ak@linux.intel.com> |
cpufreq: Add support for x86 cpuinfo auto loading v4
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>
|
| b2bd68e1d5568a3911e991fc71e083f439886d8c |
|
06-Jan-2012 |
Andreas Herrmann <andreas.herrmann3@amd.com> |
[CPUFREQ] powernow-k8: Update copyright, maintainer and documentation information
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Signed-off-by: Dave Jones <davej@redhat.com>
|
| a8eb28480e9b637cc78b9aa5e08612ba97e1317a |
|
06-Jan-2012 |
Andreas Herrmann <andreas.herrmann3@amd.com> |
[CPUFREQ] powernow-k8: Fix indexing issue
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>
|
| 201bf0f129e1715a33568d1563d9a75b840ab4d3 |
|
06-Jan-2012 |
Andreas Herrmann <andreas.herrmann3@amd.com> |
[CPUFREQ] powernow-k8: Avoid Pstate MSR accesses on systems supporting CPB
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>
|
| fbb5b89eabea5ae7d621b7861863159560d8faa4 |
|
16-Jun-2011 |
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> |
[CPUFREQ] powernow-k8: Don't try to transition if the pstate is incorrect
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>
|
| a9d3d2068064b7a6395871a49616d3784f802d50 |
|
16-Jun-2011 |
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> |
[CPUFREQ] powernow-k8: Don't notify of successful transition if we failed (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>
|
| bb0a56ecc4ba2a3db1b6ea6949c309886e3447d3 |
|
20-May-2011 |
Dave Jones <davej@redhat.com> |
[CPUFREQ] Move x86 drivers to drivers/cpufreq/
Signed-off-by: Dave Jones <davej@redhat.com>
|