summaryrefslogtreecommitdiffstats
path: root/sys/kern/kern_cpu.c
Commit message (Collapse)AuthorAgeFilesLines
* Free allocated sbufs before returning ENOMEM.brueffer2010-01-081-2/+6
| | | | | | PR: 128335 Submitted by: Mateusz Guzik <mjguzik@gmail.com> MFC after: 2 week
* Provide a new CPU device driver ivar to report the nominal speed of thenwhitehorn2009-05-311-12/+21
| | | | | | CPU, if available. This is meant to solve the issue of cpufreq misreporting speeds on CPUs that boot in a reduced power mode and have only relative speed control.
* If possible, try to obtain max_mhz on cpufreq attach instead of first request.mav2008-12-161-1/+8
| | | | | | | | | On HyperThreading CPUs logical cores have same frequency, so setting it on any core will change the other's one. In most cases first request to the second core will be the "set" request, done after setting frequency of the first core. In such case second CPU will obtain throttled frequency of the first core as it's max_mhz making cpufreq broken due to different frequency sets.
* Fix a few edge cases with error handling in cpufreq(4)'s CPUFREQ_GET()jhb2008-05-051-3/+3
| | | | | | | | | | | | | | method: - If the last of the child cpufreq drivers returns an error while trying to fetch its list of supported frequencies but an earlier driver found the requested frequency, don't return an error to the caller. - If all of the child cpufreq drivers fail and the attempt to match the frequency based on 'cpu_est_clockrate()' fails, return ENXIO rather than returning success and returning a frequency of CPUFREQ_VAL_UNKNOWN. MFC after: 3 days PR: kern/121433 Reported by: Eugene Grosbein eugen ! kuzbass dot ru
* Remove duplicate cpufreq levels, i.e. ones that are within 25 Mhz of eachnjl2008-01-161-0/+11
| | | | | | | | | | other. The first one survives, the rest are removed. So far, it appears only some acpi_perf(4) BIOS tables have these invalid states, but address this in the core to be sure to handle other potential driver data. PR: kern/114722 Tested by: stefan.lambrev / moneybookers.com MFC after: 3 days
* If we're on an SMP kernel and there is more than 1 CPU, reject any attemptsnjl2007-10-301-1/+17
| | | | | | to change the freq before the other CPUs are active. The current code always attempts to change all CPUs to match each other, and the requisite sched_bind() call won't work before APs are launched.
* Always call sched_bind(), even if on the CPU in question. It is wrong tonjl2007-08-201-25/+15
| | | | | | | | check if we're already on that cpu and skip the bind since the thread could be migrated off in the meantime. Suggested by: jeff Approved by: re
* Use a different loop variable for the inner loop. This previous reuse couldnjl2007-08-191-4/+4
| | | | | | | | | have caused a hang, but we got lucky with the available multi-CPU states on actual hardware. Submitted by: Bjorn Koenig <bkoenig / alpha-tierchen.de> Approved by: re MFC after: 3 days
* Commit 14/14 of sched_lock decomposition.jeff2007-06-051-8/+8
| | | | | | | | | | | - Use thread_lock() rather than sched_lock for per-thread scheduling sychronization. - Use the per-process spinlock rather than the sched_lock for per-process scheduling synchronization. Tested by: kris, current@ Tested on: i386, amd64, ULE, 4BSD, libthr, libkse, PREEMPTION, etc. Discussed with: kris, attilio, kmacy, jhb, julian, bde (small parts each)
* Add an interface for drivers to be notified of changes to CPU frequency.njl2007-03-261-26/+40
| | | | | | | | | | | | | | | | | | cpufreq_pre_change is called before the change, giving each driver a chance to revoke the change. cpufreq_post_change provides the results of the change (success or failure). cpufreq_levels_changed gives the unit number of the cpufreq device whose number of available levels has changed. Hook in all the drivers I could find that needed it. * TSC: update TSC frequency value. When the available levels change, take the highest possible level and notify the timecounter set_cputicker() of that freq. This gets rid of the "calcru: runtime went backwards" messages. * identcpu: updates the sysctl hw.clockrate value * Profiling: if profiling is active when the clock changes, let the user know the results may be inaccurate. Reviewed by: bde, phk MFC after: 1 month
* - Print message about cpufreq and timecounter TSCmnag2006-03-031-1/+8
| | | | | Approved by: njl MFC after: 1 day
* make saved cpu level stackable.ume2005-10-031-30/+53
|
* Break out the checks for duplicates and absolute settings being too highnjl2005-09-021-8/+17
| | | | | | | instead of trying to do them all at once. This should fix the level sorting problems from the previous revision. Testing help: ume
* Eliminate cpufreq levels for two cases that are less than optimal:njl2005-08-301-47/+48
| | | | | | | | | | | | | | | | 1. Walk the absolute list in reverse to prefer duplicated levels that have a lower absolute setting, i.e. 800 Mhz/50% is better than 1600 Mhz/25% even though both have the same actual frequency. This also removes the need to check for already-modified levels since by definition, those will be added later in the sorted list. 2. Compare the absolute settings for derived levels and don't use the new level if it's higher. For example, a level of 800 Mhz/75% is preferable to 1600 Mhz/25% even though the latter has a lower total frequency. This work is based on a patch from the submitter but reworked by myself. Submitted by: Tijl Coosemans (tijl/ulyssis.org)
* - don't forget to save freqency when priority is raised.ume2005-08-181-3/+2
| | | | - nuke redundant variable initialization.
* don't forget to update curr_priority. even when frequency isume2005-08-181-0/+1
| | | | not changed, priority may be changed.
* Save cpu level only when priority is greater than PRIO_USERume2005-08-161-1/+1
| | | | | | | to make CPUFREQ_SET(NULL, prio) work. TODO: implement saved_level as stack. Reviewed by: njl
* The "lowest" sysctl setting makes more sense as the lowest one to use, sonjl2005-08-111-2/+2
| | | | | | discard all levels less than this setting, not less than/equal to. MFC after: 1 day
* Add debugging prints to all the methods in case there are problems withnjl2005-04-101-7/+70
| | | | | managing levels. This can be enabled with the debug.cpufreq.verbose tunable and sysctl.
* Add a check for cpufreq_unregister() being called with no cpufreq devicenjl2005-03-311-0/+5
| | | | | | | active. Note that the logic indicates this should not be possible so generate a warning if this ever happens. Found by: Coverity Prevent (via sam)
* Add locking to handle multiple threads getting/setting frequencies at thenjl2005-02-271-15/+62
| | | | | same time. We use an sx lock and serialize the cpufreq device's get/set/levels methods.
* Allow users to reject levels below a given frequency (in MHz) via thenjl2005-02-261-1/+17
| | | | | | debug.cpufreq.lowest tunable and sysctl. Some systems seem to have problems with the lowest frequencies so setting this prevents them from being available or used.
* 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