On Tue, Jan 03, 2017 at 06:05:57PM -0600, Bjorn Helgaas wrote: > I don't *want* to apply the revert. It's on my for-linus branch as a > worst-case scenario change if we can't figure out a better fix. > > The patch below is preferable, but I'd rather not take even it, > because it takes away functionality and forces people to use a boot > parameter to restore it. I expect that somebody will figure out how > to fix the regression Kilian found and also keep the new functionality > (without requiring boot parameters) before v4.10. The issue is constrained to hybrid graphics laptops with Nvidia discrete GPU using nouveau. Hence it needs to be fixed in nouveau, not in the PCI core. (AFAIUI, laptops with AMD discrete GPU are not affected as it is known when and how to call an ACPI method versus using PR3.) (Neither are laptops using the Nvidia proprietary driver as it doesn't runtime suspend the card. But battery life will be terrible then.) We're at rc2 so the time frame for coming up with a fix is probably 4 weeks. Peter and others have tried for months to reverse-engineer how to handle runtime PM on newer Nvidia cards. It seems likely that we'll not find the ultimate solution to the problem within 4 weeks. The way it is now, i.e. defaulting to PR3 when available, regresses certain laptops such as Kilian's. If on the other hand we default to DSM when available, we'll regress certain other laptops, as Peter has pointed out. Whitelisting or blacklisting laptops doesn't seem a good approach either, ideally we'd want to use PR3 as Windows does. As said, the only short-term solution I see is to add an "optimus" module_param to nouveau to allow users to select which method to use. So in Kilian's case an additional command line parameter would be necessary to fix the issue. Does anyone see a better solution or can we agree on this one? If so I can come up with a patch. This could go in via Dave Airlie's tree. Thanks, 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
