From patchwork Sat Mar 31 02:09:31 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Chiu X-Patchwork-Id: 10318499 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 609A4602D6 for ; Sat, 31 Mar 2018 02:09:29 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 503EE2A616 for ; Sat, 31 Mar 2018 02:09:29 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 43E812A66E; Sat, 31 Mar 2018 02:09:29 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D6E942A672 for ; Sat, 31 Mar 2018 02:09:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752843AbeCaCJ0 (ORCPT ); Fri, 30 Mar 2018 22:09:26 -0400 Received: from mail-pg0-f66.google.com ([74.125.83.66]:40356 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752784AbeCaCJZ (ORCPT ); Fri, 30 Mar 2018 22:09:25 -0400 Received: by mail-pg0-f66.google.com with SMTP id h3so1942946pgq.7 for ; Fri, 30 Mar 2018 19:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endlessm-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=1gliRw/I/2ZENSdwZkaK0X330gAL0+J85XQ+o8BO9Uc=; b=xOyidychF32C3E5EvTMbpLoDdAudegjzRSk8xFqYdVCjzgSt0pePEpFLE5VppqT7k5 a/uJL/LtpWVsSfv2/ttWIVg/2n2C5Ts7QGvkf/4jkCBzkvYPAdDNgS04KK1ANT3XmJJ5 2NcQT9E8p3WtFrCqR433maghSeNttC611ib/qzlD4h9xHF2POtaiv9CdF2IUD+Vpj5UQ 1kevGnBy5xvJ7NiRoQzmUFgQCD70JbJHDGFqy5718nfSgdmUYor8Qiv4Vv1S/ycI7wnL S6ldZp/qYD5eEOoInJvDBObiJN+Y2bYUJ44OEPZ3+jmG7KsqvVrR8UCrUFF7+xYBJhSC ufhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=1gliRw/I/2ZENSdwZkaK0X330gAL0+J85XQ+o8BO9Uc=; b=ntlywPrfruNAOLvNWjAj7yoHoP00WdouMYvz/KN9OBKqAGsCWNUWcn2H7LlLmsqtPP DHnc32DPKGIi/CN3+0L4uyk0Ka2MLVF4R0zpkl5pSOTOMind6wEOYfWfxUQG+fCADDU/ LYuI9acYBeGXJMrTzjzh685pcn/ciDmCfBFGxGXwd9jTcSaP9+ar3OqABYC1ksL+zx7O ZRucfz/ZCXw5TSmk6jFO6ouGLPVvle01FnKhSWEWQxWZFiRkUoUyibttl1A9MVFAVz8X 5VwlqAcC1lohjMDscI/3UdKM2Zkszw3TUp1EEL3Sz9+WtcuSO+RhgYLnTCobWnfum7jz jlFg== X-Gm-Message-State: AElRT7GLooQkFlUhPNNb4NEXWWbF8jhg5sTqkIUCxUbm/MMi7qiPsDJ7 BVlsmuSiq3EnRQ6ouKLWxSBRJQ== X-Google-Smtp-Source: AIpwx4+pKL2Lw+6ZD4gq+b7qoIfwLsPkYPxSyAbCZ10S34W+vMiRucXiSsMgi8eqI9lFHB09ajkNjg== X-Received: by 10.98.103.199 with SMTP id t68mr971801pfj.24.1522462164504; Fri, 30 Mar 2018 19:09:24 -0700 (PDT) Received: from UniFi-mba.local.tw (220-133-8-225.HINET-IP.hinet.net. [220.133.8.225]) by smtp.gmail.com with ESMTPSA id l26sm22052394pfj.70.2018.03.30.19.09.22 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 30 Mar 2018 19:09:23 -0700 (PDT) From: Chris Chiu To: rjw@rjwysocki.net, lenb@kernel.org Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, linux@endlessm.com, Chris Chiu Subject: [PATCH] ACPI / PM: Fix wake up by PS2 keyboard fail on ASUS UX331UA Date: Sat, 31 Mar 2018 10:09:31 +0800 Message-Id: <1522462171-84178-1-git-send-email-chiu@endlessm.com> X-Mailer: git-send-email 2.5.4 (Apple Git-61) Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This issue happens on new ASUS laptop UX331UA which has modern standby mode (suspend-to-idle). Pressing keys on the PS2 keyboard can't wake up the system from suspend-to-idle which is not expected. However, pressing power button can wake up without problem. Per the engineers of ASUS, the keypress event is routed to Embedded Controller (EC) in standby mode. EC then signals the SCI event to BIOS so BIOS would Notify() power button to wake up the system. It's from BIOS perspective. What we observe here is that kernel receives the SCI event from SCI interrupt handler which informs that the GPE status bit belongs to EC needs to be handled and then queries the EC to find out what event is pending. Then execute the following ACPI _QDF method which defined in ACPI DSDT for EC to notify power button. Method (_QDF, 0, NotSerialized) // _Qxx: EC Query { Notify (PWRB, 0x80) // Status Change } With more debug messages added to analyze this problem, we find that the keypress does wake up the system from suspend-to-idle but it's back to suspend again almost immediately. As we see in the following messages, the acpi_button_notify() is invoked but acpi_pm_wakeup_event() can not really wake up the system here because acpi_s2idle_wakeup() is false. The acpi_s2idle_wakeup() returnd false because the acpi_s2idle_sync() has alrealdy exited. [ 52.987048] s2idle_loop going s2idle [ 59.713392] acpi_s2idle_wake enter [ 59.713394] acpi_s2idle_wake exit [ 59.760888] acpi_ev_gpe_detect enter [ 59.760893] acpi_s2idle_sync enter [ 59.760893] acpi_ec_query_flushed ec pending queries 0 [ 59.760953] Read registers for GPE 50-57: Status=01, Enable=01, RunEnable=01, WakeEnable=00 [ 59.760955] ACPI: EC: ===== IRQ (1) ===== [ 59.760972] ACPI: EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0 [ 59.760979] ACPI: EC: +++++ Polling enabled +++++ [ 59.760979] ACPI: EC: ##### Command(QR_EC) submitted/blocked ##### [ 59.761003] acpi_s2idle_sync exit [ 59.769587] ACPI: EC: ##### Query(0xdf) started ##### [ 59.769611] ACPI: EC: ##### Query(0xdf) stopped ##### [ 59.774154] acpi_button_notify button type 1 [ 59.813175] s2idle_loop going s2idle acpi_s2idle_sync() already makes an effort to flush the EC event queue, but in this case, the EC event has yet to be generated when the call to acpi_ec_flush_work() is made. The event is generated shortly after, through the ongoing handling of the SCI interrupt which is happening on another CPU, and we must synchronize that to make sure that it has run and completed. Adding another call to acpi_os_wait_events_complete() solves this issue, since that function synchronizes with SCI interrupt completion. Signed-off-by: Chris Chiu --- drivers/acpi/sleep.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c index 8082871..c6e1b4b 100644 --- a/drivers/acpi/sleep.c +++ b/drivers/acpi/sleep.c @@ -982,8 +982,9 @@ static void acpi_s2idle_sync(void) * The EC driver uses the system workqueue and an additional special * one, so those need to be flushed too. */ + acpi_os_wait_events_complete(); /* synchronize SCI IRQ handling */ acpi_ec_flush_work(); - acpi_os_wait_events_complete(); + acpi_os_wait_events_complete(); /* synchronize Notify handling */ s2idle_wakeup = false; }