[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADnq5_Oo4CMSx3Bi-41xXDCYKB9RRX33Gke9UyvAGZq1i+VOLA@mail.gmail.com>
Date: Thu, 15 Aug 2019 10:59:09 -0400
From: Alex Deucher <alexdeucher@...il.com>
To: Karol Herbst <kherbst@...hat.com>
Cc: Mario.Limonciello@...l.com,
nouveau <nouveau@...ts.freedesktop.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Linux ACPI Mailing List <linux-acpi@...r.kernel.org>,
Alex Hung <alex.hung@...onical.com>,
Ben Skeggs <bskeggs@...hat.com>,
David Airlie <airlied@...hat.com>
Subject: Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to
enable dGPU direct output"
On Thu, Aug 15, 2019 at 10:37 AM Alex Deucher <alexdeucher@...il.com> wrote:
>
> On Thu, Aug 15, 2019 at 10:25 AM Karol Herbst <kherbst@...hat.com> wrote:
> >
> > On Thu, Aug 15, 2019 at 4:20 PM <Mario.Limonciello@...l.com> wrote:
> > >
> > > > > There are definitely going to be regressions on machines in the field with the
> > > > > in tree drivers by reverting this. I think we should have an answer for all of
> > > > those
> > > > > before this revert is accepted.
> > > > >
> > > > > Regarding systems with Intel+NVIDIA, we'll have to work with partners to
> > > > collect
> > > > > some information on the impact of reverting this.
> > > > >
> > > > > When this is used on a system with Intel+AMD the ASL configures AMD GPU to
> > > > use
> > > > > "Hybrid Graphics" when on Windows and "Power Express" and "Switchable
> > > > Graphics"
> > > > > when on Linux.
> > > >
> > > > and what's exactly the difference between those? And what's the actual
> > > > issue here?
> > >
> > > DP/HDMI is not detected unless plugged in at bootup. It's due to missing HPD
> > > events.
> > >
> >
> > afaik Lyude was working on fixing all that, at least for some drivers.
> > If there is something wrong, we still should fix the drivers, not
> > adding ACPI workarounds.
> >
> > Alex: do you know if there are remaining issues regarding that with amdgpu?
>
> There was an issue with hpd events not making it to the audio side
> when things were powered down that was fixed with this patch set:
> https://patchwork.freedesktop.org/patch/316793/
> Those patches depended on a bunch of alsa changes as well which may
> have not been available in the distro used for a particular OEM
> program.
>
> >
> > > >
> > > > We already have the PRIME offloading in place and if that's not
> > > > enough, we should work on extending it, not adding some ACPI based
> > > > workarounds, because that's exactly how that looks like.
> > > >
> > > > Also, was this discussed with anybody involved in the drm subsystem?
> > > >
> > > > >
> > > > > I feel we need a knob and/or DMI detection to affect the changes that the ASL
> > > > > normally performs.
> > > >
> > > > Why do we have to do that on a firmware level at all?
> > >
> > > Folks from AMD Graphics team recommended this approach. From their perspective
> > > it's not a workaround. They view this as a different architecture for AMD graphics driver on
> > > Windows and AMD graphics w/ amdgpu driver. They have different ASL paths used for
> > > each.
> >
> > @alex: is this true?
>
> I'm not familiar with this patches in particular, but I know we've
> done things with OEM programs to support Linux on platforms where
> Linux support is lacking for in new features for the target distros.
> E.g., when the first hybrid graphics laptops were coming out, Linux
> didn't support it too well or at all depending on the timing, so the
> bios exposed power express which was working well at the time if the
> OS told ACPI it was Linux.
FWIW, windows does something similar. I don't think windows 7
supports hybrid graphics either so if the OS tells ACPI it's windows
7, it gets power express instead of hybrid graphics as well. At least
on laptops that support windows 7 in the first place.
Alex
>
> Alex
Powered by blists - more mailing lists