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 <daniel.vetter@xxxxxxxx> > 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 <daniel.vetter@xxxxxxxx> > 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@xxxxxxxxxxxxxxx > References: http://www.mail-archive.com/stable@xxxxxxxxxxxxxxx/msg38084.html > Tested-by: Richard Cochran <richardcochran@xxxxxxxxx> > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> I'm happier with that and with reducing the amount of confusion from the comments, Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html