From: Alex Deucher <alexdeucher@gmail.com>
To: Linux PM <linux-pm@vger.kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Bjorn Helgaas <helgaas@kernel.org>,
Linux PCI <linux-pci@vger.kernel.org>
Subject: Understanding DPM_FLAG_MAY_SKIP_RESUME and DPM_FLAG_SMART_SUSPEND flags
Date: Fri, 22 Jan 2021 17:47:14 -0500 [thread overview]
Message-ID: <CADnq5_P7HbKxUC7BoVEhjA2F7puTT471bYZgiHHnkfP2UN9fPg@mail.gmail.com> (raw)
Hi, I'm trying to understand how these flags are supposed to work.
What I'd like to do, is when my pcie device runtime suspends (d3cold),
I would like it to stay off during system suspend and resume and on be
turned on again if the user accesses the device which would cause it
to be runtime resumed. Runtime pm works fine on the devices, but they
get resumed on system suspend and powered back up on system resume.
The driver provides the following pm callbacks:
static const struct dev_pm_ops amdgpu_pm_ops = {
.suspend = amdgpu_pmops_suspend,
.resume = amdgpu_pmops_resume,
.freeze = amdgpu_pmops_freeze,
.thaw = amdgpu_pmops_thaw,
.poweroff = amdgpu_pmops_poweroff,
.restore = amdgpu_pmops_restore,
.runtime_suspend = amdgpu_pmops_runtime_suspend,
.runtime_resume = amdgpu_pmops_runtime_resume,
.runtime_idle = amdgpu_pmops_runtime_idle,
};
I'm having trouble parsing the last few paragraphs in the pm
documentation (https://www.kernel.org/doc/html/latest/driver-api/pm/devices.html).
Ideally once the device is runtime suspended, it would not be powered
up again until someone accesses the device and it runtime resumes with
possibly multiple system suspend/resume cycles in between.
"If that function returns true, the driver’s “noirq” and “early”
resume callbacks should be skipped and the device’s runtime PM status
will be set to “suspended” by the PM core. Otherwise, if the device
was runtime-suspended during the preceding system-wide suspend
transition and its DPM_FLAG_SMART_SUSPEND is set, its runtime PM
status will be set to “active” by the PM core. [Hence, the drivers
that do not set DPM_FLAG_SMART_SUSPEND should not expect the runtime
PM status of their devices to be changed from “suspended” to “active”
by the PM core during system-wide resume-type transitions.]"
The last sentence is confusing me. Why would setting
DPM_FLAG_SMART_SUSPEND change the status to active? Wouldn't still be
suspended?
"Likewise, if DPM_FLAG_MAY_SKIP_RESUME is set for a device, its
driver’s system-wide “noirq” and “early” resume callbacks may be
skipped while its “late” and “noirq” suspend callbacks may have been
executed (in principle, regardless of whether or not
DPM_FLAG_SMART_SUSPEND is set). In that case, the driver needs to be
able to cope with the invocation of its ->runtime_resume callback
back-to-back with its “late” and “noirq” suspend ones. [For instance,
that is not a concern if the driver sets both DPM_FLAG_SMART_SUSPEND
and DPM_FLAG_MAY_SKIP_RESUME and uses the same pair of suspend/resume
callback functions for runtime PM and system-wide suspend/resume.]"
The last sentence here is confusing me again. I'm not following why
it matters if the callbacks are the same. Why would the suspend and
resume callbacks be called at all. Wouldn't it just be the runtime
variants?
It's not clear what happens with the suspend and resume pm callbacks.
The documentation only mentions the early/late and noirq callbacks.
Is the idea that the driver should not use the suspend/resume
callbacks in this case if they want to skip system suspend/resume in
favor of the runtime variant?
Thanks,
Alex
reply other threads:[~2021-01-22 22:49 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=CADnq5_P7HbKxUC7BoVEhjA2F7puTT471bYZgiHHnkfP2UN9fPg@mail.gmail.com \
--to=alexdeucher@gmail.com \
--cc=helgaas@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.org \
/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).