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.
This in turn was caused by a bug in ACPICA, which reports the types of _SB_
and _TZ_ scopes incorrectly for its own internal reasons (utglobal.c):
/*
* Predefined ACPI Names (Built-in to the Interpreter)
*
* NOTES:
* 1) _SB_ is defined to be a device to allow \_SB_._INI to be run
* during the initialization sequence.
* 2) _TZ_ is defined to be a thermal zone in order to allow ASL code to
* perform a Notify() operation on it.
*/
Thanks to cegger@ for noticing the bug and testing a fix.
This retrieves a struct acpi_devnode from a handle. Since this requires
accessing the global softc, it is better to do it in one place alone. The
same goes for possible locking of the node-queue; it is better not to
publicize such a lock for generic device drivers.
detachment routine for acpitz(4). Add comments explaining the relationship
between power resources and active cooling. Also some improvements to code
readability.
The old code served us well, but a major overhaul would have been needed for
it to cope with the increased demands of the code -- and the specifications.
ok jmcneill@, pgoyette@
correctly pick PCI segment groups, PCI bus numbers, PCI root bridges,
PCI-to-PCI bridges, and PCI devices, among other things. In short: it is
more robust than the old code or anything in sys/arch/x86/x86/mpacpi.c.
ok cegger@, jmcneill@
installed via AcpiInstallAddressSpaceHandler(). This was already commented
out because ACPICA does this for us when ACPI_NO_ADDRESS_SPACE_INIT is not
specified when calling AcpiEnableSubsystem().
AcpiInitializeTables() instead of pushing 128 statically allocated
descriptors. This will eliminate also the need to call
AcpiReallocateRootTable().
The rationale for the statically allocated table descriptors is to allow
initialization without virtual/dynamic memory. Later these should be copied
to dynamic memory via AcpiReallocateRootTable(). But since in NetBSD both
functions were called in the very same acpi_probe(), this dance was
completely unnecessary.
jruoho