linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Norris <briannorris@chromium.org>
To: manivannan.sadhasivam@linaro.org
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, lukas@wunner.de,
	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: Thu, 21 Nov 2024 10:53:00 -0800	[thread overview]
Message-ID: <Zz-BjF3rZRyfv0Mg@google.com> (raw)
In-Reply-To: <20240802-pci-bridge-d3-v5-4-2426dd9e8e27@linaro.org>

Hi Manivannan,

Dredging up an old one, but it seems like there was almost consensus on
this patch, and yet it stalled because the series does too much. I'm
interested in reviving it, but I also have some thoughts on the
usability.

On Fri, Aug 02, 2024 at 11:25:03AM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> 
> Unlike ACPI based platforms, there are no known issues with D3Hot for the
> PCI bridges in the Devicetree based platforms. So let's allow the PCI
> bridges to go to D3Hot during runtime. It should be noted that the bridges
> need to be defined in Devicetree for this to work.

IMO, it's not an amazing idea to key off the presence of a bridge DT
node for this. AFAIK, that's not really required for most other things
(especially if we're not mapping legacy INTx support), and many
platforms I work with do not define a bridge node. But they do use DT,
and I'd like to be able to suspend their bridges.

Personally, I'd choose to match the same requirements as used by
devm_pci_alloc_host_bridge() -> devm_of_pci_bridge_init() -- that the
parent device under which the host bridge is created has an of_node.
Code sample below.

> Currently, D3Cold is not allowed since Vcc supply which is required for
> transitioning the device to D3Cold is not exposed on all Devicetree based
> platforms.
> 
> Tested-by: Hsin-Yi Wang <hsinyi@chromium.org>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
>  drivers/pci/pci.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index c7a4f961ec28..bc1e1ca673f1 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2992,6 +2992,18 @@ static bool pci_bridge_d3_allowed(struct pci_dev *bridge, pci_power_t state)
>  		if (pci_bridge_d3_force)
>  			return true;
>  
> +		/*
> +		 * Allow D3Hot for all Devicetree based platforms having a
> +		 * separate node for the bridge. We don't allow D3Cold for now
> +		 * since not all platforms are exposing the Vcc supply in
> +		 * Devicetree which is required for transitioning the bridge to
> +		 * D3Cold.
> +		 *
> +		 * NOTE: The bridge is expected to be defined in Devicetree.
> +		 */
> +		if (state == PCI_D3hot && dev_of_node(&bridge->dev))
> +			return true;
> +

For me, a way to lighten the bridge-node restriction is:

	struct pci_host_bridge *host_bridge;

	...
		/*
		 * Allow D3 for all Device Tree based systems. We check
		 * if our host bridge's parent has a Device Tree node.
		 * None of the D3 restrictions that applied to old BIOS
		 * systems are known to apply to DT systems.
		 */
		host_bridge = pci_find_host_bridge(bridge->bus);
		if (dev_of_node(host_bridge->dev.parent))
			return true;

Brian

>  		/* Even the oldest 2010 Thunderbolt controller supports D3. */
>  		if (bridge->is_thunderbolt)
>  			return true;
> @@ -3042,7 +3054,7 @@ bool pci_bridge_d3cold_allowed(struct pci_dev *bridge)
>   *
>   * This function checks if the bridge is allowed to move to D3Hot.
>   * Currently we only allow D3Hot for recent enough PCIe ports on ACPI based
> - * platforms and Thunderbolt.
> + * platforms, Thunderbolt and Devicetree based platforms.
>   */
>  bool pci_bridge_d3hot_allowed(struct pci_dev *bridge)
>  {
> 
> -- 
> 2.25.1
> 
> 

      parent reply	other threads:[~2024-11-21 18:53 UTC|newest]

Thread overview: 32+ 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 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 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 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 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 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
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 [this message]

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=Zz-BjF3rZRyfv0Mg@google.com \
    --to=briannorris@chromium.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=manivannan.sadhasivam@linaro.org \
    --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 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).