From patchwork Sat Mar 31 02:08:23 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Chiu X-Patchwork-Id: 10318497 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 1120A60380 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 ED9E32A67A for ; Sat, 31 Mar 2018 02:09:28 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E1B702A675; Sat, 31 Mar 2018 02:09:28 +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=unavailable 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 B65A82A66E for ; Sat, 31 Mar 2018 02:09:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752811AbeCaCIe (ORCPT ); Fri, 30 Mar 2018 22:08:34 -0400 Received: from mail-pg0-f65.google.com ([74.125.83.65]:36100 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752788AbeCaCIc (ORCPT ); Fri, 30 Mar 2018 22:08:32 -0400 Received: by mail-pg0-f65.google.com with SMTP id 201so6009328pgg.3 for ; Fri, 30 Mar 2018 19:08:31 -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=qJl3InwoBwPqwu2OKhqN7yjWrJ8g7H36Q2RIG8eJ9o0=; b=Yt5Z5JrN0KID58bJQ4TXFmmO5LCfoqdtJWCt+gDiLEk0u5dZAcWAQKxVV9kkIV4xms GcLB5T2GkbpiAz5ZqXRRDn7AiiU9bzCrhQk4FGFiLiCRLb9KFM9h3eQcsA2e8JEUqe54 2nMqQQfF8loMrs0twuLUz7wzCH++10zM5zrob7AvgZqnmjuR2d2FBR1f5amzKAfr4+7S yWnVsHiH4F+JsjafU7zX0knzeKsUCR8MIHH1nQvPChZQ5ukRMqd6Jf7PhI6S1OUQpPE4 4FiqIzkQ6vbXFIcFfpMg1J108l2A1wj6UnwzGRvWE/45/W7LLdpnyTvWTzO2gVFNeGC9 SLfw== 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=qJl3InwoBwPqwu2OKhqN7yjWrJ8g7H36Q2RIG8eJ9o0=; b=sHk4mEKCPBZLJVXBoVjHcR2iBe0O7av+e0ePFGzGj2otpp18MRbDVfIlQiJ+Ak1NY2 wqxTTKry0hVWgGzMYcbvWs97kUeXkEZJYkkTU1W1CiTRPa3fiUcqhjo10bIBhnjacjmD LXpvUXtTu7ZGYe1QkkOnsRlvw4n9xOFVuykEry4FQZo7x8zR4Jk/MDUJMl/CG2hYH/M2 5JJsogdina6oSLn7tlXrVh1742+zjrHtjvqa0hzKiQPYuXomamVQvgKESdeFtSIRJ8yI yGT+JKiWOSMxVnVuIXeFgD4WjHNOzbjFWRjLoeLedrWiZmzYdZ4FejFL+ZPixthNmdju VcqA== X-Gm-Message-State: AElRT7HBT1/npUq59SD63twO2RSXgnQ47iJaBiIhjJB63SviLuoVgKrF iKCuF7xG5+lStYu2EJ7g2H+ayX+w X-Google-Smtp-Source: AIpwx49eq/awcOd4t3m5Rojwh9Os1Aeg9tKeDlb2rxorgf4YXljF3DdlXl4pj8/ViGEsA/m4uJi6pQ== X-Received: by 2002:a17:902:6b45:: with SMTP id g5-v6mr1267221plt.171.1522462111342; Fri, 30 Mar 2018 19:08:31 -0700 (PDT) Received: from UniFi-mba.local.tw (60-251-143-220.HINET-IP.hinet.net. [60.251.143.220]) by smtp.gmail.com with ESMTPSA id t64sm18000626pfi.34.2018.03.30.19.08.29 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 30 Mar 2018 19:08:30 -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:08:23 +0800 Message-Id: <1522462103-84130-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 https://phabricator.endlessm.com/T21599 --- 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; }