From mboxrd@z Thu Jan 1 00:00:00 1970 From: Imre Deak Subject: Re: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate Date: Fri, 27 Feb 2015 20:23:41 +0200 Message-ID: <1425061421.14060.22.camel@ideak-mobl> References: <87bnkjcqjt.fsf@nemi.mork.no> <1424789904-26699-1-git-send-email-bjorn@mork.no> <1424794340.15554.3.camel@intel.com> <878ufnjfrr.fsf@nemi.mork.no> <1424889214.5991.4.camel@intel.com> <87bnkhqan8.fsf@nemi.mork.no> <1424976648.17078.1.camel@intel.com> <20150226200127.GU24485@phenom.ffwll.local> <20150227121504.GA30560@boom> Reply-To: imre.deak@intel.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20150227121504.GA30560@boom> Sender: stable-owner@vger.kernel.org To: David Weinehall Cc: intel-gfx@lists.freedesktop.org, =?ISO-8859-1?Q?Bj=F8rn?= Mork , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, stable@vger.kernel.org, Daniel Vetter List-Id: dri-devel@lists.freedesktop.org On Fri, 2015-02-27 at 14:15 +0200, David Weinehall wrote: > On Thu, Feb 26, 2015 at 09:01:27PM +0100, Daniel Vetter wrote: > > On Thu, Feb 26, 2015 at 08:50:48PM +0200, Imre Deak wrote: >=20 > [snip] > > >=20 > > > The problem seems to be that after the kernel puts the device int= o D3 > > > the BIOS still tries to access it, or otherwise assumes that it's= in D0. > > > This is clearly bogus, since ACPI mandates that devices are put i= nto D3 > > > by the OSPM if they are not wake-up sources. In the future we wan= t to > > > unify more of the driver's runtime and system suspend paths, for = example > > > by skipping all the system suspend/hibernation hooks if the devic= e is > > > runtime suspended already. Accordingly for all other platforms th= e goal > > > is still to properly power down the device during hibernation. >=20 > [snip] > >=20 > > If we see more of these troublesome machines we might need to apply= an > > even bigger hammer like gen < 5 or so. But as long as there's just = 1 > > report I think this is the right approach. > >=20 > > Bjorn, as soon as we have your tested-by that this work we can appl= y this > > and shovel it through the backporting machinery. >=20 > Isn't there a risk that this will negatively impact machines using ge= n4 > that *don't* have a buggy BIOS? Wouldn't a quirk tied to the laptop > or BIOS version be better suited -- or possibly a parameter that can = be > passed to the driver, which would make it easier to test if others > suffering from similar symptoms on other systems suffer from the same > issue or not? >=20 > Just my 2=C2=A2. We've checked today with Ville a few machines we've found from GEN2 to GEN5+. There was one Thinkpad x61s (GEN4) where I could reproduce the exact same problem and get rid of it using the same workaround. All the others were non-Lenovo (including GEN4) mobile and desktop platforms an= d none of these had the problem. I also tried it on a Lenovo IVB ultrabook, which also works fine. So the current theory is that it's related to GEN4 Thinkpad BIOSes, and so we need to change the condition to match that at least. --Imre