| Age | Commit message (Collapse) | Author |
|---|
|
This one fell through the automation at first because it initializes the
semaphore to locked, but that's easily remedied
Signed-off-by: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Dave Jones <davej@redhat.com>
drivers/cpufreq/cpufreq.c | 37 +++++++++++++++++++------------------
include/linux/cpufreq.h | 3 ++-
2 files changed, 21 insertions(+), 19 deletions(-)
|
|
What is the value shown in "cpu MHz" of /proc/cpuinfo when CPUs are capable of
changing frequency?
Today the answer is: It depends.
On i386:
SMP kernel - It is always the boot frequency
UP kernel - Scales with the frequency change and shows that was last set.
On x86_64:
There is one single variable cpu_khz that gets written by all the CPUs. So,
the frequency set by last CPU will be seen on /proc/cpuinfo of all the
CPUs in the system. What you see also depends on whether you have constant_tsc
capable CPU or not.
On ia64:
It is always boot time frequency of a particular CPU that gets displayed.
The patch below changes this to:
Show the last known frequency of the particular CPU, when cpufreq is present. If
cpu doesnot support changing of frequency through cpufreq, then boot frequency
will be shown. The patch affects i386, x86_64 and ia64 architectures.
Signed-off-by: Venkatesh Pallipadi<venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
|
|
I recently picked up my older work to remove unnecessary #includes of
sched.h, starting from a patch by Dave Jones to not include sched.h
from module.h. This reduces the number of indirect includes of sched.h
by ~300. Another ~400 pointless direct includes can be removed after
this disentangling (patch to follow later).
However, quite a few indirect includes need to be fixed up for this.
In order to feed the patches through -mm with as little disturbance as
possible, I've split out the fixes I accumulated up to now (complete for
i386 and x86_64, more archs to follow later) and post them before the real
patch. This way this large part of the patch is kept simple with only
adding #includes, and all hunks are independent of each other. So if any
hunk rejects or gets in the way of other patches, just drop it. My scripts
will pick it up again in the next round.
Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Fix u32 vs pm_message_t confusion in cpufreq.
Signed-off-by: Bernard Blackham <bernard@blackham.com.au>
Signed-off-by: Pavel Machek <pavel@suse.cz>
Cc: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Fix up comment in cpufreq.h stating transition latency should be passed
in microseconds -- it was decided long ago to switch to nanoseconds.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Dave Jones <davej@redhat.com>
|
|
In order to properly fix some issues with cpufreq vs. sleep on
PowerBooks, I had to add a suspend callback to the pmac_cpufreq driver.
I must force a switch to full speed before sleep and I switch back to
previous speed on resume.
I also added a driver flag to disable the warnings in suspend/resume
since it is expected in this case to have different speed (and I want it
to fixup the jiffies properly).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Remove the deprecated /proc/cpufreq interface. The same input is available
using cpufreq-info --proc from cpufrequtils.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>
|
|
Remove the deprecated /proc/sys/cpu/ interface to cpufreq.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>
|
|
From: "Zou, Nanhai" <nanhai.zou@intel.com>
Export cpufreq transition information for drivers using the freq-table helpers
via sysfs.
Two minor updates from Dominik Brodowski:
s/translation/transition
Kconfig re-ordering
Signed-off-by: Dave Jones <davej@redhat.com>
|
|
cpufreq_debug_printk will print messages if
a) debugging for the specified part is activated (add
1 for core,
2 for drivers,
4 for governors
and pass value as
cpufreq.debug=<value>
on the kernel command line).
b) and either
b1) printk_ratelimit() allows it to be printed,
b2) the user disables ratelimit'ing by passing
cpufreq.debug_ratelimit=0
on the kernel command line, _or_
b3) during driver initialization [unless a different
driver has been initialized successfully] and
unloading, and whenever a new policy is set.
The last point may cause for numerous messages
if an userspace-based dynamic governor is used
which mis-uses the policy interface to set specific
frequencies. Oh, the ACPI processor.c interface
to the file "performance" uses the same trick,
but that interface is marked deprecated as well,
so I don't care. And debugging isn't activated
normally, you know...
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>
|
|
Clarify that cpufreq_set() and cpufreq_setmax() are parts of the 2.4. API
to the userspace governor which will be removed soon after 2005-01-01.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>
|
|
Save the "affected_cpu_map" used in SMT-aware drivers in struct
cpufreq_policy->(cpumask_t) cpus, and use it wherever possible. In
most cases, the ->get() function is only allowed to run on one CPU [the
one passed as argument] to keep code simpler, and as that code path
isn't executed often, and only root can do it anyway.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>
|
|
The SA1100 and SA1110 platforms can handle situations well where the
CPU frequency is different to the value the cpufreq (and timing) code
thinks it is, e.g. when resuming from sleep. So, remove the flags
noting the opposite.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.de>
Signed-off-by: Dave Jones <davej@redhat.com>
|
|
Currently, the TSC cpufreq notifiers does almost nothing on P4s, as we
assumed the TSC to be constant independent of _all_ frequency transitions.
Extensive testing by Karol Kozimor has shown, though, that only _throttling_
does not affect the TSC, but _scaling_ does.
So:
- pass the CPUFREQ_CONST_LOOPS flags (to be exact, all flags) to cpufreq
transition notifiers
- skip TSC value changes if this flag is set
- set this flag for P4 / P4-Ms only in p4-clockmod [On Pentium-M banias
the TSC _is_ affected by p4-clock modulation
|
|
Upon resuming, first CPUfreq hardware support needs to be re-enabled in certain cases
(call to cpufreq_driver->resume()).
Then, two different paths may need to be taken:
a) frequency during suspend equals frequency during resume ==> everything is fine,
b) frequency differ ==> either we can't handle it, then panic (see flag
CPUFREQ_PANIC_RESUME_OUTOFSYNC). Or we can handle it, then notify all
|
|
Sometimes we might discover during a call to cpufreq_get() that we're "out of sync",
meaning the actual CPU frequency changed "behind our back". If this happens, the flag
CPUFREQ_PANIC_OUTOFSYNC decides what can be done: if it is set, the kernel panic's,
it it is not set, the cpufreq transition notifiers are informed of this change, and
a call to cpufreq_update_policy() is scheduled [using the default workqueue] so that
the user-defined values override BIOS / external interaction.
|
|
Contrary to the previous implementation, it now calls the cpufreq driver,
and reads out the _actual_ current frequency, and not the frequency the
CPUfreq core _thinks_ the CPU is running at. Most cpufreq drivers do provide
such a "hw get" function (only ACPI-io can definitely not be supported,
I'm not sure about sh, sparc64 and powermac) anyway, and it is useful for
other issues.
|
|
Some cpufreq drivers can only tell whether they work while the per-CPU
->init() function is executed [e.g. the acpi driver]. So that cpufreq_driver
isn't blocked by such stale drivers, unload them unless the driver sets a
special flag.
|
|
From: Dominik Brodowski <linux@dominikbrodowski.de>
Use do_div on 32-bit archs in cpufreq_scale, and native "/" on 64-bit
archs.
|
|
sometimes nanoseconds are used, sometimes microseconds, sometimes even something else.
|
|
|
|
into home.osdl.org:/home/torvalds/v2.5/linux
|
|
Add a new cpufreq_update_policy call:
Certain cpufreq policy notifers have different needs at different times.
Thus it needs to be possible to re-evaluate an already set cpufreq policy.
Note that the cpufreq policy should only be set by one person: the user.
Not any other in-kernel code [with one exception, of course: during
booting].
|
|
|
|
speedstep-smi.
|
|
Governors are for CPUfreq drivers which have a ->target callback,
Policies are for CPUfreq drivers which have a ->setpolicy callback.
Also, the "hardwired" governors "powersave" and "performance" are removed.
|
|
|
|
|
|
Implement per-CPU memory allocation. Is a bit cleaner than the
previous "once and for all" approach.
|
|
Finally implement the two different cpufreq_driver_target callbacks --
the one called while the per-CPU lock is held, the other while
not. While we're at it, clean up cpufreq_governor.
|
|
- CPUFREQ_ALL_CPUS is not a valid argument any more, don't mention it
in include/linux/cpufreq.h
- without a driver->init() function a cpufreq driver isn't even
loaded, so remove that check in the per-CPU initialization
- whitespace and clarification changes to linux/cpufreq.
All from Dominik again..
|
|
Wait with the destruction of cpufreq objects until all references
are gone (code partly based on rmk's comparable patch for the PCMCIA
subsystem.
From Dominik.
|
|
|
|
- Remove explicit call from arm PM sequence, as its handled implicitly
by sysdev_restore() in driver model core.
|
|
From: Zwane Mwaikambo <zwane@linuxpower.ca>
The proc interface has no way of telling wether there is an active cpufreq
driver or not. This means that if you don't have a cpufreq supported
processor, this will oops in various possible places.
|
|
|
|
This patch lets cpufreq drivers export per-CPU files in the cpufreq and
cpu-specific sysfs directory. As an example, a file
"scaling_available_frequencies" is added to the p4-clockmod.c driver.
|
|
This patch takes use of the now-working cpufreq_interface.kset and
cpufreq_policy.kobj to use reference counting within the cpufreq core
wherever this is more appropriate than the previous approach -- using one
semaphore. Additionally, the callbacks to the driver modules are protected
now.
|
|
- no cpufreq driver uses the frequency table helper "setpolicy" any more
("target" is much more appropriate for them anyways) - so remove
that helper
- all cpufreq drivers use the advanced registration process, so some
compatibility code can safely be removed.
|
|
Let's put the sysfs file exported by the cpufreq userspace governor also
into the cpufreq/ - subdirectory of /sys/devices/sys/cpu0/.
|
|
- Create and register kobjects when adding a cpu to the cpufreq interface,
instead of the terminally broken struct intf_data.
ACKed by Dominik Brodowski.
|
|
The old /proc/sys/cpu/ - based interface is nothing else than a
cpufreq governor which decides what frequency to use within a policy
based on userspace input. So, convert this interface (and add a
corresponding sysfs file, /sys/devices/sys/cpu0/scaling_setspeed) to
become a cpufreq governor, and move it out to an extra module (which
partly explains the size of this patch).
|
|
here's the compile fix for this breakage which appears if CONFIG_ACPI &&
!(CONFIG_CPU_FREQ_TABLE || CONFIG_CPU_FREQ_TABLE_MODULE).
|
|
The deprecated /proc/cpufreq interface can easily live outside the
cpufreq core now.
|
|
The CPU frequency table helpers can easily be modularized --
especially as they are not needed on all architectures, or for
all drivers (even on x86 -- see longrun and gx-suspmod)
|
|
More bits from Dominik.
Most cpufreq drivers (in fact, all except one, longrun) or even most
cpu frequency scaling algorithms only offer the CPU to be set to one
frequency. In order to offer dynamic frequency scaling, the cpufreq
core must be able to tell these drivers of a "target frequency". So
these specific drivers will be transformed to offer a "->target"
call instead of the existing "->setpolicy" call. For "longrun", all
stays the same, though.
How to decide what frequency within the CPUfreq policy should be used?
That's done using "cpufreq governors". Two are already in this patch
-- they're the already existing "powersave" and "performance" which
set the frequency statically to the lowest or highest frequency,
respectively. At least two more such governors will be ready for
addition in the near future, but likely many more as there are various
different theories and models about dynamic frequency scaling
around. Using such a generic interface as cpufreq offers to scaling
governors, these can be tested extensively, and the best one can be
selected for each specific use.
Basically, it's the following flow graph:
CPU can be set to switch independetly | CPU can only be set
within specific "limits" | to specific frequencies
"CPUfreq policy"
consists of frequency limits (policy->{min,max})
and CPUfreq governor to be used
/ \
/ \
/ the cpufreq governor decides
/ (dynamically or statically)
/ what target_freq to set within
/ the limits of policy->{min,max}
/ \
/ \
Using the ->setpolicy call, Using the ->target call,
the limits and the the frequency closest
"policy" is set. to target_freq is set.
It is assured that it
is within policy->{min,max}
|
|
- fix cpufreq drivers compilation on not-bleeding-edge-gcc's (Adrian Bunk)
- gx-suspmod.c hasn't had a name yet
|
|
Allow for per-CPU initialization of CPUfreq. Therefore, it's not
necessary any longer to kmalloc the per-CPU policy struct. To use
this, cpufreq_driver->policy has to be set to NULL. Of course,
cpufreq_driver->init is needed then, which is the appropriate function
for CPU initialization. cpufreq_driver->exit is available for cleanup.
All existing drivers continue to work without any changes, just for
clarity ->init and ->exit are set to NULL, and the names accordingly.
|
|
This patch adds a sysfs interface to the cpufreq core, and marks the
previous /proc/cpufreq interface as deprecated.
As in drivers/base/cpu.c a "CPU driver" is registered, cpufreq acts as
"interface" to this, offering the following files for each CPU
(in /system/devices/sys/cpu.../) where CPUfreq support is present
cpuinfo_min_freq (ro) - minimum frequency (in kHz) the CPU supports
cpuinfo_max_freq (ro) - maximum frequency (in kHz) the CPU supports
scaling_min_freq (rw) - minimum frequency (in kHz) cpufreq may scale
the CPU core to
scaling_max_freq (rw) - maximum frequency (in kHz) cpufreq may scale
the CPU core to
scaling_governor (rw) - governor == "A feedback device on a machine
or engine that is used to provide
automatic control, as of speed,
pressure, or temperature" [1, as noted
by David Kimdon]. Decides what frequency
is used. Currently, only "performance"
and "powersave" are supported, more may
be added later.
(In future, a file scaling_driver (ro) which shows what CPUfreq driver
is used (arm-sa1100, gx-suspmod, speedstep, longrun, powernow-k6,
...) might be added, and this driver will be allowed to add files
scaling_driver_* for driver-specific settings like "prefer fast FSB".
And scaling_governor_* files might offer settings for the governor.)
To implement this sysfs interface, the driver model "interface" code
is used. Unfortunately, it has a non-trivial locking bug in
drivers/base/intf.c: there's a down_write call for
cls->subsys.rwsem in add_intf(), which then calls add(), which may call
intf->add_device(), which may call interface_add_data(), which calls
kobject_register(), which calls kobject_add(), which then tries to
down_write cls->subsys.rwsem. Remember, that was already locked writable
in add_intf().
Because of that, interface_add_data() is commented out; this means
that no link in /system/class/cpu/cpufreq is added, and that the
dev-removal code isn't called. This shouldn't be a problem yet,
though; as no cpufreq driver I know of is capable of CPU hotplugging.
Dominik
[1] http://dictionary.reference.com/search?q=governor
|
|
This patch adds "frequency table helpers" to kernel/cpufreq.c and
updates some drivers to use them.
Most CPU frequency scaling methods only support a few static
frequencies. In these drivers a lot of duplicated code existed in the
->setpolicy and ->verify calls.
Please note that this in no way changes the behaviour of cpufreq or of
the ->setpolicy or ->verify calls. These "frequency table helpers"
aren't for drivers which either only support policies (longrun) or
really many frequency states (ARM, gx-suspmod).
|
