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

From: Chris Wilson <chris@chris-wilson.co.uk>
To: Daniel Vetter <daniel@ffwll.ch>,
	Sonika Jindal <sonika.jindal@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/5] drm/i915: Check live status before reading edid
Date: Wed, 13 Jul 2016 13:17:40 +0100	[thread overview]
Message-ID: <20160713121740.GF6157@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <20160713120928.GE6157@nuc-i3427.alporthouse.com>

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx