All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: "Kenneth R. Crudup" <kenny@panix.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Rafael Wysocki <rafael.j.wysocki@intel.com>,
	Linux PM <linux-pm@vger.kernel.org>
Subject: Re: Help me fix a regression caused by 56b9918490 (PM: sleep: Simplify suspend-to-idle control flow)
Date: Tue, 26 Nov 2019 19:48:50 +0100	[thread overview]
Message-ID: <12933162.9b7K5rSXZx@kreacher> (raw)
In-Reply-To: <alpine.DEB.2.21.1911260833250.2714@hp-x360n>

On Tuesday, November 26, 2019 5:35:10 PM CET Kenneth R. Crudup wrote:
> On Tue, 26 Nov 2019, Rafael J. Wysocki wrote:
> 
> > OK, so just to double check if I understand you correctly, you are
> > running the Linus' tip with [the patch] on top and with two extra
> > WARN_ON(1) statements in acpi_ec_query_flushed()?
> 
> Yeah:
> 
> ----
> $ git diff lk-linus/master drivers/acpi/
> 
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index da1e5c5ce150..0bb13a596e4f 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -530,9 +530,11 @@ static bool acpi_ec_query_flushed(struct acpi_ec *ec)
>  	bool flushed;
>  	unsigned long flags;
> 
> +	WARN_ON(1);
>  	spin_lock_irqsave(&ec->lock, flags);
>  	flushed = !ec->nr_pending_queries;
>  	spin_unlock_irqrestore(&ec->lock, flags);
> +	WARN_ON(1);
>  	return flushed;
>  }

I've just realized that it is not necessary to use acpi_ec_query_flushed() in
acpi_ec_flush_work() at all, because it calls flush_scheduled_work() anyway,
so the appended patch should be good to go.

Can you try it, please?

---
 drivers/acpi/ec.c    |   20 ++++++++++----------
 drivers/acpi/sleep.c |   13 ++++++++++---
 2 files changed, 20 insertions(+), 13 deletions(-)

Index: linux-pm/drivers/acpi/sleep.c
===================================================================
--- linux-pm.orig/drivers/acpi/sleep.c
+++ linux-pm/drivers/acpi/sleep.c
@@ -977,6 +977,13 @@ static int acpi_s2idle_prepare_late(void
 	return 0;
 }
 
+static void acpi_s2idle_sync(void)
+{
+	acpi_os_wait_events_complete(); /* synchronize GPE processing */
+	acpi_ec_flush_work();
+	acpi_os_wait_events_complete(); /* synchronize Notify handling */
+}
+
 static void acpi_s2idle_wake(void)
 {
 	/*
@@ -1005,9 +1012,7 @@ static void acpi_s2idle_wake(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 EC GPE processing */
-		acpi_ec_flush_work();
-		acpi_os_wait_events_complete(); /* synchronize Notify handling */
+		acpi_s2idle_sync();
 
 		rearm_wake_irq(acpi_sci_irq);
 	}
@@ -1024,6 +1029,8 @@ static void acpi_s2idle_restore_early(vo
 
 static void acpi_s2idle_restore(void)
 {
+	acpi_s2idle_sync();
+
 	s2idle_wakeup = false;
 
 	acpi_enable_all_runtime_gpes();
Index: linux-pm/drivers/acpi/ec.c
===================================================================
--- linux-pm.orig/drivers/acpi/ec.c
+++ linux-pm/drivers/acpi/ec.c
@@ -536,13 +536,8 @@ static bool acpi_ec_query_flushed(struct
 	return flushed;
 }
 
-static void __acpi_ec_flush_event(struct acpi_ec *ec)
+static void acpi_ec_flush_query_queue(void)
 {
-	/*
-	 * When ec_freeze_events is true, we need to flush events in
-	 * the proper position before entering the noirq stage.
-	 */
-	wait_event(ec->wait, acpi_ec_query_flushed(ec));
 	if (ec_query_wq)
 		flush_workqueue(ec_query_wq);
 }
@@ -554,14 +549,19 @@ static void acpi_ec_disable_event(struct
 	spin_lock_irqsave(&ec->lock, flags);
 	__acpi_ec_disable_event(ec);
 	spin_unlock_irqrestore(&ec->lock, flags);
-	__acpi_ec_flush_event(ec);
+
+	/*
+	 * When ec_freeze_events is true, we need to flush events in
+	 * the proper position before entering the noirq stage.
+	 */
+	wait_event(ec->wait, acpi_ec_query_flushed(ec));
+
+	acpi_ec_flush_query_queue();
 }
 
 void acpi_ec_flush_work(void)
 {
-	if (first_ec)
-		__acpi_ec_flush_event(first_ec);
-
+	acpi_ec_flush_query_queue();
 	flush_scheduled_work();
 }
 #endif /* CONFIG_PM_SLEEP */




  reply	other threads:[~2019-11-26 18:48 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-22  0:11 Help me fix a regression caused by 56b9918490 (PM: sleep: Simplify suspend-to-idle control flow) Kenneth R. Crudup
2019-11-22 10:12 ` Rafael J. Wysocki
2019-11-22 12:45   ` Rafael J. Wysocki
2019-11-22 17:35     ` Kenneth R. Crudup
2019-11-23 10:24     ` Kenneth R. Crudup
2019-11-24 16:02       ` Rafael J. Wysocki
2019-11-25  3:40         ` Kenneth R. Crudup
2019-11-25 13:27           ` Rafael J. Wysocki
2019-11-25 14:14             ` Rafael J. Wysocki
2019-11-25 18:27               ` Kenneth R. Crudup
2019-11-25 20:11                 ` Kenneth R. Crudup
2019-11-25 20:19                   ` Kenneth R. Crudup
2019-11-25 22:01                   ` Rafael J. Wysocki
2019-11-25 23:32                     ` Kenneth R. Crudup
2019-11-26  8:50                       ` Rafael J. Wysocki
2019-11-26 16:12                         ` Rafael J. Wysocki
2019-11-26 16:15                         ` Kenneth R. Crudup
2019-11-26 16:27                           ` Rafael J. Wysocki
2019-11-26 16:35                             ` Kenneth R. Crudup
2019-11-26 18:48                               ` Rafael J. Wysocki [this message]
2019-11-26 19:03                                 ` Kenneth R. Crudup
2019-11-26 19:09                                   ` Rafael J. Wysocki
2019-11-26 19:13                                     ` Kenneth R. Crudup
2019-11-26 19:45                                     ` Kenneth R. Crudup
2019-11-26 23:56                                     ` Kenneth R. Crudup
2019-11-27  2:35                                       ` Kenneth R. Crudup
2019-11-27  8:31                                         ` Rafael J. Wysocki
2019-11-27 22:30                                           ` Kenneth R. Crudup
2019-11-28 16:25                                             ` Rafael J. Wysocki
2019-11-25 21:47                 ` Rafael J. Wysocki
2019-11-25 16:21             ` Kenneth R. Crudup
2019-11-25 21:46               ` Rafael J. Wysocki
2019-11-25 23:02                 ` Kenneth R. Crudup
2019-11-26  8:53                   ` Rafael J. Wysocki
2019-11-25  5:50         ` Kenneth R. Crudup
2019-11-25  7:17           ` Kenneth R. Crudup
2019-11-22 17:29   ` Kenneth R. Crudup

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=12933162.9b7K5rSXZx@kreacher \
    --to=rjw@rjwysocki.net \
    --cc=kenny@panix.com \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rafael@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.