On Tue, Mar 10, 2015 at 12:32:43PM +0000, Tvrtko Ursulin wrote: > > On 03/10/2015 12:19 PM, Chris Wilson wrote: > > On Tue, Mar 10, 2015 at 12:02:28PM +0000, Tvrtko Ursulin wrote: > >>> @@ -13707,13 +13709,18 @@ void intel_modeset_gem_init(struct drm_device *dev) > >>> NULL)) { > >>> DRM_ERROR("failed to pin boot fb on pipe %d\n", > >>> to_intel_crtc(c)->pipe); > >>> - drm_framebuffer_unreference(c->primary->fb); > >>> - c->primary->fb = NULL; > >>> - update_state_fb(c->primary); > >>> + unused[n_unused++] = c->primary; > >>> } > >>> } > >>> mutex_unlock(&dev->struct_mutex); > >>> > >>> + while (n_unused--) { > >>> + struct drm_plane *p = unused[n_unused]; > >>> + drm_framebuffer_unreference(p->fb); > >>> + p->fb = NULL; > >>> + update_state_fb(p); > >>> + } > >>> + > >> > >> For this one I am not sure. Should c->primary->fb = NULL remain > >> under the locked loop? If not what is the the mutex protecting then? > > > > It's a dummy mutex that only exists to keep the WARNs quiet. This phase > > of initialisation is explicitly single-threaded. > > Would it be a simpler fix then to move the mutex only around > pin_and_fence_fb_obj? That would be much nicer indeed. -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx