From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 08/33] drm/i915: SWF screatch registers need an offset on VLV Date: Fri, 25 Jan 2013 17:21:01 +0100 Message-ID: <20130125162101.GN23080@phenom.ffwll.local> References: <1359034198-19678-1-git-send-email-ville.syrjala@linux.intel.com> <1359034198-19678-9-git-send-email-ville.syrjala@linux.intel.com> <20130124213728.GG31306@phenom.ffwll.local> <20130125122624.GX9135@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by gabe.freedesktop.org (Postfix) with ESMTP id C238EE5DED for ; Fri, 25 Jan 2013 08:18:55 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id l10so291127eei.3 for ; Fri, 25 Jan 2013 08:18:54 -0800 (PST) Content-Disposition: inline In-Reply-To: <20130125122624.GX9135@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: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Fri, Jan 25, 2013 at 02:26:24PM +0200, Ville Syrj=E4l=E4 wrote: > On Thu, Jan 24, 2013 at 10:37:28PM +0100, Daniel Vetter wrote: > > On Thu, Jan 24, 2013 at 03:29:33PM +0200, ville.syrjala@linux.intel.com= wrote: > > > From: Ville Syrj=E4l=E4 > > > = > > > Signed-off-by: Ville Syrj=E4l=E4 > > = > > It's true that we safe/restore these suckers across suspend/resume, but= I > > have no idea why or whether we need to. Since there's no way we'll ever > > support ums on vlv I think we should just try to guard the safe/resume > > code with DRIVER_MODESET checks and drop this chunk here. > > = > > Or too risky? > = > No idea. I suppose some silly BIOS might assume that some of these regs > retain their contents. Since opregion the driver/bios collaboration is rather well-defined, so I think we could risk it by guarding the safe/restore code with a (DRIVER_MODESET && opregion) check. Of course, if anyone knows anything to the contrary we need to reconsider. -Daniel -- = Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch