On Wed, Sep 16, 2015 at 01:48:49PM +0200, Maarten Lankhorst wrote: > Hey, > > Op 03-09-15 om 14:11 schreef Ville Syrjälä: > > On Thu, Aug 27, 2015 at 06:36:48PM +0300, ville.syrjala@xxxxxxxxxxxxxxx wrote: > >> From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > >> > >> Grab the connection_mutex around MSR link retraining to protect it > >> against a concurrent modeset. We already do the same for SST. > >> > >> DP hpd_pulse can still otherwise race against modeset and ->detect(), so > >> it's not clear what will happen when both want to scribble into eg. > >> intel_dp->dpcd[] at the same time. But sorting it all out requires way > >> more thought than I'm willing to expend now. > > Actually I suppose this might not work out so well after all. I suppose > > MST depends on short HPDs during modeset due to the sideband stuff. > > > > So if we want to grab modeset locks for retraining, I suppose we'd > > need to move the retraining to happen from .hot_plug() which gets run > > from the other hotplug work, and so wouldn't interfere with sideband. > > > I think it would be better to have a per encoder mutex. In the future we may want to run modeset > disable/enable async, in which case it may not hold the connection_mutex. > > If we do decide on a separate mutex then it would also be useful to also think about how to > protect intel_mst_*(dis,en)able_dp. :) We need to sync re-training with any other modeset work. Which means another thing to get right for async modesets. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
