From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH] drm/i915: Treat resetting of the current framebuffer as a no-op Date: Fri, 31 May 2013 19:32:48 +0300 Message-ID: <20130531163247.GZ5004@intel.com> References: <1369313837-31764-1-git-send-email-chris@chris-wilson.co.uk> <20130523212752.GE15743@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id D80CBE5C52 for ; Fri, 31 May 2013 09:33:13 -0700 (PDT) Content-Disposition: inline In-Reply-To: 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: Daniel Vetter Cc: intel-gfx List-Id: intel-gfx@lists.freedesktop.org On Fri, May 31, 2013 at 05:15:10PM +0200, Daniel Vetter wrote: > On Fri, May 31, 2013 at 4:05 PM, Paulo Zanoni wrote: > > 2013/5/23 Daniel Vetter : > >> On Thu, May 23, 2013 at 01:57:17PM +0100, Chris Wilson wrote: > >>> If none of the CRTC parameters change along with the framebuffer, we = can > >>> forgo rewriting the register and waiting for a vblank. There are a few > >>> calls made by the display managers as they start up which tend to end= up > >>> performing no-ops on the current CRTC settings. > >>> > >>> Signed-off-by: Chris Wilson > >> > >> Makes sense. Queued for -next, thanks for the patch. Now the only thin= gs > >> left (besides beating fastboot into good shape) is to cache the edids a > >> bit and we've (hopefully) killed all kms stalls at startup ... > > > > This commit introduced a regression. > > > > - Boot with both eDP and DP plugged > > - When I boot like this, eDP1 has 1920x1080 and DP1 has 1920x1080i. > > - Run "xrandr --output DP1 --mode 0x55" (that's 1024x768@60Hz here) > > - See the black screen on DP output, dmesg has the "skipping reset of > > current fb" message. > > - After we get the black screen, if we run "xrandr --output DP1 --off; > > xrandr --output DP1 --mode 0x55" the mode will work. > > > > If I diff the "bad state" with the "good state" we'll see the cause is > > the DSPCNTR register. When we do the early return in > > intel_pipe_set_base we don't call the update_plane function. For me > > what changes is the pixel format and the trickle feed bits. > = > Oh, in the modeset case we can't optimize the update_fb away, even > when both fbs are the same ... I think there are two problems currently: 1) .crtc_mode_set will clear DSPCNTR, so .update_plane() is needed to re-populate the relevant bits 2) We no longer do a tiling_mode check on the obj. That's done in intel_pin_and_fence_fb_obj() which is now skipped too. I've been pondering whether we should just prevent tiling changes for any obj with fbs... > = > Just to check that our level of paranoia is still high enough: Has the > modeset state checker complained or not? > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- = Ville Syrj=E4l=E4 Intel OTC