From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Lukas Wunner <lukas@wunner.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org, mika.westerberg@linux.intel.com,
Hsin-Yi Wang <hsinyi@chromium.org>
Subject: Re: [PATCH v5 4/4] PCI: Allow PCI bridges to go to D3Hot on all Devicetree based platforms
Date: Tue, 6 Aug 2024 18:11:07 +0530 [thread overview]
Message-ID: <20240806124107.GB2968@thinkpad> (raw)
In-Reply-To: <ZrHITXLkKrDbQKQp@wunner.de>
On Tue, Aug 06, 2024 at 08:53:01AM +0200, Lukas Wunner wrote:
> On Mon, Aug 05, 2024 at 07:05:55PM +0530, Manivannan Sadhasivam wrote:
> > On Fri, Aug 02, 2024 at 12:13:31PM +0200, Lukas Wunner wrote:
> > > The PCI core cannot put devices into D3cold without help from the
> > > platform. Checking whether D3cold is possible (or allowed or
> > > whatever) thus requires asking platform support code via
> > > platform_pci_power_manageable(), platform_pci_choose_state() etc.
> > >
> > > I think patch [3/4] is a little confusing because it creates
> > > infrastructure to decide whether D3cold is supported (allowed?)
> > > but we already have that in the platform_pci_*() functions.
> > > So I'm not sure if patch [3/4] adds value. I think generally
> > > speaking if D3hot isn't possible (allowed?), D3cold is assumed
> > > to not be possible either.
> >
> > Why? D3Hot is useful for runtime PM and if the platform doesn't want to do
> > runtime PM, it can always skip D3Hot (not ideal though).
>
> AFAICS we always program the device to go to D3hot and the platform
> then cuts power, thereby putting it into D3cold. So D3hot is never
> skipped. See __pci_set_power_state():
>
> if (state == PCI_D3cold) {
> /*
> * To put the device in D3cold, put it into D3hot in the native
> * way, then put it into D3cold using platform ops.
> */
> error = pci_set_low_power_state(dev, PCI_D3hot, locked);
>
> if (pci_platform_power_transition(dev, PCI_D3cold))
> return error;
>
This is applicable only to pci_set_power_state(), but AFAIK PCIe spec doesn't
mandate switching to D3Hot for entering D3Cold. So the PCIe host controller
drivers (especically non-ACPI platforms) may just send PME_Turn_Off followed by
removing the slot power (which again is not controlled by pci_set_power_state())
as there are no non-ACPI related hooks as of now.
- Mani
--
மணிவண்ணன் சதாசிவம்
next prev parent reply other threads:[~2024-08-06 12:41 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-02 5:54 [PATCH v5 0/4] PCI: Allow D3Hot for PCI bridges in Devicetree based platforms Manivannan Sadhasivam
2024-08-02 5:54 ` Manivannan Sadhasivam via B4 Relay
2024-08-02 5:55 ` [PATCH v5 1/4] PCI/portdrv: Make use of pci_dev::bridge_d3 for checking the D3 possibility Manivannan Sadhasivam
2024-08-02 5:55 ` Manivannan Sadhasivam via B4 Relay
2024-08-02 9:49 ` Lukas Wunner
2024-08-02 11:19 ` Rafael J. Wysocki
2024-08-02 20:07 ` Lukas Wunner
2024-08-05 13:24 ` Manivannan Sadhasivam
2024-08-06 6:46 ` Lukas Wunner
2024-08-06 11:48 ` Manivannan Sadhasivam
2024-08-02 5:55 ` [PATCH v5 2/4] PCI: Rename pci_bridge_d3_possible() to pci_bridge_d3_allowed() Manivannan Sadhasivam
2024-08-02 5:55 ` Manivannan Sadhasivam via B4 Relay
2024-08-03 11:03 ` kernel test robot
2024-08-05 13:26 ` Manivannan Sadhasivam
2024-08-02 5:55 ` [PATCH v5 3/4] PCI: Decouple D3Hot and D3Cold handling for bridges Manivannan Sadhasivam
2024-08-02 5:55 ` Manivannan Sadhasivam via B4 Relay
2024-08-19 12:44 ` Oliver Neukum
2024-08-20 6:00 ` Manivannan Sadhasivam
2024-08-20 23:45 ` Bjorn Helgaas
2024-08-29 6:10 ` Manivannan Sadhasivam
2024-08-21 1:45 ` Bjorn Helgaas
2024-08-28 15:52 ` Manivannan Sadhasivam
2024-08-28 21:07 ` Bjorn Helgaas
2024-08-29 5:22 ` Manivannan Sadhasivam
2024-11-21 18:54 ` Brian Norris
2024-08-02 5:55 ` [PATCH v5 4/4] PCI: Allow PCI bridges to go to D3Hot on all Devicetree based platforms Manivannan Sadhasivam
2024-08-02 5:55 ` Manivannan Sadhasivam via B4 Relay
2024-08-02 10:13 ` Lukas Wunner
2024-08-05 13:35 ` Manivannan Sadhasivam
2024-08-06 6:53 ` Lukas Wunner
2024-08-06 12:41 ` Manivannan Sadhasivam [this message]
2024-08-06 13:02 ` Lukas Wunner
2024-08-06 14:39 ` Manivannan Sadhasivam
2024-08-06 20:20 ` Lukas Wunner
2024-08-19 15:34 ` Manivannan Sadhasivam
2024-08-06 20:58 ` Hsin-Yi Wang
2024-11-21 18:53 ` 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=20240806124107.GB2968@thinkpad \
--to=manivannan.sadhasivam@linaro.org \
--cc=bhelgaas@google.com \
--cc=hsinyi@chromium.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mika.westerberg@linux.intel.com \
--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 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.