[Intel-gfx] [PATCH i-g-t 1/2] kms_pipe_crc_basic: Only test one pipe in the basic set
Daniel Vetter
daniel at ffwll.ch
Tue Apr 26 13:54:51 UTC 2016
On Mon, Apr 25, 2016 at 08:12:41PM +0000, Zanoni, Paulo R wrote:
> One of the things about our driver is that it tries to be very very
> conservative regarding the eDP timings, leading to waits longer than
> necessary for pretty much everyone. We tried to optimize this in the
> past, but due to the fact that we have a single code base to support
> every product released since gen 2, pretty much any sort of
> optimization attempt tends to break someone's machine because maybe
> they have a bad BIOS or a bad VBT or a bad panel or something else. Now
> that this problem is impacting our ability to run tests, maybe it is
> time to start thinking about these optimizations again?
>
> If you want to investigate this, you could start by looking at the
> patches stored here:
>
> https://cgit.freedesktop.org/~pzanoni/linux/?h=edp-reverts
>
> The first patch adds an option that you could try to play it, and the
> other patches contain references to my previous optimization attempts
> that ended up being reverted. You'll have to search the mailing list
> for the actual regression reports. Feel free to adopt the patches and
> change them.
>
> Perhaps we could also think about some local changes that would only
> optimize QA's systems, like a module option used by them? The problem
> is that this would mean QA wouldn't be testing exactly what's upstream.
> Still, it could be worth it, depending on how much time it saves.
Broken record, but I don't like code disabled by default. What we could
try is to get this merged & enabled, but only for recent-ish vbt version.
That way the support nightmare should be manageable, and hopefully we can
figure out for recent firmware how it's supposed to work.
CI could then still use the option to enable fast timings everywhere (or
at least on those machines where it works).
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the Intel-gfx
mailing list