Re: [PATCH 4/5] drm/i915: Check live status before reading edid

[David Weinehall <david.weinehall@linux.intel.com>]

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