Re: [PATCH v3] Idleness DRRS test

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 14, 2016 at 01:06:09PM +0000, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 02:44:35PM +0200, Petri Latvala wrote:
> > Chris, happy with this revision?
> 
> Me? No. It still uses a thread instead of events, so I don't think it
> qualifies as a good example for anyone else wanting to do the same thing.
> Lots of hardcoded expectations (specific sleep patterns, rather than
> waiting for the kernel to change with a timeout for failure). It doesn't
> check all the possible ways that the output maybe changed (and if they
> are irrelevent, that too also needs to be tested to establish expected
> behaviour and catch future regressions). Important question, how is
> userspace expected to know that the vrefresh changed? How do get around
> that userspace is expecting a fixed vblank frequency?

for display power testing we already have the kms_frontbuffer_tracking
testcase, adding a DRRS variants to that one should resolve all this.

And then kms_drrs would be empty, except when we (if ever) do explicit
drrs through modeset requests. And that would just be checking that the
observed timings match the requested timings.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux