Re: Help me fix a regression caused by 56b9918490 (PM: sleep: Simplify suspend-to-idle control flow)

["Kenneth R. Crudup" <kenny@panix.com>]

On Fri, 22 Nov 2019, Rafael J. Wysocki wrote:

> BTW, is the ec_no_wakeup=1 workaround still effective?

OK, I was wrong the first time, at least from the new Linus' tip (as of
merge commit 2027cabe6af anyway). So I did some testing, and I now have a matrix:

If "sleep_no_lps0" == 1, the machine never goes fully to sleep; the power
light stays on and the backlight goes off, but if I have external monitors
connected they're still showing dmesg activity. This is independent of the
state of "ec_no_wakeup".

If "ec_no_wakeup" == 1, the system *at times* will go to sleep and never return
(i.e. no power light comes on, it's totally unresponsive until I do a hard
reset with a power-button long-press) whether I'm plugged in or not.
This is new behavior.

If "ec_no_wakeup" == 0, the system goes fully to sleep and either of the
power button, lid opening or hitting a key resumes the laptop, but if I'm
plugged in and actually charging when I suspend (and I suspect if I plug
it in during suspend) it never returns, as in the case above.

Help! What can I do to return to the behavior of right before the s0 rework?

Where in the code could I start looking to try to find out where the machine
goes dead?

	-Kenny

-- 
Kenneth R. Crudup  Sr. SW Engineer, Scott County Consulting, Silicon Valley