From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH] drm/i915: Don't write DSPSURF for old chips Date: Thu, 01 Mar 2012 07:37:16 +0100 Message-ID: References: Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by gabe.freedesktop.org (Postfix) with ESMTP id 97CDCA0E7D for ; Wed, 29 Feb 2012 22:37:17 -0800 (PST) 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: Chris Wilson Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org At Wed, 29 Feb 2012 23:54:46 +0000, Chris Wilson wrote: > > On Tue, 28 Feb 2012 07:43:55 +0100, Takashi Iwai wrote: > > At Mon, 27 Feb 2012 14:08:28 +0100, > > Takashi Iwai wrote: > > > > > > At Mon, 27 Feb 2012 12:17:57 +0000, > > > Chris Wilson wrote: > > > > > > > > On Mon, 27 Feb 2012 12:39:24 +0100, Takashi Iwai wrote: > > > > > It seems that writing DSPSURF in intel_flush_display_plane() causes > > > > > the blank screen on some old laptops like Dell D630 with 965GM. > > > > > Since this operation is needed only for ILK+, make it conditional. > > > > > > > > The specs say that DSPASURF is the latch register for updates of the DSPA > > > > registers on gen4 (including 965gm) as well. Presumably the bug is that > > > > we only partially update the DSPA registers prior to the first call to > > > > intel_flush_display_plane() which this papers over by disabling the > > > > update until a valid address is written to DSPASURF. And there is such a > > > > spurious call to intel_enable_plane() prior to us setting a valid > > > > scanout surface: > > > > > > Sounds reasonable. FWIW, the change was first introduced in commit > > > [b24e7179: drm/i915: add pipe/plane enable/disable functions], > > > then in commit [efc2924e: drm/i915: Call intel_enable_plane from > > > i9xx_crtc_mode_set (again)], it's placed into i9xx_crtc_mode_set(). > > > > > > This explains the fact that it was discovered only on old machines > > > as i9xx_crtc_mode_set() is the only crtc_mode_set op calling > > > intel_enable_plane(). > > > > > > BTW, the bisection leaded to a merge commit, so the bug is really > > > depending on the activation path or timing. > > > > > > I'll ask a tester to try your patch. > > > > He reported back that it reduces the failure rate but doesn't fix > > completely. Still get a blank screen in 20% rate. > > > > Any other clue? > > I haven't yet found anything else in the same vein as this, but the > 965gm does ring a warning bell for this recent regression: > > commit 5ca0c34ae28344b6b4ca3036bc82f89c8db16a59 > Author: Dave Airlie > Date: Thu Feb 23 15:33:40 2012 +0000 > > drm/i915: fix mode set on load pipe. (v2) > > Booted my i965 machine and it started printing the unsupported pixel > format of 0 message (once I added content to it). > > Oh looksie here, we pass 0. fix. > > v2: compile it. > > Buzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45966 > > Reviewed-by: Daniel Vetter > Reviewed-by: Chris Wilson > Signed-off-by: Dave Airlie > Signed-off-by: Jesse Barnes > > which is currently sitting in airlied/drm-fixes. Hm, this must be irrelevant (inapplicable) because the tests were done with 3.1, 3.2 (and SLE11-SP2 kernels which has backports from 3.3-rc2 but without these fixes). The bug seems to have been introduced between 3.0 and 3.1. thanks, Takashi