From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757751AbbBEO4y (ORCPT ); Thu, 5 Feb 2015 09:56:54 -0500 Received: from v094114.home.net.pl ([79.96.170.134]:51562 "HELO v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753299AbbBEO4w (ORCPT ); Thu, 5 Feb 2015 09:56:52 -0500 From: "Rafael J. Wysocki" To: Lv Zheng Cc: "Rafael J. Wysocki" , Len Brown , Lv Zheng , linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH v4 0/6] ACPI / EC: Fix GPE handling related races. Date: Thu, 05 Feb 2015 16:19:48 +0100 Message-ID: <8695025.SuvMBZB7tJ@vostro.rjw.lan> User-Agent: KMail/4.11.5 (Linux/3.16.0-rc5+; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, February 05, 2015 04:24:29 PM Lv Zheng wrote: > This patchset is based on ACPICA 20150204 release. > > This patchset introduces a GPE raw handler mode and switches EC driver into > a GPE raw handler mode user. > > The EC driver is a kind of the hardware driver that wants to control the > interrupt handling itself (for example, implementing the storming > prevention or the burst mode). But it has no mean to do so using the EC > firmware provided commands. The EC driver has to rely on the GPE APIs to > achieve the interrupt controlling. > Due to the shortcoming of the current ACPICA GPE APIs, the EC driver is > using the GPE APIs in a racy way. We then can see many issues between the > ACPICA internal GPE controlling and the EC driver's GPE handling. Such > races prevents us from correctly root causing other EC issues. This > patchset fixes the GPE related race issues by holding the EC state machine > lock for the whole EC GPE handling process: > Lock(EC) <- EC lock > if (STS==1) <- GPE API > STS=0 <- GPE API > EC_SC read <- EC GPE handler > EC_SC handled <- EC GPE handler > Unlock(EC) <- EC lock > > We can see several GPE handling stuffs improved by applying this patchset > because of EC/GPE races fixed: > 1. Some platforms may suffer from GPE loss, which is because GPE is handled > in the polling mode with its GPE indication left uncleared, the > uncleared indication may stop further GPEs from being triggered. > This patchset can make sure the indication has been cleared before > handling, thus it may have fixed the potential root cause of the bugs > that were originally fixed by the MSI quirk. > 2. We originally can see many no-op EC GPE handler invocations, which is > becaue GPE can be handled in the task context after the GPE IRQ handler > is invoked, then when the driver goes back to the handler, there is no > indication left for it to handle. > This patchset can reduce the number of no-op EC GPE handler invocations > to almost 0 by fixing the races, thus it may have fixed the potential > root cause of the issues that were originally fixed by the storming > condition threshold quirk. > > Lv Zheng (6): > ACPICA: Events: Introduce ACPI_GPE_DISPATCH_RAW_HANDLER to fix 2 > issues for the current GPE APIs. > ACPICA: Events: Introduce acpi_set_gpe()/acpi_finish_gpe() to reduce > divergences. > ACPICA: Events: Enable APIs to allow interrupt/polling adaptive > request based GPE handling model. > ACPI / EC: Fix several GPE handling issues by deploying > ACPI_GPE_DISPATCH_RAW_HANDLER mode. > ACPI / EC: Reduce ec_poll() by referencing the last register access > timestamp. > ACPI / EC: Update revision due to raw handler mode. > > drivers/acpi/acpica/evgpe.c | 52 +++++++++++++++--- > drivers/acpi/acpica/evgpeblk.c | 2 + > drivers/acpi/acpica/evgpeinit.c | 6 +- > drivers/acpi/acpica/evgpeutil.c | 6 +- > drivers/acpi/acpica/evxface.c | 115 +++++++++++++++++++++++++++++++++++---- > drivers/acpi/acpica/evxfgpe.c | 114 ++++++++++++++++++++++++++++++++++++++ > drivers/acpi/ec.c | 104 ++++++++++++++++++++++++++++++----- > include/acpi/acpixf.h | 8 +++ > include/acpi/actypes.h | 11 ++-- > 9 files changed, 375 insertions(+), 43 deletions(-) Whole series queued up for 3.20, thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.