An error occurred fetching the project authors.
- 10 Feb, 2004 1 commit
-
-
Dave Jones authored
Reverting frequency changes on unloading is uncommon for cpufreq drivers so let's remove this speciality.
-
- 19 Jan, 2004 1 commit
-
-
Andrew Morton authored
From: Dominik Brodowski <linux@dominikbrodowski.de> Too many users use the p4-clockmod cpufreq driver instead of the more advanced speedstep-centrino, speedstep-ich or even acpi drivers. All of the latter (usually) provide voltage scaling, while the p4-clockmod driver only offers a variant of frequency scaling. So, warn users if they try out this driver instead. Also, instead of using a local copy, use the speedstep_lib infrastructure for detecting the processor speed. Adding the Pentium-M get_frequency function to that module only costs about 200 bytes in object size.
-
- 13 Jan, 2004 1 commit
-
-
Dave Jones authored
<Dominik Brodowski> Too many users use the p4-clockmod cpufreq driver instead of the more advanced speedstep-centrino, speedstep-ich or even acpi drivers. All of the latter (usually) provide voltage scaling, while the p4-clockmod driver only offers a variant of frequency scaling. So, warn users if they try out this driver instead. Also, instead of using a local copy, use the speedstep_lib infrastructure for detecting the processor speed. Adding the Pentium-M get_frequency function to that module only costs about 200 bytes in object size.
-
- 05 Jan, 2004 2 commits
-
-
Dave Jones authored
sometimes nanoseconds are used, sometimes microseconds, sometimes even something else.
-
Dave Jones authored
-
- 17 Sep, 2003 1 commit
-
-
Dave Jones authored
-
- 03 Sep, 2003 1 commit
-
-
Dave Jones authored
-
- 18 Aug, 2003 1 commit
-
-
Andrew Morton authored
From: William Lee Irwin III <wli@holomorphy.com> Contributions from: Jan Dittmer <jdittmer@sfhq.hn.org> Arnd Bergmann <arnd@arndb.de> "Bryan O'Sullivan" <bos@serpentine.com> "David S. Miller" <davem@redhat.com> Badari Pulavarty <pbadari@us.ibm.com> "Martin J. Bligh" <mbligh@aracnet.com> Zwane Mwaikambo <zwane@linuxpower.ca> It has ben tested on x86, sparc64, x86_64, ia64 (I think), ppc and ppc64. cpumask_t enables systems with NR_CPUS > BITS_PER_LONG to utilize all their cpus by creating an abstract data type dedicated to representing cpu bitmasks, similar to fd sets from userspace, and sweeping the appropriate code to update callers to the access API. The fd set-like structure is according to Linus' own suggestion; the macro calling convention to ambiguate representations with minimal code impact is my own invention. Specifically, a new set of inline functions for manipulating arbitrary-width bitmaps is introduced with a relatively simple implementation, in tandem with a new data type representing bitmaps of width NR_CPUS, cpumask_t, whose accessor functions are defined in terms of the bitmap manipulation inlines. This bitmap ADT found an additional use in i386 arch code handling sparse physical APIC ID's, which was convenient to use in this case as the accounting structure was required to be wider to accommodate the physids consumed by larger numbers of cpus. For the sake of simplicity and low code impact, these cpu bitmasks are passed primarily by value; however, an additional set of accessors along with an auxiliary data type with const call-by-reference semantics is provided to address performance concerns raised in connection with very large systems, such as SGI's larger models, where copying and call-by-value overhead would be prohibitive. Few (if any) users of the call-by-reference API are immediately introduced. Also, in order to avoid calling convention overhead on architectures where structures are required to be passed by value, NR_CPUS <= BITS_PER_LONG is special-cased so that cpumask_t falls back to an unsigned long and the accessors perform the usual bit twiddling on unsigned longs as opposed to arrays thereof. Audits were done with the structure overhead in-place, restoring this special-casing only afterward so as to ensure a more complete API conversion while undergoing the majority of its end-user exposure in -mm. More -mm's were shipped after its restoration to be sure that was tested, too. The immediate users of this functionality are Sun sparc64 systems, SGI mips64 and ia64 systems, and IBM ia32, ppc64, and s390 systems. Of these, only the ppc64 machines needing the functionality have yet to be released; all others have had systems requiring it for full functionality for at least 6 months, and in some cases, since the initial Linux port to the affected architecture.
-
- 12 May, 2003 1 commit
-
-
Andrew Morton authored
From: Zwane Mwaikambo <zwane@linuxpower.ca> Commented out printk causes change in program flow in cpufreq/p4-clockmod.c
-
- 17 Mar, 2003 1 commit
-
-
Dave Jones authored
-
- 08 Mar, 2003 2 commits
-
-
Dave Jones authored
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.
-
Dave Jones authored
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.
-
- 01 Mar, 2003 1 commit
-
-
Dominik Brodowski authored
Update x86 drivers so that they can live with the new cpufreq governor "userspace". sparc64 doesn't need any change, and I'll send the corresponding patch for ARM to Russell King.
-
- 23 Feb, 2003 1 commit
-
-
Dominik Brodowski authored
- switch the Intel x86 speedstep/Pentium 4/Xeon drivers and the Transmeta Crusoe Longrun driver to use the advanced cpufreq_driver registration process - cleanups - spelling fixes (Petri Koistinen) - thanks!
-
- 12 Feb, 2003 1 commit
-
-
Dave Jones authored
From Dominik Brodowski
-
- 13 Jan, 2003 1 commit
-
-
Dominik Brodowski authored
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.
-
- 10 Jan, 2003 1 commit
-
-
Dominik Brodowski authored
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).
-
- 06 Jan, 2003 1 commit
-
-
Dominik Brodowski authored
The "get current speed" algorithm wasn't aware of the disable/enable bit, and the policy verification function wasn't aware of the N44 / O17 bug. Also, some unused code is removed.
-
- 15 Dec, 2002 1 commit
-
-
Dominik Brodowski authored
This patch moves some basic per-CPU static information (minimum frequency, maximum frequency and maximum transition latency) into a struct cpufreq_cpuinfo. This offers a much cleaner struct cpufreq_driver and struct cpufreq_policy.
-
- 22 Nov, 2002 1 commit
-
-
Dominik Brodowski authored
This changes the return type of the verify and setpolicy functions from void to int. While doing this, I've changed the values for minimum and maximum supported frequency to be per CPU, as UltraSPARC needs this. Additionally, small cleanups in various drivers.
-
- 03 Nov, 2002 1 commit
-
-
Dominik Brodowski authored
This patch updates the p4-clockmod.c driver to correctly manage HyperThreading-enabled Pentium IVs as well as those models which do not support HyperThreading - thanks to Venkatesh Pallipadi for explaining cpu_sibling_map to me. Additionally, an EXPORT_SYMBOL was missing. (spotted by Marc-Christian Petersen - thanks!)
-
- 30 Sep, 2002 1 commit
-
-
Dominik Brodowski authored
In two drivers a wrong size of memory was allocated for cpufreq_driver: as it must include NR_CPUS times a struct cpufreq_policy (and not struct cpufreq_freqs). Thanks to Petr Vandrovec for this patch.
-
- 29 Sep, 2002 2 commits
-
-
Dominik Brodowski authored
- incorrect pointer calculation spotted by Gerald Britton - speedstep.c cleanup (Gerald Britton)
-
Dominik Brodowski authored
CPUFreq i386 drivers for 2.5.39: arch/i386/config.in Necessary config options arch/i386/kernel/cpu/Makefile allow for compilation of the CPUFreq subdirectory arch/i386/kernel/cpu/cpufreq/Makefile Makefile for CPUFreq drivers arch/i386/kernel/cpu/cpufreq/elanfreq.c CPUFreq driver for AMD Elan processors arch/i386/kernel/cpu/cpufreq/longhaul.c CPUFreq driver for VIA Longhaul processors arch/i386/kernel/cpu/cpufreq/longrun.c CPUFreq driver for Transmeta Crusoe processors arch/i386/kernel/cpu/cpufreq/p4-clockmod.c CPUFreq driver for Pentium 4 Xeon processors (using clock modulation) arch/i386/kernel/cpu/cpufreq/powernow-k6.c CPUFreq driver for mobile AMD K6-2+ and mobile AMD K6-3+ processors arch/i386/kernel/cpu/cpufreq/speedstep.c CPUFreq drivers for ICH2-M and ICH3-M chipsets and Intel Pentium 3-M and 4-M processors.
-