From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 1/4] drm/i915: save/restore the legacy backlight control Date: Tue, 28 Aug 2012 09:48:28 +0200 Message-ID: <20120828074828.GA5125@phenom.ffwll.local> References: <179a19e78c99201a9ec18967c122a5a3aedbf555.1346136448.git.jani.nikula@intel.com> <051c15$44688s@AZSMGA002.ch.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by gabe.freedesktop.org (Postfix) with ESMTP id C51F99E7E7 for ; Tue, 28 Aug 2012 00:48:07 -0700 (PDT) Received: by wibhq4 with SMTP id hq4so3544397wib.12 for ; Tue, 28 Aug 2012 00:48:06 -0700 (PDT) Content-Disposition: inline In-Reply-To: <051c15$44688s@AZSMGA002.ch.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Chris Wilson Cc: Jani Nikula , Indan Zupancic , intel-gfx@lists.freedesktop.org, Takashi Iwai List-Id: intel-gfx@lists.freedesktop.org On Tue, Aug 28, 2012 at 08:16:54AM +0100, Chris Wilson wrote: > On Tue, 28 Aug 2012 09:53:36 +0300, Jani Nikula wrote: > > From: Daniel Vetter > > > > This is a prep patch to stop drm/i915 from changing the LBPC registers > > itself - but we still need to properly save/restore it on > > suspend/resume. > > My presumption was that there were BIOSes out there that only adjusted > the LBPC values, and so any device setting that flag would likely only > with it through the BIOS hotkeys. I couldn't see any other rational > reason for the hardware maintaining multiple interfaces... I've run a hackish version of this through a few bug reports and they reported that there's no more black screen at boot-up, but also that the backlight doesn't work. My conclusion was: - there are machines that are only controlled through the lbpc reg - some of those use lbpc in an inverted sense - we have now idea how to figure out the sense of lbpc Hence my thinking is that we should avoid to touch lbpc (but just restore it across suspend/resume since some machines need that) and rely on any firmware madness to properly adjust the backlight. I also realize that this will regress machines without working firmware, but for which the current lbpc-adjusting mess seems to do the right thing. But if the only regression this causes is some non-working backlight adjusting I'll ignore that, since it looks like we fundamentally can't do the right thing with lbpc, and this series here should kill a few black screen bugs. Cheers, Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48