Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp496674ybl; Wed, 21 Aug 2019 00:37:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqzjTCCJkLG07sodJSDnfo37vDmzpTcuMJRtVB6NyA8EmCWemNezGp8vwPE5h9HtNIDO8Re9 X-Received: by 2002:a17:902:a40d:: with SMTP id p13mr17354827plq.92.1566373069398; Wed, 21 Aug 2019 00:37:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566373069; cv=none; d=google.com; s=arc-20160816; b=KDvF/8ZvA3KRp4a1Rc0M38lSEASTtB3R63kmwfBIOAATmBLu48RmF8XZ/x+Ovmfxdv l3GbwrQpYsF24E0tVbe06nFG3wjbDGh4Kcvwf0jLAvW/Qc7P9epJM5YiJe8W0mNMeXjv rkcUnrQJI0VE3SDpsIv280xvoZj1F2rlC0B5gd1i6Py8HFv5gne01ItcAM2irusaJelC s0qBpfXSkYZfJIRPfdD3GK5mKlrnI9TXHweAEhvV34oL7Bm01WBTezJV0mhbjLSHs9Sb Zzkei+6KI3zEjIPULVdF4jsmdvhG8QkjmVEWslnYiFBhFvu3nBFcl745rw3OXKivOPtB 2ocA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=loEkzu7PwyplZMOXsRg7Frr5hM30dLjiHBYgbEapcWA=; b=afaKZQeuo5mrcl/XTr+jETKUI5o7Ahjr2D+oksVKUbMKFrXXgV3wsQ6mvMhG5+9RB2 RtpyvC8K/N+f4PyTKpOzb0+dEHgDhSPjXn38JZ3ow/ADHq+eZXWOIa75PfeZiZvMsY0C wAsGowHpEeO454zSN3NWJgpuP/4ZdpA4NJ5EjfsllQ2pSuAAibwa8n7zL2sv64QD3+k7 9CIjv9qAMb1K5NsLd1PaNrqIKxFViW4Ipwru743Yo9TimD1IgE38JaD8TDaf5taimvr2 h0nMlsT+BElCzuk5PP/6jyDiF3gomOh58seH2zBwOrVAYbp+5LWTai95x8CEN1SUCF+s t+Cg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l24si14893406pff.66.2019.08.21.00.37.33; Wed, 21 Aug 2019 00:37:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727785AbfHUHbJ (ORCPT + 99 others); Wed, 21 Aug 2019 03:31:09 -0400 Received: from mail-oi1-f195.google.com ([209.85.167.195]:45470 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725787AbfHUHbJ (ORCPT ); Wed, 21 Aug 2019 03:31:09 -0400 Received: by mail-oi1-f195.google.com with SMTP id v12so857949oic.12; Wed, 21 Aug 2019 00:31:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=loEkzu7PwyplZMOXsRg7Frr5hM30dLjiHBYgbEapcWA=; b=aB414stHpERATSG/k84kfsZaRUmnk7cv4ZaLimsqTnxQ0errv5HgsIRAYQRsC14ePS TVIK/V91N9zqc/jkEJt1rXx+JxwF5d110lswIzygJmHRDaIV46nlA25W57gT7l4vGvRp odOK9c9AOZ7oMRIIdOtY3tI5LFpGghqwdb6S6bdoj4Z3Vob/ur4R1Ww5F5/k9mqNO/S9 Xr19p9Zq/w1RGswsLWfuvp6+BZ28P8FtkoLkskFgi1wP/kRuI2lZL37K8pdEytzUxs3s yv7QBKARFXxhIqcqYiFgK1hBJqKUEcE8r+SI4XVQso90Qgbc8Gr/XPOEUFzzIXeTNrGc PlDA== X-Gm-Message-State: APjAAAUTepBzw0b6dJeg6FXbeO3ElE55hyI2g0PPupx0SbmiVgp2MIiO 2uHjqkSHg+KLyQ225Zy18umib1GmeVTe851NuNA= X-Received: by 2002:aca:cfcb:: with SMTP id f194mr2963097oig.103.1566372667391; Wed, 21 Aug 2019 00:31:07 -0700 (PDT) MIME-Version: 1.0 References: <5997740.FPbUVk04hV@kreacher> <5499590.X6jXHfmChQ@kreacher> <5924084c-cd89-c213-5926-9f303dcd3b39@klausen.dk> In-Reply-To: <5924084c-cd89-c213-5926-9f303dcd3b39@klausen.dk> From: "Rafael J. Wysocki" Date: Wed, 21 Aug 2019 09:30:55 +0200 Message-ID: Subject: Re: [PATCH v3 0/8] PM / ACPI: sleep: Additional changes related to suspend-to-idle To: Kristian Klausen Cc: "Rafael J. Wysocki" , Linux ACPI , Linux PM , LKML , Zhang Rui , Rajneesh Bhardwaj , Andy Shevchenko , Mario Limonciello , Kai-Heng Feng Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 21, 2019 at 12:47 AM Kristian Klausen wrote: > > On 20.08.2019 23.38, Rafael J. Wysocki wrote: > > On Tuesday, August 20, 2019 3:29:48 PM CEST Rafael J. Wysocki wrote: > >> On Tue, Aug 20, 2019 at 3:10 PM Kristian Klausen wrote: > >>> On 19.08.2019 22.41, Rafael J. Wysocki wrote: > >>>> On Mon, Aug 19, 2019 at 5:47 PM Kristian Klausen wrote: > >>>>> On 19.08.2019 11.05, Rafael J. Wysocki wrote: > >>>>>> On Monday, August 19, 2019 9:59:02 AM CEST Rafael J. Wysocki wrote: > >>>>>>> On Fri, Aug 16, 2019 at 10:26 PM Kristian Klausen wrote: > >>>>>>>> On 02.08.2019 12.33, Rafael J. Wysocki wrote: > >>>>>>>>> Hi All, > >>>>>>>>> > >>>>>>>>>>> On top of the "Simplify the suspend-to-idle control flow" patch series > >>>>>>>>>>> posted previously: > >>>>>>>>>>> > >>>>>>>>>>> https://lore.kernel.org/lkml/71085220.z6FKkvYQPX@kreacher/ > >>>>>>>>>>> > >>>>>>>>>>> sanitize the suspend-to-idle flow even further. > >>>>>>>>>>> > >>>>>>>>>>> First off, decouple EC wakeup from the LPS0 _DSM processing (patch 1). > >>>>>>>>>>> > >>>>>>>>>>> Next, reorder the code to invoke LPS0 _DSM Functions 5 and 6 in the > >>>>>>>>>>> specification-compliant order with respect to suspending and resuming > >>>>>>>>>>> devices (patch 2). > >>>>>>>>>>> > >>>>>>>>>>> Finally, rearrange lps0_device_attach() (patch 3) and add a command line > >>>>>>>>>>> switch to prevent the LPS0 _DSM from being used. > >>>>>>>>>> The v2 is because I found a (minor) bug in patch 1, decided to use a module > >>>>>>>>>> parameter instead of a kernel command line option in patch 4. Also, there > >>>>>>>>>> are 4 new patches: > >>>>>>>>>> > >>>>>>>>>> Patch 5: Switch the EC over to polling during "noirq" suspend and back > >>>>>>>>>> during "noirq" resume. > >>>>>>>>>> > >>>>>>>>>> Patch 6: Eliminate acpi_sleep_no_ec_events(). > >>>>>>>>>> > >>>>>>>>>> Patch 7: Consolidate some EC code depending on PM_SLEEP. > >>>>>>>>>> > >>>>>>>>>> Patch 8: Add EC GPE dispatching debug message. > >>>>>>>>> The v3 is just a rearranged v2 so as to move the post sensitive patch (previous patch 2) > >>>>>>>>> to the end of the series. [After applying the full series the code is the same as before.] > >>>>>>>>> > >>>>>>>>> For easier testing, the series (along with some previous patches depended on by it) > >>>>>>>>> is available in the pm-s2idle-testing branch of the linux-pm.git tree at kernel.org: > >>>>>>>>> > >>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=pm-s2idle-testing > >>>>>>>> It was just testing this patch series(461fc1caed55), to see if it would > >>>>>>>> fix my charging issue > >>>>>>>> (https://bugzilla.kernel.org/show_bug.cgi?id=201307), which it didn't. > >>>>>>> It is unlikely to help in that case. > >>>>> Do you have any idea what the issue could be? > >>>> Basically, there are two possibilities: either the OS is expected to > >>>> handle the AC/battery switching events, or the platform firmware > >>>> should take care of them. In the former case, the EC should generate > >>>> events to be handled by the OS and in the latter one there needs to be > >>>> a way to let the platform firmware that it needs to take care of those > >>>> events going forward. > >>>> > >>>> In either case there may be a platform-specific action to be carried > >>>> out during suspend and resume to set this up as expected which may be > >>>> missing. > >>> Thanks for the explanation. I don't think I have the expertise to solve > >>> the issue, but at least now I'm one step closer. > >>>>>>>> I did however notice that my laptop (ASUS Zenbook UX430UNR/i7-8550U) > >>>>>>>> won't wake when opening the lid or pressing a key, the only way to wake > >>>>>>>> the laptop is pressing the power button. > >>>>>>>> > >>>>>>>> I also tested mainline (5.3.0-rc4 b7e7c85dc7b0) and 5.2.8 and the laptop > >>>>>>>> wakes without issue when the lid is opened or a key is presed. > >>>>>>>>> Please refer to the changelogs for details. > >>>>>>> Thanks for your report. > >>>>>>> > >>>>>>> I seem to see a similar issue with respect to the lid on one of my > >>>>>>> test machines, looking into it right now. > >>>>>> Well, my lid issue seems to be unrelated as it doesn't result from any patches in the > >>>>>> series in question. > >>>>>> > >>>>>> First off, please clone 5.3-rc5 from kernel.org and double check if the issue is not > >>>>>> present in that one. > >>>>>> > >>>>>> If that's not the case, merge the pm-s2idle-rework branch from my tree on top of it > >>>>>> and retest. > >>>>>> > >>>>>> If you still see the issue then, apply the appended patch (on top of the pm-s2idle-reqork > >>>>>> branch ) and, after starting the kernel, do > >>>>>> > >>>>>> # echo 1 > /sys/power/pm_debug_messages > >>>>>> > >>>>>> suspend the system and try to wake it up through all of the ways that stopped working. > >>>>>> > >>>>>> Then, wake it up with the power button, save the output of dmesg and send it to me. > >>>>>> > >>>>>> Thanks! > >>>>> With 5.3-rc5 the laptops wakes up without any issue when pressing a key > >>>>> or opening the lid. > >>>>> With v5.3-rc5+pm-s2idle-testing I can only wake the laptop by pressing > >>>>> the power button. > >>>> OK, thanks for verifying. > >>>> > >>>> So it is unclear to me how the series can cause an issue like that to appear. > >>>> > >>>>> dmesg with pm_debug_messages=1 and your patch: > >>>>> [ 55.646109] PM: suspend entry (s2idle) > >>>>> [ 55.698559] Filesystems sync: 0.052 seconds > >>>>> [ 55.698561] PM: Preparing system for sleep (s2idle) > >>>>> [ 55.700661] Freezing user space processes ... (elapsed 0.210 seconds) > >>>>> done. > >>>>> [ 55.911494] OOM killer disabled. > >>>>> [ 55.911495] Freezing remaining freezable tasks ... (elapsed 0.001 > >>>>> seconds) done. > >>>>> [ 55.913192] PM: Suspending system (s2idle) > >>>>> [ 55.913195] printk: Suspending console(s) (use no_console_suspend to > >>>>> debug) > >>>>> [ 55.914778] [drm] CT: disabled > >>>>> [ 55.916057] wlan0: deauthenticating from 64:70:02:a5:fd:02 by local > >>>>> choice (Reason: 3=DEAUTH_LEAVING) > >>>>> [ 56.045634] sd 2:0:0:0: [sda] Synchronizing SCSI cache > >>>>> [ 56.046650] sd 2:0:0:0: [sda] Stopping disk > >>>>> [ 56.287622] PM: suspend of devices complete after 371.285 msecs > >>>>> [ 56.287627] PM: start suspend of devices complete after 373.684 msecs > >>>>> [ 56.307155] PM: late suspend of devices complete after 19.477 msecs > >>>>> [ 56.312479] ACPI: EC: interrupt blocked > >>>>> [ 56.352761] PM: noirq suspend of devices complete after 45.205 msecs > >>>>> [ 56.352770] ACPI: \_PR_.PR00: LPI: Device not power manageable > >>>>> [ 56.352774] ACPI: \_PR_.PR01: LPI: Device not power manageable > >>>>> [ 56.352776] ACPI: \_PR_.PR02: LPI: Device not power manageable > >>>>> [ 56.352779] ACPI: \_PR_.PR03: LPI: Device not power manageable > >>>>> [ 56.352782] ACPI: \_PR_.PR04: LPI: Device not power manageable > >>>>> [ 56.352785] ACPI: \_PR_.PR05: LPI: Device not power manageable > >>>>> [ 56.352788] ACPI: \_PR_.PR06: LPI: Device not power manageable > >>>>> [ 56.352790] ACPI: \_PR_.PR07: LPI: Device not power manageable > >>>>> [ 56.352793] ACPI: \_SB_.PCI0.GFX0: LPI: Device not power manageable > >>>>> [ 56.352800] ACPI: \_SB_.PCI0.RP06.PXSX: LPI: Device not power manageable > >>>>> [ 56.357057] PM: suspend-to-idle > >>>>> [ 69.338656] PM: Timekeeping suspended for 12.178 seconds > >>>>> [ 69.338701] PM: irq_pm_check_wakeup: IRQ 9 > >>>>> [ 69.338704] PM: IRQ wakeup: IRQ 9 > >>>> This clearly is the power button event causing the system to wake up. > >>>> The other actions, whatever they were, didn't cause any interrupts to > >>>> be triggered. > >>>> > >>>> I suspect that the issue is related to the EC, so please try to revert commit > >>>> > >>>> fcd0a04267ac ACPI: PM: s2idle: Switch EC over to polling during "noirq" suspend > >>>> > >>>> and see if that makes any difference (should revert cleanly). > >>>> > >>>> If that doesn't make any difference, please also try to revert commits > >>>> (on top of the above revert) > >>>> > >>>> 11f26633cccb PM: suspend: Fix platform_suspend_prepare_noirq() > >>>> ac9eafbe930a ACPI: PM: s2idle: Execute LPS0 _DSM functions with > >>>> suspended devices > >>>> > >>>> (in this order) and retest. > >>> Reverting the following commits, didn't fix the issue: > >>> fcd0a04267ac ACPI: PM: s2idle: Switch EC over to polling during "noirq" > >>> suspend > >>> 6e86633a791f ACPI: PM: s2idle: Eliminate acpi_sleep_no_ec_events() > >>> 11f26633cccb PM: suspend: Fix platform_suspend_prepare_noirq() > >>> ac9eafbe930a ACPI: PM: s2idle: Execute LPS0 _DSM functions with > >>> suspended devices > >>> > >>> I didn't bother reverting all the commits, so I did a checkout of: > >>> b605c44c30b5 PM: sleep: Drop dpm_noirq_begin() and dpm_noirq_end() > >>> and everything works, then I did a checkout of: > >>> 10a08fd65ec1 ACPI: PM: Set up EC GPE for system wakeup from drivers that > >>> need it > >>> and the laptop won't wake when opening the lid or pressing a key. > >>> > >>> So 10a08fd65ec1 must be the culprit. > >> Good job, thanks! > >> > >> The assumption in there was that the EC GPE would not need to be set > >> up for wakeup unless it is needed either by the intel-hid or by the > >> intel-vbtn driver. On your platform it needs to be set up for wakeup > >> even though neither of these drivers is in use. > >> > >> Let me cut a fix patch and get back to you when it's ready. > > The appended patch should help, so please apply it (on top of > > v5.3-rc5+pm-s2idle-testing) and test. > It works, pressing a key or opening the lid the laptop wakes instantly. > Thanks! Thanks for the confirmation! I'll resend it with a changelog and tags, then.