From: Bjorn Helgaas <helgaas@kernel.org>
To: Brian Norris <briannorris@chromium.org>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
Bjorn Helgaas <bhelgaas@google.com>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] PCI/PM: Avoid redundant delays on D3hot->D3cold
Date: Mon, 6 Oct 2025 14:33:33 -0500 [thread overview]
Message-ID: <20251006193333.GA537409@bhelgaas> (raw)
In-Reply-To: <aOQLRhot8-MtXeE3@google.com>
On Mon, Oct 06, 2025 at 11:32:38AM -0700, Brian Norris wrote:
> On Mon, Oct 06, 2025 at 03:52:22PM +0200, Mika Westerberg wrote:
> > On Fri, Oct 03, 2025 at 03:40:09PM -0700, Brian Norris wrote:
> > > From: Brian Norris <briannorris@google.com>
> > >
> > > When transitioning to D3cold, __pci_set_power_state() will first
> > > transition a device to D3hot. If the device was already in D3hot, this
> > > will add excess work:
> > > (a) read/modify/write PMCSR; and
> > > (b) excess delay (pci_dev_d3_sleep()).
> >
> > How come the device is already in D3hot when __pci_set_power_state() is
> > called? IIRC PCI core will transition the device to low power state so that
> > it passes there the deepest possible state, and at that point the device is
> > still in D0. Then __pci_set_power_state() puts it into D3hot and then turns
> > if the power resource -> D3cold.
> >
> > What I'm missing here?
>
> Some PCI drivers call pci_set_power_state(..., PCI_D3hot) on their own
> when preparing for runtime or system suspend, so by the time they hit
> pci_finish_runtime_suspend(), they're in D3hot. Then, pci_target_state()
> may still pick a lower state (D3cold).
We might need this change, but maybe this is also an opportunity to
remove some of those pci_set_power_state(..., PCI_D3hot) calls from
drivers.
I didn't look into any of them in detail, but I would jump at any
chance to remove PCI details from driver suspend paths. There are
only ~20 calls from suspend functions, ~25 from shutdown, and a few
from poweroff. The fact that there are so few makes me think they
might be leftovers that could be more fully converted to generic PM.
next prev parent reply other threads:[~2025-10-06 19:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-03 22:40 [PATCH] PCI/PM: Avoid redundant delays on D3hot->D3cold Brian Norris
2025-10-06 13:52 ` Mika Westerberg
2025-10-06 18:32 ` Brian Norris
2025-10-06 19:33 ` Bjorn Helgaas [this message]
2025-10-06 23:13 ` Manivannan Sadhasivam
2025-10-13 22:13 ` Brian Norris
2025-10-07 5:00 ` Mika Westerberg
2025-11-25 16:20 ` Brian Norris
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=20251006193333.GA537409@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=briannorris@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=rafael.j.wysocki@intel.com \
--cc=stable@vger.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).