Re: [PATCH v16 0/3] Avoid PCIe D3 for AMD PCIe root ports

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 9/5/2023 05:13, Hans de Goede wrote:
Hi Mario,

On 8/29/23 19:12, Mario Limonciello wrote:
D3 on PCIe root ports isn't used on Windows systems in Modern Standby.
This series adjusts the amd-pmc driver to choose the same strategy
for Rembrandt and Phoenix platforms in Linux with s2idle.

LPS0 constraints are the basis for it; which if they are added for
Windows would also apply for Linux as well.

This version doesn't incorporate a callback, as it's pending feedback
from Bjorn if that approach is amenable.

This series relies upon changes that are both in linux-pm.git and
platform-x86.git. So it won't be able to apply to either maintainer's
tree until later.

Mario Limonciello (3):
   ACPI: x86: s2idle: Export symbol for fetching constraints for module
   platform/x86/amd: pmc: Adjust workarounds to be part of a switch/case
   platform/x86/amd: pmc: Don't let PCIe root ports go into D3

Thank you for the new version.

I understand you wanted to get this new approach "out there" but
this does not address my remarks on v15:

Right; I called out in the cover letter this is pending feedback from Bjorn.

Bjorn, I suggest to allow platform code to register a callback
to influence pci_bridge_d3_possible() results there. Can you
take a look at this and let us know what you think of this
suggestion ?

Looking at this problem again and rereading the commit message
of "platform/x86/amd: pmc: Don't let PCIe root ports go into D3"

I see that the problem is that the PCIe root ports to which
the USB controllers connect should not be allowed to go
into D3 when an USB child of them is configured to wakeup
the system.

It seems to me that given that problem description,
we should not be directly messing with the bridge_d3
setting at all.

Instead the XHCI code should have an AMD specific quirk
where it either unconditionally calls pci_d3cold_disable()
on the XHCI PCIe device; or it could even try to be smart
and call pci_d3cold_enable() / pci_d3cold_disable()
from its (runtime)suspend handler depending on if any
USB child is configured as a system wakeup source.

Note that it is safe to repeatedly call pci_d3cold_enable()
/ _disable() there is no need to balance the calls.

It's only the PCIe root port that is used for XHCI tunneling that has this issue. This specific problem is NOT for the root port of "any" AMD XHCI controllers. There is no problem with any of the XHCI controllers
going into D3hot.

So if a quirk was used in the XHCI driver, it's going to mean examining the topology of the PCI devices to find the right one. I really don't think this is a scalable way to do it.

The big advantage of the way this quirking is done now is that it should mirror how Windows makes the decision. On Windows the uPEP ACPI driver uses the constraints to orchestrate the desired ACPI states for Modern Standby. In Linux we can then use the matching driver (amd-pmc) to make the decision.

[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux