summaryrefslogtreecommitdiffstats
path: root/sys/dev/acpica/acpi_perf.c
Commit message (Collapse)AuthorAgeFilesLines
* Import ACPICA 20090521.jkim2009-06-051-1/+2
|
* Catch up with ACPI-CA 20070320 import.jkim2007-03-221-3/+3
|
* Re-work Cx handling to be per-cpu and asymmetrical, fixing support onnjl2007-01-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | modern dual-core systems as well. - Parse the _CST packages for each cpu and track all the states individually, on a per-cpu basis. - Revert to generic FADT/P_BLK based Cx control if the _CST package is not present on all cpus. In that case, the new driver will still support per-cpu Cx state handling. The driver will determine the highest Cx level that can be supported by all the cpus and configure the available Cx state based on that. - Fixed the case where multiple cpus in the system share the same registers for Cx state handling. To do that, added a new flag parameter to the acpi_PkgGas and acpi_bus_alloc_gas functions that enable the caller to add the RF_SHAREABLE flag. This flag could also be useful to other callers (acpi_throttle?) in the tree but this change is not yet made. - For Core Duo cpus, both cores seems to be taken out of C3 state when any one of the cores need to transition out. This broke the short sleep detection logic. It is disabled now if there is more than one cpu in the system for now as it fixed it in my case. This quirk may need to be re-enabled later differently. - Added support to control cx_lowest on a per-cpu basis. There is still a generic cx_lowest to enable changing cx_lowest for all cpus with a single sysctl and for ease of use. Sample output for the new sysctl: dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 0.00% 43.16% 56.83% dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 dev.cpu.1.cx_lowest: C3 dev.cpu.1.cx_usage: 0.00% 45.65% 54.34% hw.acpi.cpu.cx_lowest: C3 This work was done by Stephane E. Potvin with some simple reworking by myself. Thank you. Submitted by: Stephane E. Potvin <sepotvin / videotron.ca> MFC after: 2 weeks
* Eliminate duplicate p-states entriesbruno2006-07-151-0/+6
| | | | | | | Reported and tested by: ales dot rom at kabelnet dot net Reviewed by: njl Approved by: njl, imp (mentor) MFC after: 3 days
* Don't flood kernel logs with "invalid _PSS package" messages.bruno2005-12-121-1/+5
| | | | Approved by: njl, imp (mentor)
* Canonize the include of acpi.h.obrien2005-09-111-1/+1
|
* Remove bus_{mem,p}io.h and related code for a micro-optimization on i386nyan2005-05-291-1/+0
| | | | | | and amd64. The optimization is a trivial on recent machines. Reviewed by: -arch (imp, marcel, dfr)
* Revert part of 1.19. We do want to set the count to 0 since otherwisenjl2005-04-071-2/+2
| | | | it would give false info to other parts of the driver.
* Don't free the _PSS buffer until after we check to see if we have no validjhb2005-04-051-2/+2
| | | | states as otherwise we will try to free the buffer twice.
* Clean up resources properly if acpi_perf fails to attach. First, changenjl2005-03-271-1/+17
| | | | | | acpi_bus_alloc_gas() to delete the resource it set if alloc fails. Then, change acpi_perf to delete the resource after releasing it if alloc fails. This should make probe and attach both fully restartable if either fails.
* Check for invalid frequencies after parsing the package. Keep a runningnjl2005-03-261-8/+19
| | | | | | | | count of valid frequencies and use that as the final package count, don't give up when the first invalid state is found. Also, add 0x9999 and expand our upper check to >= 0xffff Mhz [2]. Submitted by: Bruno Ducrot, Jung-uk Kim [2]
* Attach acpi_perf early. Especially when it is being used to provide infonjl2005-03-201-1/+6
| | | | | to other devices, it needs to be attached first. (Multi-pass newbus probes would be a better solution.)
* Check for some impossible frequencies that some systems use to indicatenjl2005-03-041-0/+9
| | | | they don't actually support Px states.
* Make a pass through all drivers checking specs for desired behavior onnjl2005-02-271-0/+5
| | | | | | | SMP systems. It appears all drivers except ichss should attach to each CPU and that settings should be performed on each CPU. Add comments about this. Also, add a guard for p4tcc's identify method being called more than once.
* Don't bother with cpufreq_register if we're info-only.njl2005-02-261-1/+2
| | | | Suggested by: Jung-uk Kim
* Increase the maximum to wait for a transition from 1 to 10 ms. In somenjl2005-02-221-4/+16
| | | | | | | modes, systems may take longer. If the status values don't match, try matching just the lowest 8 bits if no bits above 8 are set in the desired value. The IBM R32 has other bits set in the status register that are irrelevant to the expected value.
* Support disabling individual cpufreq drivers with hints, e.g.,njl2005-02-221-0/+3
| | | | hint.ichss.0.disabled="1"
* Add a new field to struct cf_setting for special values. These are driver-njl2005-02-191-1/+7
| | | | | specific values that other components may want to use. Add support to acpi_perf(4) to export the control and status values via this field.
* Introduce a new method, cpufreq_drv_type(), that returns the type of thenjl2005-02-181-5/+19
| | | | | | | | | | | 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.
* The correct error value for not having enough storage is E2BIG, notnjl2005-02-171-1/+1
| | | | ENOMEM. The manpage and ichss(4) are correct.
* Add support for the CPUFREQ_FLAG_INFO_ONLY flag. Devices that report thisnjl2005-02-131-12/+39
| | | | | | | | | | | 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.
* Attach an acpi_perf device for every processor that offers the rightnjl2005-02-131-2/+2
| | | | methods.
* Remove handling _PSS notifies from acpi_cpu and let acpi_perf handle them.njl2005-02-071-1/+6
|
* Notify the OS that we're taking over Px states in acpi_perf(4) instead ofnjl2005-02-061-2/+15
| | | | | | | | | doing it in the cpu driver. The previous code was incorrect anyway since this value controls Px states, not throttling as the comment said. Since we didn't support Px states before, there was no impact. Also, note that we delay the write to SMI_CMD until after booting is complete since it sometimes triggers a change in the frequency and we want to have all drivers ready to detect/handle this.
* Convert to the new GAS APIs to allow for detach in the future. Also, checknjl2005-02-051-6/+36
| | | | | | the PERF_CTRL register in our probe method so that we can tell earlier that another driver should handle this device due to FFixedHW. This avoids scaring users when attach failed when we really wanted probe to fail.
* Don't print out a failure message when an attach for FFixedHW fails.njl2005-02-041-16/+25
| | | | | | Instead, just fail to attach so another hardware-specific driver can claim the device. Also, clean up some small memory leaks in the failure case.
* Add the ACPI Performance states driver. This driver offers two or morenjl2005-02-041-0/+420
settings as exported via the ACPI _PSS method. OEMs use this interface to encapsulate chipset or processor-specific methods (e.g., SpeedStep or Powernow) and export their settings in a standard way. On systems that have valid ACPI Performance states and a hardware-specific driver (e.g., ichss), acpi_perf(4) is preferred.
OpenPOWER on IntegriCloud