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@xxxxxxxxxx>
>
> 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@xxxxxxxxxxxx>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@xxxxxxxxxx>
> ---
> 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
>
>
