One thing that wasn't clear to me from the code is why the new sleep registers are used any time they have defined addresses rather than only when the reduced hardware flag is set. I poked through the ACPI v5 spec and it seems to indicate that the sleep registers are only for reduced hardware. On the other hand it doesn't explicitly say to not use them on non-reduced hardware either. But maybe I missed something, that document is huge. :-P Cheers, Mike On Wed, May 22, 2013 at 3:36 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > Hi Bob, > > What do you think about this? > > Rafael > > > On Wednesday, May 22, 2013 09:39:12 AM Michael Marineau wrote: >> Greetings, >> >> On the recently released Toshiba Kirabook and kernels >= 3.4 >> suspend/resume only works once. After resume input from things like >> the power button, brightness buttons, lid switch, etc. no longer work >> and the laptop simply hangs when suspended for a second time. This >> appears to also impact other recent Toshiba laptops (although the bug >> claims the hang is during the second resume rather than the second >> suspend as is my case). >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1094800 >> >> Suspend/resume and all the buttons work just fine on v3.3. I bisected >> the v3.3->v3.4 change (with the help of patching in a kvm clock fix as >> needed) and tracked it down to this commit: >> >> commit 2feec47d4c5f80b05f1650f5a24865718978eea4 >> Author: Bob Moore <robert.moore@xxxxxxxxx> >> Date: Tue Feb 14 15:00:53 2012 +0800 >> >> ACPICA: ACPI 5: Support for new FADT SleepStatus, SleepControl registers >> >> Adds sleep and wake support for systems with these registers. >> One new file, hwxfsleep.c >> >> Signed-off-by: Bob Moore <robert.moore@xxxxxxxxx> >> Signed-off-by: Len Brown <len.brown@xxxxxxxxx> >> >> Specifically, when the sleep status/control registeres are detected >> they are used instead of the traditional registers. The failure to >> resume a second time is triggered by this write in the new >> acpi_hw_extended_wake_prep function: >> >> status = acpi_get_sleep_type_data(ACPI_STATE_S0, >> &acpi_gbl_sleep_type_a, >> &acpi_gbl_sleep_type_b); >> if (ACPI_SUCCESS(status)) { >> sleep_type_value = >> ((acpi_gbl_sleep_type_a << ACPI_X_SLEEP_TYPE_POSITION) & >> ACPI_X_SLEEP_TYPE_MASK); >> >> (void)acpi_write((u64)(sleep_type_value | ACPI_X_SLEEP_ENABLE), >> &acpi_gbl_FADT.sleep_control); >> } >> >> Replacing that write with the corresponding code from >> acpi_hw_legacy_wake_prep while leaving the other acpi_hw_extended_* >> functions alone gets suspend/resume working consistantly. That isn't >> quite enough as events don't seem to get re-enabled so acpi buttons >> and such don't work after resume. Copying the enable power button code >> from acpi_hw_legacy_wake to acpi_hw_extended_wake at least gets the >> power button back but lid, brightness, etc remain dead. >> >> At the moment I've hacked these changes into v3.10.0-rc2 along with >> another hack to fix a video regression and it seems to behave >> reasonably well (minus the brightness keys and lid). I'm not sure what >> the apropriate fix is. Maybe find some way beyond their presence to >> detect if these registers are safe to use or just a device blacklist? > > > > > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center. -- Michael Marineau -- 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
