From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Weinehall Subject: Re: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate Date: Fri, 27 Feb 2015 14:15:04 +0200 Message-ID: <20150227121504.GA30560@boom> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <20150226200127.GU24485@phenom.ffwll.local> Sender: stable-owner@vger.kernel.org To: intel-gfx@lists.freedesktop.org Cc: Imre Deak , =?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 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: [snip] > >=20 > > The problem seems to be that after the kernel puts the device into = D3 > > the BIOS still tries to access it, or otherwise assumes that it's i= n D0. > > This is clearly bogus, since ACPI mandates that devices are put int= o D3 > > by the OSPM if they are not wake-up sources. In the future we want = to > > unify more of the driver's runtime and system suspend paths, for ex= ample > > by skipping all the system suspend/hibernation hooks if the device = is > > runtime suspended already. Accordingly for all other platforms the = goal > > is still to properly power down the device during hibernation. [snip] >=20 > If we see more of these troublesome machines we might need to apply a= n > 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 apply = this > and shovel it through the backporting machinery. Isn't there a risk that this will negatively impact machines using gen4 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? Just my 2=A2. Kind regards, David Weinehall