All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Ulf Hansson <ulf.hansson@linaro.org>,
	"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: Wed, 18 Oct 2017 14:45:11 -0500	[thread overview]
Message-ID: <7b9c2a3e-2e88-938e-46a5-703de0080681@ti.com> (raw)
In-Reply-To: <CAPDyKFozJtSHxxBEFtC+ofJ4XUyQjqUundPs81JATT=WfjXoYA@mail.gmail.com>



On 10/18/2017 09:11 AM, 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.
> 
> This follows the behavior of when a regular call to
> pm_runtime_get|put(), triggers the RPM callbacks to be invoked.
> 
>>
>>> And updating the runtime PM status of
>>> the device is required to manage the optimized behavior during system
>>> resume (avoiding to unnecessary resume devices).
>>
>> Well, OK.  The runtime PM status of the device after system resume should
>> better reflect its physical state.
>>
>> [The physical state of the device may not be under the control of the
>> kernel in some cases, like in S3 resume on some systems that reset
>> devices in the firmware and so on, but let's set that aside.]
>>
>> However, for the runtime PM status of the device may still reflect its state
>> if, say, a ->resume_early of the middle layer is called during resume along
>> with a driver's ->runtime_resume.  That still can produce the right state
>> of the device and all depends on the middle layer.
>>
>> On the other hand, as I said before, using a middle-layer ->runtime_suspend
>> during a system sleep transition may be outright incorrect, say if device
>> wakeup settings need to be adjusted by the middle layer (which is the
>> case for some of them).
>>
>> Of course, if the middle layer expects the driver to point its
>> system-wide PM callbacks to pm_runtime_force_*, then that's how it goes,
>> but the drivers working with this particular middle layer generally
>> won't work with other middle layers and may interact incorrectly
>> with parents and/or children using the other middle layers.
>>
>> I guess the problem boils down to having a common set of expectations
>> on the driver side and on the middle layer side allowing different
>> combinations of these to work together.
> 
> Yes!
> 
>>
>>> Besides the AMBA case, I also realized that we are dealing with PM
>>> clocks in the genpd case. For this, genpd relies on the that runtime
>>> PM status of the device properly reflects the state of the HW, during
>>> system-wide PM.
>>>
>>> In other words, if the driver would change the runtime PM status of
>>> the device, without respecting the hierarchy of the runtime PM
>>> callbacks, it would lead to that genpd starts taking wrong decisions
>>> while managing the PM clocks during system-wide PM. So in case you
>>> intend to change pm_runtime_force_* this needs to be addressed too.
>>
>> I've just looked at the genpd code and quite frankly I'm not sure how this
>> works, but I'll figure this out. :-)
> 
> You may think of it as genpd's RPM callback controls some device
> clocks, while the driver control some other device resources (pinctrl
> for example) from its RPM callback.
> 
> These resources needs to managed together, similar to as I described above.
> 
> [...]
> 
>>> Absolutely agree about the different wake-up settings. However, these
>>> issues can be addressed also when using pm_runtime_force_*, at least
>>> in general, but then not for PCI.
>>
>> Well, not for the ACPI PM domain too.
>>
>> 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.
> 
>>
>>> 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.
> 
> That means, if the resume of the parent is deferred, so will the also
> the resume of the child.
> 
>>
>>> For a PCI consumer device those will of course have to play by the rules of PCI.
>>>
>>>>
>>>> Moreover, the majority of the "other subsystems/middle-layers" you've talked
>>>> about so far don't provide any PM callbacks to be invoked by pm_runtime_force_*,
>>>> so question is how representative they really are.
>>>
>>> That's the point. We know pm_runtime_force_* works nicely for the
>>> trivial middle-layer cases.
>>
>> In which cases the middle-layer callbacks don't exist, so it's just like
>> reusing driver callbacks directly. :-)

I'd like to ask you clarify one point here and provide some info which I hope can be useful - 
what's exactly means  "trivial middle-layer cases"?

Is it when systems use "drivers/base/power/clock_ops.c - Generic clock manipulation PM callbacks"
as dev_pm_domain (arm davinci/keystone), or OMAP device framework struct dev_pm_domain omap_device_pm_domain
 (arm/mach-omap2/omap_device.c) or static const struct dev_pm_ops tegra_aconnect_pm_ops?

if yes all above have PM runtime callbacks.


-- 
regards,
-grygorii

  reply	other threads:[~2017-10-18 19:45 UTC|newest]

Thread overview: 136+ 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 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 [this message]
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
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=7b9c2a3e-2e88-938e-46a5-703de0080681@ti.com \
    --to=grygorii.strashko@ti.com \
    --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=ulf.hansson@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.