| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
TRUE/FALSE instead of 1/0 for booleans. Remove trailing and extra whitespace.
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
An improvement would be to check all batteries for critical state before
printing a message.
Reported by: Kevin Oberman (oberman at es net)
|
|
|
|
|
|
|
| |
one will never be supported on the same platform, this does not hurt
debugging.
MFC after: 3 days
|
|
|
|
| |
error had caused the hang and it has been corrected now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
| |
appropriate power (Dx) state, if the BIOS suggests one.
MFC after: 3 weeks
|
|
|
|
|
|
|
|
| |
Catch up with some #define's renaming.
Implement AcpiOsGetTimer() as per ACPI 3.0.
Approved by: njl
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
keep the locking and solve the real problem.
|
|
|
|
|
|
| |
@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.
|
|
|
|
|
| |
anyway and for some reason, witness seems confused about what's already
locked and triggers a false panic.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
that they are equivalent.
|
|
|
|
| |
several of my systems.
|
|
|
|
| |
- Sort function prototypes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
defined.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
switching. Don't initialize variables in their declaration. Reduce stack
usage for device names. Minor style cleanups.
MFC after: 1 week
|
|
|
|
| |
take up only one line.
|
|
|
|
|
|
|
| |
hw.pci.host_mem_start tunable. Add comments to TUNABLE_INT and
TUNABLE_QUAD recommending against their use.
MFC after: 3 weeks
|
| |
|
| |
|
|
|
|
| |
MFC after: 1 day
|
|
|
|
| |
MFC after: 1 day
|
|
|
|
|
|
| |
* 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.
|
|
|
|
|
|
| |
introduce hw.{pci,acpi}.host_mem_start tunable to change this.
MFC: ASAP
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
C3. Instead, flush caches before entering C3. This may be slower but
provides good power savings.
|
|
|
|
|
|
| |
This removes the last MD portion of acpi_cpu.c.
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
MFC if: no problems
|
|
|
|
|
| |
an ACPI _ADR value and use that rather than inlining the same shifts and
masks everywhere.
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
may help with double panics.
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
covered by other printfs under ACPI_DEBUG and is not a failure case.
MFC after: 3 days
|
|
|
|
| |
wrap a long line.
|