okay.. so checking whatever is the difference with _REV being 5
(meaning the firmware uses the legacy paths) doesn't help in any way.
It's using a different method to turn the link of and the other ACPI
variables touched either point to undocumented registers on the PCI
bridge or internal ACPI
On Tue, Dec 10, 2019 at 8:58 PM Dave Airlie wrote:
>
> On Mon, 9 Dec 2019 at 21:39, Rafael J. Wysocki wrote:
> >
> > On Mon, Dec 9, 2019 at 12:17 PM Karol Herbst wrote:
> > >
> > > anybody any other ideas?
> >
> > Not yet, but I'm trying to collect some more information.
> >
> > > It seems that
On Mon, 9 Dec 2019 at 21:39, Rafael J. Wysocki wrote:
>
> On Mon, Dec 9, 2019 at 12:17 PM Karol Herbst wrote:
> >
> > anybody any other ideas?
>
> Not yet, but I'm trying to collect some more information.
>
> > It seems that both patches don't really fix
> > the issue and I have no idea left on
On Mon, Dec 9, 2019 at 12:39 PM Rafael J. Wysocki wrote:
>
> On Mon, Dec 9, 2019 at 12:17 PM Karol Herbst wrote:
> >
> > anybody any other ideas?
>
> Not yet, but I'm trying to collect some more information.
>
> > It seems that both patches don't really fix
> > the issue and I have no idea left
On Mon, Dec 9, 2019 at 12:17 PM Karol Herbst wrote:
>
> anybody any other ideas?
Not yet, but I'm trying to collect some more information.
> It seems that both patches don't really fix
> the issue and I have no idea left on my side to try out. The only
> thing left I could do to further
anybody any other ideas? It seems that both patches don't really fix
the issue and I have no idea left on my side to try out. The only
thing left I could do to further investigate would be to reverse
engineer the Nvidia driver as they support runpm on Turing+ GPUs now,
but I've heard users having
On Wed, Nov 27, 2019 at 12:49 PM Mika Westerberg
wrote:
>
> On Tue, Nov 26, 2019 at 06:10:36PM -0500, Lyude Paul wrote:
> > Hey-this is almost certainly not the right place in this thread to respond,
> > but this thread has gotten so deep evolution can't push the subject further
> > to
> > the
On Tue, Nov 26, 2019 at 06:10:36PM -0500, Lyude Paul wrote:
> Hey-this is almost certainly not the right place in this thread to respond,
> but this thread has gotten so deep evolution can't push the subject further to
> the right, heh. So I'll just respond here.
:)
> I've been following this
[big snip]
> There is a sysfs attribute called "d3cold_allowed" which can be used
> for "blocking" D3cold, so can you please retest using that?
>
Hey-this is almost certainly not the right place in this thread to respond,
but this thread has gotten so deep evolution can't push the subject
On Fri, Nov 22, 2019 at 12:52 PM Mika Westerberg
wrote:
>
[cut]
[I'm really running out of time for today, unfortunately.]
> > > > The current design is mostly based on the PCI PM Spec 1.2, so it would
> > > > be consequent to follow system-wide suspend in PM-runtime and avoid
> > > > putting
On Fri, Nov 22, 2019 at 12:34 PM Karol Herbst wrote:
>
> On Fri, Nov 22, 2019 at 12:30 PM Rafael J. Wysocki wrote:
> >
[cut]
> >
>
> the issue is not AML related at all as I am able to reproduce this
> issue without having to invoke any of that at all, I just need to poke
> into the PCI
On Fri, Nov 22, 2019 at 12:30:20PM +0100, Rafael J. Wysocki wrote:
> On Fri, Nov 22, 2019 at 11:36 AM Mika Westerberg
> wrote:
> >
> > On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Thu, Nov
On Fri, Nov 22, 2019 at 12:30 PM Rafael J. Wysocki wrote:
>
> On Fri, Nov 22, 2019 at 11:36 AM Mika Westerberg
> wrote:
> >
> > On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Thu, Nov 21,
On Fri, Nov 22, 2019 at 10:07 AM Rafael J. Wysocki wrote:
>
> On Fri, Nov 22, 2019 at 1:13 AM Karol Herbst wrote:
> >
> > so while trying to test with d3cold disabled, I noticed that I run
> > into the exact same error.
>
> Does this mean that you disabled d3cold on the GPU via sysfs (the
>
On Fri, Nov 22, 2019 at 11:36 AM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg
> > wrote:
> > >
> > > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote:
> > > > On Thu, Nov 21,
On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote:
> On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg
> wrote:
> >
> > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Thu, Nov
On Fri, Nov 22, 2019 at 1:13 AM Karol Herbst wrote:
>
> so while trying to test with d3cold disabled, I noticed that I run
> into the exact same error.
Does this mean that you disabled d3cold on the GPU via sysfs (the
"d3cold_allowed" attribute was 0) and the original problem still
occurred in
so while trying to test with d3cold disabled, I noticed that I run
into the exact same error. And I verified that the
\_SB.PCI0.PEG0.PG00._STA returns 1, which indicates it should still be
turned on.
On Thu, Nov 21, 2019 at 11:50 PM Karol Herbst wrote:
>
> On Thu, Nov 21, 2019 at 11:39 PM Rafael
On Thu, Nov 21, 2019 at 11:39 PM Rafael J. Wysocki wrote:
>
> On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg
> wrote:
> >
> > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Thu, Nov 21,
On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg
> > wrote:
> > >
> > > On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote:
> > > > On Thu, Nov 21, 2019
On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote:
> On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg
> wrote:
> >
> > On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote:
> > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > > > On Thu, Nov 21,
On Thu, Nov 21, 2019 at 5:06 PM Karol Herbst wrote:
>
> On Thu, Nov 21, 2019 at 4:47 PM Rafael J. Wysocki wrote:
> >
> > On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst wrote:
> > >
> > > On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Thu, Nov 21, 2019 at
On Thu, Nov 21, 2019 at 4:47 PM Rafael J. Wysocki wrote:
>
> On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst wrote:
> >
> > On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg
> > wrote:
> > >
> > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > > > On Thu, Nov 21, 2019 at
On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst wrote:
>
> On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg
> wrote:
> >
> > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Wed, Nov 20, 2019
On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote:
> > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Wed, Nov 20,
On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote:
> > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Wed, Nov 20,
On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote:
> On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote:
> > > > > last week
On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote:
> > > > > last week or so
On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> wrote:
> >
> > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote:
> > > > last week or so I found systems where the GPU was under the "PCI
> > > > Express Root
On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
wrote:
>
> On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote:
> > > last week or so I found systems where the GPU was under the "PCI
> > > Express Root Port" (name from lspci) and on those systems all of that
> > > seems to work. So
On Thu, Nov 21, 2019 at 12:17 PM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 12:03:52PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> > > > with the branch and
On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote:
> > last week or so I found systems where the GPU was under the "PCI
> > Express Root Port" (name from lspci) and on those systems all of that
> > seems to work. So I am wondering if it's indeed just the 0x1901 one,
> > which also
On Thu, Nov 21, 2019 at 12:03:52PM +0100, Rafael J. Wysocki wrote:
> On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
> wrote:
> >
> > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> > > with the branch and patch applied:
> > >
On Thu, Nov 21, 2019 at 12:08 PM Rafael J. Wysocki wrote:
>
> On Thu, Nov 21, 2019 at 12:03 PM Rafael J. Wysocki wrote:
> >
> > On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> > > > with the branch and patch
On Thu, Nov 21, 2019 at 12:03 PM Rafael J. Wysocki wrote:
>
> On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
> wrote:
> >
> > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> > > with the branch and patch applied:
> > >
On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
wrote:
>
> On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> > with the branch and patch applied:
> >
On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> with the branch and patch applied:
> https://gist.githubusercontent.com/karolherbst/03c4c8141b0fa292d781badfa186479e/raw/5c62640afbc57d6e69ea924c338bd2836e770d02/gistfile1.txt
Thanks for testing. Too bad it did not help :( I suppose
On Wed, Nov 20, 2019 at 10:40 PM Karol Herbst wrote:
>
> On Wed, Nov 20, 2019 at 10:37 PM Rafael J. Wysocki wrote:
> >
> > On Wed, Nov 20, 2019 at 4:53 PM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 04:37:14PM +0100, Karol Herbst wrote:
> > > > On Wed, Nov 20, 2019 at 4:15 PM
On Wed, Nov 20, 2019 at 10:37 PM Rafael J. Wysocki wrote:
>
> On Wed, Nov 20, 2019 at 4:53 PM Mika Westerberg
> wrote:
> >
> > On Wed, Nov 20, 2019 at 04:37:14PM +0100, Karol Herbst wrote:
> > > On Wed, Nov 20, 2019 at 4:15 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Wed, Nov 20, 2019 at
On Wed, Nov 20, 2019 at 4:53 PM Mika Westerberg
wrote:
>
> On Wed, Nov 20, 2019 at 04:37:14PM +0100, Karol Herbst wrote:
> > On Wed, Nov 20, 2019 at 4:15 PM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote:
> > > > On Wed, Nov 20, 2019 at 1:09
with the branch and patch applied:
https://gist.githubusercontent.com/karolherbst/03c4c8141b0fa292d781badfa186479e/raw/5c62640afbc57d6e69ea924c338bd2836e770d02/gistfile1.txt
On Wed, Nov 20, 2019 at 5:23 PM Mika Westerberg
wrote:
>
> On Wed, Nov 20, 2019 at 05:53:07PM +0200, Mika Westerberg
On Wed, Nov 20, 2019 at 05:53:07PM +0200, Mika Westerberg wrote:
> On Wed, Nov 20, 2019 at 04:37:14PM +0100, Karol Herbst wrote:
> > On Wed, Nov 20, 2019 at 4:15 PM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote:
> > > > On Wed, Nov 20, 2019 at
On Wed, Nov 20, 2019 at 04:37:14PM +0100, Karol Herbst wrote:
> On Wed, Nov 20, 2019 at 4:15 PM Mika Westerberg
> wrote:
> >
> > On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote:
> > > On Wed, Nov 20, 2019 at 1:09 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Wed, Nov 20, 2019
On Wed, Nov 20, 2019 at 4:15 PM Mika Westerberg
wrote:
>
> On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote:
> > On Wed, Nov 20, 2019 at 1:09 PM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 12:58:00PM +0100, Karol Herbst wrote:
> > > > overall, what I really want to
On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote:
> On Wed, Nov 20, 2019 at 1:09 PM Mika Westerberg
> wrote:
> >
> > On Wed, Nov 20, 2019 at 12:58:00PM +0100, Karol Herbst wrote:
> > > overall, what I really want to know is, _why_ does it work on windows?
> >
> > So do I ;-)
> >
> > >
It depends on the kernel being built with ACPI_REV_OVERRIDE_POSSIBLE=y
and acpi_rev_override=1 being set on the kernel command line
On Wed, Nov 20, 2019 at 1:15 PM Rafael J. Wysocki wrote:
>
> On Wed, Nov 20, 2019 at 1:10 PM Karol Herbst wrote:
> >
> > On Wed, Nov 20, 2019 at 1:06 PM Rafael J.
On Wed, Nov 20, 2019 at 1:10 PM Karol Herbst wrote:
>
> On Wed, Nov 20, 2019 at 1:06 PM Rafael J. Wysocki wrote:
> >
> > On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst wrote:
> > >
> > > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki
> > > wrote:
> > > >
> > > > On Wed, Nov 20, 2019 at
On Wed, Nov 20, 2019 at 1:09 PM Mika Westerberg
wrote:
>
> On Wed, Nov 20, 2019 at 12:58:00PM +0100, Karol Herbst wrote:
> > overall, what I really want to know is, _why_ does it work on windows?
>
> So do I ;-)
>
> > Or what are we doing differently on Linux so that it doesn't work? If
> >
On Wed, Nov 20, 2019 at 1:06 PM Rafael J. Wysocki wrote:
>
> On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst wrote:
> >
> > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Wed, Nov 20,
On Wed, Nov 20, 2019 at 1:06 PM Rafael J. Wysocki wrote:
>
> On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst wrote:
> >
> > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Wed, Nov 20,
On Wed, Nov 20, 2019 at 12:58:00PM +0100, Karol Herbst wrote:
> overall, what I really want to know is, _why_ does it work on windows?
So do I ;-)
> Or what are we doing differently on Linux so that it doesn't work? If
> anybody has any idea on how we could dig into this and figure it out
> on
On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst wrote:
>
> On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki wrote:
> >
> > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 11:52:22AM +0100, Rafael J. Wysocki wrote:
> > > > On Wed, Nov 20, 2019 at
overall, what I really want to know is, _why_ does it work on windows?
Or what are we doing differently on Linux so that it doesn't work? If
anybody has any idea on how we could dig into this and figure it out
on this level, this would probably allow us to get closer to the root
cause? no?
On
for newer Windows the firmware uses bit 0x80 on 0x248 (Q0L2 being the
field name) on the bridge controller to turn of the device, on other
versions it uses the "older"? 0xb0 register and the P0LD field, which
is documented, where the former is not.
On Wed, Nov 20, 2019 at 12:51 PM Mika
On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki wrote:
>
> On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg
> wrote:
> >
> > On Wed, Nov 20, 2019 at 11:52:22AM +0100, Rafael J. Wysocki wrote:
> > > On Wed, Nov 20, 2019 at 11:18 AM Mika Westerberg
> > > wrote:
> > > >
> > > > Hi Karol,
> > >
On Wed, Nov 20, 2019 at 01:22:16PM +0200, Mika Westerberg wrote:
> If (((OSYS <= 0x07D9) || ((OSYS == 0x07DF) && (_REV ==
> 0x05
> {
The OSYS comes from this (in DSDT):
If (_OSI ("Windows 2009"))
{
On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg
wrote:
>
> On Wed, Nov 20, 2019 at 11:52:22AM +0100, Rafael J. Wysocki wrote:
> > On Wed, Nov 20, 2019 at 11:18 AM Mika Westerberg
> > wrote:
> > >
> > > Hi Karol,
> > >
> > > On Tue, Nov 19, 2019 at 11:26:45PM +0100, Karol Herbst wrote:
> > > >
On Wed, Nov 20, 2019 at 11:52:22AM +0100, Rafael J. Wysocki wrote:
> On Wed, Nov 20, 2019 at 11:18 AM Mika Westerberg
> wrote:
> >
> > Hi Karol,
> >
> > On Tue, Nov 19, 2019 at 11:26:45PM +0100, Karol Herbst wrote:
> > > On Tue, Nov 19, 2019 at 10:50 PM Bjorn Helgaas wrote:
> > > >
> > > > [+cc
On Wed, Nov 20, 2019 at 11:18 AM Mika Westerberg
wrote:
>
> Hi Karol,
>
> On Tue, Nov 19, 2019 at 11:26:45PM +0100, Karol Herbst wrote:
> > On Tue, Nov 19, 2019 at 10:50 PM Bjorn Helgaas wrote:
> > >
> > > [+cc Dave]
> > >
> > > On Thu, Oct 17, 2019 at 02:19:01PM +0200, Karol Herbst wrote:
> > >
Hi Karol,
On Tue, Nov 19, 2019 at 11:26:45PM +0100, Karol Herbst wrote:
> On Tue, Nov 19, 2019 at 10:50 PM Bjorn Helgaas wrote:
> >
> > [+cc Dave]
> >
> > On Thu, Oct 17, 2019 at 02:19:01PM +0200, Karol Herbst wrote:
> > > Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher
>
[+cc Daniel, Vidya, Thierry; thread starts at
https://lore.kernel.org/r/20191017121901.13699-1-kher...@redhat.com]
On Tue, Nov 19, 2019 at 11:26:45PM +0100, Karol Herbst wrote:
> On Tue, Nov 19, 2019 at 10:50 PM Bjorn Helgaas wrote:
> > On Thu, Oct 17, 2019 at 02:19:01PM +0200, Karol Herbst
On Tue, Nov 19, 2019 at 10:50 PM Bjorn Helgaas wrote:
>
> [+cc Dave]
>
> On Thu, Oct 17, 2019 at 02:19:01PM +0200, Karol Herbst wrote:
> > Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device
> > states.
> >
> > v2: convert to pci_dev quirk
> > put a proper technical
[+cc Dave]
On Thu, Oct 17, 2019 at 02:19:01PM +0200, Karol Herbst wrote:
> Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device
> states.
>
> v2: convert to pci_dev quirk
> put a proper technical explanation of the issue as a in-code comment
> v3: disable it only for
On Thu, 17 Oct 2019 at 22:19, Karol Herbst wrote:
>
> Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device
> states.
Can we get this acked/committed? At this stage I think we've done all
we can unless Intel actually escalate this internally and work out how
the hw is
ping on the patch.
I wasn't able to verify this issue on any other bridge controller, so
it really might be only this one.
On Thu, Oct 17, 2019 at 2:19 PM Karol Herbst wrote:
>
> Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device
> states.
>
> v2: convert to pci_dev
Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device
states.
v2: convert to pci_dev quirk
put a proper technical explanation of the issue as a in-code comment
v3: disable it only for certain combinations of intel and nvidia hardware
v4: simplify quirk by setting flag
66 matches
Mail list logo
