layer to the main code. Makes the caches coherent and provides consistent
vmstat(1) output. This is still not quite right, given that most of the
cross-calls are typically unnecessary with the dependency coordination.
object noted in the revision 1.40, there is only one C-state on the machine,
yet the BIOS define its type as C2. Thus, instead of relying on the BIOS
data, sequentially count the parsed C-states.
the revision 1.38. As noted in the specification (ACPI 4.0, p. 314):
The platform must expose a _CST object for either all or none of its
processors. If the _CST object exists, OSPM uses the C state information
specified in the _CST object in lieu of P_LVL2 and P_LVL3 registers
defined in P_BLK and the P_LVLx_LAT values defined in the FADT.
The _CST is seemingly valid on the system under consideration:
Name (_CST, Package (0x02)
{
0x01,
Package (0x04)
{
ResourceTemplate ()
{
Register (SystemIO,
0x08, // Bit Width
0x00, // Bit Offset
0x000000000000F800, // Address
0x01, // Access Size
)
},
0x02,
0x0064,
0x00000000
}
})
The check was also unnecessary in the sense that ACPI doesn't use bus_space(9).
object address is valid. Some systems define the Processor() as:
Scope (_PR)
{
Processor (C000, 0x00, 0x00000410, 0x06) {}
Processor (C001, 0x01, 0x00000000, 0x00) {}
Processor (C002, 0x02, 0x00000000, 0x00) {}
Processor (C003, 0x03, 0x00000000, 0x00) {}
}
This may be typical to AMD systems that do not seem to use _CST, but instead
operate with HLT (and C1E for the C3-state). The same check is already done
in acpicpu_cstate_fadt(). Note that it is unclear whether this violates the
specification, given:
"PBlockAddress provides the system I/O address for the processors
register block. Each processor can supply a different such address.
PBlockLength is the length of the processor register block, in bytes and
is either 0 (for no P_BLK) or 6. With one exception, all processors are
required to have the same PBlockLength. The exception is that the boot
processor can have a non-zero PBlockLength when all other processors
have a zero PBlockLength. It is valid for every processor to have a
PBlockLength of 0. (ACPI 4.0, p. 626)"
1. Remove the AcpiEnableGpe() call. This was wrong.
2. Only call _PSW or _DSW for devices that are scheduled for wake.
This was an old bug.
3. Only enable wake GPEs during suspend. Disabling these for
devices not setup for wake was causing problems.
4. No wake GPEs should be enabled at runtime.
Unconditionally disable these during resume.
This should make the wake-device code work again. Note that waking via
pckbd(4) has always been unreliable; the _PRW object is not typically located
under the PC keyboard object, but in the parent of it (e.g. the LPC bridge).
100 % duty cycle) had control value of zero, as in the IA32 clock modulation
MSR. As the access may be based on I/O, it is unclear if a strict validation
like this was correct. Should fix the problem reported by Hisashi T Fujinaka
on current users.
Completed the major overhaul of the GPE support code that was begun in July
2010. Major features include: removal of _PRW execution in ACPICA (host
executes _PRWs anyway), cleanup of "wake" GPE interfaces and processing,
changes to existing interfaces, simplification of GPE handler operation, and
a handful of new interfaces:
AcpiUpdateAllGpes
AcpiFinishGpe
AcpiSetupGpeForWake
AcpiSetGpeWakeMask
ACPICA 20100702:
Implemented several updates to the recently added GPE reference count
support. The model for "wake" GPEs is changing to give the host OS complete
control of these GPEs. Eventually, the ACPICA core will not execute any _PRW
methods, since the host already must execute them. Also, additional changes
were made to help ensure that the reference counts are kept in proper
synchronization with reality. Rafael J. Wysocki.
1) Ensure that GPEs are not enabled twice during initialization.
2) Ensure that GPE enable masks stay in sync with the reference count.
3) Do not inadvertently enable GPEs when writing GPE registers.
4) Remove the internal wake reference counter and add new AcpiGpeWakeup
interface. This interface will set or clear individual GPEs for wakeup.
5) Remove GpeType argument from AcpiEnable and AcpiDisable. These interfaces
are now used for "runtime" GPEs only.
Fixed a problem with the prototype for AcpiOsReadPciConfiguration.
The prototype in acpiosxf.h had the output value pointer as a (void *).
It should be a (UINT64 *). This may affect some host OSL code.
