17 May, 2014
1 commit
-
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 lineAlso, define the pr_fmt macro instead of PFX for the module name.
Signed-off-by: Stratos Karafotis
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
07 Apr, 2014
1 commit
-
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
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
26 Mar, 2014
1 commit
-
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
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
12 Mar, 2014
1 commit
-
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
Signed-off-by: Rafael J. Wysocki
19 Feb, 2014
1 commit
-
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
Signed-off-by: Srivatsa S. Bhat
Cc: All applicable
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
06 Jan, 2014
1 commit
-
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-oldThe 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
[rjw: Folded 3 patches into one, rebased unicore2 changes]
Signed-off-by: Rafael J. Wysocki
31 Oct, 2013
1 commit
-
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
Acked-by: Kukjin Kim
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
26 Oct, 2013
1 commit
-
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
Acked-by: Jesper Nilsson
Acked-by: Linus Walleij
Acked-by: Russell King
Acked-by: David S. Miller
Tested-by: Andrew Lunn
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
16 Oct, 2013
2 commits
-
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
Signed-off-by: Rafael J. Wysocki -
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
Signed-off-by: Rafael J. Wysocki
01 Oct, 2013
1 commit
-
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
Signed-off-by: Rafael J. Wysocki
10 Aug, 2013
1 commit
-
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
Signed-off-by: Rafael J. Wysocki
08 Aug, 2013
1 commit
-
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
Signed-off-by: Rafael J. Wysocki
15 Jul, 2013
1 commit
-
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"
Cc: Viresh Kumar
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Acked-by: Dirk Brandewie
Acked-by: Viresh Kumar
Signed-off-by: Paul Gortmaker
24 Jun, 2013
1 commit
-
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
Signed-off-by: Rafael J. Wysocki
04 Jun, 2013
1 commit
-
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
Acked-by: Simon Horman
Signed-off-by: Rafael J. Wysocki
02 Apr, 2013
2 commits
-
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
Acked-by: David S. Miller
Signed-off-by: Rafael J. Wysocki -
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
Acked-by: Stephen Warren
Tested-by: Stephen Warren
Signed-off-by: Rafael J. Wysocki
02 Feb, 2013
2 commits
-
Make it hotplug-safe and cleanup formatting.
Signed-off-by: Borislav Petkov
Signed-off-by: Rafael J. Wysocki -
Check whether we've actually already loaded acpi-cpufreq before
requesting it.Signed-off-by: Borislav Petkov
Signed-off-by: Rafael J. Wysocki
21 Nov, 2012
2 commits
-
CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.Signed-off-by: Bill Pemberton
Signed-off-by: Rafael J. Wysocki -
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.Signed-off-by: Bill Pemberton
Signed-off-by: Rafael J. Wysocki
01 Nov, 2012
1 commit
-
Change the Andreas' email address in drivers/cpufreq/powernow-k8.c.
Signed-off-by: Andreas Herrmann
Signed-off-by: Rafael J. Wysocki
23 Oct, 2012
1 commit
-
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:
[] debug_smp_processor_id+0xc7/0xe0
[] powernowk8_target+0x20/0x49
[] __cpufreq_driver_target+0x82/0x8a
[] cpufreq_governor_performance+0x4e/0x54
[] __cpufreq_governor+0x8c/0xc9
[] __cpufreq_set_policy+0x1a9/0x21e
[] store_scaling_governor+0x16f/0x19b
[] ? cpufreq_update_policy+0x124/0x124
[] ? _raw_spin_unlock_irqrestore+0x2c/0x49
[] store+0x60/0x88
[] sysfs_write_file+0xf4/0x130
[] vfs_write+0xb5/0x151
[] sys_write+0x4a/0x71
[] system_call_fastpath+0x16/0x1bFix this by by always using work_on_cpu().
Signed-off-by: Andreas Herrmann
Cc: stable@vger.kernel.org
Signed-off-by: Rafael J. Wysocki
03 Oct, 2012
1 commit
-
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
...
20 Sep, 2012
1 commit
-
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
Reported-by: Duncan
Tested-by: Duncan
Cc: Rafael J. Wysocki
Cc: Andreas Herrmann
Cc: stable@vger.kernel.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47301
10 Sep, 2012
3 commits
-
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
Signed-off-by: Andre Przywara
Signed-off-by: Rafael J. Wysocki -
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
Signed-off-by: Rafael J. Wysocki -
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
Signed-off-by: Rafael J. Wysocki
05 Sep, 2012
1 commit
-
_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
Signed-off-by: Borislav Petkov
Signed-off-by: Rafael J. Wysocki
27 Jan, 2012
1 commit
-
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 loadingCc: Dave Jones
Cc: Kay Sievers
Signed-off-by: Andi Kleen
Signed-off-by: Thomas Renninger
Acked-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman
06 Jan, 2012
3 commits
-
Signed-off-by: Andreas Herrmann
Signed-off-by: Dave Jones -
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 -
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
17 Jun, 2011
2 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
20 May, 2011
1 commit
-
Signed-off-by: Dave Jones
