Nouveau - Oct 2016 - 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 +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 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, 0x0000)

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,

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 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, 0x0000)
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

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 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, 0x0000)
> 
> 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

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 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, 0x0000)
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 ", 0x00003000)
{
    Scope (\)
    {
        Name (_PR3, Package (0x01) { NVP3 })
    }
    PowerResource (NVP3, 0x00, 0x0000) {}
}
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