> Yep -- here's the quote from ACPI 3.0b: > > OSPM will invoke _GTS, _PTS, _TTS, _WAK, and _BFS in the following > order: > 1.OSPM decides (through a policy scheme) to place the system into a > sleeping state. > 2._TTS(Sx) is run, where Sx is the desired sleep state to enter. > 3. OSPM notifies all native device drivers of the sleep state transition > 4._PTS is run > 5.OSPM readies system for the sleep state transition > 6._GTS is run > 7.OSPM writes the sleep vector and the system enters the specified Sx > sleep state. > 8.System Wakes up > 9._BFS is run > 10.OSPM readies system for the return from the sleep state transition > 11._WAK is run > 12. OSPM notifies all native device drivers of the return from the sleep > state transition > 13._TTS(0) is run to indicate the return to the S0 state. > > Technically we write the sleep vector too early as well. > And we don't evaluate _TTS at all -- though _TTS was > added only as of ACPI 3.0 and I've not seen it implemented on > any of the systems I've got. However, we still do something wrong with ACPI and suspend-to-ram because my system is unable to reboot after resume from ram. The only way to reboot is to disable the ACPI in the machine_emergency_restart(). (in particular, keyboard LEDs flash as the reset has been issued but the BIOS logo does not appear.) Any ideas, Len? Andrew dislikes the patch resulted from this bug report: http://bugzilla.kernel.org/show_bug.cgi?id=6655 Anyway, it works for me pretty well. -- Lukáš Hejtmánek - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
