From: Bjorn Helgaas <email@example.com> To: "Rafael J. Wysocki" <firstname.lastname@example.org> Cc: Linux PM <email@example.com>, Alan Stern <firstname.lastname@example.org>, Linux ACPI <email@example.com>, Linux PCI <firstname.lastname@example.org>, LKML <email@example.com>, Greg Kroah-Hartman <firstname.lastname@example.org>, Mika Westerberg <email@example.com>, Hans De Goede <firstname.lastname@example.org>, Ulf Hansson <email@example.com>, DRI-devel <firstname.lastname@example.org>, Intel Graphics <email@example.com>, firstname.lastname@example.org Subject: Re: [PATCH 5/7] PM: sleep: core: Rename DPM_FLAG_NEVER_SKIP Date: Fri, 10 Apr 2020 14:38:00 -0500 [thread overview] Message-ID: <20200410193800.GA5202@google.com> (raw) In-Reply-To: <5092680.jloV5Ae5OO@kreacher> On Fri, Apr 10, 2020 at 05:56:13PM +0200, Rafael J. Wysocki wrote: > From: "Rafael J. Wysocki" <email@example.com> > > Rename DPM_FLAG_NEVER_SKIP to DPM_FLAG_NO_DIRECT_COMPLETE which > matches its purpose more closely. > > No functional impact. > > Signed-off-by: Rafael J. Wysocki <firstname.lastname@example.org> Acked-by: Bjorn Helgaas <email@example.com> # for PCI parts > --- > Documentation/driver-api/pm/devices.rst | 6 +++--- > Documentation/power/pci.rst | 10 +++++----- > drivers/base/power/main.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +- > drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +- > drivers/gpu/drm/radeon/radeon_kms.c | 2 +- > drivers/misc/mei/pci-me.c | 2 +- > drivers/misc/mei/pci-txe.c | 2 +- > drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- > drivers/net/ethernet/intel/igb/igb_main.c | 2 +- > drivers/net/ethernet/intel/igc/igc_main.c | 2 +- > drivers/pci/pcie/portdrv_pci.c | 2 +- > include/linux/pm.h | 6 +++--- > 13 files changed, 21 insertions(+), 21 deletions(-) > > diff --git a/Documentation/driver-api/pm/devices.rst b/Documentation/driver-api/pm/devices.rst > index f66c7b9126ea..4ace0eba4506 100644 > --- a/Documentation/driver-api/pm/devices.rst > +++ b/Documentation/driver-api/pm/devices.rst > @@ -361,9 +361,9 @@ the phases are: ``prepare``, ``suspend``, ``suspend_late``, ``suspend_noirq``. > runtime PM disabled. Minor question about a preceding paragraph that ends: In that case, the ``->complete`` callback will be invoked directly after the ``->prepare`` callback and is entirely responsible for putting the device into a consistent state as appropriate. What does" a consistent state as appropriate" mean? I know this is generic documentation at a high level, so maybe there's no good explanation for "consistent state," but I don't know what to imagine there. And what does "as appropriate" mean? Would it change the meaning to drop those two words, or are there situations where it's not appropriate to put the device into a consistent state? Or maybe it's just that the type of device determines what the consistent state is? > This feature also can be controlled by device drivers by using the > - ``DPM_FLAG_NEVER_SKIP`` and ``DPM_FLAG_SMART_PREPARE`` driver power > - management flags. [Typically, they are set at the time the driver is > - probed against the device in question by passing them to the > + ``DPM_FLAG_NO_DIRECT_COMPLETE`` and ``DPM_FLAG_SMART_PREPARE`` driver > + power management flags. [Typically, they are set at the time the driver > + is probed against the device in question by passing them to the > :c:func:`dev_pm_set_driver_flags` helper function.] If the first of > these flags is set, the PM core will not apply the direct-complete > procedure described above to the given device and, consequenty, to any s/consequenty/consequently/ Drive-by comment: I looked for a definition of "direct-complete". The closest I found is a couple paragraphs above this, where it says "Note that this direct-complete procedure ...," but that leaves me to try to reconstruct the definition from the preceding text. AFAICT, going to freeze, standby, or memory sleep includes these callbacks: ->prepare ->suspend ->suspend_late ->suspend_noirq ->complete (not mentioned in the list of phases) And "direct-complete" means we skip the suspend, suspend_late, and suspend_noirq callbacks so we only use these: ->prepare ->complete And apparently we skip those callbacks for device X if ->prepare() for X and all its descendents returns a positive value AND they are all runtime-suspended, except if a driver for X or a descendent sets DPM_FLAG_NO_DIRECT_COMPLETE. Bjorn
next prev parent reply other threads:[~2020-04-10 19:38 UTC|newest] Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-10 15:46 [PATCH 0/7] PM: sleep: core: Rearrange the handling of driver power management flags Rafael J. Wysocki 2020-04-10 15:48 ` [PATCH 1/7] PM: sleep: core: Simplify the SMART_SUSPEND flag handling Rafael J. Wysocki 2020-04-10 15:48 ` [PATCH 2/7] PM: sleep: core: Fold functions into their callers Rafael J. Wysocki 2020-04-10 15:51 ` [PATCH 3/7] PM: sleep: core: Do not skip callbacks in the resume phase Rafael J. Wysocki 2020-04-10 15:51 ` [PATCH 4/7] PM: sleep: core: Rename dev_pm_may_skip_resume() Rafael J. Wysocki 2020-04-10 15:56 ` [PATCH 5/7] PM: sleep: core: Rename DPM_FLAG_NEVER_SKIP Rafael J. Wysocki 2020-04-10 19:38 ` Bjorn Helgaas [this message] 2020-04-13 6:35 ` Jeff Kirsher 2020-04-10 15:57 ` [PATCH 6/7] PM: sleep: core: Rename DPM_FLAG_LEAVE_SUSPENDED Rafael J. Wysocki 2020-04-15 9:51 ` Wolfram Sang 2020-04-10 15:58 ` [PATCH 7/7] Documentation: PM: sleep: Update driver flags documentation Rafael J. Wysocki 2020-04-13 13:11 ` [PATCH 0/7] PM: sleep: core: Rearrange the handling of driver power management flags Hans de Goede 2020-04-18 16:23 ` [PATCH v2 0/9] " Rafael J. Wysocki 2020-04-18 16:29 ` [PATCH v2 1/9] PM: sleep: core: Simplify the SMART_SUSPEND flag handling Rafael J. Wysocki 2020-04-18 16:51 ` [PATCH v2 2/9] PM: sleep: core: Fold functions into their callers Rafael J. Wysocki 2020-04-18 16:52 ` [PATCH v2 3/9] PM: sleep: core: Do not skip callbacks in the resume phase Rafael J. Wysocki 2020-04-18 16:52 ` [PATCH v2 4/9] PM: sleep: core: Rework the power.may_skip_resume handling Rafael J. Wysocki 2020-04-18 16:52 ` [PATCH v2 5/9] PM: sleep: core: Rename dev_pm_may_skip_resume() Rafael J. Wysocki 2020-04-18 16:52 ` [PATCH v2 6/9] PM: sleep: core: Rename dev_pm_smart_suspend_and_suspended() Rafael J. Wysocki 2020-04-18 16:53 ` [PATCH v2 7/9] PM: sleep: core: Rename DPM_FLAG_NEVER_SKIP Rafael J. Wysocki 2020-04-22 20:10 ` Alex Deucher 2020-04-18 16:53 ` [PATCH v2 8/9] PM: sleep: core: Rename DPM_FLAG_LEAVE_SUSPENDED Rafael J. Wysocki 2020-04-18 16:55 ` [PATCH v2 9/9] Documentation: PM: sleep: Update driver flags documentation Rafael J. Wysocki 2020-04-18 18:00 ` [PATCH v2 0/9] PM: sleep: core: Rearrange the handling of driver power management flags Alan Stern 2020-04-18 18:08 ` Rafael J. Wysocki 2020-04-18 19:41 ` Alan Stern 2020-04-19 14:43 ` Alan Stern 2020-04-19 15:13 ` Rafael J. Wysocki 2020-04-21 10:30 ` Ulf Hansson 2020-04-21 11:32 ` Rafael J. Wysocki 2020-04-23 17:07 ` Bjorn Helgaas
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=20200410193800.GA5202@google.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH 5/7] PM: sleep: core: Rename DPM_FLAG_NEVER_SKIP' \ /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
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).