search for: _off

...when support from the PCI core is detected) and this sequence should instead happen: - \_SB.PCI0.RP05.PEGP._PS3 (does nothing besides updating _STA) - PCIe core removes power for the PCIe port since all its children are in D3 and are willing to transition to D3cold. It does so by invoking \NVP3._OFF (where \NVP3 is the power resource from \_SB.PCI0.RP05._PR3) That is how I think it should work in theory, but on Ricks laptop running 4.8.4, /sys/bus/devices/0000:1c.4/firmware_node/ does not have power_resources_D0 devices (which I do have on my own laptop for 0000:01:0). The SSDT1 of Rick'...

...) I have not seen any issues like > > > > this when D3cold is properly implemented in the platform. That's why > > > > I'm bit skeptical that this has anything to do with specific Intel PCIe > > > > ports. More likely it is some power sequence in the _ON/_OFF() methods > > > > that is run differently on Windows. > > > > > > yeah.. maybe. I really don't know what's the actual root cause. I just > > > know that with this workaround it works perfectly fine on my and some > > > other systems it was tes...

...ed) and this sequence should instead happen: > > - \_SB.PCI0.RP05.PEGP._PS3 (does nothing besides updating _STA) > > - PCIe core removes power for the PCIe port since all its children are in > > D3 and are willing to transition to D3cold. It does so by invoking > > \NVP3._OFF (where \NVP3 is the power resource from \_SB.PCI0.RP05._PR3) > > > > That is how I think it should work in theory, but on Ricks laptop running > > 4.8.4, > > /sys/bus/devices/0000:1c.4/firmware_node/ does not have power_resources_D0 > > devices (which I do have on my...

...t; > > off the power resource (which is attached to the root port) resulting > > > > > the topology entering D3cold. > > > > > > > > I don't see that happening in the AML though. > > > > > > Which AML do you mean, specifically? The _OFF method for the root > > > port's _PR3 power resource or something else? > > > > The root port's _OFF method for the power resource returned by its _PR3. > > OK, so without the $subject patch we (1) program the downstream > component (GPU) into D3hot, then we (...

...ut I'm not aware of any ;-) I have not seen any issues like > > this when D3cold is properly implemented in the platform. That's why > > I'm bit skeptical that this has anything to do with specific Intel PCIe > > ports. More likely it is some power sequence in the _ON/_OFF() methods > > that is run differently on Windows. > > yeah.. maybe. I really don't know what's the actual root cause. I just > know that with this workaround it works perfectly fine on my and some > other systems it was tested on. Do you know who would be best to > app...

...ched to the root port) resulting > > > > > > > the topology entering D3cold. > > > > > > > > > > > > I don't see that happening in the AML though. > > > > > > > > > > Which AML do you mean, specifically? The _OFF method for the root > > > > > port's _PR3 power resource or something else? > > > > > > > > The root port's _OFF method for the power resource returned by its _PR3. > > > > > > OK, so without the $subject patch we (1) program the down...

...gt; > > then the root port and then turn > > > off the power resource (which is attached to the root port) resulting > > > the topology entering D3cold. > > > > I don't see that happening in the AML though. > > Which AML do you mean, specifically? The _OFF method for the root > port's _PR3 power resource or something else? The root port's _OFF method for the power resource returned by its _PR3. > > Basically the difference is that when Windows 7 or Linux (the _REV==5 > > check) then we directly do link disable whereas in Wind...

...en any issues like > > > > > this when D3cold is properly implemented in the platform. That's why > > > > > I'm bit skeptical that this has anything to do with specific Intel PCIe > > > > > ports. More likely it is some power sequence in the _ON/_OFF() methods > > > > > that is run differently on Windows. > > > > > > > > yeah.. maybe. I really don't know what's the actual root cause. I just > > > > know that with this workaround it works perfectly fine on my and some > > > >...

...r resource (which is attached to the root port) resulting > > > > > > the topology entering D3cold. > > > > > > > > > > I don't see that happening in the AML though. > > > > > > > > Which AML do you mean, specifically? The _OFF method for the root > > > > port's _PR3 power resource or something else? > > > > > > The root port's _OFF method for the power resource returned by its _PR3. > > > > OK, so without the $subject patch we (1) program the downstream > > componen...

...e GPU driver to prepare the GPU for power removal in some specific way and the latter fails if the GPU has not been prepared as expected. Because testing indicates that the Windows 7 path in the platform firmware works, it may be worth trying to do what it does to the PCIe link before invoking the _OFF method for the power resource controlling the GPU power. If the Mika's theory that the Win7 path simply turns the PCIe link off is correct, then whatever the _OFF method tries to do to the link after that should not matter. > On Wed, Nov 27, 2019 at 8:55 PM Lyude Paul <lyude at redhat.c...

...t; > > off the power resource (which is attached to the root port) resulting > > > > > the topology entering D3cold. > > > > > > > > I don't see that happening in the AML though. > > > > > > Which AML do you mean, specifically? The _OFF method for the root > > > port's _PR3 power resource or something else? > > > > The root port's _OFF method for the power resource returned by its _PR3. > > OK, so without the $subject patch we (1) program the downstream > component (GPU) into D3hot, then we (2...

...> core is detected) and this sequence should instead happen: > - \_SB.PCI0.RP05.PEGP._PS3 (does nothing besides updating _STA) > - PCIe core removes power for the PCIe port since all its children are in > D3 and are willing to transition to D3cold. It does so by invoking > \NVP3._OFF (where \NVP3 is the power resource from \_SB.PCI0.RP05._PR3) > > That is how I think it should work in theory, but on Ricks laptop running > 4.8.4, > /sys/bus/devices/0000:1c.4/firmware_node/ does not have power_resources_D0 > devices (which I do have on my own laptop for 0000:01:0)...

...e should instead happen: > > > - \_SB.PCI0.RP05.PEGP._PS3 (does nothing besides updating _STA) > > > - PCIe core removes power for the PCIe port since all its children are in > > > D3 and are willing to transition to D3cold. It does so by invoking > > > \NVP3._OFF (where \NVP3 is the power resource from \_SB.PCI0.RP05._PR3) > > > > > > That is how I think it should work in theory, but on Ricks laptop running > > > 4.8.4, > > > /sys/bus/devices/0000:1c.4/firmware_node/ does not have power_resources_D0 > > > device...

...wer_transition(D3cold) > pci_platform_power_transition(D3cold) > platform_pci_set_power_state(D3cold) > acpi_pci_set_power_state(D3cold) > acpi_device_set_power(ACPI_STATE_D3_COLD) > ... > acpi_evaluate_object("_OFF") <-- set to D3cold > > I did not understand the connection with platform (ACPI) power > management from your patch. It sounds like you want this entire path > except that you want to skip the PCI_PM_CTRL write? > exactly. I am running with this workaround for a while n...

...ike > > > > > > this when D3cold is properly implemented in the platform. That's why > > > > > > I'm bit skeptical that this has anything to do with specific Intel PCIe > > > > > > ports. More likely it is some power sequence in the _ON/_OFF() methods > > > > > > that is run differently on Windows. > > > > > > > > > > yeah.. maybe. I really don't know what's the actual root cause. I just > > > > > know that with this workaround it works perfectly fine on my and some...

...t; pci_platform_power_transition(D3cold) > > platform_pci_set_power_state(D3cold) > > acpi_pci_set_power_state(D3cold) > > acpi_device_set_power(ACPI_STATE_D3_COLD) > > ... > > acpi_evaluate_object("_OFF") <-- set to D3cold > > > > I did not understand the connection with platform (ACPI) power > > management from your patch. It sounds like you want this entire path > > except that you want to skip the PCI_PM_CTRL write? > > > > exactly. I am running...

....2 and Windows 8 (and later) > > > > does something else. > > > > > > My understanding (which may not be correct) is that up to Windows 7 it > > > never put the devices into D3cold runtime. Only when the system entered > > > Sx states it evaluated the _OFF methods. > > > > I see. I think I have misunderstood what you said. I also think that Windows 7 and before didin't do RTD3, but it did PCI PM nevertheless and platform firmware could expect it to behave in a specific way in that respect. That expected behavior seems to have chang...

...ched to the root port) resulting > > > > > > > the topology entering D3cold. > > > > > > > > > > > > I don't see that happening in the AML though. > > > > > > > > > > Which AML do you mean, specifically? The _OFF method for the root > > > > > port's _PR3 power resource or something else? > > > > > > > > The root port's _OFF method for the power resource returned by its _PR3. > > > > > > OK, so without the $subject patch we (1) program the down...

...ort and then turn > > > > off the power resource (which is attached to the root port) resulting > > > > the topology entering D3cold. > > > > > > I don't see that happening in the AML though. > > > > Which AML do you mean, specifically? The _OFF method for the root > > port's _PR3 power resource or something else? > > The root port's _OFF method for the power resource returned by its _PR3. OK, so without the $subject patch we (1) program the downstream component (GPU) into D3hot, then we (2) program the port holding it...

...r resource (which is attached to the root port) resulting > > > > > > the topology entering D3cold. > > > > > > > > > > I don't see that happening in the AML though. > > > > > > > > Which AML do you mean, specifically? The _OFF method for the root > > > > port's _PR3 power resource or something else? > > > > > > The root port's _OFF method for the power resource returned by its _PR3. > > > > OK, so without the $subject patch we (1) program the downstream > > componen...