All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Wolfram Sang <wsa@the-dreams.de>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Kevin Hilman <khilman@kernel.org>,
	Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Jisheng Zhang <jszhang@marvell.com>,
	John Stultz <john.stultz@linaro.org>,
	Guodong Xu <guodong.xu@linaro.org>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Haojian Zhuang <haojian.zhuang@linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	linux-i2c <linux-i2c@vger.kernel.org>
Subject: Re: [PATCH v2 5/9] PM / ACPI: Provide option to disable direct_complete for ACPI devices
Date: Thu, 24 Aug 2017 10:19:43 +0200	[thread overview]
Message-ID: <CAPDyKFrGvqhBdenSyQ8Qr76DbfEvc74_dKZAjraA5qL63Mm2rg@mail.gmail.com> (raw)
In-Reply-To: <CAJZ5v0gJn=SzNFGUT7Zb+CfhQBZ7KNDK2GTSSXGexD8GObjGOw@mail.gmail.com>

On 24 August 2017 at 01:39, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Wed, Aug 23, 2017 at 4:42 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> In some cases a driver for an ACPI device needs to be able to prevent the
>> ACPI PM domain from using the direct_complete path during system sleep.
>>
>> One typical case is when the driver for the device needs its device to stay
>> runtime enabled, during the __device_suspend phase. This isn't the case
>> when the direct_complete path is being executed by the PM core, as it then
>> disables runtime PM for the device in __device_suspend(). Any following
>> attempts to runtime resume the device after that point, just fails.
>
> OK, that is a problem.
>
>> A workaround to this problem is to let the driver runtime resume its device
>> from its ->prepare() callback, as that would prevent the direct_complete
>> path from being executed. However, that may often be a waste, especially if
>> it turned out that no one really needed the device.
>>
>> For this reason, invent acpi_dev_disable|enable_direct_complete(), to allow
>> drivers to inform the ACPI PM domain to change its default behaviour during
>> system sleep, and thus control whether it may use the direct_complete path
>> or not.
>
> But I'm not sure this is the right place to address it as it very well
> may affect a PCI device too.
>
> Also, this is about the device and not about its ACPI companion
> object, so putting the flag in there is somewhat unclean, so to speak.
>
> It looks like we need a flag in dev_pm_info saying something along the
> lines of "my system suspend callback can deal with runtime PM" that
> will cause the direct_complete update to occur in
> __device_suspend_late() instead of __device_suspend().

I realize that in the end this turns out to be a comparison between
the runtime PM centric path and the direct_complete path while
implementing system sleep. In patch 9, there is some more explanation
around this, however if you like I can elaborate even more about
this!?

Regarding making changes to the PM core and adding more flags to the
dev_pm_info etc, I am not sure we really want that. Isn't it already
complex enough?

My point is, that I am trying to improve the behavior of the ACPI PM
domain by enabling the runtime PM centric path for it, and even if
there is something similar that could be done for PCI, I don't think
we should need involvement by the PM core.

Kind regards
Uffe

WARNING: multiple messages have this Message-ID (diff)
From: ulf.hansson@linaro.org (Ulf Hansson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 5/9] PM / ACPI: Provide option to disable direct_complete for ACPI devices
Date: Thu, 24 Aug 2017 10:19:43 +0200	[thread overview]
Message-ID: <CAPDyKFrGvqhBdenSyQ8Qr76DbfEvc74_dKZAjraA5qL63Mm2rg@mail.gmail.com> (raw)
In-Reply-To: <CAJZ5v0gJn=SzNFGUT7Zb+CfhQBZ7KNDK2GTSSXGexD8GObjGOw@mail.gmail.com>

On 24 August 2017 at 01:39, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Wed, Aug 23, 2017 at 4:42 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> In some cases a driver for an ACPI device needs to be able to prevent the
>> ACPI PM domain from using the direct_complete path during system sleep.
>>
>> One typical case is when the driver for the device needs its device to stay
>> runtime enabled, during the __device_suspend phase. This isn't the case
>> when the direct_complete path is being executed by the PM core, as it then
>> disables runtime PM for the device in __device_suspend(). Any following
>> attempts to runtime resume the device after that point, just fails.
>
> OK, that is a problem.
>
>> A workaround to this problem is to let the driver runtime resume its device
>> from its ->prepare() callback, as that would prevent the direct_complete
>> path from being executed. However, that may often be a waste, especially if
>> it turned out that no one really needed the device.
>>
>> For this reason, invent acpi_dev_disable|enable_direct_complete(), to allow
>> drivers to inform the ACPI PM domain to change its default behaviour during
>> system sleep, and thus control whether it may use the direct_complete path
>> or not.
>
> But I'm not sure this is the right place to address it as it very well
> may affect a PCI device too.
>
> Also, this is about the device and not about its ACPI companion
> object, so putting the flag in there is somewhat unclean, so to speak.
>
> It looks like we need a flag in dev_pm_info saying something along the
> lines of "my system suspend callback can deal with runtime PM" that
> will cause the direct_complete update to occur in
> __device_suspend_late() instead of __device_suspend().

I realize that in the end this turns out to be a comparison between
the runtime PM centric path and the direct_complete path while
implementing system sleep. In patch 9, there is some more explanation
around this, however if you like I can elaborate even more about
this!?

Regarding making changes to the PM core and adding more flags to the
dev_pm_info etc, I am not sure we really want that. Isn't it already
complex enough?

My point is, that I am trying to improve the behavior of the ACPI PM
domain by enabling the runtime PM centric path for it, and even if
there is something similar that could be done for PCI, I don't think
we should need involvement by the PM core.

Kind regards
Uffe

  parent reply	other threads:[~2017-08-24  8:19 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-23 14:42 [PATCH v2 0/9] PM / ACPI / i2c: Deploy runtime PM centric path for system sleep Ulf Hansson
2017-08-23 14:42 ` Ulf Hansson
2017-08-23 14:42 ` [PATCH v2 1/9] PM / ACPI: Restore acpi_subsys_complete() Ulf Hansson
2017-08-23 14:42   ` Ulf Hansson
2017-08-23 22:41   ` Rafael J. Wysocki
2017-08-23 22:41     ` Rafael J. Wysocki
2017-08-23 14:42 ` [PATCH v2 2/9] PM / Sleep: Remove pm_complete_with_resume_check() Ulf Hansson
2017-08-23 14:42   ` Ulf Hansson
2017-08-23 14:42 ` [PATCH v2 3/9] PM / ACPI: Split code validating need for runtime resume in ->prepare() Ulf Hansson
2017-08-23 14:42   ` Ulf Hansson
2017-08-23 14:42 ` [PATCH v2 4/9] PM / ACPI: Split acpi_lpss_suspend_late|resume_early() Ulf Hansson
2017-08-23 14:42   ` Ulf Hansson
2017-08-23 14:42 ` [PATCH v2 5/9] PM / ACPI: Provide option to disable direct_complete for ACPI devices Ulf Hansson
2017-08-23 14:42   ` Ulf Hansson
2017-08-23 23:39   ` Rafael J. Wysocki
2017-08-23 23:39     ` Rafael J. Wysocki
2017-08-24  0:13     ` Rafael J. Wysocki
2017-08-24  0:13       ` Rafael J. Wysocki
2017-08-24  0:20       ` Rafael J. Wysocki
2017-08-24  0:20         ` Rafael J. Wysocki
2017-08-24  1:03         ` Rafael J. Wysocki
2017-08-24  1:03           ` Rafael J. Wysocki
2017-08-24  9:15           ` Ulf Hansson
2017-08-24  9:15             ` Ulf Hansson
2017-08-24 16:35             ` Rafael J. Wysocki
2017-08-24 16:35               ` Rafael J. Wysocki
2017-08-24 21:50               ` Rafael J. Wysocki
2017-08-24 21:50                 ` Rafael J. Wysocki
2017-08-25 13:42                 ` Rafael J. Wysocki
2017-08-25 13:42                   ` Rafael J. Wysocki
2017-08-28  1:30                   ` Rafael J. Wysocki
2017-08-28  1:30                     ` Rafael J. Wysocki
2017-08-28  8:31                     ` Ulf Hansson
2017-08-28  8:31                       ` Ulf Hansson
2017-08-28 12:39                       ` Rafael J. Wysocki
2017-08-28 12:39                         ` Rafael J. Wysocki
2017-08-28 12:54                         ` Ulf Hansson
2017-08-28 12:54                           ` Ulf Hansson
2017-08-28 13:40                           ` Rafael J. Wysocki
2017-08-28 13:40                             ` Rafael J. Wysocki
2017-08-28 14:24                             ` Ulf Hansson
2017-08-28 14:24                               ` Ulf Hansson
2017-08-28 21:14                               ` Rafael J. Wysocki
2017-08-28 21:14                                 ` Rafael J. Wysocki
2017-08-25  9:28               ` Ulf Hansson
2017-08-25  9:28                 ` Ulf Hansson
2017-08-25 12:23                 ` Rafael J. Wysocki
2017-08-25 12:23                   ` Rafael J. Wysocki
2017-08-24  8:19     ` Ulf Hansson [this message]
2017-08-24  8:19       ` Ulf Hansson
2017-08-24 14:57       ` Rafael J. Wysocki
2017-08-24 14:57         ` Rafael J. Wysocki
2017-08-25  9:04         ` Ulf Hansson
2017-08-25  9:04           ` Ulf Hansson
2017-08-23 14:42 ` [PATCH v2 6/9] PM / ACPI: Enable the runtime PM centric approach for system sleep Ulf Hansson
2017-08-23 14:42   ` Ulf Hansson
2017-08-23 14:42 ` [PATCH v2 7/9] PM / ACPI: Avoid runtime resuming device in acpi_subsys_suspend|freeze() Ulf Hansson
2017-08-23 14:42   ` Ulf Hansson
2017-08-23 14:42 ` [PATCH v2 8/9] i2c: designware: Don't resume device in the ->complete() callback Ulf Hansson
2017-08-23 14:42   ` Ulf Hansson
2017-08-23 14:42 ` [PATCH v2 9/9] i2c: designware: Deploy the runtime PM centric approach for system sleep Ulf Hansson
2017-08-23 14:42   ` Ulf Hansson
2017-08-25 14:10 ` [PATCH v2 0/9] PM / ACPI / i2c: Deploy runtime PM centric path " Jarkko Nikula
2017-08-25 14:10   ` Jarkko Nikula
2017-08-29  0:18 ` [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep handling Rafael J. Wysocki
2017-08-29  0:18   ` Rafael J. Wysocki
2017-08-29  0:20   ` [PATCH 1/3] PM / core: Add SAFE_SUSPEND driver flag Rafael J. Wysocki
2017-08-29  0:20     ` Rafael J. Wysocki
2017-08-29 14:57     ` Ulf Hansson
2017-08-29 14:57       ` Ulf Hansson
2017-08-29 15:02       ` Rafael J. Wysocki
2017-08-29 15:02         ` Rafael J. Wysocki
2017-08-29  0:59   ` [PATCH 2/3] PM / ACPI: Use SAFE_SUSPEND in the generic ACPI PM domain Rafael J. Wysocki
2017-08-29  0:59     ` Rafael J. Wysocki
2017-08-29  0:59   ` [PATCH 3/3] PM: i2c-designware-platdrv: System sleep handling rework Rafael J. Wysocki
2017-08-29  0:59     ` Rafael J. Wysocki
2017-08-29 16:38     ` Rafael J. Wysocki
2017-08-29 16:38       ` Rafael J. Wysocki
2017-08-29 16:40       ` Rafael J. Wysocki
2017-08-29 16:40         ` Rafael J. Wysocki
2017-08-29 10:29   ` [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep handling Johannes Stezenbach
2017-08-29 10:29     ` Johannes Stezenbach
2017-08-29 11:44     ` Ulf Hansson
2017-08-29 11:44       ` Ulf Hansson
2017-08-29 13:53       ` Johannes Stezenbach
2017-08-29 13:53         ` Johannes Stezenbach
2017-08-29 14:43       ` Rafael J. Wysocki
2017-08-29 14:43         ` Rafael J. Wysocki
2017-08-29 15:05         ` Ulf Hansson
2017-08-29 15:05           ` Ulf Hansson
2017-08-29 16:44           ` Rafael J. Wysocki
2017-08-29 16:44             ` Rafael J. Wysocki
2017-08-29 14:49     ` Rafael J. Wysocki
2017-08-29 14:49       ` 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=CAPDyKFrGvqhBdenSyQ8Qr76DbfEvc74_dKZAjraA5qL63Mm2rg@mail.gmail.com \
    --to=ulf.hansson@linaro.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=guodong.xu@linaro.org \
    --cc=haojian.zhuang@linaro.org \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=john.stultz@linaro.org \
    --cc=jszhang@marvell.com \
    --cc=khilman@kernel.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=sumit.semwal@linaro.org \
    --cc=wsa@the-dreams.de \
    /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.