On Mon, Jul 20, 2020 at 3:19 AM Alex Hung <alex.hung@xxxxxxxxxxxxx> wrote:
>
> On 2020-07-19 1:50 p.m., Karol Herbst wrote:
> > On Fri, Jul 17, 2020 at 9:52 PM Alex Hung <alex.hung@xxxxxxxxxxxxx> wrote:
> >>
> >> On 2020-07-17 1:05 p.m., Karol Herbst wrote:
> >>> It's hard to figure out what systems are actually affected and right now I
> >>> don't see a good way of removing those...
> >>>
> >>> But I'd like to see thos getting removed and drivers fixed instead (which
> >>> happened at least for nouveau).
> >>>
> >>> And as mentioned before, I prefer people working on fixing issues instead
> >>> of spending time to add firmware level workarounds which are hard to know
> >>> to which systems they apply to, hard to remove and basically a big huge
> >>> pain to work with.> In the end I have no idea how to even figure out what systems are affected
> >>> and which not by this, so I have no idea how to even verify we can safely
> >>> remove this (which just means those are impossible to remove unless we risk
> >>> breaking systems, which again makes those supper annoying to deal with).
> >>>
> >>> Also from the comments it's hard to get what those bits really do. Are they
> >>> just preventing runtime pm or do the devices are powered down when booting?
> >>> I am sure it's the former, still...
> >>>
> >>> Please, don't do this again.
> >>>
> >>> For now, those workaround prevent power savings on systems those workaround
> >>> applies to, which might be any so those should get removed asap and if
> >>> new issues arrise removing those please do a proper bug report and we can
> >>> look into it and come up with a proper fix (and keep this patch out until
> >>> we resolve all of those).
> >>>
> >>> Signed-off-by: Karol Herbst <kherbst@xxxxxxxxxx>
> >>> CC: Alex Hung <alex.hung@xxxxxxxxxxxxx>
> >>> CC: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>
> >>> CC: Len Brown <lenb@xxxxxxxxxx>
> >>> CC: Lyude Paul <lyude@xxxxxxxxxx>
> >>> CC: linux-kernel@xxxxxxxxxxxxxxx
> >>> CC: dri-devel@xxxxxxxxxxxxxxxxxxxxx
> >>> CC: nouveau@xxxxxxxxxxxxxxxxxxxxx
> >>> ---
> >>> drivers/acpi/osi.c | 24 ------------------------
> >>> 1 file changed, 24 deletions(-)
> >>>
> >>> diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c
> >>> index 9f68538091384..d4405e1ca9b97 100644
> >>> --- a/drivers/acpi/osi.c
> >>> +++ b/drivers/acpi/osi.c
> >>> @@ -44,30 +44,6 @@ osi_setup_entries[OSI_STRING_ENTRIES_MAX] __initdata = {
> >>> {"Processor Device", true},
> >>> {"3.0 _SCP Extensions", true},
> >>> {"Processor Aggregator Device", true},
> >>> - /*
> >>> - * Linux-Dell-Video is used by BIOS to disable RTD3 for NVidia graphics
> >>> - * cards as RTD3 is not supported by drivers now. Systems with NVidia
> >>> - * cards will hang without RTD3 disabled.
> >>> - *
> >>> - * Once NVidia drivers officially support RTD3, this _OSI strings can
> >>> - * be removed if both new and old graphics cards are supported.
> >>> - */
> >>> - {"Linux-Dell-Video", true},
> >>> - /*
> >>> - * Linux-Lenovo-NV-HDMI-Audio is used by BIOS to power on NVidia's HDMI
> >>> - * audio device which is turned off for power-saving in Windows OS.
> >>> - * This power management feature observed on some Lenovo Thinkpad
> >>> - * systems which will not be able to output audio via HDMI without
> >>> - * a BIOS workaround.
> >>> - */
> >>> - {"Linux-Lenovo-NV-HDMI-Audio", true},
> >>> - /*
> >>> - * Linux-HPI-Hybrid-Graphics is used by BIOS to enable dGPU to
> >>> - * output video directly to external monitors on HP Inc. mobile
> >>> - * workstations as Nvidia and AMD VGA drivers provide limited
> >>> - * hybrid graphics supports.
> >>> - */
> >>> - {"Linux-HPI-Hybrid-Graphics", true},
> >>> };
> >>>
> >>> static u32 acpi_osi_handler(acpi_string interface, u32 supported)
> >>>
> >>
> >> The changes were discussed and tested a while ago, and no crashes were
> >> observed. Thanks for solving PM issues in nouveau.
> >>
> >> Acked-by: Alex Hung <alex.hung@xxxxxxxxxxxxx>
> >>
> >
> > By any chance, do you have a list of systems implementing those workarounds?
> >
>
> I don't keep a list but the workaround, in theory, should only apply to
> the systems with the specific nvidia hardware.
>
> I reminded OEMs and ODMs that these _OSI strings were temporary
> solutions, and highlighted we were going to remove them after our
> discussion last year. If they were paying attentions recent systems
> shouldn't have these _OSI strings.
>
Right.. but I am actually wondering because I never saw those strings
in the wild or not on the Dell and Lenovo systems I was testing on. So
I think we might want to ask the vendors themselves and verify on
those systems.
> --
> Cheers,
> Alex Hung
>
