Displaying 20 results from an estimated 33 matches for "_rev".
Did you mean:
_dev
2019 Nov 20
4
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...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...
2019 Nov 20
0
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...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...
2019 Nov 20
0
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...> > > 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...
2019 Nov 20
1
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...thods
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 has any ideas.
Prev...
2019 Oct 22
2
[PATCH v3] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...s 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. There is similar...
2019 Nov 22
1
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...vice.
>
> > Because if the port has _PSx methods we need to put it into D3hot AFAIK.
>
> Yes, we need to run _PS3 then, but maybe we don't need to write to its
> PMCSR directly.
>
> > > > > > Basically the difference is that when Windows 7 or Linux (the _REV==5
> > > > > > check) then we directly do link disable whereas in Windows 8+ we invoke
> > > > > > LKDS() method that puts the link into L2/L3. None of the fields they
> > > > > > access seem to touch the GPU itself.
> > > > >
>...
2019 Nov 22
0
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...u said.
I also think that Windows 7 and before didin't do RTD3, but it did PCI
PM nevertheless and platform firmware could expect it to behave in a
specific way in that respect. That expected behavior seems to have
changed in the next generations of Windows, as reflected by the OS
version and _REV checks in ASL.
> > > Starting from Windows 8 it started doing this runtime so devices can
> > > enter D3cold even when system is in S0.
> >
> > Hmm. So by setting _REV to 5 we effectively change the _OFF into a NOP?
>
> No, there are two paths in the _OFF() and...
2019 Nov 20
3
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...hich 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 t...
2019 Nov 19
3
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
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
2019 Nov 20
1
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
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"))
{...
2019 Nov 22
3
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...skipping (3) would make things work either, but what about doing
> (1) and (3) without (2)?
You mean in this particular case or in general? Because if the port has
_PSx methods we need to put it into D3hot AFAIK.
> > > > Basically the difference is that when Windows 7 or Linux (the _REV==5
> > > > check) then we directly do link disable whereas in Windows 8+ we invoke
> > > > LKDS() method that puts the link into L2/L3. None of the fields they
> > > > access seem to touch the GPU itself.
> > >
> > > So that may be where the pro...
2019 Nov 20
2
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
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
2019 Nov 21
1
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...> No. We put the GPU into D3hot first, then the root port and then turn
> off the power resource (which is attached to the root port) resulting
> the topology entering D3cold.
I don't see that happening in the AML though.
Basically the difference is that when Windows 7 or Linux (the _REV==5
check) then we directly do link disable whereas in Windows 8+ we invoke
LKDS() method that puts the link into L2/L3. None of the fields they
access seem to touch the GPU itself.
LKDS() for the first PEG port looks like this:
P0L2 = One
Sleep (0x10)
Local0 = Zero
While (P0L2)
{...
2019 Nov 22
0
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...f skipping it for the downstream device.
> Because if the port has _PSx methods we need to put it into D3hot AFAIK.
Yes, we need to run _PS3 then, but maybe we don't need to write to its
PMCSR directly.
> > > > > Basically the difference is that when Windows 7 or Linux (the _REV==5
> > > > > check) then we directly do link disable whereas in Windows 8+ we invoke
> > > > > LKDS() method that puts the link into L2/L3. None of the fields they
> > > > > access seem to touch the GPU itself.
> > > >
> > > > So...
2019 Nov 21
5
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
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
> <mika.westerberg at intel.com> 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
2019 Oct 22
0
[PATCH v3] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...; 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 following variable...
2019 Nov 20
0
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...eld, 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 ("W...
2019 Nov 20
0
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...e "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.
2019 Nov 21
3
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...the AML though.
>
> Which AML do you mean, specifically? The _OFF method for the root
> port's _PR3 power resource or something else?
The root port's _OFF method for the power resource returned by its _PR3.
> > Basically the difference is that when Windows 7 or Linux (the _REV==5
> > check) then we directly do link disable whereas in Windows 8+ we invoke
> > LKDS() method that puts the link into L2/L3. None of the fields they
> > access seem to touch the GPU itself.
>
> So that may be where the problem is.
>
> Putting the downstream compon...
2012 Aug 21
3
[LLVMdev] Let's get rid of neverHasSideEffects
...setting the mayLoad and mayStore flags in the big ArithBinOp multiclasses.
You can see the problem in the big ArithBinOp_RF multiclass in X86InstrArithmetic.td. It's not obvious at a glance which of those instructions have patterns, and as a result we forgot to set neverHasSideEffects on the *_REV and *8i8 variants. I don't think it would detract to add "let mayLoad = 1 in {…}" around the *rm groups etc.
Or you could set the flags on the various BinOpRMW super classes.
/jakob