| Age | Commit message (Collapse) | Author |
|---|
|
After the recent discussions regarding the effects of the vblank
disabling policies on PC state residencies, I started running some
experiments to reevaluate some non-intuitive conclusions I had
reached. In order to help me do this, I decided to write this tool.
The idea is very simple: the tool puts the system on an screen-on idle
state, checks which PC state residency is the deepest we can reach,
measures its residency, then does some not-so-idle tests and measures
the residencies. You can use the tool to compare different Kernel
trees and you can also use the tool to compare enabled vs disabled
features.
It's obvious that these cases do not represent real-world use cases of
our driver, but they are already enough to highlight differences
between the many patches I wrote. I was even able to catch a bug in
one of my patches by spotting an unexpected regression in the
residencies.
I've been using this tool for FBC, but I expect it to also be useful
for PSR, DRRS and similar features. I've been measuring the effects of
different optimizations I wrote, and I've also been measuring the FBC
vs no-FBC cases.
It is also important to highlight that if your system is not properly
configured for efficient power savings the tool may not be able to
show differences between the results. On my Broadwell machine, for
example, if I don't run "powertop --auto-tune" before running the
tool, I get PC2 as the deepest state, and 90%+ residency for every
workload. After properly configuring the machine, I get PC7 as the
deepest state, which is the expected.
So far I only tested this tool on BDW and SKL, and it may hit some
unexpected assertions for older platforms.
I only implemented the cases that are immediately useful for me, but
we may also expand the tool in the future. We can add more important
workloads. We can add support for screen-off cases, so we can compare
the effects of runtime PM and other screen-off features. There's a lot
we can do, but none of this is on my current priority list.
And remember: /usr/bin/paste is your friend when comparing results.
v2:
- Be more idle at setup_idle().
- Improve printing for /usr/bin/paste usage.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
Recent kernels compress the active objects using zlib + ascii85
encoding. This adapts the tool to decompress those inplace.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
intel_iosf_sb_read, intel_iosf_sb_write, intel_reg_dumper,
intel_reg_read, intel_reg_snapshot, intel_reg_write, intel_vga_read, and
intel_vga_write have been deprecated in favor of intel_reg. Remove the
deprecated tools. intel_reg does everything they do, and more.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
A rudimentary tool on top of the igt_stats library. Reads a list of
numbers from stdin or from a file and prints the estimate of the central
location, aka average.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
So we can inspect fw headers. Sample output:
Firmware: skl_dmc_ver1_18.bin (7892 bytes)
CSS header (128 bytes)
module_type: DMC (9)
header_len: 32
header_ver: 0x10000
module_id: 0x0
module_vendor: 0x0
date: 0x7df060c
size: 1973
key_size: 0
modulus_size: 0
exponent_size: 0
version: 1.18 (0x10012)
kernel_header_info: 0x0
Package header (256 bytes)
header_len: 64
header_ver: 1
num_entries: 3
Firmware #1
stepping: A.*
offset: 4294967295
Firmware #2
stepping: B.*
offset: 4294967295
Firmware #3
stepping: *.*
offset: 0
0x7f0867143000
0x7f0867143180
signature: 0x40403e3e
header_len: 128
header_ver: 1
dmcc_ver: 520
project: 0x900
fw_size: 1845
fw_version: 0x10008
mmio_count: 3
write(0x0008f074, 0x00002fc0)
write(0x0008f004, 0x02500204)
write(0x0008f034, 0xc003b400)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
|
|
The CRC debug interface is a bit more than a simple textual file in
debugfs as there are a small command language to control what we want
from them.
This tool starts, slowly, by allowing us to dump the pipe CRCs whenever
we want. It can be handy to check what is the current CRC when we reach
a certain state on the screen (when using --interactive-debug for
instance) against a known CRC.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
|
|
I had various problems (infinite loops, unable to compute dividers for
certain frequencies) after implementing a BSpec update. Much easier to
debug that in userspace.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
|
|
We're going to add the SKL version, time to rename the HSW/BDW one.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
|
|
Make sure all the sources for intel_reg are included in the
distribution.
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
|
|
Three Tools for the Elven-kings under the sky,
Seven for the Dwarf-lords in their halls of stone,
Nine for Mortal Men doomed to die,
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
One Tool to rule them all, One Tool to find them,
One Tool to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.
J.R.R. Tolkien's epigraph to The Lord of The Tools
| sed 's/Ring/Tool/g'
Introduce intel_reg as the one Intel graphics register multitool to
replace intel_reg_read, intel_reg_write, intel_iosf_sb_read,
intel_iosf_sb_write, intel_vga_read, intel_vga_write, intel_reg_dumper,
intel_reg_snapshot, and quick_dump.py.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The watermark registers on the gmch platform are a bit of a mess. Add
a tool to make some sense of them. While at it decode the ilk-bdw wm
registers as well. SKL+ is left out for now since it's a very different
beast.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
intel_dpio_{read,write} as redundant as intel_iosf_sb_{read,write}
handle the same task.
The difference between the tools was the opcode used to read/write the
registers, but with DPIO both opcodes work just fine, so there's no need
for both sets of tools.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
WARNING: very minimally tested
In general you should not need this tool. Its primary purpose is for
benchmarking, and for debugging performance issues.
For many kernel releases now sysfs has supported reading and writing the GPU
frequency. Therefore, this tool provides no new functionality. What it does
provide is an easy to package (for distros) tool that handles the most common
scenarios.
v2:
Get rid of -f from the usage message (Jordan)
Add space before [-s (Jordan)
Add a -c/--custom example (Jordan)
Add a setting for resetting to hardware default (Ken)
Replicate examples in commit message in the source code. (me)
v3:
Its not It's (me)
Add --help/-h to usage
Add Version + man page
Rename tool to intel_gpu_frequency, from intel_frequency
Remove "sudo" from the examples
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Here are some sample usages:
$ intel_gpu_frequency --get=cur,min,max,eff
cur: 200 MHz
min: 200 MHz
RP1: 200 MHz
max: 1200 MHz
$ intel_gpu_frequency -g
cur: 200 MHz
min: 200 MHz
RP1: 200 MHz
max: 1200 MHz
$ intel_gpu_frequency -geff
RP1: 200 MHz
$ intel_gpu_frequency --set min=300
$ intel_gpu_frequency --get min
cur: 300 MHz
min: 300 MHz
RP1: 200 MHz
max: 1200 MHz
$ intel_gpu_frequency --custom max=900
$ intel_gpu_frequency --get max
cur: 300 MHz
min: 300 MHz
RP1: 200 MHz
max: 900 MHz
$ intel_gpu_frequency --max
$ intel_gpu_frequency -g
cur: 1200 MHz
min: 1200 MHz
RP1: 200 MHz
max: 1200 MHz
$ intel_gpu_frequency -e
$ intel_gpu_frequency -g
cur: 200 MHz
min: 200 MHz
RP1: 200 MHz
max: 200 MHz
$ intel_gpu_frequency --max
$ intel_gpu_frequency -g
cur: 1200 MHz
min: 1200 MHz
RP1: 200 MHz
max: 1200 MHz
$ intel_gpu_frequency --min
$ intel_gpu_frequency -g
cur: 200 MHz
min: 200 MHz
RP1: 200 MHz
max: 200 MHz
|
|
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
They're now igt tests, and so if you blindly run lib/igt.cocci with
spatch on tests/*c they get mangled. Move them away, but still keep
them as noinst targets.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
intel_iosf_sb_{read,write} provide the same functionality.
intel_dpio_{read,write} are still left in place since they use a
ifferent opcode to do the register access. Need to verify if
both opcodes work.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
registers
intel_poller can be used to poll various display registers
(IIR,scanline/pixel/flip/frame counter, live address, etc.).
It can be used to determine eg. at which scanline or pixel count certain
events occur.
v2: s/intel_poller/intel_display_poller/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Add generic tools to poke at IOSF sideband. The user needs to
manually specify SB port as well as the register.
TODO: Maybe add symbolic names for the units? Would avoid having
to trawl the docs for the magic hex value.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
No reason really not too, especially since we install manpages for
some of them.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66656
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This tool only supports ILK. I take the fact that nobody has felt the
need to update for later platform a sign it's not very useful.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
|
|
In this way, all source files are listed in Makefile.sources and included
from Makefile.am, thus enabling the reuse from Android makefiles.
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
