From: Ulf Hansson <ulf.hansson@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Linux PM <linux-pm@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Alan Stern <stern@rowland.harvard.edu>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux ACPI <linux-acpi@vger.kernel.org>,
Linux PCI <linux-pci@vger.kernel.org>,
Linux Documentation <linux-doc@vger.kernel.org>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Kevin Hilman <khilman@kernel.org>,
Wolfram Sang <wsa@the-dreams.de>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume
Date: Fri, 20 Oct 2017 07:57:15 +0200 [thread overview]
Message-ID: <CAPDyKFoVsagf86ozVss4GcWWjmu_2uixPB=cJb+fktOdbtcXOw@mail.gmail.com> (raw)
In-Reply-To: <4041983.hUlLtGrCgL@aspire.rjw.lan>
On 20 October 2017 at 03:19, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Thursday, October 19, 2017 2:21:07 PM CEST Ulf Hansson wrote:
>> On 19 October 2017 at 00:12, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> > On Wednesday, October 18, 2017 4:11:33 PM CEST Ulf Hansson wrote:
>> >> [...]
>> >>
>> >> >>
>> >> >> The reason why pm_runtime_force_* needs to respects the hierarchy of
>> >> >> the RPM callbacks, is because otherwise it can't safely update the
>> >> >> runtime PM status of the device.
>> >> >
>> >> > I'm not sure I follow this requirement. Why is that so?
>> >>
>> >> If the PM domain controls some resources for the device in its RPM
>> >> callbacks and the driver controls some other resources in its RPM
>> >> callbacks - then these resources needs to be managed together.
>> >
>> > Right, but that doesn't automatically make it necessary to use runtime PM
>> > callbacks in the middle layer. Its system-wide PM callbacks may be
>> > suitable for that just fine.
>> >
>> > That is, at least in some cases, you can combine ->runtime_suspend from a
>> > driver and ->suspend_late from a middle layer with no problems, for example.
>> >
>> > That's why some middle layers allow drivers to point ->suspend_late and
>> > ->runtime_suspend to the same routine if they want to reuse that code.
>> >
>> >> This follows the behavior of when a regular call to
>> >> pm_runtime_get|put(), triggers the RPM callbacks to be invoked.
>> >
>> > But (a) it doesn't have to follow it and (b) in some cases it should not
>> > follow it.
>>
>> Of course you don't explicitly *have to* respect the hierarchy of the
>> RPM callbacks in pm_runtime_force_*.
>>
>> However, changing that would require some additional information
>> exchange between the driver and the middle-layer/PM domain, as to
>> instruct the middle-layer/PM domain of what to do during system-wide
>> PM. Especially in cases when the driver deals with wakeup, as in those
>> cases the instructions may change dynamically.
>
> Well, if wakeup matters, drivers can't simply point their PM callbacks
> to pm_runtime_force_* anyway.
>
> If the driver itself deals with wakeups, it clearly needs different callback
> routines for system-wide PM and for runtime PM, so it can't reuse its runtime
> PM callbacks at all then.
It can still re-use its runtime PM callbacks, simply by calling
pm_runtime_force_ from its system sleep callbacks.
Drivers already do that today, not only to deal with wakeups, but
generally when they need to deal with some additional operations.
>
> If the middle layer deals with wakeups, different callbacks are needed at
> that level and so pm_runtime_force_* are unsuitable too.
>
> Really, invoking runtime PM callbacks from the middle layer in
> pm_runtime_force_* is a not a idea at all and there's no general requirement
> for it whatever.
>
>> [...]
>>
>> >> > In general, not if the wakeup settings are adjusted by the middle layer.
>> >>
>> >> Correct!
>> >>
>> >> To use pm_runtime_force* for these cases, one would need some
>> >> additional information exchange between the driver and the
>> >> middle-layer.
>> >
>> > Which pretty much defeats the purpose of the wrappers, doesn't it?
>>
>> Well, no matter if the wrappers are used or not, we need some kind of
>> information exchange between the driver and the middle-layers/PM
>> domains.
>
> Right.
>
> But if that information is exchanged, then why use wrappers *in* *addition*
> to that?
If we can find a different method that both avoids both open coding
and offers the optimize system-wide PM path at resume, I am open to
that.
>
>> Anyway, me personally think it's too early to conclude that using the
>> wrappers may not be useful going forward. At this point, they clearly
>> helps trivial cases to remain being trivial.
>
> I'm not sure about that really. So far I've seen more complexity resulting
> from using them than being avoided by using them, but I guess the beauty is
> in the eye of the beholder. :-)
Hehe, yeah you may be right. :-)
>
>> >
>> >> >
>> >> >> Regarding hibernation, honestly that's not really my area of
>> >> >> expertise. Although, I assume the middle-layer and driver can treat
>> >> >> that as a separate case, so if it's not suitable to use
>> >> >> pm_runtime_force* for that case, then they shouldn't do it.
>> >> >
>> >> > Well, agreed.
>> >> >
>> >> > In some simple cases, though, driver callbacks can be reused for hibernation
>> >> > too, so it would be good to have a common way to do that too, IMO.
>> >>
>> >> Okay, that makes sense!
>> >>
>> >> >
>> >> >> >
>> >> >> > Also, quite so often other middle layers interact with PCI directly or
>> >> >> > indirectly (eg. a platform device may be a child or a consumer of a PCI
>> >> >> > device) and some optimizations need to take that into account (eg. parents
>> >> >> > generally need to be accessible when their childres are resumed and so on).
>> >> >>
>> >> >> A device's parent becomes informed when changing the runtime PM status
>> >> >> of the device via pm_runtime_force_suspend|resume(), as those calls
>> >> >> pm_runtime_set_suspended|active().
>> >> >
>> >> > This requires the parent driver or middle layer to look at the reference
>> >> > counter and understand it the same way as pm_runtime_force_*.
>> >> >
>> >> >> In case that isn't that sufficient, what else is needed? Perhaps you can
>> >> >> point me to an example so I can understand better?
>> >> >
>> >> > Say you want to leave the parent suspended after system resume, but the
>> >> > child drivers use pm_runtime_force_suspend|resume(). The parent would then
>> >> > need to use pm_runtime_force_suspend|resume() too, no?
>> >>
>> >> Actually no.
>> >>
>> >> Currently the other options of "deferring resume" (not using
>> >> pm_runtime_force_*), is either using the "direct_complete" path or
>> >> similar to the approach you took for the i2c designware driver.
>> >>
>> >> Both cases should play nicely in combination of a child being managed
>> >> by pm_runtime_force_*. That's because only when the parent device is
>> >> kept runtime suspended during system suspend, resuming can be
>> >> deferred.
>> >
>> > And because the parent remains in runtime suspend late enough in the
>> > system suspend path, its children also are guaranteed to be suspended.
>>
>> Yes.
>>
>> >
>> > But then all of them need to be left in runtime suspend during system
>> > resume too, which is somewhat restrictive, because some drivers may
>> > want their devices to be resumed then.
>>
>> Actually, this scenario is also addressed when using the pm_runtime_force_*.
>>
>> The driver for the child would only need to bump the runtime PM usage
>> count (pm_runtime_get_noresume()) before calling
>> pm_runtime_force_suspend() at system suspend. That then also
>> propagates to the parent, leading to that both the parent and the
>> child will be resumed when pm_runtime_force_resume() is called for
>> them.
>>
>> Of course, if the driver of the parent isn't using pm_runtime_force_,
>> we would have to assume that it's always being resumed at system
>> resume.
>
> There may be other ways to avoid that, though.
>
> BTW, I don't quite like using the RPM usage counter this way either, if
> that hasn't been clear so far.
>
>> As at matter of fact, doesn't this scenario actually indicates that we
>> do need to involve the runtime PM core (updating RPM status according
>> to the HW state even during system-wide PM) to really get this right.
>> It's not enough to only use "driver PM flags"!?
>
> I'm not sure what you are talking about.
>
> For all devices with enabled runtime PM any state produced by system
> suspend/resume has to be labeled either as RPM_SUSPENDED or as RPM_ACTIVE.
> That has always been the case and hasn't involved any magic.
>
> However, while runtime PM is disabled, the state of the device doesn't
> need to be reflected by its RPM status and there's no need to track it then.
> Moreover, in some cases it cannot be tracked even, because of the firmare
> involvement (and we cannot track the firmware).
>
> Besides, please really look at what happens in the patches I posted and
> then we can talk.
Yes, I will have look.
>
>> Seems like we need to create a list of all requirements, pitfalls,
>> good things vs bad things etc. :-)
>
> We surely need to know what general cases need to be addressed.
>
>> >
>> > [BTW, our current documentation recommends resuming devices during
>> > system resume, actually, and gives a list of reasons why. :-)]
>>
>> Yes, but that too easy and to me not good enough. :-)
>
> But the list of reasons why is kind of valid still. There may be better
> reasons for not doing that, but it really is a tradeoff and drivers
> should be able to decide which way they want to go.
Agree.
>
> IOW, the "leave the device in runtime suspend throughout system
> suspend" optimization doesn't have to be bundled with the "leave the
> device in suspend throughout and after system resume" one.
Agree.
Kind regards
Uffe
next prev parent reply other threads:[~2017-10-20 5:57 UTC|newest]
Thread overview: 135+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-16 1:12 [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume Rafael J. Wysocki
2017-10-16 1:29 ` [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags Rafael J. Wysocki
2017-10-16 5:34 ` Lukas Wunner
2017-10-16 22:03 ` Rafael J. Wysocki
2017-10-16 6:28 ` Greg Kroah-Hartman
2017-10-16 22:05 ` Rafael J. Wysocki
2017-10-17 7:15 ` Greg Kroah-Hartman
2017-10-17 15:26 ` Rafael J. Wysocki
2017-10-18 6:56 ` Greg Kroah-Hartman
2017-10-16 6:31 ` Greg Kroah-Hartman
2017-10-16 22:07 ` Rafael J. Wysocki
2017-10-17 13:26 ` Greg Kroah-Hartman
2017-10-16 20:16 ` Alan Stern
2017-10-16 22:11 ` Rafael J. Wysocki
2017-10-18 23:17 ` [Update][PATCH v2 " Rafael J. Wysocki
2017-10-19 7:33 ` Greg Kroah-Hartman
2017-10-20 11:11 ` Rafael J. Wysocki
2017-10-20 11:35 ` Greg Kroah-Hartman
2017-10-20 11:28 ` Rafael J. Wysocki
2017-10-23 16:37 ` Ulf Hansson
2017-10-23 20:41 ` Rafael J. Wysocki
2017-10-16 1:29 ` [PATCH 02/12] PCI / PM: Use the NEVER_SKIP driver flag Rafael J. Wysocki
2017-10-23 16:40 ` Ulf Hansson
2017-10-16 1:29 ` [PATCH 03/12] PM: i2c-designware-platdrv: Use DPM_FLAG_SMART_PREPARE Rafael J. Wysocki
2017-10-23 16:57 ` Ulf Hansson
2017-10-16 1:29 ` [PATCH 04/12] PM / core: Add SMART_SUSPEND driver flag Rafael J. Wysocki
2017-10-23 19:01 ` Ulf Hansson
2017-10-24 5:22 ` Ulf Hansson
2017-10-24 8:55 ` Rafael J. Wysocki
2017-10-16 1:29 ` [PATCH 05/12] PCI / PM: Drop unnecessary invocations of pcibios_pm_ops callbacks Rafael J. Wysocki
2017-10-23 19:06 ` Ulf Hansson
2017-10-16 1:29 ` [PATCH 06/12] PCI / PM: Take SMART_SUSPEND driver flag into account Rafael J. Wysocki
2017-10-16 1:29 ` [PATCH 07/12] ACPI / LPSS: Consolidate runtime PM and system sleep handling Rafael J. Wysocki
2017-10-23 19:09 ` Ulf Hansson
2017-10-16 1:30 ` [PATCH 08/12] ACPI / PM: Take SMART_SUSPEND driver flag into account Rafael J. Wysocki
2017-10-16 1:30 ` [PATCH 09/12] PM / mfd: intel-lpss: Use DPM_FLAG_SMART_SUSPEND Rafael J. Wysocki
2017-10-31 15:09 ` Lee Jones
2017-10-31 16:28 ` Rafael J. Wysocki
2017-11-01 9:28 ` Lee Jones
2017-11-01 20:26 ` Rafael J. Wysocki
2017-11-08 11:08 ` Lee Jones
2017-10-16 1:30 ` [PATCH 10/12] PM / core: Add LEAVE_SUSPENDED driver flag Rafael J. Wysocki
2017-10-23 19:38 ` Ulf Hansson
2017-10-16 1:31 ` [PATCH 11/12] PM: i2c-designware-platdrv: Optimize power management Rafael J. Wysocki
2017-10-26 20:41 ` Wolfram Sang
2017-10-26 21:14 ` Rafael J. Wysocki
2017-10-16 1:32 ` [PATCH 12/12] PM / core: Add AVOID_RPM driver flag Rafael J. Wysocki
2017-10-17 15:33 ` Andy Shevchenko
2017-10-17 15:59 ` Rafael J. Wysocki
2017-10-17 16:25 ` Andy Shevchenko
2017-10-16 7:08 ` [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume Greg Kroah-Hartman
2017-10-16 21:50 ` Rafael J. Wysocki
2017-10-17 8:36 ` Ulf Hansson
2017-10-17 15:25 ` Rafael J. Wysocki
2017-10-17 19:41 ` Ulf Hansson
2017-10-17 20:12 ` Alan Stern
2017-10-17 23:07 ` Rafael J. Wysocki
2017-10-18 0:39 ` Rafael J. Wysocki
2017-10-18 10:24 ` Rafael J. Wysocki
2017-10-18 12:34 ` Ulf Hansson
2017-10-18 21:54 ` Rafael J. Wysocki
2017-10-18 11:57 ` Ulf Hansson
2017-10-18 13:00 ` Rafael J. Wysocki
2017-10-18 14:11 ` Ulf Hansson
2017-10-18 19:45 ` Grygorii Strashko
2017-10-18 21:48 ` Rafael J. Wysocki
2017-10-19 8:33 ` Ulf Hansson
2017-10-19 17:21 ` Grygorii Strashko
2017-10-19 18:04 ` Ulf Hansson
2017-10-19 18:11 ` Ulf Hansson
2017-10-19 21:31 ` Grygorii Strashko
2017-10-20 6:05 ` Ulf Hansson
2017-10-18 22:12 ` Rafael J. Wysocki
2017-10-19 12:21 ` Ulf Hansson
2017-10-19 18:01 ` Ulf Hansson
2017-10-20 1:19 ` Rafael J. Wysocki
2017-10-20 5:57 ` Ulf Hansson [this message]
2017-10-20 20:46 ` Bjorn Helgaas
2017-10-21 1:04 ` Rafael J. Wysocki
2017-10-27 22:11 ` [PATCH v2 0/6] PM / sleep: Driver flags for system suspend/resume (part 1) Rafael J. Wysocki
2017-10-27 22:17 ` [PATCH v2 1/6] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags Rafael J. Wysocki
2017-11-06 8:07 ` Ulf Hansson
2017-10-27 22:19 ` [PATCH v2 2/6] PCI / PM: Use the NEVER_SKIP driver flag Rafael J. Wysocki
2017-10-27 22:22 ` [PATCH v2 3/6] PM / core: Add SMART_SUSPEND " Rafael J. Wysocki
2017-11-06 8:09 ` Ulf Hansson
2017-11-06 11:23 ` Rafael J. Wysocki
2017-10-27 22:23 ` [PATCH v2 4/6] PCI / PM: Drop unnecessary invocations of pcibios_pm_ops callbacks Rafael J. Wysocki
2017-10-27 22:27 ` [PATCH v2 5/6] PCI / PM: Take SMART_SUSPEND driver flag into account Rafael J. Wysocki
2017-10-31 22:48 ` Bjorn Helgaas
2017-10-27 22:30 ` [PATCH v2 6/6] ACPI " Rafael J. Wysocki
2017-11-08 0:41 ` [PATCH v2 0/6] PM / sleep: Driver flags for system suspend/resume (part 2) Rafael J. Wysocki
2017-11-08 13:25 ` [PATCH v2 1/6] PM / core: Add LEAVE_SUSPENDED driver flag Rafael J. Wysocki
2017-11-10 9:09 ` Ulf Hansson
2017-11-10 23:45 ` Rafael J. Wysocki
2017-11-11 0:41 ` Rafael J. Wysocki
2017-11-11 1:36 ` Rafael J. Wysocki
2017-11-14 16:07 ` Ulf Hansson
2017-11-15 1:48 ` Rafael J. Wysocki
2017-11-16 10:18 ` Ulf Hansson
2017-11-08 13:28 ` [PATCH v2 2/6] PCI / PM: Support for " Rafael J. Wysocki
2017-11-08 20:38 ` Bjorn Helgaas
2017-11-08 21:09 ` Rafael J. Wysocki
2017-11-08 13:34 ` [PATCH v2 3/6] ACPI / PM: Support for LEAVE_SUSPENDED driver flag in ACPI PM domain Rafael J. Wysocki
2017-11-08 13:37 ` [PATCH v2 4/6] PM / core: Add helpers for subsystem callback selection Rafael J. Wysocki
2017-11-08 13:38 ` [PATCH v2 5/6] PM / core: Direct handling of DPM_FLAG_LEAVE_SUSPENDED Rafael J. Wysocki
2017-11-08 13:39 ` [PATCH v2 6/6] PM / core: DPM_FLAG_SMART_SUSPEND optimization Rafael J. Wysocki
2017-11-12 0:34 ` [PATCH v3 0/6] PM / sleep: Driver flags for system suspend/resume (part 2) Rafael J. Wysocki
2017-11-12 0:37 ` [PATCH v3 1/6] PM / core: Add LEAVE_SUSPENDED driver flag Rafael J. Wysocki
2017-11-16 15:10 ` Ulf Hansson
2017-11-16 23:07 ` Rafael J. Wysocki
2017-11-17 6:11 ` Ulf Hansson
2017-11-17 13:18 ` Rafael J. Wysocki
2017-11-17 13:49 ` Ulf Hansson
2017-11-17 14:31 ` Rafael J. Wysocki
2017-11-17 15:57 ` Ulf Hansson
2017-11-17 12:45 ` Rafael J. Wysocki
2017-11-12 0:40 ` [PATCH v3 2/6] PCI / PM: Support for " Rafael J. Wysocki
2017-11-12 0:40 ` [PATCH v3 3/6] ACPI / PM: Support for LEAVE_SUSPENDED driver flag in ACPI PM domain Rafael J. Wysocki
2017-11-12 0:42 ` [PATCH v3 4/6] PM / core: Add helpers for subsystem callback selection Rafael J. Wysocki
2017-11-15 7:43 ` Ulf Hansson
2017-11-15 17:55 ` Rafael J. Wysocki
2017-11-12 0:43 ` [PATCH v3 5/6] PM / core: Direct handling of DPM_FLAG_LEAVE_SUSPENDED Rafael J. Wysocki
2017-11-12 0:44 ` [PATCH v3 6/6] PM / core: DPM_FLAG_SMART_SUSPEND optimization Rafael J. Wysocki
2017-11-18 14:27 ` [PATCH v4 0/6] PM / sleep: Driver flags for system suspend/resume (part 2) Rafael J. Wysocki
2017-11-18 14:31 ` [PATCH v4 1/6] PM / core: Add LEAVE_SUSPENDED driver flag Rafael J. Wysocki
2017-11-20 12:25 ` Ulf Hansson
2017-11-21 0:16 ` Rafael J. Wysocki
2017-11-18 14:33 ` [PATCH v4 2/6] PCI / PM: Support for " Rafael J. Wysocki
2017-11-18 14:35 ` [PATCH v4 3/6] ACPI / PM: Support for LEAVE_SUSPENDED driver flag in ACPI PM domain Rafael J. Wysocki
2017-11-18 14:37 ` [PATCH v4 4/6] PM / core: Add helpers for subsystem callback selection Rafael J. Wysocki
2017-11-18 14:41 ` [PATCH v4 5/6] PM / core: Direct handling of DPM_FLAG_LEAVE_SUSPENDED Rafael J. Wysocki
2017-11-20 13:42 ` Ulf Hansson
2017-11-22 1:10 ` Rafael J. Wysocki
2017-11-22 1:28 ` Rafael J. Wysocki
2017-11-18 14:44 ` [PATCH v4 6/6] PM / core: DPM_FLAG_SMART_SUSPEND optimization 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='CAPDyKFoVsagf86ozVss4GcWWjmu_2uixPB=cJb+fktOdbtcXOw@mail.gmail.com' \
--to=ulf.hansson@linaro.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=khilman@kernel.org \
--cc=lee.jones@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=rjw@rjwysocki.net \
--cc=stern@rowland.harvard.edu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).