From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [pull] drm-intel-next Date: Mon, 18 Mar 2013 21:59:57 +0100 Message-ID: References: <20120913141841.GC5693@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: 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: =?ISO-8859-1?Q?St=E9phane_Marchesin?= Cc: Intel Graphics Development , DRI Development List-Id: dri-devel@lists.freedesktop.org On Mon, Mar 18, 2013 at 8:35 PM, St=E9phane Marchesin wrote: > >> For starters I guess we need: >> - drm.debug=3D0xe dmesg from just before that commit >> - same for latest 3.9-rc kernels, presuming it's not broken there >> >> Latest upstream has a minor chance to work better I think since we've >> improved the pfit handling in the setup and teardown sequence a bit. >> >> Generally lvds has been hit&miss on way too many machines >> unfortunately with things randomly breaking and getting fixed again >> (e.g. one of Chris' machines works again with the new code ...). And >> the commit above doesn't really change much in the code itself but it >> does change the order (and timing) of the different enable/disable >> codepaths. > > So I did look at the thing a bit, and it triggers the workaround > if (INTEL_INFO(dev)->gen < 4 && !intel_check_plane_mapping(crtc)) { > which seems to be part of the problem (but not the whole problem as > removing that gets me a corrupted display, looks like the second pipe > stays enabled then). Well, that particular piece of lore took a few trials to get right. Can you please attach a drm.debug=3D0xe dmesg of the entire boot on latest kernels? Thanks, Daniel -- = Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch