Hi Mario, On 9/5/23 14:45, Mario Limonciello wrote: > 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. >>> >>> NOTE: >>> 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 >>> use >>> 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: >> >> https://lore.kernel.org/platform-driver-x86/53d26a63-64f3-e736-99f5-32bf4b5ba31d@xxxxxxxxxx/ >> > > 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. "XHCI tunneling" is an unfamiliar term for me. Are we talking about a XHCI controller inside a USB4/thunderbold dock here which is connected to the laptop over PCIe tunneling over thunderbolt ? Or do you mean the XHCI controller inside the laptop which is connected to a USB4/thunderbolt capable Type-C port which is used when that port is in USB3/USB2 mode ? As long as the XHCI controller is inside the laptop (and not in the dock), presumably you can identify it by say a set of PCI device-ids of the "tunneling" XHCI controllers on affected AMD platforms. So you could then still call pci_d3cold_disable() from the XHCI driver on only those controllers. Note I'm not saying this is the best solution. I'm just trying to understand what you mean with " the PCIe root port that is used for XHCI tunneling" . I also see that Rafael has said elsewhere in the thread that he needs to think a bit about how to best handle this ... Regards, Hans
