[Intel-gfx] [RFC] Smattering of selftests

[Chris Wilson]

More changes to GEM are on the cards, so before touching it again, let's
try and nail down how the internals are meant to work. The advantage
of mock testing is that we can write a universal test independent of the
hw (e.g. testing physical object creation) and we can inspect internal
state which should be able to spot subtle bugs easier than mashing the
uabi. The downside to mock testing is that it doubles the upfront cost
of every patch submission (if you change internal state, you're likely
going to upset a test) and adds maintainance burden tracking change to
external API (on the other hand it catches those silent changes that
would lead to broken code).

In addition to mock tests, I thought it would be useful to start writing
a few run-once tests against real hardware. These are not as interesting
as probing uabi (I don't envisage having kms_flip inside the kernel),
but we might like to exercise runtime suspend once upon startup, for
example. Again, we have access to internal state that may prove
impossible to capture even in debugfs.

Is this a totally insane and impractical proposal?
-Chris