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@xxxxxxxxx> --- 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
