[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAPM=9tyY9bkCh2+-Sn3AXN+R4rZOS1z--bZoycGBmStQS2-bMw@mail.gmail.com>
Date: Wed, 17 Feb 2016 11:57:49 +1000
From: Dave Airlie <airlied@...il.com>
To: Linux ACPI <linux-acpi@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Lenovo W541, windows 10 and ACPI PM
So we got a bug filed in Fedora 23 that the nvidia GPU wasn't stalling
on resume from runtime poweroff. When we looked into it, we noticed
the GPU wasn't powering off and the delay was from things going to
hell after that.
I dug out the DSDT and noticed it has special Windows 10 handling code
for the SB.PCI0.PEG.VID device. Adding acpi_osi="!Windows 2013" made
things work again and everyone rejoiced and had battery life again.
Now what to do about this? I doubt this is restricted to the W541
laptop, I assume all Optimus laptops that support windows 10 will have
this problem, so I'm not sure blacklisting on a case by case basis is
going to help.
More information from investigation:
On Win7/8 paths, the way to poweroff the GPU is to call an ACPI _DSM
on the VID device that sets a magic bit, then the next time you go
into D3 the _PS3 method gets called and powers the device down. This
is to make up for the lack of D3cold in Windows at the time I suspect.
Now with Win10, the PCI0.PEG device has power resource methods,
specifically PR3 which enables D3cold. However nouveau is bound to the
VID device not the PEG device, so never attempts to power it down
using those methods. I've hacked up the attached patch, and it does
indeed power the device down, but I've no idea how this is meant to
work in real world.
Dave.
View attachment "0001-nouveau-hack-the-parent-power-down-so-the-GPU-powers.patch" of type "text/x-patch" (1887 bytes)
Powered by blists - more mailing lists