summaryrefslogtreecommitdiffstats
path: root/sys/dev/acpica
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* Grab Giant around calls to DEVICE_SUSPEND/RESUME in acpi_SetSleepState().njl2004-12-051-0/+12
| | | | | | | | | | | If we are resuming non-MPSAFE drivers, they need Giant held for them. This may fix some obscure suspend/resume problems. It has fixed keyrate setting problems that were triggered by cardbus (MPSAFE) changing the ordering for syscons resume (non-MPSAFE). Also, add some asserts that Giant is held in our suspend/resume and shutdown methods. Found by: iedowse MFC after: 2 days
* Enable the relaxed behavior for op regions and other workarounds fornjl2004-12-031-1/+2
| | | | | | | | | non-standard BIOSen. We used to implement this in local patches but now that ACPI-CA has merged/re-implemented most of our fixes, they were no longer needed and we just needed to turn this knob on. Also, remove an unnecessary cast. Tested by: phk
* Turn ACPI and PCI devices off or to a lower power state in suspend andnjl2004-12-021-3/+210
| | | | | | | | | | | | | | | | back on again in resume. Override the default of D3 with the value the BIOS specifies in _SxD, if present. Skip serial devices (PNP05xx) since they seem to hang when set to D3 and may require special driver support. Also, skip non-type 0 PCI devices (i.e., bridges) since our we don't yet save/restore their config space and that seems to be necessary. If this gives you trouble with suspend/resume, you can disable the new ACPI and PCI power behavior separately with these tunables & sysctls: debug.acpi.do_powerstate hw.pci.do_powerstate Approved by: imp (pci) Tested by: acpi@ (numerous)
* Add the ACPI_PWR_FOR_SLEEP method. It takes a device and outputs thenjl2004-12-021-0/+20
| | | | | | appropriate power (Dx) state, if the BIOS suggests one. MFC after: 3 weeks
* Catch up with AcpiOsSleep() interface change.marks2004-12-024-11/+31
| | | | | | | | Catch up with some #define's renaming. Implement AcpiOsGetTimer() as per ACPI 3.0. Approved by: njl MFC after: 1 week
* - Do a better job of handling any Dependent Functions (aka DPFs) that appearjhb2004-12-011-69/+218
| | | | | | | | | | | | | | in the _PRS or _CRS of link devices. If faced with multiple DPFs in a _PRS, we just use the first one. We assume that if _CRS has DPF tags they only contain a single set since multiple DPFs wouldn't make any sense. In practice, the only DPFs I've seen so far for link devices are that the one IRQ resource is surrounded by a DPF tag pair for no apparent reason, and this should handle that case fine now. - Only allocate link structures for IRQ resources for link devices rather than allocating a link structure for every resource. Reviewed by: njl Tested by: phk
* Completely back out 1.37. Something else is going on and John wants tonjl2004-12-011-9/+0
| | | | keep the locking and solve the real problem.
* Fix "Lock ACPI PCI link not exclusively lockedobrien2004-12-011-0/+12
| | | | | | @sys/dev/acpica/acpi_pci_link.c:153" panic by backing out rev 1.37 in the SMP case. It appears that on a dual-proc machine the assertions in the rev 1.37 commit log hold true.
* Don't bother locking in attach(). At boot time, we're single-threadednjl2004-11-301-4/+1
| | | | | anyway and for some reason, witness seems confused about what's already locked and triggers a false panic.
* Make sure the link array is big enough to hold both _CRS and _PRSnjl2004-11-301-8/+30
| | | | | | | | | | | | resource lists. It used to be sized based only on _CRS, hence _PRS could perform an out-of-bounds access if it was larger (i.e., when there are dependent functions). Add asserts to detect this case. Note, this is only a temporary fix and I believe _PRS and _CRS should have separate arrays. Also, fix a typo where the wrong irq was being check for the APIC case. Submitted by: tegge
* Instead of translating PCI to ACPI power states, just use a CTASSERTnjl2004-11-291-18/+10
| | | | that they are equivalent.
* Temporarily disable programming IRQ links on resume. The new code hangsnjl2004-11-261-0/+2
| | | | several of my systems.
* - Remove some no longer used constants.jhb2004-11-231-8/+3
| | | | - Sort function prototypes.
* Rework the ACPI PCI link code.jhb2004-11-235-1060/+697
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Use a new-bus device driver for the ACPI PCI link devices. The devices are called pci_linkX. The driver includes suspend/resume support so that the ACPI bridge drivers no longer have to poke the links to get them to handle suspend/resume. Also, the code to handle which IRQs a link is routed to and choosing an IRQ when a link is not already routed is all contained in the link driver. The PCI bridge drivers now ask the link driver which IRQ to use once they determine that a _PRT entry does not use a hardwired interrupt number. - The new link driver includes support for multiple IRQ resources per link device as well as preserving any non-IRQ resources when adjusting the IRQ that a link is routed to. - The entire approach to routing when using a link device is now link-centric rather than pci bus/device/pin specific. Thus, when using a tunable to override the default IRQ settings, one now uses a single tunable to route an entire link rather than routing a single device that uses the link (which has great foot-shooting potential if the user tries to route the same link to two different IRQs using two different pci bus/device/pin hints). For example, to adjust the IRQ that \_SB_.LNKA uses, one would set 'hw.pci.link.LNKA.irq=10' from the loader. - As a side effect of having the link driver, unused link devices will now be disabled when they are probed. - The algorithm for choosing an IRQ for a link that doesn't already have an IRQ assigned is now much closer to the one used in $PIR routing. When a link is routed via an ISA IRQ, only known-good IRQs that the BIOS has already used are used for routing instead of using probabilities to guess at which IRQs are probably not used by an ISA device. One change from $PIR is that the SCI is always considered a viable ISA IRQ, so that if the BIOS does not setup any IRQs the kernel will degenerate to routing all interrupts over the SCI. For non ISA IRQs, interrupts are picked from the possible pool using a simplistic weighting algorithm. Tested by: ru, scottl, others on acpi@ Reviewed by: njl
* Enable throttling/C3 quirks for PIIX4 parts. Defer checking quirks untilnjl2004-11-161-9/+21
| | | | | | | | | after boot so that PCI is initialized and we can probe for the problem chipsets. Note that while probed but unusable states are disabled, they aren't freed yet. In the future, it may make sense to detach them. Tested by: Adam K Kirchoff <adamk at voicenet com> MFC after: 2 days
* After discussions with Nate, repo copy the acpi assist drivers fromimp2004-11-151-168/+0
| | | | | | | | | | i386 to dev/acpi_support. In theory, these devices could be found other than in i386 machines only as amd64 becomes more popular. These drivers don't appear to do anything i386 specific, so move them to dev/acpi_support. Move config lines to files so that those architectures that don't support kernel modules can build them into the kernel. At the same time, rename acpi_snc to acpi_sony to follow the lead of all the other specialty devices.
* s/return_VALUE/return / to fix build breakage when ACPI_DEBUG istruckman2004-11-141-3/+3
| | | | defined.
* Kill ACPI_FUNCTION_TRACE. It is killing the tinderbox build, and itimp2004-11-131-10/+6
| | | | | | | | isn't worth adding to the modules lists that we have to hard code for this to work. Since we print PID right away, we have a trace point already. Minor knf while I'm here.
* Commit takawata-san's Sony Notebook Controller driver, integrated intoimp2004-11-111-0/+172
| | | | | | | | the tree. Small tweaks were made by myself to eliminate unnecessary includes and some other minor issues. Last time I asked takawata-san about this driver, he suggested I commit it. Submitted by: takawata
* Only warn about missing _PRT tables if bootverbose is set. I've yet to seejhb2004-11-111-2/+4
| | | | | | | a bridge without a _PRT were a _PRT was needed. Instead, the warning in dmesg is a false warning and only serves to cause unnecessary concern. MFC after: 1 week
* unsigned long -> u_longnjl2004-11-091-1/+1
|
* Tell the BIOS we want to handle brightness switching as well as outputnjl2004-11-091-24/+33
| | | | | | | switching. Don't initialize variables in their declaration. Reduce stack usage for device names. Minor style cleanups. MFC after: 1 week
* Make the bootverbose output from qualitydetermination of the ACPI timerphk2004-11-031-5/+6
| | | | take up only one line.
* Add TUNABLE_LONG and TUNABLE_ULONG, and use the latter for thedes2004-10-311-2/+2
| | | | | | | hw.pci.host_mem_start tunable. Add comments to TUNABLE_INT and TUNABLE_QUAD recommending against their use. MFC after: 3 weeks
* Whitespace cleanupdes2004-10-311-4/+4
|
* Print before the footer, not after.njl2004-10-131-1/+1
|
* If flags are present, print them like ISA does.njl2004-10-131-0/+2
| | | | MFC after: 1 day
* Attach the device description for ISA devices on the ACPI bus.njl2004-10-121-0/+3
| | | | MFC after: 1 day
* Update C3 support when BM control is not present.njl2004-10-111-16/+28
| | | | | | * Fix a bug where caches were flushed on non-C3 transitions. * Be sure a working flush cache instruction is present before using it. * Disable C3 completely if it isn't present.
* Make the lower range of the memory area 0x80000000 again. Alsoimp2004-10-111-1/+5
| | | | | | introduce hw.{pci,acpi}.host_mem_start tunable to change this. MFC: ASAP
* Notify the user when the battery is critically low. In the future, wenjl2004-10-111-0/+4
| | | | | | | may want to shut down here but the chance of BIOS vendors getting this wrong is high. They're only supposed to announce this when all batteries hit their critical level but past experience indicates we should be conservative about this for now.
* If bus mastering control is not available (PM2_BLK), don't just disablenjl2004-10-111-16/+27
| | | | | C3. Instead, flush caches before entering C3. This may be slower but provides good power savings.
* Move the code for halting the CPU (acpi_cpu_c1) into machdep files.njl2004-10-111-15/+0
| | | | | | This removes the last MD portion of acpi_cpu.c. MFC after: 2 weeks
* Update a quirk for the ASUS P5A to disable the timer. It appears to work finenjl2004-10-083-9/+9
| | | | | | | | | | | | | | with acpi but the timer runs twice as fast. Note that the main problem (system doesn't work properly with acpi disabled) should be fixed separately. Changes: * Add a quirk to disable the timer * Merge the P5A and P5A-B quirks since they appear to be based on the same ASL. PR: i386/72450 Tested by: Kevin Oberman <oberman es.net> MFC after: 3 days
* For older systems with ACPI which don't have a pci <-> pci bridge,imp2004-10-061-3/+3
| | | | | | | allocate unallocated memory resources from the top 32MB of the address space rather than the top 2GB. While the latter works on some chipsets, it fails badly on others. 32MB is more conservative and matches what cheap harware from this era is hardwired to pass.
* When the user overrides the DSDT, replace any SSDTs with a simple no-opnjl2004-10-051-10/+40
| | | | | | | | table. acpidump(8) concatenates the body of the DSDT and SSDTs so an edited ASL will contain all the necessary information. We can't use a completely empty table since ACPI-CA reports this as a problem. MFC after: 3 days
* Allow routing to the SCI even if it's not in the list of valid IRQs.njl2004-09-251-0/+10
| | | | MFC if: no problems
* Add a couple of macros to extract the PCI slot (device) and function fromjhb2004-09-224-7/+11
| | | | | an ACPI _ADR value and use that rather than inlining the same shifts and masks everywhere.
* Initialize the flags value properly. We used to do this in acpi_tz_all_off()njl2004-09-211-33/+2
| | | | | | | but that function has been removed. This avoids a potential unnecessary fan switch on boot. Also remove some commented out code. MFC after: 3 days
* Don't disable acpi in shutdown if we're panicing (panicstr != NULL). Thisnjl2004-09-211-1/+1
| | | | may help with double panics.
* Record a problem we can't workaround for now regarding duplicate interruptsnjl2004-09-201-0/+7
| | | | | because of links left enabled while in APIC mode. A large scale rework of irq links is underway by jhb@ which should fix this eventually.
* Don't print a warning message if the _CRS value is empty. This is alreadynjl2004-09-161-7/+5
| | | | | | covered by other printfs under ACPI_DEBUG and is not a failure case. MFC after: 3 days
* Clean up rev 1.49 by using the temperature conversion for _PSV also andnjl2004-09-081-4/+5
| | | | wrap a long line.
OpenPOWER on IntegriCloud