(removing nouveau list since it is an ACPI core issue)

On Sat, Oct 29, 2016 at 12:49:22AM +0000, Zheng, Lv wrote:
> Hi,
> 
> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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

It seems that acpi_gbl_parse_table_as_term_list is a new flag in
v4.9-rc1. Changing the flag to TRUE in in include/acpi/acpixf.h has no
effect other than:

    ACPI: Executed 2 blocks of module-level executable AML code

changing into:


    ACPI: 2 ACPI AML tables successfully acquired and loaded

That was tested using v4.9-rc2-40-g9fe68ca + debug patch from previous
mail, but with a slightly modified QEMU command (to allow the device to
become visible in Windows Device Manager) and slightly modified SSDT1:

    qemu-system-x86_64 -M pc,accel=kvm -m 2G -acpitable file=ssdt1.aml \
        -net none -device pci-bridge,addr=12.0,chassis_nr=2,id=head.2 \
        -device isa-debugcon,iobase=0x402,chardev=dbug \
        -chardev file,id=dbug,path=/dev/stdout ...

With this command and Windows 10 (-drive file=w10.qcow2), I can see that
the power resource methods are invoked (stdout | grep PR_TEST):

    PR_TEST: NVP3._ON
    PR_TEST: NVP2._OFF
    PR_TEST: _PS0
    PR_TEST: _S0W
    PR_TEST: NVP3._ON
    PR_TEST: _PS0

Using the above test setup with Linux (-kernel arch/x86/boot/bzImage):

    PR_TEST: _S0W

If you think that the default runtime PM state affects this, note that
the dmesg also shows:

    ACPI: \_SB_.PCI0.S90_: Adding power resources for device:14? 0
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl