search for: nvp3

...eau (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...

...etected) 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 o...

...ue to a kbuild issue which I reported elsewhere), but the output is empty. That seems to indicate that flags.power_resources is unset. Given that _PS3 exists and is indeed a package with some elements, it seems that acpi_extract_power_resources is failing. Note that in the SSDT, the power resource NVP3 was referenced before it was defined, could that result in this enumeration failure? Relevant SSDT excerpt: Scope (\_SB.PCI0.RP05) { Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot { NVP3 }) // ... } PowerResource (NVP3, 0...

...tely empty or is it empty just for RP05? It should print out > all devices with power resources. > > > Given that _PS3 exists and is indeed a package with some elements, it > > seems that acpi_extract_power_resources is failing. Note that in the > > SSDT, the power resource NVP3 was referenced before it was defined, > > could that result in this enumeration failure? Relevant SSDT excerpt: > > > > Scope (\_SB.PCI0.RP05) > > { > > Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot > > { > >...

...e 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:...

...just for RP05? It should print out > > all devices with power resources. > > > > > Given that _PS3 exists and is indeed a package with some elements, it > > > seems that acpi_extract_power_resources is failing. Note that in the > > > SSDT, the power resource NVP3 was referenced before it was defined, > > > could that result in this enumeration failure? Relevant SSDT excerpt: > > > > > > Scope (\_SB.PCI0.RP05) > > > { > > > Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot > > &g...

...quence 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 > > > d...

...s is unset. Is it completely empty or is it empty just for RP05? It should print out all devices with power resources. > Given that _PS3 exists and is indeed a package with some elements, it > seems that acpi_extract_power_resources is failing. Note that in the > SSDT, the power resource NVP3 was referenced before it was defined, > could that result in this enumeration failure? Relevant SSDT excerpt: > > Scope (\_SB.PCI0.RP05) > { > Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot > { > NVP3 > }) >...

No, there are not. Here is the recursive directory listing: http://sprunge.us/FIRE Op do 27 okt. 2016 11:30 schreef Mika Westerberg < mika.westerberg at linux.intel.com>: > On Thu, Oct 27, 2016 at 09:15:19AM +0000, Rick Kerkhof wrote: > > I can confirm what Peter said, path contains \_SB_.PCI0.RP05 and > > power_state contains D3hot. > > And there are no

...to > > boot due to a kbuild issue which I reported elsewhere), but the output > > is empty. That seems to indicate that flags.power_resources is unset. > > Is it completely empty or is it empty just for RP05? It should print out > all devices with power resources. \NVP2 and \NVP3 are the only power resources under RP05 and defined in SSDT1, there are no others. Kind regards, Peter > > Given that _PS3 exists and is indeed a package with some elements, it > > seems that acpi_extract_power_resources is failing. Note that in the > > SSDT, the power resource...

...pen: > > > > - \_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 > p...

On Wed, May 25, 2016 at 12:53:01AM +0200, Peter Wu wrote: > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port > can be runtime-suspended which disables power resources via ACPI. This > is incompatible with DSM, resulting in a GPU device which is still in D3 > and locks up the kernel on resume. > > Mirror the behavior of Windows 8 and newer[1] (as

...sewhere), but the output > > > > is empty. That seems to indicate that flags.power_resources is unset. > > > > > > Is it completely empty or is it empty just for RP05? It should print out > > > all devices with power resources. > > > > \NVP2 and \NVP3 are the only power resources under RP05 and defined in > > SSDT1, there are no others. > > We should probably add a debug print before checking > flags.power_resources just to be sure the patch is correctly applied. It was correctly applied. I did some testing with QEMU, it seems t...

...of curiosity I looked up an pre-2015 laptop (found Acer V5-573G, > apparently from November 2013, Windows 8.1) and extracted the ACPI > tables from the BIOS images. BIOS 2.28 (2014/05/13) introduces support > for power resources on the parent devicea(\_SB.PCI0.PEG0._PR3 and a > related NVP3 device) when _OSI("Windows 2013") is true. (This is added > as alternative for the old DSM interface.) > > Maybe 2014 is also an appropriate cutoff date? I wonder if it is > feasible to detect firmware use of _OSI("Windows 2013") and use that > instead of the BIO...

On Mon, May 30, 2016 at 06:13:51PM +0200, Peter Wu wrote: > Do you have any suggestions for the case where the pcieport driver > refuses to put the bridge in D3 (because the BIOS is too old)? In that > case the nouveau driver needs to fallback to the DSM method (but not > when runtime PM is deliberately disabled by writing control=on). Do you know what Windows does then? I think we

...se will likely be machine from 2014 > or before. > > Interesting to see is the _PR3 method of a HP Envy TS 15 (11/20/2014): > > Method (_PR3, 0, NotSerialized) { > If (\_OSI ("Windows 2013")) { > Return (Package (0x01) { > \NVP3 > }) > } Else { > Return (Package (0x00) {}) > } > } > > (Note for self: just checking for the _PR3 handle in the nouveau patch > is apparently not sufficient, it must really be evaluated.) > > Other machines with _PR3: &gt...

...uild issue which I reported elsewhere), but the output > > > is empty. That seems to indicate that flags.power_resources is unset. > > > > Is it completely empty or is it empty just for RP05? It should print out > > all devices with power resources. > > \NVP2 and \NVP3 are the only power resources under RP05 and defined in > SSDT1, there are no others. We should probably add a debug print before checking flags.power_resources just to be sure the patch is correctly applied.

...d possibility. Out of curiosity I looked up an pre-2015 laptop (found Acer V5-573G, apparently from November 2013, Windows 8.1) and extracted the ACPI tables from the BIOS images. BIOS 2.28 (2014/05/13) introduces support for power resources on the parent devicea(\_SB.PCI0.PEG0._PR3 and a related NVP3 device) when _OSI("Windows 2013") is true. (This is added as alternative for the old DSM interface.) Maybe 2014 is also an appropriate cutoff date? I wonder if it is feasible to detect firmware use of _OSI("Windows 2013") and use that instead of the BIOS year. -- Kind regards,...

...S is set to 0x07DD. - This in turn cause VMSH to be set to 1. - This in turn causes _SB_.PCI0.PEG_.VID_.PS3 to _NOT call GPOF when the device is set to D3. - and so the card is never really turned off completely Now if you look at how GPOF can be called, you can see it will be called as part of NVP3 power resource which is PR3 ... but on the node _SB.PCI0.PEG_ and not _SB_.PCI0.PEG_.VID_ ! So this means that the parent PCIe root port the card is connected to needs to be put in D3. I did a quick hack using bumblebee (easier to try stuff out) to test and this indeed seems to work. I was able t...

...or comments in early 2015 or before, those will likely be machine from 2014 or before. Interesting to see is the _PR3 method of a HP Envy TS 15 (11/20/2014): Method (_PR3, 0, NotSerialized) { If (\_OSI ("Windows 2013")) { Return (Package (0x01) { \NVP3 }) } Else { Return (Package (0x00) {}) } } (Note for self: just checking for the _PR3 handle in the nouveau patch is apparently not sufficient, it must really be evaluated.) Other machines with _PR3: - Dell Inspiron 3543 (11/04/2014), comment 757. - D...