[PATCH] drm/i915/vlv: don't try to enable a crtc without fb

[Rob Clark]

On valleyview, all enabled pipes get added to the prepare mask.  However
if you did state readout to find that the crtc is enabled, but failed to
map stolen mem and wrap it in a bo (and fb), you could end up in a
scenario where crtc->primary->fb is still null on first modeset.  So
lets check for this rather than exploding.

Signed-off-by: Rob Clark <robdclark at gmail.com>
---
As with http://lists.freedesktop.org/archives/dri-devel/2014-September/069341.html
the root cause is issues with stolen region.  But it would be nice if
i915 was a bit less fragile when things don't go as planned.

This could have the side effect that, at first modeset, the crtc's which
were enabled by BIOS but not yet set (by fbcon or userspace) get disabled.
This is a somewhat lesser inconvenience compared to opps'ing under
console_lock.

 drivers/gpu/drm/i915/intel_display.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index d8324c6..9f85033 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10895,6 +10895,9 @@ static int __intel_set_mode(struct drm_crtc *crtc,
 
 	/* Now enable the clocks, plane, pipe, and connectors that we set up. */
 	for_each_intel_crtc_masked(dev, prepare_pipes, intel_crtc) {
+		if (!intel_crtc->base.primary->fb)
+			continue;
+
 		update_scanline_offset(intel_crtc);
 
 		dev_priv->display.crtc_enable(&intel_crtc->base);
-- 
1.9.3