[Intel-gfx] [PATCH] drm/i915: Always wake the device to flush the GTT

[Daniel Vetter]

On Wed, Aug 30, 2017 at 04:13:41PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2017-08-30 14:59:32)
> > On Wed, Aug 30, 2017 at 01:56:40PM +0100, Chris Wilson wrote:
> > > Quoting Daniel Vetter (2017-08-30 13:23:56)
> > > > Or just the need to add a pile more tests to pm_rpm?
> > > 
> > > No. It's just your regular combinatorial explosion. The approach I would
> > > take here would be to register a sysenter callback that attempted to do a
> > > rpm suspend (i.e. so ~every ioctl would start from idle, and controlled
> > > via the faultinjection framework) and then run the minimal test set that
> > > exercises all ioctl paths, and then expand to all driver branches.
> > > 
> > > First we need coverage feedback.
> > 
> > What I meant to imply: As long as any display is on we will never rpm
> > suspend. Mostly this is the case for CI machines.
> > 
> > The new testcases I've had in mind would explicitly dpms off the display
> > before running a set of gem testcases. We don't want to do that everywhere
> > though, because a dpms on/off is very costly.
> 
> If no userspace is using the display and we remove fbcon, shouldn't the
> kernel be disabling the outputs anyway? There's literally nothing there
> to provide display continuity.

Fastboot will take over boot-up state and keep it running until a kms
client takes over. Once that happened, we'll have dropped the bios fb on
the floor and will shut down all outputs on close (due to removal of the
userspace fbs).

Which means if you want to rely on that, then how your test behaves
depends upon when we last had to reboot, and whether a kms test has run
before you. That's really bad from a "too much noise in CI" pov (because
with the full sharded run it's somewhat randomized each time).

Also, we have fbcon tests in igt, so disabling fbcon isn't an option
really.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch