From: Lv Zheng <lv.zheng@intel.com>
To: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <len.brown@intel.com>
Cc: Lv Zheng <lv.zheng@intel.com>, Lv Zheng <zetalog@gmail.com>,
<linux-kernel@vger.kernel.org>,
linux-acpi@vger.kernel.org
Subject: [PATCH v3 0/5] ACPI / EC: Move the event handling out of the noirq stage
Date: Wed, 3 Aug 2016 16:01:09 +0800 [thread overview]
Message-ID: <cover.1470205312.git.lv.zheng@intel.com> (raw)
In-Reply-To: <bd9df7ba491b33cfbaa46f4cc6a6325f74153e36.1469093001.git.lv.zheng@intel.com>
There is a known issue in the EC driver.
1. During the suspend/resume process, the EC driver is required to work
even in the noirq stage. And currently the event handling is
disabled/enabled in the noirq stage.
2. Unfortunately, the EC driver only implements the polling mode for
handling the transactions, and is not prepared to handle events in the
polling mode.
The result of the above conflict is: if an SCI_EVT is indicated during the
noirq stage (especially after resuming), the EC driver is not able to
detect the SCI_EVT unless:
1. GPE STS not cleared: When the GPE is enabled, advance_transaction() will
be invoked to poll SCI_EVT.
2. EC transaction occurred: When an EC transaction ocurred,
advance_transaction() will be invoked in the
polling mode.
If an SCI_EVT ocurred during noirq stage and the above 2 triggering sources
cannot handle it, then a problem could be seen by the users:
If SCI_EVT is left set after resuming and there is still no EC
transactions, this event cannot be handled.
This patchset tries to disable/enable the event handling out of the noirq
stage to fix this issue.
Though it is always correct to enable the event handling in a later stage
during resuming as long as the event won't be lost, it may not be correct
to disable the event handling in an earlier stage during suspending. This
patchset thus put a boot parameter for the suspending part tuning in order
to be able to respond to the possible regressions.
Since the event handling is disabled for a longer period during
suspend/resume, this patchset can also tune the suspend/resume speed
faster.
Lv Zheng (5):
ACPI / EC: Add EC_FLAGS_QUERY_ENABLED to reveal a hidden logic
ACPI / EC: Fix an issue that SCI_EVT cannot be detected after event
is enabled
ACPI / EC: Add PM operations to improve event handling for resume
process
ACPI / EC: Add PM operations to improve event handling for suspend
process
ACPI / EC: Enable event freeze mode to improve event handling
efficiency for suspend process
drivers/acpi/ec.c | 177 +++++++++++++++++++++++++++++++++++------------
drivers/acpi/internal.h | 1 -
drivers/acpi/sleep.c | 4 +-
3 files changed, 136 insertions(+), 46 deletions(-)
--
1.7.10
next prev parent reply other threads:[~2016-08-03 11:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-21 9:36 [PATCH 1/2] ACPI / EC: Add PM operations to tune polling mode efficiency Lv Zheng
2016-07-21 9:36 ` [PATCH 2/2] ACPI / EC: Add PM operations to block event handling Lv Zheng
2016-07-26 0:11 ` Zheng, Lv
2016-07-29 10:05 ` [PATCH v2 0/2] ACPI / EC: Tune suspend/resume speed using PM operations Lv Zheng
2016-07-29 10:05 ` [PATCH v2 1/2] ACPI / EC: Add PM operations to tune polling mode efficiency Lv Zheng
2016-07-29 10:05 ` [PATCH v2 2/2] ACPI / EC: Add PM operations to block event handling Lv Zheng
2016-08-03 1:03 ` Zheng, Lv
2016-08-03 8:01 ` Lv Zheng [this message]
2016-08-03 8:01 ` [PATCH v3 1/5] ACPI / EC: Add EC_FLAGS_QUERY_ENABLED to reveal a hidden logic Lv Zheng
2016-08-03 8:01 ` [PATCH v3 2/5] ACPI / EC: Fix an issue that SCI_EVT cannot be detected after event is enabled Lv Zheng
2016-08-03 8:01 ` [PATCH v3 3/5] ACPI / EC: Add PM operations to improve event handling for resume process Lv Zheng
2016-08-03 8:01 ` [PATCH v3 4/5] ACPI / EC: Add PM operations to improve event handling for suspend process Lv Zheng
2016-08-03 8:01 ` [PATCH v3 5/5] ACPI / EC: Enable event freeze mode " Lv Zheng
2016-09-12 21:59 ` [PATCH v3 0/5] ACPI / EC: Move the event handling out of the noirq stage Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1470205312.git.lv.zheng@intel.com \
--to=lv.zheng@intel.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rjw@rjwysocki.net \
--cc=zetalog@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox