On Wed, Jul 13, 2016 at 01:59:52PM +0200, Daniel Vetter wrote: > I think the proper solution should be to make all the probing and fbdev > restoring async. As soon as we have working async atomic commit for > modeset we should be able to do all that. We're not just blocked on the mode change here (indeed, we shouldn't be changing modes at resume at all, right?) but we appear to be doing a full detection cycle whereas the intent was just to tell userspace everything had changed, and for it to go figure out what to do about it. Also note that we can simply move this all out of the blocking resume path and still run this in parallel to userspace resuming (and of course serialised with whatever userspace wants to do). -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
