[Intel-gfx] [PATCH igt] igt/kms_flip: Calibrate timestamp errors

[Chris Wilson]

On Thu, Oct 27, 2016 at 01:13:59PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 27, 2016 at 08:43:44AM +0200, Daniel Vetter wrote:
> > On Wed, Oct 26, 2016 at 12:17:25PM +0300, Ville Syrjälä wrote:
> > > On Wed, Oct 26, 2016 at 08:18:13AM +0200, Daniel Vetter wrote:
> > > > On Mon, Oct 24, 2016 at 10:38:34AM +0100, Chris Wilson wrote:
> > > > > On Mon, Oct 24, 2016 at 11:14:31AM +0200, Daniel Vetter wrote:
> > > > > > On Mon, Oct 24, 2016 at 09:54:52AM +0100, Chris Wilson wrote:
> > > > > > Also with this patch we should be able to throw out the hacks for tv-out.
> > > > > > I only added those because the reported mode-timings are massively off
> > > > > > (due to the magic tv scaler thing) from the real timestamps we receive.
> > > > > > Auto-detecting this is much better.
> > > > > 
> > > > > Not quite just yet, we need to split the timing tests into a subgroup
> > > > > with a subtest per output so that we can skip one without skipping the
> > > > > others. At the moment, this check makes it bail out on my ctg/ilk who
> > > > > have a difference of about 50us between measured and expected vblank
> > > > > interval on LVDS (which is nigh on impossible given our confidence in the
> > > > > measurement, i.e. about 7 sigma).
> > > > 
> > > > Hm, should we be a bit more sloppy in our acceptance? Iirc Ville has made
> > > > changes to make it a bit more strict a while ago, and way, way back this
> > > > stuff worked on my ctg. Haven't fired it up in a while ;-)
> > > > 
> > > > > > And another issue: Failing to match the reported mode timings is a driver
> > > > > > bug.
> > > > > 
> > > > > Not quite, remember we override the user for fixed mode panels. But yes,
> > > > > piglit also has a similar expectation that the dotclock we report (via
> > > > > GetMscRate) in someway corresponds to actual vblank interval.
> > > > 
> > > > Yeah, I hope that DRRS would fix that, at least on newer stuff. At least I
> > > > proposed just using the matching dotclock for manual DRRS (mostly to
> > > > perfectly match with the refresh rate of a video). Didn't yet happen :(
> > > > 
> > > > But at least for the default mode we should try real hard to match.
> > > 
> > > The problem is the granularity of the PLL. For fixed mode panels we
> > > could easily fix up what we report to userspace as the clock, which
> > > would fix these tests. For external displays it's not quite so clear.
> > 
> > Over-the top idea would be to adjust the reported modlines to match what
> > we can do with the PLL on each platform. Probably not worth the trouble,
> > but I guess if we bother with this for panels it won't be more work
> > really.
> 
> Yeah for panels it should be quite doable. For external displays we may
> run into problems with cloning (maybe would affect the PLL limits and
> whatnot, can't recall exactly). And at least HDMI 12bpc would still
> affect the clock you can get so not clear if we should report the 8bpc
> one or the 12bpc one, or maybe both?
> 
> Hmm, or do you mean just adjuting the mode blob on the crtc? I think
> that might confuse userspace if it compares that against what it
> thought it set, or against the thing it pulled off from the connector's
> mode list. We could add some kind of "actual pixel clock" type of
> property though. Or even an "actual mode" blob if the driver would feel
> the need to fudge things just a little to get a picture on the screen.

So does the adjusted_mode match reality? Just exposing that as a blob
seems reasonable... However, will also have to propagate the
check-after-set to randr clients. I can make it work for GetMscRate()
which is probably enough for the majority (by doing a query for the
current crtc mode and ignoring the connector modes).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre