From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH] drm/i915: Treat resetting of the current framebuffer as a no-op Date: Fri, 31 May 2013 18:50:09 +0100 Message-ID: <20130531175008.GA11399@cantiga.alporthouse.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="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from fireflyinternet.com (s16502780.onlinehome-server.info [87.106.93.118]) by gabe.freedesktop.org (Postfix) with ESMTP id ECAB9E63E8 for ; Fri, 31 May 2013 10:50:12 -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 things > >> 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 ... Hopefully we can push the check higher to the fb fast path then? The skip is much safer in the kernel as it has correct knowledge of the current state (as opposed to trying to track it the ddx sharing control of the machine). -Chris -- Chris Wilson, Intel Open Source Technology Centre