summaryrefslogtreecommitdiffstats
path: root/sys/dev/acpica
Commit message (Collapse)AuthorAgeFilesLines
* On i386 platforms at least, ACPI throttling is accomplished by the chipsetnjl2005-03-041-1/+10
| | | | | | | | | modulating the STPCLK# pin based on the duty cycle. Since p4tcc uses the same mechanism (but internal to the CPU), we triggered a hang on some systems at low frequencies when both were in use. Now, disable acpi_throttle when p4tcc is also present. Tested by: Kevin Oberman
* Check for some impossible frequencies that some systems use to indicatenjl2005-03-041-0/+9
| | | | they don't actually support Px states.
* Fix SCM ID's.obrien2005-03-028-13/+22
|
* Protect acpivar.h with _KERNEL. No user parts inside currently.njl2005-03-021-0/+3
|
* Protect against multiple includes and use _KERNEL to protect the PCI fns.njl2005-02-283-1/+14
|
* 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
* Remove unused variable.njl2005-02-251-2/+0
| | | | Noticed by: Coverity tool
* Instead of assuming units of bytes, it seems more likely that this isnjl2005-02-251-10/+5
| | | | a bitfield.
* If a register width is less than 8, assume the BIOS author thought it wasnjl2005-02-231-0/+12
| | | | | in units of bytes and adjust accordingly. This is found at least on the Sony PCG-505BX.
* Add a entry for the Compaq R3000Z to indicate that it has the weird MADTjhb2005-02-221-0/+7
| | | | IRQ 0 quirk.
* - Add a new quirk to indicate that pin 0 of the first I/O APIC is reallyjhb2005-02-221-3/+12
| | | | | | | | | IRQ 0 and not an ExtINT pin. The MADT enumerators ignore the PC-AT flag and ignore overrides that map IRQ 0 to pin 2 when this quirk is present. - Add a block comment above the quirks to document each quirk so that we can use more verbose descriptions quirks. MFC after: 2 weeks
* 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-222-0/+6
| | | | hint.ichss.0.disabled="1"
* Set the start of the cooling time later on, when we're actually performingnjl2005-02-221-2/+2
| | | | | | | | | the switch. Other interim tests (i.e., for minimum runtime) could invalidate the start time. This fixes transitions to cooler states in that now they go to the next active state (_AC0 -> _AC1) instead of going straight to off (_AC0 -> off). Submitted by: Alexandre "Sunny" Kovalenko (Alex.Kovalenko / verizon.net)
* Since the GPE handler is directly called by ACPI-CA and it may have unknownnjl2005-02-211-3/+8
| | | | | | | | | | | | | | | | locks held, specify the ACPI_ISR flag to keep it from acquiring any more mutexes (which could potentially sleep.) This should fix "could sleep" warning messages on the following path: msleep() AcpiOsWaitSemaphore() AcpiUtAcquireMutex() AcpiDisableGpe() EcGpeHandler() AcpiEvGpeDispatch() AcpiEvGpeDetect() AcpiEvGpeDetect() AcpiEvSciXruptHandler()
* 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-182-8/+34
| | | | | | | | | | | 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.
* Check for the address space type first before validating it. In particular,njl2005-02-171-2/+6
| | | | | | we want to return EOPNOTSUPP for FFixedHW no matter what the address. Submitted by: Bruno Ducrot
* The correct error value for not having enough storage is E2BIG, notnjl2005-02-172-2/+2
| | | | ENOMEM. The manpage and ichss(4) are correct.
* Allow users to manually override quirks with the tunable "debug.acpi.quirks".njl2005-02-131-2/+6
| | | | Suggested by: Jung-uk Kim
* 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.
* Be sure to register with cpufreq(4). On systems that only supportednjl2005-02-131-9/+36
| | | | | | | | | throttling, neglecting to do this kept the sysctls from appearing. Attach an acpi_throttle device to each CPU that supports it. Don't add a device if the P_BLK is invalid or if _PTC is not present. This removes extraneous probe/attach failure messages on some machines. Make the cpu throttle state local to the softc to account for partial successes when changing the clock rate on MP machines.
* 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-072-18/+13
|
* Remove acpi throttling support from the acpi_cpu(4) driver now that thisnjl2005-02-061-236/+9
| | | | is supported by acpi_throttle(4).
* Break out acpi throttling support into a new relative cpufreq driver,njl2005-02-061-0/+384
| | | | acpi_throttle(4).
* Notify the OS that we're taking over Px states in acpi_perf(4) instead ofnjl2005-02-062-11/+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.
* Staticize the legacy cpu devclasses and revert the name for the acpi_cpunjl2005-02-061-3/+3
| | | | | | devclass. As pointed out by dfr@, devclasses don't have to share the same linkage if multiple drivers have the same name. Newbus should match the devclasses based on name and allocate non-conflicting unit numbers.
* 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.
* Convert to the new GAS API so that we can free registers in the future.njl2005-02-051-7/+13
|
* Convert the acpi_bus_alloc_gas() and acpi_PkgGas() APIs to output the memorynjl2005-02-053-24/+27
| | | | | | type. This is needed if the resource is to be released later. The RID is still also present, though less necessary since rman_get_rid() can be used to obtain it from the resource.
* 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.
* Return a special status of "not supported" for functional fixed hardwarenjl2005-02-041-3/+3
| | | | since this type of register should be handled by another driver.
* Make the devclass static for now until deciding whether to share them.njl2005-02-041-1/+1
|
* 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.
* Update the CPU attachments to return CPU_IVAR_PCPU as well as pass onnjl2005-02-041-15/+101
| | | | appropriate requests to any children.
* Consistently use pcib for a printf.njl2005-01-271-1/+1
|
* Don't create new-bus resources for ACPI extended IRQ resources that arejhb2005-01-181-1/+5
| | | | | | producers rather than consumers as new-bus resources only handle consumed resources. We already do this for the other ACPI resource types that support the producer/consumer attribute.
* For the sake of consistency, look up link devices relative to the rootjhb2005-01-181-2/+1
| | | | | | | | object (/) rather than the pci bus object when walking the _PRT to force attach devices. We already look up relative to the root object when doing interrupt routing. Suggested by: njl
* - Add support for link devices where _CRS just outright fails to execute.jhb2005-01-181-28/+147
| | | | | | | | | | | | | | | | | | For such devices, we require _PRS to exist and we warn if any of the resources in _PRS are not IRQ resources (since we'll have no way of knowing which of those resources to use without a working _CRS). When it does come time to set resources, we build up a resource buffer from scratch as we do for devices with _CRS that only have IRQ resources. - Fix a bug with setting extended IRQ resources where we set the IRQ value in the wrong resource structure meaning that whichever IRQ was listed in _PRS was used instead. This might fix some weird issues on certain boxes where IRQs > 16 don't seem to work when using ACPI. - Fix a bug with how we walked the resource buffer after _SRS to call config_intr() in that the 'end' variable was not properly updated, so we could either terminate the loop early or loop after the end of the buffer. Tested by: pjd
* In total violation of at least 4 sections in the ACPI spec, some systemsnjl2005-01-081-19/+26
| | | | | | | | | place device objects in \ (in this case, PCI links.) Work around this by starting our probe from \. To avoid attaching system scope objects, explicitly skip them. (I think it's an ACPI-CA bug that \_SB and \_TZ have device and thermal object types.) Thanks to pjd@ for testing. MFC after: 2 weeks
* Start each of the license/copyright comments with /*-, minor shuffle of linesimp2005-01-063-3/+4
|
* Minor cleanup: Reduce stack usage in probe method. Outdent probe. Usenjl2004-12-271-41/+38
| | | | TRUE/FALSE instead of 1/0 for booleans. Remove trailing and extra whitespace.
* Remove trailing whitespace.njl2004-12-276-10/+10
|
* Only use the current value if there's one IRQ. Some systems returnnjl2004-12-201-8/+8
| | | | | | | | | multiple IRQs (which is nonsense for _CRS) when the link hasn't been programmed. Before, this was a KASSERT. A ServerWorks system was seen returning IRQs of 0, 2 in response to _CRS before link setup. Thanks to sam@ for quick testing and turnaround on this. Tested by: sam
* Only report a critical battery level once until it's gone non-critical.njl2004-12-201-3/+9
| | | | | | | An improvement would be to check all batteries for critical state before printing a message. Reported by: Kevin Oberman (oberman at es net)
* Unify ACPI_DEBUG support for all OEM drivers under ACPI_OEM. Since more thannjl2004-12-131-2/+1
| | | | | | | one will never be supported on the same platform, this does not hurt debugging. MFC after: 3 days
* Re-enable link programming on resume. It appears the previous boundsnjl2004-12-131-2/+0
| | | | error had caused the hang and it has been corrected now.
* Allow the acpi_ibm module to be built with ACPI_DEBUG.scottl2004-12-131-0/+1
|
OpenPOWER on IntegriCloud