Displaying 7 results from an estimated 7 matches for "q0l2".
Did you mean:
q02
2019 Oct 22
0
[PATCH v3] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...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 variables which all cause a link
to be powered down: Q0L2 (newest), P0L2, P0LD (oldest, I think).
Maybe I remember incorrectly and have to read the code again... okay,
the fallback path uses P0LD indeed. That's actually the only register
of those being documented by Intel afaik.
> If I read it right, the later condition tries to detect Linux whic...
2019 Nov 20
0
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
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:
>
&...
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
2019 Nov 20
2
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...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 a...
2019 Oct 22
2
[PATCH v3] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Tue, Oct 22, 2019 at 11:16:14AM +0200, Karol Herbst wrote:
> I think there is something I totally forgot about:
>
> When there was never a driver bound to the GPU, and if runtime power
> management gets enabled on that device, runtime suspend/resume works
> as expected (I am not 100% sure on if that always works, but I will
> recheck that).
AFAIK, if there is no driver bound
2019 Jun 19
2
[PATCH v2 4/4] pci: save the boot pcie link speed and restore it on fini
Hi Bjorn,
I was playing around with some older information again (write into the
PCI config to put the card into d3 state). And there is something
which made me very curious:
If I put the card manually into any other state besides D0 via the
0x64 pci config register, the card just dies and pci core seems to
expect this to not happen. pci_raw_set_power_state has this
2019 Nov 20
4
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
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
> <mika.westerberg at intel.com> 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 <helgaas at kernel.org> wrote:
> > > >