In digging into the async crtc stuff, I found it was going to be really difficult to prevent other functions from getting clobbered by a delayed crtc enable or disable. Daniel's work to remove a bunch of the ->mode_set callbacks is a good start, but we still end up doing some reg reads and writes in the mode set path today. Until those are cleared up and we somehow enforce a rule that all hw changes go through the crtc enable/disable paths with everything else staged in multithread safe structs, I don't think the async crtc approach will be solid. So, since resume is the biggest issue here anyway, I've tried making just the resume mode set asynchronous. Even this is a bit tricky, since we need to apply any pending mode set at certain points, then check whether the crtc we're operating on in any given path is still active. I think I've caught those cases here, but if we have more we can use the intel_sync_mode_set() call with appropriate post-call checks (after we re-acquire the corresponding crtc mutex). Feedback welcome. This has seen light testing on my BYT and really reduces the time spend in the i915 _thaw function, letting userspace start running much sooner than before. Thanks, Jesse _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx