From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH] drm/i915: Sanitize cursors on driver load Date: Fri, 16 May 2014 20:22:22 +0300 Message-ID: <20140516172221.GV27580@intel.com> References: <1400258219-19420-1-git-send-email-chris@chris-wilson.co.uk> <20140516165352.GU8790@phenom.ffwll.local> <20140516170229.GG3473@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id BAF7C6F005 for ; Fri, 16 May 2014 10:23:34 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20140516170229.GG3473@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Chris Wilson , Daniel Vetter , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Fri, May 16, 2014 at 06:02:29PM +0100, Chris Wilson wrote: > On Fri, May 16, 2014 at 06:53:52PM +0200, Daniel Vetter wrote: > > On Fri, May 16, 2014 at 05:36:59PM +0100, Chris Wilson wrote: > > > Extremely unlikely to ever be required, but BIOSes do like to attack = in > > > unexpected ways. > > > = > > > Signed-off-by: Chris Wilson > > > --- > > > drivers/gpu/drm/i915/intel_display.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > = > > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i= 915/intel_display.c > > > index a943ea7..5583e9b 100644 > > > --- a/drivers/gpu/drm/i915/intel_display.c > > > +++ b/drivers/gpu/drm/i915/intel_display.c > > > @@ -11817,6 +11817,8 @@ static void intel_sanitize_crtc(struct intel_= crtc *crtc) > > > /* Adjust the state of the output pipe according to whether we > > > * have active connectors/encoders. */ > > > intel_crtc_update_dpms(&crtc->base); > > > + intel_crtc_update_cursor(crtc, > > > + intel_crtc->active && intel_crtc->cursor_bo); > > = > > Should we do this for sprite planes, too? That way it would be nice fod= der > > for Matt to clean up later on ;-) > = > * pokes Ville ;-) The problem I see here is that we would end up restoring twice, first in sanitize while we're still using whatever mode we get handed, and later when we restore the mode we actually want. So if we start restoring in sanitize based on the state userspace requested before we suspended, we might end up in some weird plane flicker land. Just forcing all the extra planes off in sanitize should be OK. Or we do the restore only when force_restore=3D=3Dfalse, which means driver init and so we can't even have any user space state to worry about. So really the two options should both result in just turning all the extra planes off. -- = Ville Syrj=E4l=E4 Intel OTC