- 27 Oct, 2004 34 commits
-
-
Dave Jones authored
Return -EINVAL instead of a non-error-value if the user echo'es something bad into attributes generated by the ondemand cpufreq governor. Signed-off-by:
Dominik Brodowski <linux@brodo.de> Signed-off-by:
Dave Jones <davej@redhat.com>
-
Dave Jones authored
Signed-off-by:
-
Dave Jones authored
Fixes the lack of MODULE_OWNER setting, and allows for code recuction. Signed-off-by:
-
Dave Jones authored
Signed-off-by:
-
Dave Jones authored
Fixes the lack of MODULE_OWNER setting [can't cause problems yet because cpufreq can only be built into the kernel], and allows for code reduction. Signed-off-by:
-
Dave Jones authored
so put #ifdefs around them. Signed-off-by:
-
Dave Jones authored
Signed-off-by:
-
Dave Jones authored
[CPUFREQ] Show the CPUs which can only change frequencies at the same time in a sysfs file named "affected_cpus". The usefulness of such a file was first noted by Zwane Mwaikambo. Signed-off-by:
-
Dave Jones authored
Signed-off-by:
-
Dave Jones authored
Signed-off-by:
-
Dave Jones authored
Signed-off-by:
-
Dave Jones authored
Signed-off-by:
-
Dave Jones authored
Also convert the driver's ACPI debug messages to cpufreq debug messages. Signed-off-by:
-
Dave Jones authored
Modified existing dprintks. Signed-off-by:
-
Dave Jones authored
Modified existing dprintks, and removed the driver-only debug module parameter. Signed-off-by:
-
Dave Jones authored
Modified existing dprintks, and removed the driver-only debug module parameter. Signed-off-by:
-
Dave Jones authored
Modified existing dprintks. Signed-off-by:
-
Dave Jones authored
and add some dprintks which might be / have been of interest. Signed-off-by:
-
Dave Jones authored
Modified existing dprintks and added a few which might be / have been of interest. Signed-off-by:
-
Dave Jones authored
Modified existing dprintks and added a few which might be / have been of interest, and cleared some whitespace/tab confusion. The big comment regarding which frequency to pass as "old" value wasn't up to date any longer in two regards: the driver's behaviour had changed, and the core is know able to handle such things... anyways, the comment could be removed. Signed-off-by:
-
Dave Jones authored
Modified existing dprintks and added a few which might be / have been of interest. Signed-off-by:
-
Dave Jones authored
Modified existing dprintks and added a few which might be / have been of interest. Signed-off-by:
-
Dave Jones authored
Modified existing dprintks and added a few which might be / have been of interest. Signed-off-by:
-
Dave Jones authored
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: -
Dave Jones authored
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:
-
Dave Jones authored
Signed-off-by:
-
Dave Jones authored
The "acpi" cpufreq driver uses the far too generic module name "acpi". Fix it by renaming it to "cpufreq-acpi". A MODULE_ALIAS("acpi"); will allow for backwards-compatible naming until 2005-06-30. Signed-off-by: -
Dave Jones authored
Thanks to Brian Miles for debugging this issue. Signed-off-by:
-
Dave Jones authored
Signed-off-by:
-
Dave Jones authored
Signed-off-by:
-
Dave Jones authored
Signed-off-by:
-
Dave Jones authored
Signed-off-by:
-
Dave Jones authored
Some BIOSes export invalid _PSS entries where all bits are set to one. While this is totally contrary to the ACPI specification, BIOS vendors try to tell userspace that these entries should not be considered or used. In order to not fail on such entries, the speedstep-centrino already contains a method to ignore these things. However, due to a wrong ordering of checks the driver aborts nonetheless. So move some checks around. Signed-off-by:
-
Dave Jones authored
Sometimes, a user or userspace daemon wants a specific frequency is set, but that frequency is (temporarily) unavailable or becomes unavailable due to e.g. thermal considerations. As soon as this situation changes, the user wish should be re-evaluated. The attached patch saves the user wish in "cpu_set_freq", and re-uses that whenever appropriate. Thanks to Thomas Renninger for testing. Signed-off-by:
-
- 26 Oct, 2004 6 commits
-
-
bk://gkernel.bkbits.net/libata-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
bk://gkernel.bkbits.net/net-drivers-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Andrew Morton authored
We decided to do this a different way. Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
bk://kernel.bkbits.net/davem/net-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Roland McGrath authored
In general it is not safe to do any non-ptrace wakeup of a thread in TASK_TRACED, because the waking thread could race with a ptrace call that could be doing things like mucking directly with its kernel stack. AFAIK noone has established that whatever clobberation ptrace can do to a running thread is safe even if it will never return to user mode, so we can't allow this even for SIGKILL. What we _can_ safely do is make a thread switching out of TASK_TRACED resume rather than sitting in TASK_STOPPED if it has a pending SIGKILL or SIGCONT. The following patch does this. This should be sufficient for the shutdown case. When killing all processes, if the tracer gets killed first, the tracee goes into TASK_STOPPED and will be woken and killed by the SIGKILL (same as before). If the tracee gets killed first, it gets a pending SIGKILL and doesn't wake up immediately--but, now, when the tracer gets killed, the tracee will then wake up to die. This will also fix the (same) situations that can arise now where you have used gdb (or whatever ptrace caller), killed -9 the gdb and the process being debugged, but still have to kill -CONT the process before it goes away (now it should just go away either the first time or when you kill gdb). Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
-
Benjamin Herrenschmidt authored
This is a batch of sparse fixes for things in arch/ppc64/* and include/asm-ppc64/* More to come of course... Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
