user/sven/linux.git/Documentation/cpu-freq, branch v3.0.92

[CPUFREQ] Add documentation for sampling_down_factor

2011-03-16T21:54:31Z

Update cpufreq governor documentation for sampling_down_factor tunable parameter. Signed-off-by: Vishwanath BS Signed-off-by: Dave Jones

[CPUFREQ] Processor Clocking Control interface driver

2010-01-13T15:55:16Z

Processor Clocking Control (PCC) is an interface between the BIOS and OSPM. Based on the server workload, OSPM can request what frequency it expects from a logical CPU, and the BIOS will achieve that frequency transparently. This patch introduces driver support for PCC. OSPM uses the PCC driver to communicate with the BIOS via the PCC interface. There is a Documentation file that provides a link to the PCC Specification, and also provides a summary of the PCC interface. Currently, certain HP ProLiant platforms implement the PCC interface. However, any platform whose BIOS implements the PCC Specification, can utilize this driver. V2 --> V1 changes (based on Dominik's suggestions): - Removed the dependency on CPU_FREQ_TABLE - "cpufreq_stats" will no longer PANIC. Actually, it will not load anymore because it is not applicable. - Removed the sanity check for target frequency in the ->target routine. NOTE: A patch to sanitize the target frequency requested by "ondemand" is needed to ensure that the target freq < policy->min. Can this driver be queued up for the 2.6.33 tree? Signed-off-by: Naga Chumbalkar Signed-off-by: Matthew Garrett Signed-off-by: Thomas Renninger Signed-off-by: Dave Jones

[CPUFREQ] fix default value for ondemand governor

2010-01-13T15:55:15Z

Signed-off-by: Mike Frysinger Signed-off-by: Dave Jones

[ACPI/CPUFREQ] Introduce bios_limit per cpu cpufreq sysfs interface

2009-11-24T18:33:34Z

This interface is mainly intended (and implemented) for ACPI _PPC BIOS frequency limitations, but other cpufreq drivers can also use it for similar use-cases. Why is this needed: Currently it's not obvious why cpufreq got limited. People see cpufreq/scaling_max_freq reduced, but this could have happened by: - any userspace prog writing to scaling_max_freq - thermal limitations - hardware (_PPC in ACPI case) limitiations Therefore export bios_limit (in kHz) to: - Point the user that it's the BIOS (broken or intended) which limits frequency - Export it as a sysfs interface for userspace progs. While this was a rarely used feature on laptops, there will appear more and more server implemenations providing "Green IT" features like allowing the service processor to limit the frequency. People want to know about HW/BIOS frequency limitations. All ACPI P-state driven cpufreq drivers are covered with this patch: - powernow-k8 - powernow-k7 - acpi-cpufreq Tested with a patched DSDT which limits the first two cores (_PPC returns 1) via _PPC, exposed by bios_limit: # echo 2200000 >cpu2/cpufreq/scaling_max_freq # cat cpu*/cpufreq/scaling_max_freq 2600000 2600000 2200000 2200000 # #scaling_max_freq shows general user/thermal/BIOS limitations # cat cpu*/cpufreq/bios_limit 2600000 2600000 2800000 2800000 # #bios_limit only shows the HW/BIOS limitation CC: Pallipadi Venkatesh CC: Len Brown CC: davej@codemonkey.org.uk CC: linux@dominikbrodowski.net Signed-off-by: Thomas Renninger Signed-off-by: Dave Jones

[CPUFREQ] Document units for transition latency

2009-11-24T18:33:34Z

They're documented in the header but not in Documentation. Signed-off-by: Mark Brown Signed-off-by: Dave Jones

[CPUFREQ] update Doc for cpuinfo_cur_freq and scaling_cur_freq

2009-09-01T16:45:09Z

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 Signed-off-by: Dave Jones

[CPUFREQ] minor correction to cpu-freq documentation

2009-06-15T15:49:42Z

I have been reading the documentation for cpufreq closely. Found a couple of minor errors in the Documentation. Signed-off-by: Naga Chumbalkar Signed-off-by: Dave Jones

[CPUFREQ] Only set sampling_rate_max deprecated, sampling_rate_min is useful

2009-06-15T15:49:41Z

Update the documentation accordingly. Cleanup and use printk_once. Signed-off-by: Thomas Renninger Signed-off-by: Dave Jones

[CPUFREQ] ondemand/conservative: sanitize sampling_rate restrictions

2009-02-25T03:47:31Z

Limit sampling rate to transition_latency * 100 or kernel limits. If sampling_rate is tried to be set too low, set the lowest allowed value. Signed-off-by: Thomas Renninger Signed-off-by: Dave Jones

[CPUFREQ] ondemand/conservative: deprecate sampling_rate{min,max}

2009-02-25T03:47:31Z

The same info can be obtained via the transition_latency sysfs file Signed-off-by: Thomas Renninger Signed-off-by: Dave Jones