> > ->hpd_pulse() is called from a workqueue via an interrupt so it happens > asynchronously with modesets. Grab the connection_mutex in > intel_dp_hpd_pulse() to avoid disturbing on angoing modeset with > parallel hpd processing. Nope, not right, we need to lock just not that amount of stuff, since MST won't work anymore, since it relies on hpd irqs while other threads are holding the locks to talk to the remote devices. I also think we shouldn't be locking the the irq processing in intel_dp_check_link_status. > On my IVB turning off the port during a modeset could result in a > hpd which would then proceed to link train while the modeset was > still happening. Suffice to say that didn't go so well. Does this not point to an ordering issue somewhere, we've turned off the port, but the device thinks the link should be trained but it currently isn't? maybe intel_dp_check_link_status needs to be smarter about something but we should be able to process the irqs fine without locking the modesetting locks. Or maybe we need to know that we don't want the link trained so don't retrain when the remote device signals a link status problem. Daniel, the only way intel_dp->is_mst can get reset is inside this path. Dave. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
