On 11/15/2022 18:37, Bjorn Helgaas wrote:
On Mon, Nov 14, 2022 at 04:33:52PM +0100, Rafael J. Wysocki wrote:
On Fri, Nov 11, 2022 at 10:42 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
On Fri, Nov 11, 2022 at 12:58:28PM -0600, Limonciello, Mario wrote:
On 11/11/2022 11:41, Bjorn Helgaas wrote:
On Mon, Oct 31, 2022 at 05:33:55PM -0500, Mario Limonciello wrote:
Firmware typically advertises that ACPI devices that represent PCIe
devices can support D3 by a combination of the value returned by
_S0W as well as the HotPlugSupportInD3 _DSD [1].
`acpi_pci_bridge_d3` looks for this combination but also contains
an assumption that if an ACPI device contains power resources the PCIe
device it's associated with can support D3. This was introduced
from commit c6e331312ebf ("PCI/ACPI: Whitelist hotplug ports for
D3 if power managed by ACPI").
Some firmware configurations for "AMD Pink Sardine" do not support
wake from D3 in _S0W for the ACPI device representing the PCIe root
port used for tunneling. The PCIe device will still be opted into
runtime PM in the kernel [2] because of the logic within
`acpi_pci_bridge_d3`. This currently happens because the ACPI
device contains power resources.
Wait. Is this as simple as just recognizing that:
_PS0 means the OS has a knob to put the device in D0, but it doesn't
mean the device can wake itself from a low-power state. The OS has
to use _S0W to learn the device's ability to wake itself.
It is.
Now I'm confused again about what "HotPlugSupportInD3" means. The MS
web page [1] says it identifies Root Ports capable of handling hot
plug events while in D3. That sounds kind of related to _S0W: If _S0W
says "I can wake myself from D3hot and D3cold", how is that different
from "I can handle hotplug events in D3"?
It's impossible to know for sure the logic in Windows, but from all the
discussion and patches that have flowed related to it my inference is
the logic for Windows must only examine and use the "HotPlugSupportInD3"
property if the device also has _S0W.
This patch says that if dev's Root Port has "HotPlugSupportInD3", we
don't need _PS0 or _PR0 for dev. I guess that must be true, because
previously the fact that we checked for "HotPlugSupportInD3" meant the
device did NOT have _PS0 or _PR0.
A lot of this confusion and this patch of mine stem from c6e331312ebfb
being too broad to start out with IMO. Wouldn't it have made more sense
to only match and allowlist that specific topology combination (dGPU
connected to hotplug port and missing those properties)?
[1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fwindows-hardware%2Fdrivers%2Fpci%2Fdsd-for-pcie-root-ports%23identifying-pcie-root-ports-supporting-hot-plug-in-d3&data=05%7C01%7Cmario.limonciello%40amd.com%7Cc883ba6351534df445f408dac76ac5e5%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638041558659543898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5Qv3wUYB%2FXJhbeu%2Fh3A0swvgRaB8afjyEYzu9SpHK%2Bo%3D&reserved=0
