We have changed ACPICA to only use the new registers if the HW-reduced flag is set. This should fix the problem you are seeing. > -----Original Message----- > From: Michael Marineau [mailto:mike@xxxxxxxxxxxx] > Sent: Wednesday, May 22, 2013 1:51 PM > To: Rafael J. Wysocki > Cc: Moore, Robert; linux-acpi@xxxxxxxxxxxxxxx; Len Brown; Zheng, Lv > Subject: Re: ACPI v5 sleep registers broken on Toshiba laptops > > 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 ��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
