state. This follows the "bus power state" -logic noted in the spec:
bus: D1
device A : D1 -> D0 -> error
device B : D1 -> D2 -> success
-> bus must remain in D1 due device A
Following this scheme, it is easy to derive the "bus power state" now that
we have the device nodes in a tree-like structure. If required, separate
acpi_power_get_bus() and acpi_power_set_bus() can be added in the future.
all "struct acpi_devnodes" to their corresponding ACPI_HANDLEs. Anywhere in
the acpi(4) subtree, the node-structure can be obtained from a handle via
acpi_get_node(). The idea is similar to e.g. device_private().
Benefits: (a) simplifies code, (b) avoids issues with locking as ACPICA does
the serialization for us, (c) avoids the need to access the glocal softc, and
(d) avoids the O(n) loop required to search for a handle from the node queue.
GPEs, but unset only wake GPEs. The old behavior was questionable, as the
intention was only to disable a device's ability to wake the system.
Maintaining the runtime GPE generation is more important now as ACPICA
supports sharing a single GPE across multiple devices.
Discussed with jmcneill@.
interrupt handler. However, all edge-triggered GPEs should already be
cleared before our GPE handler has a chance to run.
The reason can be found from the changes in the locking primitives of
ACPICA. All GPE operations now use a spin mutex on AcpiGbl_GpeLock, acquired
via AcpiOsAcquireLock(). This same lock is now acquired unconditionally in
the AcpiClearGpe() function. This causes a deadlock of the following form:
...
AcpiEvGpeDetect() : acquire AcpiGbl_GpeLock;
-> AcpiEvGpeDispatch();
-> acpiec_gpe_handler();
-> AcpiClearGpe() : acquire AcpiGbl_GpeLock;
-> panic.
Completed a major update for the GPE support in order to improve
support for shared GPEs and to simplify both host OS and ACPICA
code. Added a reference count mechanism to support shared GPEs that
require multiple device drivers. Several external interfaces have
changed. One external interface has been removed. One new external
interface was added. Most of the GPE external interfaces now use the
GPE spinlock instead of the events mutex (and the Flags parameter
for many GPE interfaces has been removed.) See the updated ACPICA
Programmer Reference for details. Matthew Garrett, Bob Moore, Rafael
Wysocki. ACPICA BZ 831.
Changed:
AcpiEnableGpe, AcpiDisableGpe, AcpiClearGpe, AcpiGetGpeStatus
Removed:
AcpiSetGpeType
New:
AcpiSetGpe
order to be ready for possible future API changes, call it if we failed to
install the fixed event handlers. Also small ACPI_DEBUG_PRINT clarifications.
/*
* sleep(9) isn't safe because AcpiOsStall may be called
* with interrupt-disabled. (eg. by AcpiEnterSleepState)
* we should watch out for long stall requests.
*/
ACPICA has long printed a similar warning by itself. Moreover, this message
was never reached as the interpreter does not invoke AcpiOsStall() when a
delay longer than 255 usec is requested.
This is now in ACPICA (20100528):
Added support to limit the maximum time for the ASL Sleep()
operator. To prevent accidental deep sleeps, limit the maximum time
that Sleep() will actually sleep. Configurable, the default maximum
is two seconds. ACPICA bugzilla 854.
devices should be placed in the D0 state ("fully on") after resume. We were
not prepared to handle the previous value as it implied that devices could
be placed in an arbitrary power state once in S0.
Minimal functional change, given that the _DSW is seldom seen in the field.
This "fixes" the issue observed by dyoung@. Since the AML may not keep any
state by itself, it is possible that the firmware tries to continuously put
a device into a power state where the device already is (e.g. D3 -> D3).
XXX: The code (like the old power resource code) rests on the assumption
that it is possible to reliably obtain the power state of a device
either directly via _PSC or indirectly via _STA. However, because there
is some evidence that few broken systems implement these methods
incorrectly (e.g. always returns D0 as a constant, even if the state
would be D3 in reality), we may need to revisit this by always setting
the power state, even if it is impossible to get the power state.
by defining 'options ACPIVERBOSE' in the kernel config file (no change
from current behavior), or it can be loaded at boot time on those
architectures that support the boot loader's "load" command.
ACPIVERBOSE also includes code to dump acpi/wmi data.
has no support for it. For example, in Kurt Schreiner's Shuttle G61:
Device (FAN)
{
Name (_HID, EisaId ("PNP0C0B"))
Method (_INI, 0, NotSerialized)
{
Store (TP1H, CTOS)
Store (TP1L, CTHY)
}
}
Obviously acpitz(4) has little use for a device that only contains _INI.
(The handle of this device is referenced incorrectly in _AL0.)
seconds. It is known that there are systems in the field that pass bogus AML
values to the Sleep() operation code, possibly requesting delays that could
be measured in days.
Discussed with jmcneill@.
XXX: While the used mstohz(9) is documented to round to one second if the
passed value is larger than 131072 ms, we may still need to force a
sensible upper limit if this warning starts to appear.
include all device nodes, regardless of the status of the device.
XXX: It is known that some systems implement the _STA method incorrectly.
If needed in the future, attachment based on the values from this
method may need revisiting. Same goes for ACPI_ACTIVATE_DEV.
laptop there is a PNP0C0B ("ACPI fan") with the following properties:
_PSC : Power state for D3 (alone).
_PR0 : Power resources for D0.
_PSx : Power state switch for D0 and D3.
Thus, it is impossible to get or set the D3 power state via power resources
alone; there is only a single PowerResource() and it is for D0.
To tackle this:
1. Evaluate the direct _PSC control method if and only if there is no
given _PRx. The order is important; it is known that some other
systems implement the _PSC method (like _STA) incorrectly.
2. If no _PRx is available (and thus no _ON or _OFF), do not error out.
Instead, if we have AE_NOT_FOUND, continue to evaluate the power state
switch method, _PSx, which (on this laptop) should alone suffice for
the D0 -> D3 transition.
admirable goal, it is pretty much mission impossible; the specifications are
nearly thousand pages each and the amount of methods is counted in hundreds.
In addition, use ACPICA's native constants from <actypes.h> when possible.
Also move ACPI_STA_OK from "mpacpi.c" to <dev/acpi/acpireg.h> to simplify
the evaluation of device status.
We really should not add code that aims to satisfy some oddball firmware,
not in the generic drivers that aim to comply with the specifications.
In the long-term this is even worse than quirk tables.
