On Tue, Feb 6, 2018 at 8:24 AM, <Mario.Limonciello@xxxxxxxx> wrote: >> -----Original Message----- >> From: Andy Shevchenko [mailto:andriy.shevchenko@xxxxxxxxxxxxxxx] >> Sent: Tuesday, February 6, 2018 7:46 AM >> To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx>; >> dmitry.torokhov@xxxxxxxxx >> Cc: jdelvare@xxxxxxx; alex.hung@xxxxxxxxxxxxx; rjw@xxxxxxxxxxxxx; >> lenb@xxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; >> mika.westerberg@xxxxxxxxxxxxxxx; f.fainelli@xxxxxxxxx; kishon@xxxxxx; >> karniksayli1995@xxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx >> Subject: Re: [PATCH 2/2] ACPI / osi: add DMI quirk for Dell systems >> >> 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? > > The usage of OSI here is: do you support the feature "Linux-Dell-Video" > to Linux kernel. If Linux kernel responds yes then firmware will turn off > RTD3 functionality for the discrete GPU. > >> >> > > > 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 >> >> > > 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. > > I don't disagree it's a workaround for a driver deficiency. > >> >> > 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). Workarounds are never preferred, but they are needed from time to time. There are other alternatives such as 1) _REV & acpi_rev_dmi_table, 2) windows & linux osi strings & acpi_osi_dmi_table. However, Linux-OEM-my_interface_name strings + OEM strings in DMI are better choices for couple reasons: 1. Linux-OEM-my_interface_name are more informative than current available mechanisms. 2. Linux-OEM-my_interface_name is defined in Documentation/acpi/osi.txt as below: _OSI("Linux-OEM-my_interface_name") where 'OEM' is needed if this is an OEM-specific hook, and 'my_interface_name' describes the hook, which could be a quirk, a bug, or a bug-fix. 3. DMI OEM strings used in this patch are System IDs and they are unlikely to repeat for years. System IDs are also more precise than Product names. 4. The workaround is controlled and limited to specific systems as Mario commented previously. > > I'm not going to be able to force NVIDIA to fix the blob or to give what's > necessary to enable Nouvaeu for this function. What we can do is prevent > someone's system from hanging because of this situation. and we never stopped poking NVIDIA to fix drivers and will never stop trying. If NVIDIA fixes RTD3, a clean-up patch will be submit to remove the quirks. > >> >> 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. > > I know that OSI has been abused in the past, but that's exactly why this > has been implemented as seen in this patch series. > > It's done specifically to fit within exactly what the Linux kernel ideally > looks for in a custom OSI feature string. > > * It has an OS Prefix (Linux-) > * It's an OEM specific string (-Dell-) > * It's a feature specific string (-Video) > *It's specific to a single platform (not a blanket match to Dell Inc) > *It only modifies one feature in ASL > > -- 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
