[Intel-gfx] [PATCH] drm/i915/mst: fix pipe and vblank enable

[Sarvela, Tomi P]

> From: Jani Nikula <jani.nikula at intel.com>
> 
> On Mon, 10 Feb 2020, Arkadiusz Hiler <arkadiusz.hiler at intel.com> wrote:
> > As of the 3 days worth of queued shards:
> >
> > I agree that this is unacceptable, but we can do only so much from the
> > CI/infra side. The time has been creeping up steadily over the last year
> > or so and the machines are not getting any faster.
> 
> I am *not* trying to say that it's all your fault and you need to
> provide all results faster for the ever-increasing firehose of incoming
> patches.
> 
> I'd like to pose the question, what would all this look like if we made
> it a hard requirement that we need a go/no-go decision on every patch
> series within 24 hours? I emphasize that I don't mean full results in 24
> hours. Given all the other constraints, how could we provide as much
> useful information as possible within 24 hours to make a decision?
> 
> In another thread I said, we've shifted a bit from review being the
> bottle neck to shard runs being the bottle neck. It's still much more
> likely that a patch will change due to review feedback instead of shard
> run results. Half a dozen rounds of review ping pong directly leads to
> half a dozen rounds of mostly unnecessary testing. I would not outright
> dismiss only running full igt on reviewed/acked patches.

This is actually a good idea. In practice, the shards are swamped by the
amount of builds today, and the throughput has been close to 1/h a long
time, even with work ongoing to prune or tighten stupidest IGT tests.

We could make the shard run requirements stricter: in addition to passing
BAT it would need some amount of Acks. Patchwork already collects them.

Another idea has been moving the serialized shard run queue to something
that can handle reordering: trybots can be moved after everything else. This
doesn't affect to the shard queue length though, if we still want to test
everything.

> Additionally, there are smaller optimizations to be made (obviously all
> depending on developer bandwidth to implement this stuff), such as
> identifying patches that don't change the resulting binary
> (comment/documentation/whitespace changes), and only running build
> testing on them.

This idea has been floating around, and would help in 5% changes or so
(which is still noticeable: 1-2 more builds / day tested instead of queued).

Just need a good diff checker that says "text changes only, skip it".

Tomi