Mika Westerberg
2016-Oct-27 08:17 UTC
[Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
On Thu, Oct 27, 2016 at 12:56:41AM +0200, Peter Wu wrote:> Hi PCI/ACPI PM experts, > > Since Linux 4.8, nouveau switched to rely on the PCIe port driver to > transition to D3cold. This however does not happen for an Acer Aspire > V7-582PG (Haswell, NVIDIA GTX 750M) from Rick. > > Any idea why? acpidump, lspci, dmesg and other details can be found in > the linked bug below.> > Kind regards, > Peter > > On Wed, Oct 26, 2016 at 10:42:07PM +0000, bugzilla-daemon at freedesktop.org wrote: > > https://bugs.freedesktop.org/show_bug.cgi?id=98398 > > > > --- Comment #11 from Peter Wu <peter at lekensteyn.nl> --- > > So 4.7 and before used the "DSM" method on runtime-suspend: > > - \_SB.PCI0.RP05.PEGP._DSM would be invoked to enable Optimus > > - \_SB.PCI0.RP05.PEGP._PS3 is then invoked which would enter D3cold > > (note, this method is still used in 4.8 on older laptops or with the > > pcie_pm_port=off kernel option) > > > > Since 4.8, _DSM is not called anymore by nouveau (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's Acer laptop shows this structure: > > > > If (\_OSI ("Windows 2013")) > > { > > Scope (\_SB.PCI0.RP05) > > { > > //... > > Name (_PR0, Package (0x01) // _PR0: Power Resources for D0 > > { > > NVP3 > > }) > > Name (_PR2, Package (0x01) // _PR2: Power Resources for D2 > > { > > NVP2 > > }) > > Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot > > { > > NVP3 > > }) > > // ... > > Method (_PS0, 0, NotSerialized) // _PS0: Power State 0 > > { > > } > > > > Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 > > { > > } > > } > > > > Name (MSD3, Zero) > > PowerResource (NVP3, 0x00, 0x0000) > > { > > Name (_STA, One) // _STA: Status > > // ... > > > > Method (_ON, 0, NotSerialized) // _ON_: Power On > > { > > // ... > > } > > > > Method (_OFF, 0, NotSerialized) // _OFF: Power Off > > { > > // ... > > } > > } > > > > The dmesg does show "ACPI: Power Resource [NVP3] (on)", so I guess that the > > methods are found. It is a mystery to me why the "power_resources_Dx" files are > > not created, possibly breaking PM.The ASL code looks right to me (except for the NVP2 which never set _STA to 0 but should not affect here). I wonder what does /sys/bus/pci/devices/0000:00:1c.4/firmware_node/path contain?
Peter Wu
2016-Oct-27 09:06 UTC
[Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
On Thu, Oct 27, 2016 at 11:17:48AM +0300, Mika Westerberg wrote:> On Thu, Oct 27, 2016 at 12:56:41AM +0200, Peter Wu wrote: > > Hi PCI/ACPI PM experts, > > > > Since Linux 4.8, nouveau switched to rely on the PCIe port driver to > > transition to D3cold. This however does not happen for an Acer Aspire > > V7-582PG (Haswell, NVIDIA GTX 750M) from Rick. > > > > Any idea why? acpidump, lspci, dmesg and other details can be found in > > the linked bug below. > > > > > Kind regards, > > Peter > > > > On Wed, Oct 26, 2016 at 10:42:07PM +0000, bugzilla-daemon at freedesktop.org wrote: > > > https://bugs.freedesktop.org/show_bug.cgi?id=98398 > > > > > > --- Comment #11 from Peter Wu <peter at lekensteyn.nl> --- > > > So 4.7 and before used the "DSM" method on runtime-suspend: > > > - \_SB.PCI0.RP05.PEGP._DSM would be invoked to enable Optimus > > > - \_SB.PCI0.RP05.PEGP._PS3 is then invoked which would enter D3cold > > > (note, this method is still used in 4.8 on older laptops or with the > > > pcie_pm_port=off kernel option) > > > > > > Since 4.8, _DSM is not called anymore by nouveau (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's Acer laptop shows this structure: > > > > > > If (\_OSI ("Windows 2013")) > > > { > > > Scope (\_SB.PCI0.RP05) > > > { > > > //... > > > Name (_PR0, Package (0x01) // _PR0: Power Resources for D0 > > > { > > > NVP3 > > > }) > > > Name (_PR2, Package (0x01) // _PR2: Power Resources for D2 > > > { > > > NVP2 > > > }) > > > Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot > > > { > > > NVP3 > > > }) > > > // ... > > > Method (_PS0, 0, NotSerialized) // _PS0: Power State 0 > > > { > > > } > > > > > > Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 > > > { > > > } > > > } > > > > > > Name (MSD3, Zero) > > > PowerResource (NVP3, 0x00, 0x0000) > > > { > > > Name (_STA, One) // _STA: Status > > > // ... > > > > > > Method (_ON, 0, NotSerialized) // _ON_: Power On > > > { > > > // ... > > > } > > > > > > Method (_OFF, 0, NotSerialized) // _OFF: Power Off > > > { > > > // ... > > > } > > > } > > > > > > The dmesg does show "ACPI: Power Resource [NVP3] (on)", so I guess that the > > > methods are found. It is a mystery to me why the "power_resources_Dx" files are > > > not created, possibly breaking PM. > > The ASL code looks right to me (except for the NVP2 which never set _STA > to 0 but should not affect here). > > I wonder what does /sys/bus/pci/devices/0000:00:1c.4/firmware_node/path contain?The value is as expected, \_SB.PCI0.RP05: /sys/bus/pci/devices/0000:00:1c.4/firmware_node/path:\_SB_.PCI0.RP05 /sys/bus/pci/devices/0000:00:1c.4/firmware_node/power_state:D3hot -- Kind regards, Peter Wu https://lekensteyn.nl
Rick Kerkhof
2016-Oct-27 09:15 UTC
[Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
I can confirm what Peter said, path contains \_SB_.PCI0.RP05 and power_state contains D3hot. Op do 27 okt. 2016 11:06 schreef Peter Wu <peter at lekensteyn.nl>:> On Thu, Oct 27, 2016 at 11:17:48AM +0300, Mika Westerberg wrote: > > On Thu, Oct 27, 2016 at 12:56:41AM +0200, Peter Wu wrote: > > > Hi PCI/ACPI PM experts, > > > > > > Since Linux 4.8, nouveau switched to rely on the PCIe port driver to > > > transition to D3cold. This however does not happen for an Acer Aspire > > > V7-582PG (Haswell, NVIDIA GTX 750M) from Rick. > > > > > > Any idea why? acpidump, lspci, dmesg and other details can be found in > > > the linked bug below. > > > > > > > > Kind regards, > > > Peter > > > > > > On Wed, Oct 26, 2016 at 10:42:07PM +0000, > bugzilla-daemon at freedesktop.org wrote: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=98398 > > > > > > > > --- Comment #11 from Peter Wu <peter at lekensteyn.nl> --- > > > > So 4.7 and before used the "DSM" method on runtime-suspend: > > > > - \_SB.PCI0.RP05.PEGP._DSM would be invoked to enable Optimus > > > > - \_SB.PCI0.RP05.PEGP._PS3 is then invoked which would enter D3cold > > > > (note, this method is still used in 4.8 on older laptops or with the > > > > pcie_pm_port=off kernel option) > > > > > > > > Since 4.8, _DSM is not called anymore by nouveau (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's Acer laptop shows this structure: > > > > > > > > If (\_OSI ("Windows 2013")) > > > > { > > > > Scope (\_SB.PCI0.RP05) > > > > { > > > > //... > > > > Name (_PR0, Package (0x01) // _PR0: Power Resources for > D0 > > > > { > > > > NVP3 > > > > }) > > > > Name (_PR2, Package (0x01) // _PR2: Power Resources for > D2 > > > > { > > > > NVP2 > > > > }) > > > > Name (_PR3, Package (0x01) // _PR3: Power Resources for > D3hot > > > > { > > > > NVP3 > > > > }) > > > > // ... > > > > Method (_PS0, 0, NotSerialized) // _PS0: Power State 0 > > > > { > > > > } > > > > > > > > Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 > > > > { > > > > } > > > > } > > > > > > > > Name (MSD3, Zero) > > > > PowerResource (NVP3, 0x00, 0x0000) > > > > { > > > > Name (_STA, One) // _STA: Status > > > > // ... > > > > > > > > Method (_ON, 0, NotSerialized) // _ON_: Power On > > > > { > > > > // ... > > > > } > > > > > > > > Method (_OFF, 0, NotSerialized) // _OFF: Power Off > > > > { > > > > // ... > > > > } > > > > } > > > > > > > > The dmesg does show "ACPI: Power Resource [NVP3] (on)", so I guess > that the > > > > methods are found. It is a mystery to me why the > "power_resources_Dx" files are > > > > not created, possibly breaking PM. > > > > The ASL code looks right to me (except for the NVP2 which never set _STA > > to 0 but should not affect here). > > > > I wonder what does /sys/bus/pci/devices/0000:00:1c.4/firmware_node/path > contain? > > The value is as expected, \_SB.PCI0.RP05: > > /sys/bus/pci/devices/0000:00:1c.4/firmware_node/path:\_SB_.PCI0.RP05 > /sys/bus/pci/devices/0000:00:1c.4/firmware_node/power_state:D3hot > -- > Kind regards, > Peter Wu > https://lekensteyn.nl >-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/nouveau/attachments/20161027/2c2a6cb5/attachment-0001.html>
Reasonably Related Threads
- Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
- [Bug 98398] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU with runtime PM
- Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
- Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
- Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources