similar to: [Bug 98398] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU with runtime PM

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

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

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

On Fri, Oct 28, 2016 at 11:56:30AM +0300, Mika Westerberg wrote: > On Thu, Oct 27, 2016 at 06:06:48PM +0200, Peter Wu wrote: > > On Thu, Oct 27, 2016 at 12:55:08PM +0300, Mika Westerberg wrote: > > > On Thu, Oct 27, 2016 at 09:42:28AM +0000, Rick Kerkhof wrote: > > > > No, there are not. Here is the recursive directory listing: > > > > > > Are

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

On Thu, Oct 27, 2016 at 12:55:08PM +0300, Mika Westerberg wrote: > On Thu, Oct 27, 2016 at 09:42:28AM +0000, Rick Kerkhof wrote: > > No, there are not. Here is the recursive directory listing: > > Are you able to try the following patch and send me dmesg (or attach it > to that bug)? It should show if the ACPI core even tries to add those > power resources. So Rick has

Hi, Mika > From: Mika Westerberg [mailto:mika.westerberg at linux.intel.com] > Subject: Re: Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources > > On Thu, Oct 27, 2016 at 06:06:48PM +0200, Peter Wu wrote: > > On Thu, Oct 27, 2016 at 12:55:08PM +0300, Mika Westerberg wrote: > > > On Thu, Oct 27, 2016 at 09:42:28AM +0000, Rick Kerkhof

On Fri, Oct 28, 2016 at 02:19:07PM +0300, Mika Westerberg wrote: > On Fri, Oct 28, 2016 at 01:09:30PM +0200, Peter Wu wrote: > > On Fri, Oct 28, 2016 at 11:56:30AM +0300, Mika Westerberg wrote: > > > On Thu, Oct 27, 2016 at 06:06:48PM +0200, Peter Wu wrote: > > > > On Thu, Oct 27, 2016 at 12:55:08PM +0300, Mika Westerberg wrote: > > > > > On Thu, Oct

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

On Sat, Oct 29, 2016 at 12:42:34AM +0000, Zheng, Lv wrote: > Hi, Mika > > > From: Mika Westerberg [mailto:mika.westerberg at linux.intel.com] > > Subject: Re: Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources > > > > On Thu, Oct 27, 2016 at 06:06:48PM +0200, Peter Wu wrote: > > > On Thu, Oct 27, 2016 at 12:55:08PM +0300,

On Thu, Oct 27, 2016 at 06:06:48PM +0200, Peter Wu wrote: > On Thu, Oct 27, 2016 at 12:55:08PM +0300, Mika Westerberg wrote: > > On Thu, Oct 27, 2016 at 09:42:28AM +0000, Rick Kerkhof wrote: > > > No, there are not. Here is the recursive directory listing: > > > > Are you able to try the following patch and send me dmesg (or attach it > > to that bug)? It

On Fri, Oct 28, 2016 at 01:09:30PM +0200, Peter Wu wrote: > On Fri, Oct 28, 2016 at 11:56:30AM +0300, Mika Westerberg wrote: > > On Thu, Oct 27, 2016 at 06:06:48PM +0200, Peter Wu wrote: > > > On Thu, Oct 27, 2016 at 12:55:08PM +0300, Mika Westerberg wrote: > > > > On Thu, Oct 27, 2016 at 09:42:28AM +0000, Rick Kerkhof wrote: > > > > > No, there are

On Tue, May 31, 2016 at 01:02:31PM +0200, Peter Wu wrote: > On Tue, May 31, 2016 at 11:43:56AM +0300, Mika Westerberg wrote: > > 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

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

Hello Marcos, I sent a serie a year ago to fix some of the ACPI handling in Nouveau and add runtime pm support for laptops with an Apple GMUX (see [0], and especially [1] and [2]). I was told that a more generic work for the runtime pm was in the work, so I let the whole serie slip away. I was thinking of resubmitting the serie without the runtime pm additions, to at least fix those warning/error

On Tue, May 31, 2016 at 11:43:56AM +0300, Mika Westerberg wrote: > 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

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 power_resources_Dx directories under /sys/bus/pci/devices/0000:00:1c.4/firmware_node?

These patch update Windows generation ID support on ACPI. First patch mainly update to new specifications while second one introduce again the device in ACPI table. Frediano Ziglio (2): genid: Update Windows generation ID genid: Introduce again Windows generation ID device docs/misc/xenstore-paths.markdown | 6 ++++ tools/firmware/hvmloader/acpi/build.c | 49

tools/firmware: remove "_PS0/3" Method Do not expose the ACPI power management "_PS0/3" Method to guest firmware. According to section 3.4 of the APCI specification 4.0, PCI device control the device power through its own specification but not through APCI. Qemu pushes "_PS0/3" to guest will cause a mess between ACPI PM and PCI PM as a result of incorrect ACPI table

Hi Pierre, Em qui, 19 de mai de 2016 às 06:49, Pierre Moreau <pierre.morrow at free.fr> escreveu: > Hello Marcos, > > I sent a serie a year ago to fix some of the ACPI handling in Nouveau and > add > runtime pm support for laptops with an Apple GMUX (see [0], and especially > [1] > and [2]). I was told that a more generic work for the runtime pm was in the > work,