http://bugzilla.kernel.org/show_bug.cgi?id=9528
------- Comment #55 from [EMAIL PROTECTED] 2007-12-25 05:43 ------- (In reply to comment #54) > This is that same section from ACPI 1.0B: > > 3. The OS executes the Prepare To Sleep (_PTS) control method, passing an > argument that indicates the desired sleeping state (1, 2, 3, or 4 representing > S1, S2, S3, and S4). > > 4. The OS places all device drivers into their respective Dx state. If the > device is enabled for wakeup, it enters the Dx state associated with the > wakeup capability. If the device is not enabled to wakeup the system, it > enters the D3 state. > > Which very clearly states _PTS() is executed before we suspend the devices. > > So, I am correct for the 1.0 case (which is what this BIOS claims to be > conformant to). > > For the 2.0 case, the spec just contradicts itself - section 7.3.2 in 2.0 > states _PTS() should be run before device suspend, but as you say, 9.1.6 says > the opposite. Well, that's probably because section 7.3.2 was based on the 1.0 specification. > So for 1.0 we are still doing the wrong thing (and both the DSDTs here > claim to be conformant to ACPI 1.0), and for 2.0, we are not unclear (to > which I presume 3.0 tried to clear it up). Yes, I think that the 3.0 specification tried to clear things up. Well, the solution might be to execute _PTS in acpi_pm_set_target() and not to execute it in acpi_pm_prepare() for ACPI 1.0x-compliant systems. [We'll also need an additional global callback for executing _WAK after resuming devices on ACPI 1.0x systems in that case.] -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
