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

On Thu, Aug 15, 2019 at 10:15 AM Karol Herbst <kherbst at redhat.com>
wrote:
>
> On Thu, Aug 15, 2019 at 4:13 PM Alex Deucher <alexdeucher at
gmail.com> wrote:
> >
> > 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
> >
>
> thanks for clarifying. But that still means that we won't need such
> workarounds for AMD users, right? amdgpu handles hybrid graphics just
> fine, right?
Yeah it should, assuming you have a new enough kernel which supports
HG, which has been several years at this point IIRC.

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

> On Thu, Aug 15, 2019 at 10:15 AM Karol Herbst <kherbst at redhat.com>
wrote:
> >
> > On Thu, Aug 15, 2019 at 4:13 PM Alex Deucher <alexdeucher at
gmail.com>
> wrote:
> > >
> > > 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
> > >
> >
> > thanks for clarifying. But that still means that we won't need
such
> > workarounds for AMD users, right? amdgpu handles hybrid graphics just
> > fine, right?
> 
> Yeah it should, assuming you have a new enough kernel which supports
> HG, which has been several years at this point IIRC.
> 
> Alex
> 
Can you define how new of a kernel is a new enough kernel?

Looking on my side these problems were on new hardware (Precision 7740) and
are checked as recently as start of this summer, w/ kernel 4.15.

We can arrange to have it checked again on 5.3rcX w/ the OSI disabled.

On Thu, Aug 15, 2019 at 4:30 PM <Mario.Limonciello at dell.com>
wrote:
>
> > On Thu, Aug 15, 2019 at 10:15 AM Karol Herbst <kherbst at
redhat.com> wrote:
> > >
> > > On Thu, Aug 15, 2019 at 4:13 PM Alex Deucher <alexdeucher at
gmail.com>
> > wrote:
> > > >
> > > > 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
> > > >
> > >
> > > thanks for clarifying. But that still means that we won't
need such
> > > workarounds for AMD users, right? amdgpu handles hybrid graphics
just
> > > fine, right?
> >
> > Yeah it should, assuming you have a new enough kernel which supports
> > HG, which has been several years at this point IIRC.
> >
> > Alex
> >
>
> Can you define how new of a kernel is a new enough kernel?
>
> Looking on my side these problems were on new hardware (Precision 7740) and
> are checked as recently as start of this summer, w/ kernel 4.15.
That's not even a long term one. And it shouldn't get any fixes. I
just checked, last update was 16 months ago.
>
> We can arrange to have it checked again on 5.3rcX w/ the OSI disabled.
yeah, please do. If there are any issues, we (as in drm developers)
are happy to fix the issues inside the drivers.

On Thu, Aug 15, 2019 at 10:30 AM <Mario.Limonciello at dell.com>
wrote:
>
> > On Thu, Aug 15, 2019 at 10:15 AM Karol Herbst <kherbst at
redhat.com> wrote:
> > >
> > > On Thu, Aug 15, 2019 at 4:13 PM Alex Deucher <alexdeucher at
gmail.com>
> > wrote:
> > > >
> > > > 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
> > > >
> > >
> > > thanks for clarifying. But that still means that we won't
need such
> > > workarounds for AMD users, right? amdgpu handles hybrid graphics
just
> > > fine, right?
> >
> > Yeah it should, assuming you have a new enough kernel which supports
> > HG, which has been several years at this point IIRC.
> >
> > Alex
> >
>
> Can you define how new of a kernel is a new enough kernel?
>
> Looking on my side these problems were on new hardware (Precision 7740) and
> are checked as recently as start of this summer, w/ kernel 4.15.
I don't remember off hand.  It was before the _PR3 support in the pci
subsystem was upstream.  What was the problem you were seeing with
this system?

Alex
>
> We can arrange to have it checked again on 5.3rcX w/ the OSI disabled.