linux-kernel - RE: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3fc22fe8bcaf4304bb07534b61c4de90@AUSX13MPC101.AMER.DELL.COM>
Date:   Thu, 15 Aug 2019 14:19:58 +0000
From:   <Mario.Limonciello@...l.com>
To:     <kherbst@...hat.com>
CC:     <airlied@...il.com>, <linux-kernel@...r.kernel.org>,
        <linux-acpi@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
        <nouveau@...ts.freedesktop.org>, <rafael.j.wysocki@...el.com>,
        <alex.hung@...onical.com>, <bskeggs@...hat.com>,
        <airlied@...hat.com>
Subject: RE: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to
 enable dGPU direct output"

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