On Tue, Feb 6, 2018 at 2:45 PM, Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > On Tue, 2018-02-06 at 00:45 +0000, Mario.Limonciello@xxxxxxxx wrote: > >> > > > Playing with OSI string is a bad idea. I wouldn't do anything >> > > > while >> > > > Rafael, or even Len can confirm that is the right thing to do. >> > > > >> > > > For me, AFAIK we need to be bug-to-bug compatible with Windows >> > > > (at least >> > > > on ACPICA side), so, what Windows exactly does on such laptops? >> > > > >> > > >> > > The issue that's being worked around isn't an ACPICA interpreter >> > > issue, but it's >> > > a graphics device configuration issue. > > Then clearly nothing to do with OSI strings here, right? > >> > > Windows expects to use RTD3 on the NVIDIA GPU but Linux drivers >> > > don't. It leads to system hangs on the Linux side. >> > >> > Can we adjust Linux drivers to do the right thing? > > +100 IMO you should only say so if *you* are willing to do the work and have all of the requisite means for that. >> > Or is it regarding >> > the binary NVIDIA blob? > > nVidia vs. Linux again? :-) > >> >> Neither Nouveau nor the NVIDIA blob have support for RTD3. >> >> Last I heard it's waiting on NVIDIA releasing something Nouveau >> needs. So.. Eventually? For now it's better to not hang though. > > Hmm... While you are talking sense, the patch itself looks like an ugly > hack. > >> That's part of why we wanted to enable this via a transient OSI >> string, >> to let this be removed by Linux whenever the driver does grow support. > > So, means "never" then? (Assume a bit of irony here) > > I don't know how it feels for maintainers, for me it's quite unlikely to > go (at least in this shape). > > I'm sorry I can't be much constructive here, I heard Len once about OSI > huge abuse by almost every party. I would rather let him speak on the > matter. One thing is the merit and another thing is the patch itself. On the merit side, with all due respect, this isn't about fixing the drivers in question. They aren't broken. RTD3 (or generally runtime PM) support in Linux has been regarded as optional so far and it is not even realistic to change this policy ATM. The lack of it is a matter of energy-efficiency, but not a matter of basic correctness, as far as Linux is concerned. If some platform firmware doesn't work correctly with an OS that doesn't do RTD3 all over and crashes when Linux runs on it for this reason, than that platform is simply not compatible with Linux as it stands. Granted, we can say "Too bad, Linux is not going to run on this platform any time soon" (but frankly I don't see how that would benefit anyone) or we can make the kernel give a little hint to the platform firmware to make it behave in a Linux-compatible way. So if we can agree that this has merit (and I personally think that it does), let's try to make the implementation cleaner, if possible. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
