On Sat, Jan 07, 2017 at 01:36:35PM +0100, Peter Wu wrote: > On Sat, Jan 07, 2017 at 01:19:59PM +0100, Lukas Wunner wrote: > > On Sat, Jan 07, 2017 at 12:35:10PM +0100, Peter Wu wrote: > > > On Thu, Jan 05, 2017 at 03:42:20PM +0100, Lukas Wunner wrote: > > > > On Wed, Jan 04, 2017 at 10:09:54PM +0100, Peter Wu wrote: > > > > > [ Help/ideas are welcome, I suspect that these failures to restore > > > > > power on laptops designed for Win8+ all have the same cause, > > > > > related to some unknown interaction between ACPI and PCI. > > > > > Some links: > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=190861 > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=156341 ] > > > > > > > > Looking at Kilian's acpidump again I notice that the methods to power > > > > the GPU on or off (GPON / GPOF) are called from two places: > > > > > > > > - From the _PS0 and _PS3 methods of the GPU and > > > > - from the _PR3 power resource of the root port above the GPU. > > > > > > > > In the former case they're called for pre Windows 2013 or if VDAD is > > > > true. In the latter case they're called unconditionally but GPOF > > > > becomes a no-op in the pre Windows 2013 case. > > > > > > > > This means that GPOF would be executed *twice* on Windows 2013+ if > > > > VDAD is true. I could imagine this to cause issues. > > > > > > There is a flag "DGOS" which is set when PGON/PGOF are called, so > > > multiple invocations should not matter for the powerdown/up sequence. > > > There are some SMI calls though that might have side-effects though. > > > > The PGON method becomes a no-op if DGOS is true. But the PGOF method > > doesn't check DGOS. > > You are right, GPON does not check that. Hopefully "VDAD" is 0 then when > _PS3 is called, otherwise it might invoke PGOF multiple times (though > NVP3._OFF and through _PS3). Kilian responded off-list that the byte containing the VDAD bit has value 0x01. So one of the 8 bits is set but I'm not sure if that's the VDAD bit. In the DSDT the bit is defined thus: OperationRegion (MNVS, SystemMemory, 0x7CE7D018, 0x1000) Field (MNVS, DWordAcc, NoLock, Preserve) { Offset (0xEE2), TPPP, 8, TPPC, 8, WKRS, 8, FNWK, 8, USBC, 8, ODDF, 8, VDAD, 1, <------- Offset (0xEE9), Does this mean that VDAD is the most significant or least significant bit? The value read on Kilian's laptop has the least significant bit set. In any case, he cleared that bit but locking the screen still breaks keyboard/mouse input. I'm running out of ideas, the only viable solution I can see is to add a model-specific quirk which causes nouveau to fall back to DSM. :-( Best regards, Lukas -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
