Very basic since I lack a bit ideas. After all with the latest
patches runtime pm doesn't make much a difference between dpms off
and disabling the outputs completely with SetCrtc.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The PC8 state won't be entered unless runtime PM is enabled, so support
for PC8 residency counters alone is not enough to run this test.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Shorter and more in line with our general igt_ prefix for everything
which isn't somehow intel or i915-gem or otherwise hw specific - these
helpers here are all fully generic framebuffer handling functions
based on kms + cairo.
Well, the actual buffer alloc is done with i915 gem, but meh ;-)
Two special cases:
- bpp_depth_to_drm_format and drm_format_to_bpp completely lacked
prefixes, so just add igt_.
- write_fb was a bit misleading given that we have gem_write for
uploading to buffers. Rename that to write_fb_to_png to make it
crystal clear what this thing does even without looking at docs.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the new-style function using drm fourcc codes instead everywhere.
To easily use thew fourcc based interface also expose
bpp_depth_to_drm_format from the library. Finally include drm_fourcc.h
from the igt_kms.h header since pretty much everyone needs this now.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the header cleanup we can now give this header a suitable name,
since it now really only contains register access and other I/O
functions and assorted definitions.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... and I immediately regret that I've killed the return value
for igt_debugfs_init, since we have callers which need to work
without the forcewake stuff, e.g. the reg dumper needs to work
without i915 loaded.
Put this new helper to good use in the mmio code and the pm_pc8
testcase.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I used to have a binary that would just disable all the screens - so
we can enter PC8/runtime PM - and then sleep forever. I used this
binary many times while debugging PC8 and runtime PM, and I also sent
the binary to many people so they would be able to test these things
without X running.
Since pm_pc8 already implements everything that the separate binary
needs, and it even has some additional code to try to configure the
environment to actually reach PC8, it's easier to just ask people to
run "sudo ./pm_pc8 --stay" instead of sending them a file, asking them
to compile it, setup the environment, and then run it.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Currently the test suite just looks at the files provided by the
runtime power management framework to check if the device is runtime
suspended. Add a test that reads the PCI config space to check if the
device is actually in PCI D3 state or not.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
After I finally fixed the code that WARNs if we're runtime suspended
when reading registers I started getting the WARNs, so this test
should reproduce them on a Kernel with the problem.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Just in case it's compile with M instead of Y. If the module is not
there, the other assertions will catch the problem.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Just in case the module is compiled with M instead of Y. If the module
is not there, the other assertions will catch the problem.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
This sleep was added because sometimes we didn't reach PC8+
residencies, but it was still not enough to prevent the problem every
time, and it is really not needed most of the times. I have
investigated more and it seems that we only have to wait until after
some minutes have past since the machine booted. So just remove the
sleep for now since when you run each subtest in a separate process,
you end up having to sleep at every subtest.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
cairo_t is the short lived drawing context, whereas cairo_surface_t is
the heavyweight object that persists and is also tied to underlying GEM
objects. So make the kmstest API reflect the different weights and fix
the lifetime and underlying object reference leaks.
Based on the fix by Paulo Zanoni.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
QA reported a failure that I believe happened because we couldn't
become DRM master, so add code that checks for this and prints a nice
error message.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
This one was missing. For some reason we never really detected it on
our test suite. I checked the Kernel source and now we should be fine.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Instead of creating a new FB every time we need one, create a cache of
FBs and reuse whenever possible. That means we'll create at most two
FBs, and reuse them hundreds and hundreds of times.
The kmstest_paint_test_pattern function takes about 1-2 seconds to
run, and we'll avoid it whenever we reuse the FB.
This makes the time taken to run the modeset-lpsp-stress subtest go
from 2:29 to 1:29.
A full "time ./pm_pc8 --quick" goes from 8:14 to 6:27.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
If we want to actually reach PC8+ states, we need to properly
configure all the devices on the system to allow this. This function
will try to setup the things we know we need, but won't scream in case
anything fails: we don't know which devices are present on your
machine, so we can't really expect anything, just try to help with the
more common problems.
Another reason for this commit is that I got tired of having to
readjust the runtime PM policies every time I reboot my machine.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Not meant to be used on the QA cycles, but by developers who just want
to quickly check things while doing development. Reduces the total
time from 27 minutes to 6 minutes on my machine.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
I was suspecting some problems just happen if we have a bigger wait
than the current ones we have, so add a new WAIT_EXTRA flag just to
see if the problems really happen. Also, add support for the wait
flags on the gem stress tests, and use them.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
It's not executed by default, and it's completely relying on Haswell
registers and on internal knowledge of how the Kernel is supposed to
work. Since we plan to test generic runtime PM on all supported
platforms, maintaining this test so it works on all those platforms
will be a pain. We already have some ideas on how to verify registers
that must stay at specific values from inside the Kernel, so let's
kill this test and wait until the proper Kernel code gets merged.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Since we're not only testing PC8 anymore, we're resting "PM", rename
some variables from something_pc8 to something_suspend, just to make
it not-so-confusing.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
We don't wake up from forcewake when we only have PC8, but not runtime
PM, so make the test pass.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
If you really want to reach the PC8+ states and consequently get PC8+
residency, you need to properly configure all the devices on your
machine to allow PC8+, not just graphics. The current code for PC8
checks for PC8+ residency everywhere, so if you have a machine that's
not properly configured you'll fail every test. OTOH, even if your
machine can't reach the PC8+ states, it will still try to enable and
disable PC8, so we can try to test the feature even if we're never
really reaching the PC8+ states. Also, if your machine does allow PC8+
residencies, but some other driver/program decides to keep the machine
busy while you're running the test suite, you'll also get failures
which you shouldn't be getting.
Based on the arguments above, I'm changing most of the subtests to
only check for the PC8 status reported by sysfs (enabled/disabled),
not check real PC8+ residency. I also added two tests that should
check for PC8+ residency, so we will stil be able to diagnose badly
configured machines.
As a bonus, we won't sleep for full 5 seconds every time we expect PC8
to be disabled: we'll just read i915_pc8_status, which quickly gives
the result we're expecting. Considering how many modeset stress
subtests we have in the program, we'll save a *lot* of time with this
change.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
We try to detect if we have runtime PM or if we just have PC8. In case
there's runtime PM, the functions that wait will wait for the runtime
PM status reported by the sysfs file instead of waiting for PC8
residencies to move.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
This makes cairo dependencies easier to handle. Otherwise, we
would have to litter drmtest all over with "#ifndef ANDROID"
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
[danvet: Add missing _GNU_SOURCE to igt_kms.c and missing include to
intel_sprite_on.c]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Split the tests into categories. There are too many tests, it's
getting harder to locate the ones we need.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
These are more complete tests than the previous test_batch() one. We
test CPU/GTT mmaps, pread/pwrite and batch buffers.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
They use a bad BLT command and don't check its result. The next patch
will add proper GEM tests that contain commands that work and code
that checks if the command is really working.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
They don't really exercise any particular special code path for PC8,
but the runtime D3 code will touch these code paths, so we'll need the
tests.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
And do the assertion in the code line that actually verifies the
condition we need. Makes it easier to debug failed tests.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Imo power management, power consumption and performance are tightly
enough coupled that we can throw them all into one bin.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
