All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linux PM list <linux-pm@vger.kernel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Linux PCI <linux-pci@vger.kernel.org>
Subject: Re: [Update][PATCH 3/3] input: i8042: Avoid resetting controller on system suspend/resume
Date: Mon, 12 Oct 2015 22:17:05 +0200	[thread overview]
Message-ID: <5474174.JsPHbLRjZ7@vostro.rjw.lan> (raw)
In-Reply-To: <1738265.GZcYUZQGSy@vostro.rjw.lan>

On Wednesday, October 07, 2015 03:03:57 AM Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> If the upcoming system suspend is not going to be handled by the
> platform firmware, like in the suspend-to-idle case, it is not
> necessary to reset the controller in i8042_pm_suspend(), so avoid
> doing that.
> 
> Moreover, if the system resume currently in progress has not been
> started by the platform firmware, like in the suspend-to-idle case,
> i8042_controller_resume() need not be called by i8042_pm_resume(),
> so avoid doing that too in that case.
> 
> Additionally, try to catch the event that woke up the system by
> calling the interrupt handler early during system resume if it has
> not been started by the platform firmware.
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

If there are no more comments here, I'll tentatively queue it up for v4.4
along with the [1-2/3] from this series.

Please let me know if there are any problems with that.

Thanks,
Rafael


> ---
>  drivers/input/serio/i8042.c |   32 +++++++++++++++++++++++++++-----
>  1 file changed, 27 insertions(+), 5 deletions(-)
> 
> Index: linux-pm/drivers/input/serio/i8042.c
> ===================================================================
> --- linux-pm.orig/drivers/input/serio/i8042.c
> +++ linux-pm/drivers/input/serio/i8042.c
> @@ -24,6 +24,7 @@
>  #include <linux/platform_device.h>
>  #include <linux/i8042.h>
>  #include <linux/slab.h>
> +#include <linux/suspend.h>
>  
>  #include <asm/io.h>
>  
> @@ -1170,7 +1171,8 @@ static int i8042_pm_suspend(struct devic
>  {
>  	int i;
>  
> -	i8042_controller_reset(true);
> +	if (pm_suspend_via_firmware())
> +		i8042_controller_reset(true);
>  
>  	/* Set up serio interrupts for system wakeup. */
>  	for (i = 0; i < I8042_NUM_PORTS; i++) {
> @@ -1183,8 +1185,17 @@ static int i8042_pm_suspend(struct devic
>  	return 0;
>  }
>  
> +static int i8042_pm_resume_noirq(struct device *dev)
> +{
> +	if (!pm_resume_via_firmware())
> +		i8042_interrupt(0, NULL);
> +
> +	return 0;
> +}
> +
>  static int i8042_pm_resume(struct device *dev)
>  {
> +	bool force_reset;
>  	int i;
>  
>  	for (i = 0; i < I8042_NUM_PORTS; i++) {
> @@ -1195,11 +1206,21 @@ static int i8042_pm_resume(struct device
>  	}
>  
>  	/*
> -	 * On resume from S2R we always try to reset the controller
> -	 * to bring it in a sane state. (In case of S2D we expect
> -	 * BIOS to reset the controller for us.)
> +	 * If platform firmware was not going to be involved in suspend, we did
> +	 * not restore the controller state to whatever it had been at boot
> +	 * time, so we do not need to do anything.
>  	 */
> -	return i8042_controller_resume(true);
> +	if (!pm_suspend_via_firmware())
> +		return 0;
> +
> +	/*
> +	 * We only need to reset the controller if we are resuming after handing
> +	 * off control to the platform firmware, otherwise we can simply restore
> +	 * the mode.
> +	 */
> +	force_reset = pm_resume_via_firmware();
> +
> +	return i8042_controller_resume(force_reset);
>  }
>  
>  static int i8042_pm_thaw(struct device *dev)
> @@ -1223,6 +1244,7 @@ static int i8042_pm_restore(struct devic
>  
>  static const struct dev_pm_ops i8042_pm_ops = {
>  	.suspend	= i8042_pm_suspend,
> +	.resume_noirq	= i8042_pm_resume_noirq,
>  	.resume		= i8042_pm_resume,
>  	.thaw		= i8042_pm_thaw,
>  	.poweroff	= i8042_pm_reset,
> 
> --

  reply	other threads:[~2015-10-12 20:17 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-30  0:46 [RFC][PATCH 0/2] PM / sleep: Make it possible to check if suspend/resume goes via firmware Rafael J. Wysocki
2015-09-30  0:52 ` [RFC][PATCH 1/2] PM / sleep: Add flags to indicate platform firmware involvement Rafael J. Wysocki
2015-09-30  0:53 ` [RFC][PATCH 2/2] PM / sleep: Kick devices that might have been reset by firmware Rafael J. Wysocki
2015-09-30  0:36   ` kbuild test robot
2015-09-30 14:46   ` Alan Stern
2015-09-30 21:51     ` Rafael J. Wysocki
2015-10-01 14:47       ` Alan Stern
2015-10-01 22:13         ` Rafael J. Wysocki
2015-10-02  1:50 ` [RFC][PATCH v2 0/2] PM / sleep: Make it possible to check if suspend/resume goes via firmware Rafael J. Wysocki
2015-10-02  1:52   ` [RFC][PATCH v2 1/2] PM / sleep: Add flags to indicate platform firmware involvement Rafael J. Wysocki
2015-10-02  1:54   ` [RFC][PATCH v2 2/2] PM / PCI / ACPI: Kick devices that might have been reset by firmware Rafael J. Wysocki
2015-10-06 22:48   ` [PATCH v3 0/3] PM / sleep: Make it possible to check if suspend/resume goes via firmware Rafael J. Wysocki
2015-10-06 22:49     ` [PATCH v3 1/3] PM / sleep: Add flags to indicate platform firmware involvement Rafael J. Wysocki
2015-10-06 22:50     ` [PATCH v3 2/3] PM / PCI / ACPI: Kick devices that might have been reset by firmware Rafael J. Wysocki
2015-10-06 22:53     ` [RFC][PATCH v3 3/3] input: i8042: Avoid resetting controller on system suspend/resume Rafael J. Wysocki
2015-10-06 22:34       ` Dmitry Torokhov
2015-10-06 23:08         ` Rafael J. Wysocki
2015-10-06 22:43           ` Dmitry Torokhov
2015-10-06 23:31             ` Rafael J. Wysocki
2015-10-06 23:11               ` kbuild test robot
2015-10-06 23:26               ` Dmitry Torokhov
2015-10-06 23:44                 ` Rafael J. Wysocki
2015-10-07  1:03       ` [Update][PATCH " Rafael J. Wysocki
2015-10-12 20:17         ` Rafael J. Wysocki [this message]
2015-10-12 20:11           ` Dmitry Torokhov
2015-10-12 20:41             ` 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=5474174.JsPHbLRjZ7@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=bhelgaas@google.com \
    --cc=daniel.vetter@intel.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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.