From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH] drm/i915: Fixup Oops in the pipe config computation Date: Fri, 12 Apr 2013 18:46:40 +0100 Message-ID: <20130412174640.GA16242@cantiga.alporthouse.com> References: <1365785323-4220-1-git-send-email-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id B0837E5CEB for ; Fri, 12 Apr 2013 10:47:01 -0700 (PDT) Content-Disposition: inline In-Reply-To: <1365785323-4220-1-git-send-email-daniel.vetter@ffwll.ch> 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 Graphics Development , stable@vger.kernel.org List-Id: intel-gfx@lists.freedesktop.org On Fri, Apr 12, 2013 at 06:48:43PM +0200, Daniel Vetter wrote: > Yet again our current confusion between doing the modeset globally, > but only having the new parameters for one crtc at a time. > > So that intel_set_mode essentially already does a global modeset: > intel_modeset_affected_pipes compares the current state with where we > want to go to (which is carefully set up by intel_crtc_set_config) and > then goes through the modeset sequence for any crtc which needs > updating. > > Now the issue is that the actual interface with the remaining code > still only works on one crtc, and so we only pass in one fb and one > mode. In intel_set_mode we also only compute one intel_crtc_config > (which should be the one for the crtc we're doing a modeset on). > > The reason for that mismatch is twofold: > - We want to eventually do all modeset as global state changes, so > it's just infrastructure prep. > - But even the old semantics can change more than one crtc when you > e.g. move a connector from crtc A to crtc B, then both crtc A and B > need to be updated. Usually that means one pipe is disabled and the > other enabled. This is also the reason why the hack doesn't touch the > disable_pipes mask. > > Now hilarity ensued in our kms config restore paths when we actually > try to do a modeset on all crtcs: If the first crtc should be off and > the second should be on, then the call on the first crtc will notice > that the 2nd one should be switched on and so tries to compute the > pipe_config. But due to a lack of passed-in fb (crtc 1 should be off > after all) it only results in tears. > > This case is ridiculously easy to hit on gen2/3 where the lvds output > is restricted to pipe B. Note that before the pipe_config bpp rework > gen2/3 didn't care really about the fb->depth, so this is a regression > brought to light with > > commit 4e53c2e010e531b4a014692199e978482d471c7e > Author: Daniel Vetter > Date: Wed Mar 27 00:44:58 2013 +0100 > > drm/i915: precompute pipe bpp before touching the hw > > But apparently Ajax also managed to blow up pch platforms, probably > with some randomized configs, and pch platforms trip up over the lack > of an fb even in the old code. So this actually goes back to the first > introduction of the new modeset restore code in > > commit 45e2b5f640b3766da3eda48f6c35f088155c06f3 > Author: Daniel Vetter > Date: Fri Nov 23 18:16:34 2012 +0100 > > drm/i915: force restore on lid open > > Fix this mess by now by justing shunting all the cool new global > modeset logic in intel_modeset_affected_pipes. > > v2: Improve commit message and clean up all the comments in > intel_modeset_affected_pipes - since the introduction of the modeset > restore code they've been a bit outdated. > > Bugzill: https://bugzilla.redhat.com/show_bug.cgi?id=917725 ^ Bugzilla > Cc: stable@vger.kernel.org > References: http://www.mail-archive.com/stable@vger.kernel.org/msg38084.html > Tested-by: Richard Cochran > Signed-off-by: Daniel Vetter I'm happier with that and with reducing the amount of confusion from the comments, Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre