On Wed, Jul 13, 2016 at 01:17:40PM +0100, Chris Wilson wrote: > 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.
Good news on this front -- it seems that the SuspendResume tool can be adapted to measure our resume-time even if we "cheat", and the author offered to help with this. So we "just" need to decide what actually constitutes being done with resume. Kind regards, David _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
