> -----Original Message----- > From: Alex Hung [mailto:alex.hung@xxxxxxxxxxxxx] > Sent: Wednesday, February 7, 2018 2:39 PM > To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx> > Cc: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>; Dmitry Torokhov > <dmitry.torokhov@xxxxxxxxx>; Jean Delvare <jdelvare@xxxxxxx>; Rafael J. > Wysocki <rjw@xxxxxxxxxxxxx>; Len Brown <lenb@xxxxxxxxxx>; > gregkh@xxxxxxxxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; > mika.westerberg@xxxxxxxxxxxxxxx; Florian Fainelli <f.fainelli@xxxxxxxxx>; > kishon@xxxxxx; sayli karnik <karniksayli1995@xxxxxxxxx>; Linux ACPI Mailing List > <linux-acpi@xxxxxxxxxxxxxxx> > Subject: Re: [PATCH 2/2] ACPI / osi: add DMI quirk for Dell systems > > 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. Actually for Dell they're guaranteed to always be unique and will never repeat on another platform. > > 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 > > > > ��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
