All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	"Robert R. Howell" <RHowell@uwyo.edu>
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT
Date: Mon, 24 Jun 2019 12:51:33 +0200	[thread overview]
Message-ID: <b02ef915-faf5-635d-bf2f-92dd10d274b1@redhat.com> (raw)
In-Reply-To: <2830645.pXxymQ5XCC@kreacher>

Hi Rafael,

<snip>

> Sorry for the long delay.
> 
> I haven't dropped this issue on the floor, I hope that you are still able to follow up here.
> 
> Can you please test the appended patch instead of the previous one?
> 
> I have found some inconsistencies in the handling of hibernation in the ACPI PM domain
> and the LPSS driver that should be covered by this patch.

I know this is just a testing patch for now, but still I've given it
a quick look, some comments inline.

> ---
>   drivers/acpi/acpi_lpss.c |   63 +++++++++++++++++++++++++++++++++++------------
>   drivers/acpi/device_pm.c |   30 ++++++++++++++++++++--
>   include/linux/acpi.h     |    4 ++
>   3 files changed, 79 insertions(+), 18 deletions(-)
> 
> Index: linux-pm/drivers/acpi/device_pm.c
> ===================================================================
> --- linux-pm.orig/drivers/acpi/device_pm.c
> +++ linux-pm/drivers/acpi/device_pm.c
> @@ -1171,6 +1171,32 @@ int acpi_subsys_thaw_noirq(struct device
>   	return pm_generic_thaw_noirq(dev);
>   }
>   EXPORT_SYMBOL_GPL(acpi_subsys_thaw_noirq);
> +
> +/**
> + * acpi_subsys_restore_noirq - Run the device driver's "noirq" restore callback.
> + * @dev: Device to handle.
> + */
> +int acpi_subsys_restore_noirq(struct device *dev)
> +{
> +	/* This is analogous to what acpi_subsys_resune_noirq() does. */
> +	if (dev_pm_smart_suspend_and_suspended(dev))
> +		pm_runtime_set_active(dev);
> +
> +	return pm_generic_restore_noirq(dev);
> +}
> +EXPORT_SYMBOL_GPL(acpi_subsys_restore_noirq);
> +
> +/**
> + * acpi_subsys_restore_early - Restore device using ACPI.
> + * @dev: Device to restore.
> + */
> +int acpi_subsys_restore_early(struct device *dev)
> +{
> +	int ret = acpi_dev_resume(dev);
> +	return ret ? ret : pm_generic_restore_early(dev);
> +}
> +EXPORT_SYMBOL_GPL(acpi_subsys_restore_early);
> +
>   #endif /* CONFIG_PM_SLEEP */
>   
>   static struct dev_pm_domain acpi_general_pm_domain = {
> @@ -1192,8 +1218,8 @@ static struct dev_pm_domain acpi_general
>   		.poweroff = acpi_subsys_suspend,
>   		.poweroff_late = acpi_subsys_suspend_late,
>   		.poweroff_noirq = acpi_subsys_suspend_noirq,
> -		.restore_noirq = acpi_subsys_resume_noirq,
> -		.restore_early = acpi_subsys_resume_early,
> +		.restore_noirq = acpi_subsys_restore_noirq,
> +		.restore_early = acpi_subsys_restore_early,
>   #endif
>   	},
>   };
> Index: linux-pm/drivers/acpi/acpi_lpss.c
> ===================================================================
> --- linux-pm.orig/drivers/acpi/acpi_lpss.c
> +++ linux-pm/drivers/acpi/acpi_lpss.c
> @@ -1069,36 +1069,67 @@ static int acpi_lpss_suspend_noirq(struc
>   	return acpi_subsys_suspend_noirq(dev);
>   }
>   
> -static int acpi_lpss_do_resume_early(struct device *dev)
> +static int acpi_lpss_resume_noirq(struct device *dev)
>   {
> -	int ret = acpi_lpss_resume(dev);
> +	struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
> +
> +	/* Follow acpi_subsys_resune_noirq(). */
> +	if (dev_pm_may_skip_resume(dev))
> +		return 0;
> +
> +	if (dev_pm_smart_suspend_and_suspended(dev))
> +		pm_runtime_set_active(dev);
>   
> -	return ret ? ret : pm_generic_resume_early(dev);
> +	if (pdata->dev_desc->resume_from_noirq) {
> +		int ret = acpi_lpss_resume(dev);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return pm_generic_resume_noirq(dev);
>   }

Hmm, normally acpi_lpss_resume runs at resume_early time, AFAIK
the order of resume callbacks calling is: resume_noirq, resume_early, resume

So normally our call order is:

---noirq-phase---
pm_generic_resume_noirq()
---early-phase---
acpi_lpss_resume()
pm_generic_resume_early()

My patch adding the resume_from_noirq flag, move the calling of
acpi_lpss_resume() to the resume_noirq phase (if the flag is
set) but kept the generic order, so the call order with the
flag set currently is:

---noirq-phase---
pm_generic_resume_noirq()
acpi_lpss_resume()
---early-phase---
pm_generic_resume_early()

So the order of the 3 calls relative to each other did not change.

You are changing this to:

---noirq-phase---
acpi_lpss_resume()
pm_generic_resume_noirq()
---early-phase---
pm_generic_resume_early()

So now when the flag is set acpi_lpss_resume() runs before
pm_generic_resume_noirq(). Is this intentional ?

Regards,

Hans




>   
>   static int acpi_lpss_resume_early(struct device *dev)
>   {
>   	struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
>   
> -	if (pdata->dev_desc->resume_from_noirq)
> -		return 0;
> +	if (!pdata->dev_desc->resume_from_noirq) {
> +		int ret = acpi_lpss_resume(dev);
> +		if (ret)
> +			return ret;
> +	}
>   
> -	return acpi_lpss_do_resume_early(dev);
> +	return pm_generic_resume_early(dev);
>   }
>   
> -static int acpi_lpss_resume_noirq(struct device *dev)
> +static int acpi_lpss_restore_noirq(struct device *dev)
>   {
>   	struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
> -	int ret;
>   
> -	ret = acpi_subsys_resume_noirq(dev);
> -	if (ret)
> -		return ret;
> +	/* Follow acpi_subsys_restore_noirq(). */
> +	if (dev_pm_smart_suspend_and_suspended(dev))
> +		pm_runtime_set_active(dev);
> +
> +	if (pdata->dev_desc->resume_from_noirq) {
> +		int ret = acpi_lpss_resume(dev);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return pm_generic_restore_noirq(dev);
> +}
> +
> +static int acpi_lpss_restore_early(struct device *dev)
> +{
> +	struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
>   
> -	if (!dev_pm_may_skip_resume(dev) && pdata->dev_desc->resume_from_noirq)
> -		ret = acpi_lpss_do_resume_early(dev);
> +	if (!pdata->dev_desc->resume_from_noirq) {
> +		int ret = acpi_lpss_resume(dev);
> +		if (ret)
> +			return ret;
> +	}
>   
> -	return ret;
> +	return pm_generic_restore_early(dev);
>   }
>   
>   #endif /* CONFIG_PM_SLEEP */
> @@ -1140,8 +1171,8 @@ static struct dev_pm_domain acpi_lpss_pm
>   		.poweroff = acpi_subsys_suspend,
>   		.poweroff_late = acpi_lpss_suspend_late,
>   		.poweroff_noirq = acpi_lpss_suspend_noirq,
> -		.restore_noirq = acpi_lpss_resume_noirq,
> -		.restore_early = acpi_lpss_resume_early,
> +		.restore_noirq = acpi_lpss_restore_noirq,
> +		.restore_early = acpi_lpss_restore_early,
>   #endif
>   		.runtime_suspend = acpi_lpss_runtime_suspend,
>   		.runtime_resume = acpi_lpss_runtime_resume,
> Index: linux-pm/include/linux/acpi.h
> ===================================================================
> --- linux-pm.orig/include/linux/acpi.h
> +++ linux-pm/include/linux/acpi.h
> @@ -925,6 +925,8 @@ int acpi_subsys_freeze(struct device *de
>   int acpi_subsys_freeze_late(struct device *dev);
>   int acpi_subsys_freeze_noirq(struct device *dev);
>   int acpi_subsys_thaw_noirq(struct device *dev);
> +int acpi_subsys_restore_noirq(struct device *dev);
> +int acpi_subsys_restore_early(struct device *dev);
>   #else
>   static inline int acpi_dev_resume_early(struct device *dev) { return 0; }
>   static inline int acpi_subsys_prepare(struct device *dev) { return 0; }
> @@ -938,6 +940,8 @@ static inline int acpi_subsys_freeze(str
>   static inline int acpi_subsys_freeze_late(struct device *dev) { return 0; }
>   static inline int acpi_subsys_freeze_noirq(struct device *dev) { return 0; }
>   static inline int acpi_subsys_thaw_noirq(struct device *dev) { return 0; }
> +static inline int acpi_subsys_restore_noirq(struct device *dev) { return 0; }
> +static inline int acpi_subsys_restore_early(struct device *dev) { return 0; }
>   #endif
>   
>   #ifdef CONFIG_ACPI
> 
> 
> 

  reply	other threads:[~2019-06-24 10:51 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-03  5:43 [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT Kai-Heng Feng
2019-04-03  8:33 ` Jarkko Nikula
2019-04-03  8:54 ` Hans de Goede
2019-04-07 20:58   ` Robert R. Howell
2019-04-08  3:44     ` Kai Heng Feng
2019-04-11 19:50       ` Robert R. Howell
2019-04-08  8:16     ` Hans de Goede
2019-04-11 19:50       ` Robert R. Howell
2019-04-18 11:42         ` Hans de Goede
2019-04-19 22:44           ` Robert R. Howell
2019-04-23  8:07             ` Rafael J. Wysocki
2019-04-23 20:03               ` Robert R. Howell
2019-04-24  7:20                 ` Rafael J. Wysocki
2019-04-25 16:38                   ` Robert R. Howell
2019-04-30 14:39                     ` Hans de Goede
2019-05-09  4:24                       ` Robert R. Howell
2019-05-09  8:50                         ` Hans de Goede
2019-05-09 18:09                           ` Robert R. Howell
2019-05-13  8:41                             ` Hans de Goede
2019-05-16 16:34                               ` Robert R. Howell
2019-05-14 10:10                             ` Hans de Goede
2019-05-16 11:11                     ` Rafael J. Wysocki
2019-05-16 16:35                       ` Robert R. Howell
2019-05-16 22:42                         ` Rafael J. Wysocki
2019-05-25  5:31                       ` Robert R. Howell
2019-06-24 10:24                         ` Rafael J. Wysocki
2019-06-24 10:51                           ` Hans de Goede [this message]
2019-06-24 23:14                             ` Rafael J. Wysocki
2019-06-26 18:43                           ` Robert R. Howell

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=b02ef915-faf5-635d-bf2f-92dd10d274b1@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=RHowell@uwyo.edu \
    --cc=kai.heng.feng@canonical.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rjw@rjwysocki.net \
    /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.