On Wed, Jul 13, 2016 at 01:09:28PM +0100, Chris Wilson wrote: > 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). And to remind myself of conversations going on elsewhere, the more async we make resume the more inaccurate the current method of measuing resume time becomes (which more or less just looks at the initcall graph). We need a metric that measures the time from resume to the time of first pixel (first flip to a lit display preferably). I've shown how we can get our "resume time" down to about 10ms - all because the metric is subject to abuse. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
