[Intel-gfx] [PATCH] drm/i915: Fixup Oops in the pipe config computation

[Chris Wilson]

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 at ffwll.ch>
> 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 at ffwll.ch>
> 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 at vger.kernel.org
> References: http://www.mail-archive.com/stable@vger.kernel.org/msg38084.html
> Tested-by: Richard Cochran <richardcochran at gmail.com>
> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>

I'm happier with that and with reducing the amount of confusion from the
comments,
Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre