diff options
author | Daniel Vetter <daniel.vetter@ffwll.ch> | 2014-03-26 21:30:17 +0100 |
---|---|---|
committer | Daniel Vetter <daniel.vetter@ffwll.ch> | 2014-03-26 21:33:38 +0100 |
commit | 669a2fca6c5ccd256d2d767107963840f7de438e (patch) | |
tree | 5c8bc2036033d2a619635e735d2302a5aae3e829 /tests | |
parent | 896b550984cf3ffd0fa67051d5b9cf0239634894 (diff) |
tests/pm_rps: quiescent harder
Apparently some rps chips are prone to stick to max once you're there.
And all the synchronous waits in gem_quiescent_gpu are _really_ good
at forcing the kernel to go full throttle.
And even a positively tiny load (one MI_STORE_IMM per 50 ms) is enough
to eternally keeep it there, which means the first idle measurement of
the freqs before we do the reset it completely busted.
Just add a wait before the tricky test and call it a day.
Option b) would have been to now have this tiny load, but I think a
good reminder how quirky rps is is always welcome. Just in case we
start sleeping too easy at night.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74956
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'tests')
-rw-r--r-- | tests/pm_rps.c | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/tests/pm_rps.c b/tests/pm_rps.c index 157f9e39..7898e78c 100644 --- a/tests/pm_rps.c +++ b/tests/pm_rps.c @@ -488,6 +488,12 @@ static void reset(void) int pre_freqs[NUMFREQ]; int post_freqs[NUMFREQ]; + /* + * quiescent_gpu upsets the gpu and makes it get pegged to max somehow. + * Don't ask. + */ + sleep(10); + igt_debug("Apply low load...\n"); load_helper_run(LOW); stabilize_check(pre_freqs); |