[Intel-gfx] [RFC i-g-t] tests: add runtime_pm

Daniel Vetter daniel at ffwll.ch
Mon Oct 28 17:05:47 CET 2013


On Mon, Oct 28, 2013 at 10:20:56AM -0200, Paulo Zanoni wrote:
> 2013/10/27 Daniel Vetter <daniel at ffwll.ch>:
> > On Fri, Oct 25, 2013 at 11:44:05AM -0200, Paulo Zanoni wrote:
> >> From: Paulo Zanoni <paulo.r.zanoni at intel.com>
> >>
> >> This test is based on pc8.c. It copies most of the tests from pc8.c,
> >> but it depends on runtime PM status changes (parsed from sysfs)
> >> instead of PC8 residency changes (parsed from the MSR registers).
> >> There's also a test that checks for PC8 residency.
> >>
> >> For now, runtime PM and PC8 are different features, so having 2 test
> >> suites makes sense. In the future we'll merge both, so we'll only get
> >> PC8 when runtime PM is enabled, so we'll just kill pc8.c and keep
> >> using runtime_pm.c.
> >>
> >> Changes compared to pc8.c:
> >>   - We now look at the runtime PM status instead of PC8 residencies
> >>   - Added more GEM tests (mmap, pread, execbuf, stress tests)
> >>   - Added LPSP and non-LPSP tests
> >>   - Added tests fro sysfs and debugfs files
> >>   - Added a test specifically for PC8
> >>
> >> Signed-off-by: Paulo Zanoni <paulo.r.zanoni at intel.com>
> >
> > Since the actual tests we're running are so similar I prefer if we merge
> > all the runtime pm tests in one file. It makes testcase maintaince (and
> > bufixing, that happens) much easier. I guess a struct per runtime pm
> > method (pc8, D3, ...) with a few vfuncs should get things going. The
> > overall test would loop over all the pm methods and try to set things up.
> > Then loop over all subtests and either skip them all (if that particular
> > runtime pm method isn't supported) or just run them.
> >
> > We've had a few other case of massive copy&pasting in i-g-t and in the
> > past few months I've merged most of them back again.
> 
> At this moment I'm really leaning towards merging PC8 and D3 into a
> single feature, so it won't be possible to test them in separate
> anymore. With this, we'd just have runtime_pm.c and we'd completely
> kill pc8.c.

Yeah, I guess for hsw this makes sense. But it looks like we'll have all
kinds of different runtime pm features with all possible cuts between the
different domains going forward. Hence why I think a bit a more
generalized runtime pm test framework might be useful.
-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