summaryrefslogtreecommitdiffstats
path: root/sys/kern/kern_cpu.c
Commit message (Collapse)AuthorAgeFilesLines
* Bump the maximum number of levels to 64 and add warning messages aboutnjl2005-02-241-5/+15
| | | | what to do to fix reduced functionality if the number of levels is too low.
* Add the "freq_settings" sysctl to each device that registers with cpufreqnjl2005-02-201-0/+41
| | | | so their individual settings can be seen separately for debugging.
* Introduce a new method, cpufreq_drv_type(), that returns the type of thenjl2005-02-181-6/+7
| | | | | | | | | | | driver. This used to be handled by cpufreq_drv_settings() but it's useful to get the type/flags separately from getting the settings. (For example, you don't have to pass an array of cf_setting just to find the driver type.) Use this new method in our in-tree drivers to detect reliably if acpi_perf is present and owns the hardware. This simplifies logic in drivers as well as fixing a bug introduced in my last commit where too many drivers attached.
* When dealing with systems with no absolute drivers attached, only calibratenjl2005-02-151-10/+22
| | | | | | | the rate for the 100% state once. Afterwards, use that value for deriving states. This should fix the problem where the calibrated frequency was different once a switch was done, giving a different set of levels each time. Also, properly search for the right cpufreqX device when detaching.
* Bind to the driver's parent cpu before switching, for both absolute andnjl2005-02-151-18/+28
| | | | | relative drivers. Remove some extraneous KASSERTs since NULL pointers will be found when they're used right afterwards.
* Implement priorities. This allows a driver (say, for cooling purposes) tonjl2005-02-141-4/+38
| | | | | | | override the current freq level temporarily and restore it when the higher priority condition is past. Note that only the first overridden value is saved. Callers pass NULL to CPUFREQ_SET to restore the saved level. Priorities are not yet used so this commit should have no effect.
* Add support for the CPUFREQ_FLAG_INFO_ONLY flag. Devices that report thisnjl2005-02-131-1/+8
| | | | | | | | | | | are not added to the list(s) of available settings. However, other drivers can call the CPUFREQ_DRV_SETTINGS() method on those devices directly to get info about available settings. Update the acpi_perf(4) driver to use this flag in the presence of "functional fixed hardware." Thus, future drivers like Powernow can query acpi_perf for platform info but perform frequency transitions themselves.
* Set levels on all CPUs and attach a cpufreq device to each one. Sysctlnjl2005-02-131-22/+62
| | | | | | on dev.cpu.0 will affect all of the CPUs together. In the future, independent control will be supported but this is good enough for now. Check that the timecounter isn't TSC before switching (from Colin Percival.)
* Add support for relative cpufreq drivers. Such drivers modulate clocknjl2005-02-061-27/+192
| | | | | | frequency as a percentage of the base rate and do not change the base rate directly. The cpufreq framework combines these with absolute drivers to produce synthesized levels made of one or more settings.
* Add the cpufreq framework. This code manages multiple drivers and presentsnjl2005-02-041-0/+532
a unified kernel and user interface for controlling cpu frequencies.
OpenPOWER on IntegriCloud