aboutsummaryrefslogtreecommitdiff
path: root/Documentation/cpu-freq/user-guide.txt
AgeCommit message (Collapse)Author
2009-09-01[CPUFREQ] update Doc for cpuinfo_cur_freq and scaling_cur_freqNaga Chumbalkar
I think the way "cpuinfo_cur_info" and "scaling_cur_info" are defined under ./Documentation/cpu-freq/user-guide.txt can be enhanced. Currently, they are both defined the same way: "Current speed/frequency" of the CPU, in KHz". Below is a patch that distinguishes one from the other. Regards, - naga - ----------------------------------------- Update description for "cpuinfo_cur_freq" and "scaling_cur_freq". Some of the wording is drawn from comments found in ./drivers/cpufreq/cpufreq.c: cpufreq_out_of_sync(): * @old_freq: CPU frequency the kernel thinks the CPU runs at * @new_freq: CPU frequency the CPU actually runs at Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com> Signed-off-by: Dave Jones <davej@redhat.com>
2009-06-15[CPUFREQ] minor correction to cpu-freq documentationChumbalkar Nagananda
I have been reading the documentation for cpufreq closely. Found a couple of minor errors in the Documentation. Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com> Signed-off-by: Dave Jones <davej@redhat.com>
2009-02-24[CPUFREQ] Introduce ↵Thomas Renninger
/sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_transition_latency It's not only useful for the ondemand and conservative governors, but also for userspace daemons to know about the HW transition latency of the CPU. It is especially useful for userspace to know about this value when the ondemand or conservative governors are run. The sampling rate control value depends on it and for userspace being able to set sane tuning values there it has to know about the transition latency. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Dave Jones <davej@redhat.com>
2009-02-04ACPI: cpufreq: Remove deprecated /proc/acpi/processor/../performance proc ↵Thomas Renninger
entries They were long enough set deprecated... Update Documentation/cpu-freq/users-guide.txt: The deprecated files listed there seen not to exist for some time anymore already. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-22doc: Update sh cpufreq documentation.Paul Mundt
The sh cpufreq driver is no longer limited to just the SH-3 and SH-4, update the documentation to reflect this fact accordingly. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2008-11-25[CPUFREQ] Documentation: Add Blackfin to list of supported processorsRobin Getz
Signed-off-by: Robin Getz <rgetz@blackfin.uclinux.org> Signed-off-by: Bryan Wu <cooloney@kernel.org> Signed-off-by: Dave Jones <davej@redhat.com>
2008-04-28[CPUFREQ] document the currently undocumented parts of the sysfs interfaceDarrick J. Wong
There is a description of some of the sysfs files. However, there are some that are not mentioned in the documentation, so add them to the user's guide. Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Jones <davej@redhat.com>
2008-01-26[ARM] pxa: add cpufreq supportRussell King
There have been patches hanging around for ages to add support for cpufreq to PXA255 processors. It's about time we applied one. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-07-31[CPUFREQ] return error when failing to set minfreqMattia Dongili
I just stumbled on this bug/feature, this is how to reproduce it: # echo 450000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq # echo 450000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq # echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor # cpufreq-info -p 450000 450000 powersave # echo 1800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq ; echo $? 0 # cpufreq-info -p 450000 450000 powersave Here it is. The kernel refuses to set a min_freq higher than the max_freq but it allows a max_freq lower than min_freq (lowering min_freq also). This behaviour is pretty straightforward (but undocumented) and it doesn't return an error altough failing to accomplish the requested action (set min_freq). The problem (IMO) is basically that userspace is not allowed to set a full policy atomically while the kernel always does that thus it must enforce an ordering on operations. The attached patch returns -EINVAL if trying to increase frequencies starting from scaling_min_freq and documents the correct ordering of writes. Signed-off-by: Mattia Dongili <malattia@linux.it> Signed-off-by: Dominik Brodowski <linux at dominikbrodowski.net> Signed-off-by: Dave Jones <davej@redhat.com> --
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!