On Tuesday, May 23, 2017 09:58:49 PM Hans de Goede wrote:
> Hi,
Hi,
> On (some?) Cherry Trail devices the system can be woken up
> by pressing a key on the USB attached keyboard (even on some tablets
> with an external USB keyboard).
So first I need to know if this is with USB wakeup properly enabled via sysfs
or just because the system reacts to the first ACPI interrupt triggered while
suspended.
Note that USB wakeup is not enabled by default in the kernel, so if user
space init doesn't do that, it has to be done manually.
> This has never worked properly, with 4.11 it works once, followed
> by a "irq 9: nobody cared" message, after which other wakeup
> methods will need to be used (luckily irq 9 is otherwise unused).
>
> Since commit eed4d47efe95("ACPI / sleep: Ignore spurious SCI wakeups
> from suspend-to-idle") the first wakeup by USB-keyboard also no longer
> works.
Which makes me a bit suspicious about the "works" part.
> Worse, trying to wake up the system through an USB-keyboard (or in
> case of laptop models _the_ keyboard) seems to result in the
> system no longer waking up at all, not even through other wake-up
> sources.
>
> While testing I got the system to wake-up once after trying a wakeup
> with the usb-keyb first. I managed to get it to wake-up by repeatedly
> pressing the power-button without pressing it long enough for the
> system to do a hard-poweroff. Here is what I found in dmesg in this
> case:
>
> [ 99.987110] PM: Preparing system for sleep (freeze)
> [ 99.990133] Freezing user space processes ... (elapsed 0.003 seconds) done.
> [ 99.993359] OOM killer disabled.
> [ 99.993360] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> [ 99.994592] PM: Suspending system (freeze)
> [ 99.994594] Suspending console(s) (use no_console_suspend to debug)
> [ 100.005486] serial 00:01: disabled
> [ 101.133291] PM: suspend of devices complete after 1135.306 msecs
> [ 101.133296] PM: suspend devices took 1.139 seconds
> [ 101.155819] PM: late suspend of devices complete after 22.522 msecs
> [ 101.183734] PM: noirq suspend of devices complete after 27.902 msecs
> [ 101.183746] PM: suspend-to-idle
> [ 106.750715] Suspended for 5.203 seconds
> [ 106.751155] PM: resume from suspend-to-idle
> [ 106.777022] PM: noirq resume of devices complete after 25.650 msecs
> [ 106.805621] PM: noirq suspend of devices complete after 27.745 msecs
> [ 106.830932] PM: noirq resume of devices complete after 25.309 msecs
> [ 106.858605] PM: noirq suspend of devices complete after 27.023 msecs
> <repeated lots (really lots) of times>
> [ 146.693603] irq 9: nobody cared (try booting with the "irqpoll" option)
> <backtrace about irq>
> [ 146.693861] Disabling IRQ #9
> [ 149.179549] PM: noirq suspend of devices complete after 3857.221 msecs
> [ 149.179563] PM: suspend-to-idle
> [ 2519.926892] Suspended for 2371.000 seconds
> [ 2519.927373] PM: resume from suspend-to-idle
> [ 2519.953064] PM: noirq resume of devices complete after 25.272 msecs
> [ 2521.066390] PM: early resume of devices complete after 1113.460 msecs
> [ 2521.067464] pcieport 0000:00:1c.0: System wakeup disabled by ACPI
> [ 2521.068616] rtc_cmos 00:04: System wakeup disabled by ACPI
> <unrelated i915 unclaimed register access oops>
> [ 2521.131849] PM: resume of devices complete after 65.482 msecs
> [ 2521.132828] PM: resume devices took 0.066 seconds
> [ 2521.132895] PM: Finishing wakeup.
> [ 2521.132896] OOM killer enabled.
> [ 2521.132897] Restarting tasks ... done.
>
> I have a fix for the "irq 9: nobody cared" issue and I actually found
> this regression(ish) while trying to test this fix.
>
> The "irq 9: nobody cared" issue is caused by Linux not having a driver
> for the INT0002 ACPI device, let me quote the commit message for the
> driver for this device which fixes this with 4.11:
>
> "Some peripherals on Baytrail and Cherrytrail platforms signal PME to the
> PMC to wakeup the system. When this happens software needs to clear the
> PME_B0_STS bit in the GPE0a_STS register to avoid an IRQ storm on IRQ 9.
>
> This is modeled in ACPI through the INT0002 ACPI device.
>
> This commit adds a driver which will bind to that device, call the
> ACPI event handler for the wakeup and clear the interrupt source
> avoiding the irq storm."
>
> The int0002 driver shares irq 9 / the SCI with the ACPI subsys,
This is why in interacts with the commit in question.
> it detects if the interrupt is for it by doing the following:
>
> gpe_sts_reg = inl(GPE0A_STS_PORT);
> if (!(gpe_sts_reg & GPE0A_PME_B0_STS_BIT))
> return IRQ_NONE;
>
> Looking at the "ACPI / sleep: Ignore spurious SCI wakeups from
> suspend-to-idle" commit I've added a pm_wakeup_hard_event()
> to the int0002 driver when the GPE0A_PME_B0_STS_BIT is set and
> with this change the fix works for 4.12-rc1 too and fixes the
> issue with the system more or less hanging on the first wakeup
> attempt by USB-keyboard.
Does the USB keyboard still wake up only once?
> So the question now is how to move forward with this, although
> this may not really count as a regression the change from wakeup
> by USB-keyboard working once, to it more or less hanging the
> system certainly does not make things better.
>
> As such I think it might be a good idea to merge the int0002 driver
> during the 4.12 cycle ?
It looks like that.
> The int0002 driver was a platform/x86 driver, but various people
> have asked to redo it as a gpio driver. I will post the new
> version shortly and put everyone who is getting this mail on
> the CC.
OK, thanks!
Rafael
--
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
