Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
Hi, Mika
> From: Mika Westerberg [mailto:mika.westerb...@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 +, 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 tested this patch now on top of 4.8.4 (mainline fails 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.
>
> > 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, 0x00, 0x)
Looks wrong order to me.
However, _PR3 is a package, for AML opcode that contains PkgLength grammar
primitive, forward reference may be OK (for example Method).
DefPackage := PackageOp PkgLength NumElements PackageElementList
DefMethod := MethodOp PkgLength NameString MethodFlags TermList
As when it is encountered, AML interpreter may only saves entire packaged
object.
I need to test behaviors around Package with qemu but I don't have environment
now.
Can you help to give it a try?
By adding customize an ssdt with the above code putting under root scope,
DefinitionBlock ("ssdt-package.aml", "SSDT", 2, "INTEL ", "PACKAGE ",
0x3000)
{
Scope (\)
{
Name (_PR3, Package (0x01) { NVP3 })
}
PowerResource (NVP3, 0x00, 0x) {}
}
Running Windows images on qemu with this ssdt appended "-acpitable
file=ssdt-package.aml".
To see if blue screen can be resulted.
Thanks
Lv
>
> That and the fact that they come from an SSDT instead of DSDT may cause
> this. However, I'm not expert in ACPICA so adding Bob and Lv if they
> have ideas.
>
> Bob, Lv, the bug in question is:
> https://bugs.freedesktop.org/show_bug.cgi?id=98398
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
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.westerb...@linux.intel.com>: > On Thu, Oct 27, 2016 at 09:15:19AM +, 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/:00:1c.4/firmware_node? > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
Op do 27 okt. 2016 om 11:59 schreef Mika Westerberg < mika.westerb...@linux.intel.com>: > On Thu, Oct 27, 2016 at 09:42:28AM +, 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. > > diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c > index fcd4ce6f78d5..af9c3e15dd74 100644 > --- a/drivers/acpi/power.c > +++ b/drivers/acpi/power.c > @@ -444,6 +444,9 @@ void acpi_power_add_remove_device(struct acpi_device > *adev, bool add) > if (!adev->power.flags.power_resources) > return; > > + acpi_handle_info(adev->handle, "Adding power resources for %s\n", > +dev_name(&adev->dev)); > + > for (state = ACPI_STATE_D0; state <= ACPI_STATE_D3_HOT; state++) > acpi_power_expose_hide(adev, > > &adev->power.states[state].resources, > Thank you for the patch, I have applied it to the kernel sources but I'm not sure how to proceed from now on. Should I compile the whole kernel or can I just build an out-of-tree acpi module? ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
Hi, > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Mika > Westerberg > Subject: Re: Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU > via Power Resources > > On Fri, Oct 28, 2016 at 02:30:41PM +0200, Peter Wu wrote: > > It was correctly applied. I did some testing with QEMU, it seems that > > the \_OSI check is problematic. Removing it makes things work again. > > I hope Bob and Lv can answer why _OSI fails. > > In the meantime I think we should check flags.power_resources in nouveau > driver (in addition to _PR3) so that it falls back to _DSM if there are > no power resources (or if we failed to evaluate them for some reason). IMO, the problem wasn't _OSI, the problem was "If". "If" is module level here. So execution order of it in current Linux upstream may be different from Windows. You can try to modify acpi_gbl_parse_table_as_term_list to TRUE. To see if this can be solved. Thanks and best regards Lv > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [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 :
> 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 +,
> bugzilla-dae...@freedesktop.org wrote:
> > > > https://bugs.freedesktop.org/show_bug.cgi?id=98398
> > > >
> > > > --- Comment #11 from Peter Wu ---
> > > > 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/:1c.4/firmware_node/ does not have
> power_resources_D0
> > > > devices (which I do have on my own laptop for :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, 0x)
> > > > {
> > > > 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/:00:1c.4/firmware_node/path
> contain?
>
> The value is as expected, \_SB.PCI0.RP05:
>
> /sys/bus/pci/devices/:00:1c.4/firmware_node/path:\_SB_.PCI0.RP05
> /sys/bus/pci/devices/:00:1c.4/firmware_node/power_state:D3hot
> --
> Kind regards,
> Peter Wu
> https://lekensteyn.nl
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
Op do 27 okt. 2016 om 12:12 schreef Mika Westerberg < mika.westerb...@linux.intel.com>: > On Thu, Oct 27, 2016 at 10:07:45AM +, Rick Kerkhof wrote: > >Thank you for the patch, I have applied it to the kernel sources but > >I'm not sure how to proceed from now on. Should I compile the whole > >kernel or can I just build an out-of-tree acpi module? > > You need to build the whole kernel, install and reboot. > Thanks, it's compiling now, I'll take it for a test drive once it is done and installed and provide you with a dmesg log. ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
On Sat, Oct 29, 2016 at 12:42:34AM +, Zheng, Lv wrote:
> Hi, Mika
>
> > From: Mika Westerberg [mailto:mika.westerb...@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 +, 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 tested this patch now on top of 4.8.4 (mainline fails 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.
> >
> > > 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, 0x00, 0x)
>
> Looks wrong order to me.
>
> However, _PR3 is a package, for AML opcode that contains PkgLength grammar
> primitive, forward reference may be OK (for example Method).
> DefPackage := PackageOp PkgLength NumElements PackageElementList
> DefMethod := MethodOp PkgLength NameString MethodFlags TermList
> As when it is encountered, AML interpreter may only saves entire packaged
> object.
>
> I need to test behaviors around Package with qemu but I don't have
> environment now.
> Can you help to give it a try?
> By adding customize an ssdt with the above code putting under root scope,
> DefinitionBlock ("ssdt-package.aml", "SSDT", 2, "INTEL ", "PACKAGE ",
> 0x3000)
> {
> Scope (\)
> {
> Name (_PR3, Package (0x01) { NVP3 })
> }
> PowerResource (NVP3, 0x00, 0x) {}
> }
> Running Windows images on qemu with this ssdt appended "-acpitable
> file=ssdt-package.aml".
> To see if blue screen can be resulted.
>
> Thanks
> Lv
Testing this code with Windows 10 gives a BSOD, changing the order of
the PowerResource and Scope does not make a difference. If I take my
previous SSDT and change the ordering of NVP3 definition vs _PR3 use,
there is no change.
Kind regards,
Peter
> >
> > That and the fact that they come from an SSDT instead of DSDT may cause
> > this. However, I'm not expert in ACPICA so adding Bob and Lv if they
> > have ideas.
> >
> > Bob, Lv, the bug in question is:
> > https://bugs.freedesktop.org/show_bug.cgi?id=98398
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
On Fri, Oct 28, 2016 at 02:30:41PM +0200, Peter Wu wrote: > It was correctly applied. I did some testing with QEMU, it seems that > the \_OSI check is problematic. Removing it makes things work again. I hope Bob and Lv can answer why _OSI fails. In the meantime I think we should check flags.power_resources in nouveau driver (in addition to _PR3) so that it falls back to _DSM if there are no power resources (or if we failed to evaluate them for some reason). ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
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 27, 2016 at 09:42:28AM +, 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 tested this patch now on top of 4.8.4 (mainline fails 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.
>
> 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 that
the \_OSI check is problematic. Removing it makes things work again.
To reproduce:
1. Build the kernel with the attached config (minconfig with ACPI and
printk stuff enabled) and debug patch.
2. Compile the attached ASL file to AML (iasl ssdt1.dsl).
(You can remove the If(\_OSI(...)) check to see the difference.
3. Boot QEMU and watch the dmesg for the debug prints.
Alternatively, just boot QEMU with this SSDT and check against any Linux
distro and inspect /sys/bus/pci/devices/:00:01.3/firmware_node/.
Tested with Linux v4.8.5, QEMU 2.7.0, iasl 20160831. The SSDT structure
is adapted from Ricks SSDT1 file and modified for the 00:01.3 device in
QEMU. The QEMU command I used was:
qemu-system-x86_64 -m 1G -M pc,accel=kvm -nographic \
-kernel arch/x86/boot/bzImage -serial file:/dev/stdout \
-acpitable file=ssdt1.aml \
-append 'console=ttyS0 acpi.aml_debug_output=1'
--
Kind regards,
Peter Wu
https://lekensteyn.nl
/*
* Intel ACPI Component Architecture
* AML/ASL+ Disassembler version 20160831-64
* Copyright (c) 2000 - 2016 Intel Corporation
*
* Disassembling to symbolic ASL+ operators
*
* Disassembly of ssdt1.dat, Wed Oct 26 21:43:27 2016
*
* Original Table Header:
* Signature"SSDT"
* Length 0x2CA9 (11433)
* Revision 0x01
* Checksum 0x8F
* OEM ID "ACRSYS"
* OEM Table ID "ACRPRDCT"
* OEM Revision 0x1000 (4096)
* Compiler ID "1025"
* Compiler Version 0x0004 (262144)
*/
DefinitionBlock ("", "SSDT", 1, "ACRSYS", "ACRPRDCT", 0x1000)
{
External (\_SB.PCI0.PX13, DeviceObj)
If (\_OSI ("Windows 2013"))
{
Scope (\_SB.PCI0.PX13)
{
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 (_S0W, 0, NotSerialized) // _S0W: S0 Device Wake State
{
Debug = "_S0W"
// Return(3)
Return(4)
}
Method (_DSW, 3, NotSerialized) // _DSW: Device Sleep Wake
{
}
Method (_PS0, 0, NotSerialized) // _PS0: Power State 0
{
Debug = "_PS0"
}
Method (_PS3, 0, NotSerialized) // _PS3: Power State 3
{
Debug = "_PS3"
}
}
PowerResource (NVP3, 0x00, 0x)
{
Name (_STA, One) // _STA: Status
Method (_ON, 0, NotSerialized) // _ON_: Power On
{
Debug = "NVP3._ON"
_STA = One
}
Method (_OFF, 0, NotSerialized) // _OFF: Power Off
{
Debug = "NVP3._OFF"
_STA = Zero
}
}
PowerResource (NVP2, 0x00, 0x)
{
Name (_STA, One) // _STA: Status
Method (_ON, 0, NotSerialized) // _ON_: Power On
{
Debug = "NVP2._ON"
_STA = One
}
Method (_OFF, 0, NotSerialized) // _OFF: Power Off
{
Debug = "NVP2._OFF"
_STA = One
}
}
}
}
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.8.5 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X
Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
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 +, 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 tested this patch now on top of 4.8.4 (mainline fails 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. We should probably add a debug print before checking flags.power_resources just to be sure the patch is correctly applied. ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
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 +, 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 tested this patch now on top of 4.8.4 (mainline fails 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 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, 0x00, 0x)
>
> That and the fact that they come from an SSDT instead of DSDT may cause
> this. However, I'm not expert in ACPICA so adding Bob and Lv if they
> have ideas.
>
> Bob, Lv, the bug in question is:
> https://bugs.freedesktop.org/show_bug.cgi?id=98398
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 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 +, 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 tested this patch now on top of 4.8.4 (mainline fails 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.
> 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, 0x00, 0x)
That and the fact that they come from an SSDT instead of DSDT may cause
this. However, I'm not expert in ACPICA so adding Bob and Lv if they
have ideas.
Bob, Lv, the bug in question is:
https://bugs.freedesktop.org/show_bug.cgi?id=98398
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
On Thu, Oct 27, 2016 at 12:55:08PM +0300, Mika Westerberg wrote:
> On Thu, Oct 27, 2016 at 09:42:28AM +, 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 tested this patch now on top of 4.8.4 (mainline fails 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.
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, 0x00, 0x)
Kind regards,
Peter
> diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
> index fcd4ce6f78d5..af9c3e15dd74 100644
> --- a/drivers/acpi/power.c
> +++ b/drivers/acpi/power.c
> @@ -444,6 +444,9 @@ void acpi_power_add_remove_device(struct acpi_device
> *adev, bool add)
> if (!adev->power.flags.power_resources)
> return;
>
> + acpi_handle_info(adev->handle, "Adding power resources for %s\n",
> + dev_name(&adev->dev));
> +
> for (state = ACPI_STATE_D0; state <= ACPI_STATE_D3_HOT; state++)
> acpi_power_expose_hide(adev,
> &adev->power.states[state].resources,
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
On Thu, Oct 27, 2016 at 10:07:45AM +, Rick Kerkhof wrote: >Thank you for the patch, I have applied it to the kernel sources but >I'm not sure how to proceed from now on. Should I compile the whole >kernel or can I just build an out-of-tree acpi module? You need to build the whole kernel, install and reboot. ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
On Thu, Oct 27, 2016 at 09:42:28AM +, 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. diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c index fcd4ce6f78d5..af9c3e15dd74 100644 --- a/drivers/acpi/power.c +++ b/drivers/acpi/power.c @@ -444,6 +444,9 @@ void acpi_power_add_remove_device(struct acpi_device *adev, bool add) if (!adev->power.flags.power_resources) return; + acpi_handle_info(adev->handle, "Adding power resources for %s\n", +dev_name(&adev->dev)); + for (state = ACPI_STATE_D0; state <= ACPI_STATE_D3_HOT; state++) acpi_power_expose_hide(adev, &adev->power.states[state].resources, ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
On Thu, Oct 27, 2016 at 12:30:11PM +0300, Mika Westerberg wrote: > On Thu, Oct 27, 2016 at 09:15:19AM +, 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/:00:1c.4/firmware_node? Correct, this is what Rick sent me yesterday for ls -lR /sys/bus/pci/devices/:00:1c.4/firmware_node/ .: totaal 0 -r--r--r-- 1 root root 4096 26 okt 22:10 adr drwxr-xr-x 3 root root0 26 okt 22:12 device:32 drwxr-xr-x 12 root root0 26 okt 22:12 LNXVIDEO:00 -r--r--r-- 1 root root 4096 26 okt 22:10 path lrwxrwxrwx 1 root root0 26 okt 22:10 physical_node -> ../../../../pci:00/:00:1c.4 drwxr-xr-x 2 root root0 26 okt 22:12 power -r--r--r-- 1 root root 4096 26 okt 22:10 power_state lrwxrwxrwx 1 root root0 26 okt 22:10 subsystem -> ../../../../../bus/acpi -rw-r--r-- 1 root root 4096 26 okt 22:10 uevent ./device:32: totaal 0 -r--r--r-- 1 root root 4096 26 okt 22:12 adr -r--r--r-- 1 root root 4096 26 okt 22:12 path drwxr-xr-x 2 root root0 26 okt 22:31 power lrwxrwxrwx 1 root root0 26 okt 22:10 subsystem -> ../../../../../../bus/acpi -rw-r--r-- 1 root root 4096 26 okt 22:12 uevent ./device:32/power: totaal 0 -rw-r--r-- 1 root root 4096 26 okt 22:12 async -rw-r--r-- 1 root root 4096 26 okt 22:12 autosuspend_delay_ms -rw-r--r-- 1 root root 4096 26 okt 22:12 control -r--r--r-- 1 root root 4096 26 okt 22:12 runtime_active_kids -r--r--r-- 1 root root 4096 26 okt 22:12 runtime_active_time -r--r--r-- 1 root root 4096 26 okt 22:12 runtime_enabled -r--r--r-- 1 root root 4096 26 okt 22:12 runtime_status -r--r--r-- 1 root root 4096 26 okt 22:12 runtime_suspended_time -r--r--r-- 1 root root 4096 26 okt 22:12 runtime_usage ./LNXVIDEO:00: totaal 0 -r--r--r-- 1 root root 4096 26 okt 22:31 adr drwxr-xr-x 3 root root0 26 okt 22:31 device:33 drwxr-xr-x 3 root root0 26 okt 22:31 device:34 drwxr-xr-x 3 root root0 26 okt 22:31 device:35 drwxr-xr-x 3 root root0 26 okt 22:31 device:36 drwxr-xr-x 3 root root0 26 okt 22:31 device:37 drwxr-xr-x 3 root root0 26 okt 22:31 device:38 drwxr-xr-x 3 root root0 26 okt 22:31 device:39 drwxr-xr-x 3 root root0 26 okt 22:31 device:3a lrwxrwxrwx 1 root root0 26 okt 22:10 driver -> ../../../../../../bus/acpi/drivers/video -r--r--r-- 1 root root 4096 26 okt 22:31 hid drwxr-xr-x 3 root root0 26 okt 22:31 input -r--r--r-- 1 root root 4096 26 okt 22:31 modalias -r--r--r-- 1 root root 4096 26 okt 22:31 path lrwxrwxrwx 1 root root0 26 okt 22:31 physical_node -> ../../../../../pci:00/:00:1c.4/:01:00.0 drwxr-xr-x 2 root root0 26 okt 22:31 power -r--r--r-- 1 root root 4096 26 okt 22:31 power_state -r--r--r-- 1 root root 4096 26 okt 22:31 status lrwxrwxrwx 1 root root0 26 okt 22:10 subsystem -> ../../../../../../bus/acpi -rw-r--r-- 1 root root 4096 26 okt 22:31 uevent ./LNXVIDEO:00/device:33: totaal 0 -r--r--r-- 1 root root 4096 26 okt 22:31 adr -r--r--r-- 1 root root 4096 26 okt 22:31 path drwxr-xr-x 2 root root0 26 okt 22:31 power lrwxrwxrwx 1 root root0 26 okt 22:10 subsystem -> ../../../../../../../bus/acpi -rw-r--r-- 1 root root 4096 26 okt 22:31 uevent ./LNXVIDEO:00/device:33/power: totaal 0 -rw-r--r-- 1 root root 4096 26 okt 22:31 async -rw-r--r-- 1 root root 4096 26 okt 22:31 autosuspend_delay_ms -rw-r--r-- 1 root root 4096 26 okt 22:31 control -r--r--r-- 1 root root 4096 26 okt 22:31 runtime_active_kids -r--r--r-- 1 root root 4096 26 okt 22:31 runtime_active_time -r--r--r-- 1 root root 4096 26 okt 22:31 runtime_enabled -r--r--r-- 1 root root 4096 26 okt 22:31 runtime_status -r--r--r-- 1 root root 4096 26 okt 22:31 runtime_suspended_time -r--r--r-- 1 root root 4096 26 okt 22:31 runtime_usage ./LNXVIDEO:00/device:34: totaal 0 -r--r--r-- 1 root root 4096 26 okt 22:31 adr -r--r--r-- 1 root root 4096 26 okt 22:31 path drwxr-xr-x 2 root root0 26 okt 22:31 power lrwxrwxrwx 1 root root0 26 okt 22:10 subsystem -> ../../../../../../../bus/acpi -rw-r--r-- 1 root root 4096 26 okt 22:31 uevent ./LNXVIDEO:00/device:34/power: totaal 0 -rw-r--r-- 1 root root 4096 26 okt 22:31 async -rw-r--r-- 1 root root 4096 26 okt 22:31 autosuspend_delay_ms -rw-r--r-- 1 root root 4096 26 okt 22:31 control -r--r--r-- 1 root root 4096 26 okt 22:31 runtime_active_kids -r--r--r-- 1 root root 4096 26 okt 22:31 runtime_active_time -r--r--r-- 1 root root 4096 26 okt 22:31 runtime_enabled -r--r--r-- 1 root root 4096 26 okt 22:31 runtime_status -r--r--r-- 1 root root 4096 26 okt 22:31 runtime_suspended_time -r--r--r-- 1 root
Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
On Thu, Oct 27, 2016 at 09:15:19AM +, 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/:00:1c.4/firmware_node? ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [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 +, bugzilla-dae...@freedesktop.org
> > wrote:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=98398
> > >
> > > --- Comment #11 from Peter Wu ---
> > > 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/:1c.4/firmware_node/ does not have power_resources_D0
> > > devices (which I do have on my own laptop for :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, 0x)
> > > {
> > > 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/:00:1c.4/firmware_node/path
> contain?
The value is as expected, \_SB.PCI0.RP05:
/sys/bus/pci/devices/:00:1c.4/firmware_node/path:\_SB_.PCI0.RP05
/sys/bus/pci/devices/:00:1c.4/firmware_node/power_state:D3hot
--
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [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 +, bugzilla-dae...@freedesktop.org
> wrote:
> > https://bugs.freedesktop.org/show_bug.cgi?id=98398
> >
> > --- Comment #11 from Peter Wu ---
> > 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/:1c.4/firmware_node/ does not have power_resources_D0
> > devices (which I do have on my own laptop for :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, 0x)
> > {
> > 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/:00:1c.4/firmware_node/path contain?
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources
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 +, bugzilla-dae...@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=98398
>
> --- Comment #11 from Peter Wu ---
> 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/:1c.4/firmware_node/ does not have power_resources_D0
> devices (which I do have on my own laptop for :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, 0x)
> {
> 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.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
