Nouveau - Aug 2019 - [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

> -----Original Message-----
> From: linux-acpi-owner at vger.kernel.org <linux-acpi-owner at
vger.kernel.org> On
> Behalf Of Dave Airlie
> Sent: Wednesday, August 14, 2019 5:48 PM
> To: Karol Herbst
> Cc: LKML; Linux ACPI; dri-devel; nouveau; Rafael J . Wysocki; Alex Hung;
Ben
> Skeggs; Dave Airlie
> Subject: Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI
string to
> enable dGPU direct output"
> 
> On Thu, 15 Aug 2019 at 07:31, Karol Herbst <kherbst at redhat.com>
wrote:
> >
> > This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c.
> >
> > The original commit message didn't even make sense. AMD _does_
support it and
> > it works with Nouveau as well.
> >
> > Also what was the issue being solved here? No references to any bugs
and not
> > even explaining any issue at all isn't the way we do things.
> >
> > And even if it means a muxed design, then the fix is to make it work
inside the
> > driver, not adding some hacky workaround through ACPI tricks.
> >
> > And what out of tree drivers do or do not support we don't care
one bit anyway.
> >
> 
> I think the reverts should be merged via Rafael's tree as the original
> patches went in via there, and we should get them in asap.
> 
> Acked-by: Dave Airlie <airlied at redhat.com>
> Dave.
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.

I feel we need a knob and/or DMI detection to affect the changes that the ASL
normally performs.

On Thu, Aug 15, 2019 at 10:04 AM Karol Herbst <kherbst at redhat.com>
wrote:
>
> On Thu, Aug 15, 2019 at 3:56 PM <Mario.Limonciello at dell.com>
wrote:
> >
> > > -----Original Message-----
> > > From: linux-acpi-owner at vger.kernel.org <linux-acpi-owner at
vger.kernel.org> On
> > > Behalf Of Dave Airlie
> > > Sent: Wednesday, August 14, 2019 5:48 PM
> > > To: Karol Herbst
> > > Cc: LKML; Linux ACPI; dri-devel; nouveau; Rafael J . Wysocki;
Alex Hung; Ben
> > > Skeggs; Dave Airlie
> > > Subject: Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add
OEM _OSI string to
> > > enable dGPU direct output"
> > >
> > > On Thu, 15 Aug 2019 at 07:31, Karol Herbst <kherbst at
redhat.com> wrote:
> > > >
> > > > This reverts commit
28586a51eea666d5531bcaef2f68e4abbd87242c.
> > > >
> > > > The original commit message didn't even make sense. AMD
_does_ support it and
> > > > it works with Nouveau as well.
> > > >
> > > > Also what was the issue being solved here? No references to
any bugs and not
> > > > even explaining any issue at all isn't the way we do
things.
> > > >
> > > > And even if it means a muxed design, then the fix is to make
it work inside the
> > > > driver, not adding some hacky workaround through ACPI
tricks.
> > > >
> > > > And what out of tree drivers do or do not support we
don't care one bit anyway.
> > > >
> > >
> > > I think the reverts should be merged via Rafael's tree as the
original
> > > patches went in via there, and we should get them in asap.
> > >
> > > Acked-by: Dave Airlie <airlied at redhat.com>
> > > Dave.
> >
> > 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?
Hybrid Graphics is the new "standard" way of handling these laptops.
It uses the standard _PR3 APCI method to handle dGPU power.  Support
for this was added to Linux relatively later compared to when the
laptops were launched.  "Power Express" used the other AMD specific
ATPX ACPI method to handle dGPU power.  The driver supports both so
either method will work.

Alex
>
> 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?
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

> > 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.
> 
> 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.