[Intel-gfx] [RFC] More structure for igt_kms tests

Daniel Vetter daniel at ffwll.ch
Fri Jul 11 10:19:23 CEST 2014


Hi all,

So kms tests have rather ugly control flow compared to other tests. And
the pattern is usually the same:

- A subtest loops over a set of possible configurations to test and tries
  igt_commit. If that fails then it needs to manually reset the
  igt_display state and go to the next possible configuration.

- A counter needs to keep track of the number of successfully applied
  configurations so that the test can decide to either skip (no config
  worked out) or succeed - failures will have bailed out earlier.

The result is a lot of:
- Fragile control flow code (since e.g. only few platforms have
  restrictions on the connector->pipe links like lvds on gen2/3 and dp on
  chv).
- Fragile result computation logice - everyone has to duplicate the little
  bit of accounting to correctly skip/succeed.
- Duplicated code (especially for the cleanup and try handling).

I have a few ideas how we can improve:

1. We need an igt_display_reset to bring the configuration back to a known
state. Imo that should be everything turned off and all properties (where
known to the framework like e.g. rotation) reset to defaults. We probably
need to make an igt_commit as part of this to avoid fun with strange state
transitions.

2. New control flow block macros for display tests. I'm thinking of a
special-cases igt_display_subtest (to make sure the special skip/succeed
logic doesn't get lost) and a new igt_display_try block like this:

igt_display_subtest("foo") {
	for_each_possible_config {
		/* set up the igt_display config with the igt_kms library */

		/* Tries to commit the display config and skips the entire block
		 * on failure. */
		igt_display_try(display) {
			/* actual test code */
		}
		/* Implicit state reset for the entire display
		 * structure. The explicit call would be

		igt_display_reset();

		 * This is part of the igt_display_try block.
		 */
	}

	/* Implicit call to igt_display_result which skips/succeeds depending
	 * whether at least one config worked. Explicit call would be
	 
	igt_display_result();
	
	 * This is part of the igt_display_subtest block.
	 */
}

igt_display_try would also assert that it's called from within an
igt_display_subtest block. And I guess we should disallow nesting.

Comments?

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch



More information about the Intel-gfx mailing list