search for: 0x07df

...s and it is hard to follow the dissassembled > > ASL which does not have any comments but there are couple of things that > > stand out where we may go into a different path. One of them is this in > > the PGOF() method: > > > > If (((OSYS <= 0x07D9) || ((OSYS == 0x07DF) && (_REV == 0x05)))) > > > > The ((OSYS == 0x07DF) && (_REV == 0x05)) checks specifically for Linux > > (see [1] and 18d78b64fddc ("ACPI / init: Make it possible to override > > _REV")) so it might be that Dell people tested this at some point in &...

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

...s in that case (it is never put into D3hot). I looked at the acpidump you sent and there is one thing that may explain the differences between Windows and Linux. Not sure if you were aware of this already, though. The power resource PGOF() method has this: If (((OSYS <= 0x07D9) || ((OSYS == 0x07DF) && (_REV == 0x05)))) { ... } If I read it right, the later condition tries to detect Linux which fails nowadays but if you have acpi_rev_override in the command line (or the machine is listed in acpi_rev_dmi_table) this check passes and does some magic which is not clear to me....

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

...accordingly. The methods itself do lots of things and it is hard to follow the dissassembled ASL which does not have any comments but there are couple of things that stand out where we may go into a different path. One of them is this in the PGOF() method: If (((OSYS <= 0x07D9) || ((OSYS == 0x07DF) && (_REV == 0x05)))) The ((OSYS == 0x07DF) && (_REV == 0x05)) checks specifically for Linux (see [1] and 18d78b64fddc ("ACPI / init: Make it possible to override _REV")) so it might be that Dell people tested this at some point in Linux as well. Added Mario in case he ha...

...; 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 > &gt...

...; itself do lots of things and it is hard to follow the dissassembled > ASL which does not have any comments but there are couple of things that > stand out where we may go into a different path. One of them is this in > the PGOF() method: > > If (((OSYS <= 0x07D9) || ((OSYS == 0x07DF) && (_REV == 0x05)))) > > The ((OSYS == 0x07DF) && (_REV == 0x05)) checks specifically for Linux > (see [1] and 18d78b64fddc ("ACPI / init: Make it possible to override > _REV")) so it might be that Dell people tested this at some point in > Linux as well. A...

...w the dissassembled > > > ASL which does not have any comments but there are couple of things that > > > stand out where we may go into a different path. One of them is this in > > > the PGOF() method: > > > > > > If (((OSYS <= 0x07D9) || ((OSYS == 0x07DF) && (_REV == 0x05)))) > > > > > > The ((OSYS == 0x07DF) && (_REV == 0x05)) checks specifically for Linux > > > (see [1] and 18d78b64fddc ("ACPI / init: Make it possible to override > > > _REV")) so it might be that Dell people tested thi...

On Wed, Nov 20, 2019 at 1:06 PM Rafael J. Wysocki <rafael at kernel.org> wrote: > > On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst <kherbst at redhat.com> wrote: > > > > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki <rafael at kernel.org> wrote: > > > > > > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg > > > <mika.westerberg

...> > > ASL which does not have any comments but there are couple of things that > > > > stand out where we may go into a different path. One of them is this in > > > > the PGOF() method: > > > > > > > > If (((OSYS <= 0x07D9) || ((OSYS == 0x07DF) && (_REV == 0x05)))) > > > > > > > > The ((OSYS == 0x07DF) && (_REV == 0x05)) checks specifically for Linux > > > > (see [1] and 18d78b64fddc ("ACPI / init: Make it possible to override > > > > _REV")) so it might be that De...

...nto D3hot). > > I looked at the acpidump you sent and there is one thing that may > explain the differences between Windows and Linux. Not sure if you were > aware of this already, though. The power resource PGOF() method has > this: > > If (((OSYS <= 0x07D9) || ((OSYS == 0x07DF) && (_REV == 0x05)))) { > ... > } > I think this is the fallback to some older method of runtime suspending the device, and I think it will end up touching different registers on the bridge controller which do not show the broken behaviour. You'll find references to...

...PI tables without the "Linux workaround" in the AML in > > question. > > > > the workaround is not enabled by default, because it has to be > explicitly enabled by the user. I'm not sure what you are talking about. I'm taking specifically about the ((OSYS == 0x07DF) && (_REV == 0x05)) check mentioned by Mika which doesn't seem to depend on user input in any way.

On Tue, Nov 19, 2019 at 10:50 PM Bjorn Helgaas <helgaas at kernel.org> 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 explanation of the issue as a

On Mon, Oct 21, 2019 at 5:46 PM Mika Westerberg <mika.westerberg at intel.com> wrote: > > On Mon, Oct 21, 2019 at 04:49:09PM +0200, Karol Herbst wrote: > > On Mon, Oct 21, 2019 at 4:09 PM Mika Westerberg > > <mika.westerberg at intel.com> wrote: > > > > > > On Mon, Oct 21, 2019 at 03:54:09PM +0200, Karol Herbst wrote: > > > > > I

...eIf ((Arg0 == 0x02)) { ELC2 = LCT2 /* \_SB_.PCI0.LCT2 */ H2VI = S2VI /* \_SB_.PCI0.S2VI */ H2DI = S2DI /* \_SB_.PCI0.S2DI */ ECP2 = LCP2 /* \_SB_.PCI0.LCP2 */ } If (((OSYS <= 0x07D9) || ((OSYS == 0x07DF) && (_REV == 0x05)))) { If ((PIOF == Zero)) { P0LD = One TCNT = Zero While ((TCNT < LDLY)) { If ((P0LT == 0x08))...

...> ELC2 = LCT2 /* \_SB_.PCI0.LCT2 */ > H2VI = S2VI /* \_SB_.PCI0.S2VI */ > H2DI = S2DI /* \_SB_.PCI0.S2DI */ > ECP2 = LCP2 /* \_SB_.PCI0.LCP2 */ > } > > If (((OSYS <= 0x07D9) || ((OSYS == 0x07DF) && (_REV == > 0x05)))) > { > If ((PIOF == Zero)) > { > P0LD = One > TCNT = Zero > While ((TCNT < LDLY)) > { >...

So a new thinkpad: 01:00.0 VGA compatible controller: NVIDIA Corporation GP107GLM [Quadro P2000 Mobile] (rev a1) Hangs whenever I try to poke at the card. It starts happily enough with [ 3.971515] ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20181003/nsarguments-66) [ 3.971553] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4

...{ Return (0x0001E7FF) } } Case (One) { If ((Arg1 == One)) { If (((S0ID == One) && (OSYS < 0x07DF))) { If (((DerefOf (Arg3 [Zero]) & 0xFF) == One)) { \GUAM (One) } Local0 = (DerefOf (Arg3 [One]) &...

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 > <mika.westerberg at intel.com> 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 > > > <mika.westerberg at intel.com> wrote: > > > >