Karol Herbst
2019-Nov-20 11:58 UTC
[Nouveau] [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
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 Wed, Nov 20, 2019 at 12:54 PM Karol Herbst <kherbst at redhat.com> wrote:> > 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 Westerberg > <mika.westerberg at intel.com> wrote: > > > > 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")) > > { > > OSYS = 0x07D9 > > } > > > > If (_OSI ("Windows 2012")) > > { > > OSYS = 0x07DC > > } > > > > If (_OSI ("Windows 2013")) > > { > > OSYS = 0x07DD > > } > > > > If (_OSI ("Windows 2015")) > > { > > OSYS = 0x07DF > > } > > > > So I guess this particular check tries to identify Windows 7 and older, > > and Linux. > > > > > If ((PIOF == Zero)) > > > { > > > P0LD = One > > > TCNT = Zero > > > While ((TCNT < LDLY)) > > > { > > > If ((P0LT == 0x08)) > > > { > > > Break > > > } > > > > > > Sleep (0x10) > > > TCNT += 0x10 > > > } > > > > > > P0RM = One > > > P0AP = 0x03 > > > } > > > ElseIf ((PIOF == One)) > > > { > > > P1LD = One > > > TCNT = Zero > > > While ((TCNT < LDLY)) > > > { > > > If ((P1LT == 0x08)) > > > { > > > Break > > > } > > > > > > Sleep (0x10) > > > TCNT += 0x10 > > > } > > > > > > P1RM = One > > > P1AP = 0x03 > > > } > > > ElseIf ((PIOF == 0x02)) > > > { > > > P2LD = One > > > TCNT = Zero > > > While ((TCNT < LDLY)) > > > { > > > If ((P2LT == 0x08)) > > > { > > > Break > > > } > > > > > > Sleep (0x10) > > > TCNT += 0x10 > > > } > > > > > > P2RM = One > > > P2AP = 0x03 > > > } > > > > > > If ((PBGE != Zero)) > > > { > > > If (SBDL (PIOF)) > > > { > > > MBDL = GMXB (PIOF) > > > PDUB (PIOF, MBDL) > > > } > > > } > > > } > > > Else > > > { > > > LKDS (PIOF) > > > } > > > > > > If ((DerefOf (SCLK [Zero]) != Zero)) > > > { > > > PCRO (0xDC, 0x100C, DerefOf (SCLK [One])) > > > Sleep (0x10) > > > } > > > > > > GPPR (PIOF, Zero) > > > If ((OSYS != 0x07D9)) > > > { > > > DIWK (PIOF) > > > } > > > > > > \_SB.SGOV (0x01010004, Zero) > > > Sleep (0x14) > > > Return (Zero) > > > } > >
Mika Westerberg
2019-Nov-20 12:09 UTC
[Nouveau] [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
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 this level, this would probably allow us to get closer to the root > cause? no?Have you tried to use the acpi_rev_override parameter in your system and does it have any effect? Also did you try to trace the ACPI _ON/_OFF() methods? I think that should hopefully reveal something.
Karol Herbst
2019-Nov-20 12:11 UTC
[Nouveau] [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Wed, Nov 20, 2019 at 1:09 PM Mika Westerberg <mika.westerberg at intel.com> 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 > > 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? > > Have you tried to use the acpi_rev_override parameter in your system and > does it have any effect? > > Also did you try to trace the ACPI _ON/_OFF() methods? I think that > should hopefully reveal something. >I think I did in the past and it seemed to have worked, there is just one big issue with this: it's a Dell specific workaround afaik, and this issue plagues not just Dell, but we've seen it on HP and Lenovo laptops as well, and I've heard about users having the same issues on Asus and MSI laptops as well. I will spend some time to collect all the necessary information, create a bug to put it all in there and send out a v5 with the updated information and references to this bug.
Apparently Analagous Threads
- [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
- [PATCH 1/5] drm: don't set the pci power state if the pci subsystem handles the ACPI bits
- [PATCH 0/2] drm/nouveau: Fix DP AUX RPM issues
- [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
- [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges