[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <cover.1423123818.git.lv.zheng@intel.com>
Date: Thu, 5 Feb 2015 16:24:29 +0800
From: Lv Zheng <lv.zheng@...el.com>
To: "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Len Brown <len.brown@...el.com>
Cc: Lv Zheng <lv.zheng@...el.com>, Lv Zheng <zetalog@...il.com>,
<linux-kernel@...r.kernel.org>, linux-acpi@...r.kernel.org
Subject: [PATCH v4 0/6] ACPI / EC: Fix GPE handling related races.
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(-)
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists