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:25 AM Karol Herbst <kherbst at redhat.com>
wrote:
>
> On Thu, Aug 15, 2019 at 4:20 PM <Mario.Limonciello at dell.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.

Alex

On Thu, 15 Aug 2019 16:37:05 +0200,
Alex Deucher wrote:
> 
> On Thu, Aug 15, 2019 at 10:25 AM Karol Herbst <kherbst at redhat.com>
wrote:
> >
> > On Thu, Aug 15, 2019 at 4:20 PM <Mario.Limonciello at dell.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.
FYI, the corresponding commit for ALSA part is destined for 5.4
kernel: 
 
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=ade49db337a9d44ac5835cfce1ee873549011b27

BTW, Nouveau should suffer from the same problem.  The patch to add
the audio component support is found at:
  https://patchwork.freedesktop.org/patch/319131/


thanks,

Takashi

On Thu, Aug 15, 2019 at 10:37 AM Alex Deucher <alexdeucher at gmail.com>
wrote:
>
> On Thu, Aug 15, 2019 at 10:25 AM Karol Herbst <kherbst at redhat.com>
wrote:
> >
> > On Thu, Aug 15, 2019 at 4:20 PM <Mario.Limonciello at dell.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

> -----Original Message-----
> From: Takashi Iwai <tiwai at suse.de>
> Sent: Thursday, August 15, 2019 9:57 AM
> To: Alex Deucher
> Cc: Karol Herbst; Limonciello, Mario; nouveau; Rafael J . Wysocki; LKML;
dri-devel;
> Linux ACPI Mailing List; Alex Hung; Ben Skeggs; David Airlie
> Subject: Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI
string to
> enable dGPU direct output"
> 
> 
> [EXTERNAL EMAIL]
> 
> On Thu, 15 Aug 2019 16:37:05 +0200,
> Alex Deucher wrote:
> >
> > On Thu, Aug 15, 2019 at 10:25 AM Karol Herbst <kherbst at
redhat.com> wrote:
> > >
> > > On Thu, Aug 15, 2019 at 4:20 PM <Mario.Limonciello at
dell.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.
> 
> FYI, the corresponding commit for ALSA part is destined for 5.4
> kernel:
> 
>
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=ade
> 49db337a9d44ac5835cfce1ee873549011b27
> 
> BTW, Nouveau should suffer from the same problem.  The patch to add
> the audio component support is found at:
>   https://patchwork.freedesktop.org/patch/319131/
> 
> 
It sounds like 5.3rcX won't be a useful check then.

So am I correct to understand that everything related to the AMD failures
described in this thread should be in linux-next at this point?