- 10 4月, 2010 1 次提交
-
-
由 Mark Langsdorf 提交于
Starting with model 10 of Family 0x10, AMD processors may have support for APERF/MPERF. Add support for identifying it and using it within cpufreq. Move the APERF/MPERF functions out of the acpi-cpufreq code and into their own file so they can easily be shared. Signed-off-by: NMark Langsdorf <mark.langsdorf@amd.com> LKML-Reference: <20100401141956.GA1930@aftab> Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Reviewed-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
- 13 1月, 2010 1 次提交
-
-
由 Naga Chumbalkar 提交于
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: NNaga Chumbalkar <nagananda.chumbalkar@hp.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 25 2月, 2009 1 次提交
-
-
由 Matthew Garrett 提交于
Change the link order of the cpufreq modules to ensure that they're probed in the preferred order when statically linked in. Signed-off-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 11 10月, 2007 1 次提交
-
-
由 Thomas Gleixner 提交于
Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 11 2月, 2007 1 次提交
-
-
由 Rafa Bilski 提交于
This is driver for Enhanced Powersaver which is present in VIA C7 processors. Beta tested by Jorgen (jorgen (at) greven dot dk). Thanks! Based on documentation provided by Dave Jones (Thanks!) and C7 Eden datasheet available from www.via.com.tw. Looks like all these C7 Eden CPU's don't have P-states in BIOS. I know that 2 p-states is low, but Jorgen finds it usefull anyway because board is passive cooled. There are 3 different types of C7 processors (called brands): 0. C7-M - these processors can set any maultiplier between min and max, any voltage between min and max. 1. C7 - only min and max states are supported. Voltage is different for min and max states. 2. Eden - only min and max states are supported. Looks like this brand can only change multiplier. Voltage seems to be the same for min and max frequency. Signed-off-by: NRafal Bilski <rafalbilski@interia.pl> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 16 10月, 2006 1 次提交
-
-
由 Venkatesh Pallipadi 提交于
Mark ACPI hooks in speedstep-centrino as deprecated. Change the order in which speedstep-centrino and acpi-cpufreq (when both are in kernel) will be added. First driver to be tried is now acpi-cpufreq, followed by speedstep-centrino. Add a note in feature-removal-schedule to mark this deprecation. Signed-off-by: NDenis Sadykov <denis.m.sadykov@intel.com> Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: NAlexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 01 6月, 2005 1 次提交
-
-
由 Dave Jones 提交于
From: Sean Young <sean@mess.org> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus 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!
-