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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
