On Mon, Jan 02, 2017 at 02:10:19PM +0200, Mika Westerberg wrote: > I've checked the acpidump of this machine and it does not seem to be a > traditional Optimus machine. At least this one is missing the magic _DSM > which is used to gather capabilities of the graphics device. > > However, it does have _PR3 and it is attached to the device > (_SB.PCI0.PEG) itself, not the root port. > > One thing you could try in addition to Lucas' patches is just to prevent > D3cold from the device by doing this: > > # echo 0 > /sys/bus/pci/devices/0000:01:00.0/d3cold_allowed Following messages look like the device fails to resume properly from D3cold: Dec 30 08:45:06 klaptop kernel: [ 27.775949] nouveau 0000:01:00.0: rpm_resume Dec 30 08:45:06 klaptop kernel: [ 27.776316] nouveau 0000:01:00.0: Refused to change power state, currently in D3 Dec 30 08:45:06 klaptop kernel: [ 27.836049] nouveau 0000:01:00.0: Refused to change power state, currently in D3 Dec 30 08:45:06 klaptop kernel: [ 27.836053] nouveau 0000:01:00.0: Refused to change power state, currently in D3 This happens if we read back 0xffffffff from PM register. Dec 30 08:45:06 klaptop kernel: [ 27.836055] nouveau 0000:01:00.0: DRM: resuming kernel object tree... Dec 30 08:45:06 klaptop kernel: [ 27.836127] nouveau 0000:01:00.0: pci: failed to adjust cap speed Dec 30 08:45:06 klaptop kernel: [ 27.836131] nouveau 0000:01:00.0: pci: failed to adjust lnkctl speed Preventing D3cold should at least show some difference on resume path. -- 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
