This patch adds the details dump for audio registers of Cherryview.
Signed-off-by: Libin Yang <libin.yang@intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
getsubopt is not available in android. The "get" option
doesn't really need sub-options, just display all the
current frequency settings (as per discussion with
Ben Widawsky)
Ben v2: Remove the -geff example in the header
Fixed another typo for the --set while there (found by Dave Gordon)
Signed-off-by: Tim Gore <tim.gore@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
intel_gpu_frequency was added in commit 5fb26d1 (intel_gpu_frequency: A
tool to manipulate Intel GPU frequency), but wasn't added to .gitignore.
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Add a parameter for the size of the act_upon array in the parse function
since its size cannot be calculated with ARRAY_SIZE from just the
pointer.
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Thomas Wood <thomas.wood@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
intel-gpu-tools ships a #!/bin/sh script that has bash-specific syntax
(which breaks on distros such as Debian and Ubuntu where /bin/sh is a
symlink to something other than bash).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87888
The android makefiles were passing the -std=c99 flag to the
compiler which disables the typeof keyword. This causes a
build fail for a recent addition to igt_aux.h.
Change this to -std=gnu99, which is the flag used in the
linux build
Signed-off-by: Tim Gore <tim.gore@intel.com>
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
This also ensures that "make dist" works even if SWIG is not available.
BUILT_SOURCES is not required because the files are already explicit
dependencies of other rules.
v2: make sure SWIG is not invoked with the incorrect output filename
Signed-off-by: Thomas Wood <thomas.wood@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>
Commit 711a17a (quick_dump: Move base_display.txt to indivual platforms)
renamed base_display.txt to common_display.txt, but didn't update
Makefile.am accordingly. Since common_display.txt is now included in the
platform files, it is automatically included in $(QUICK_DUMP_EXTRA_DIST)
and therefore just the reference to base_display.txt needs removing.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Modifications to 'null_state_gen' so it can generate GEN9
golden context batch buffer source for SKL.
v2: - rebased on top of gen8 changes (Mika)
- fixed state base address command size (Mika)
- base address size macro as pages (Mika)
v3: - rebased on top of current master (Mika)
- removed obsolete #includes (Mika)
- added copyright (Mika)
- render and component packing added (Mika)
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Armin Reese <armin.c.reese@intel.com>
Cc: Volkin, Bradley D <bradley.d.volkin@intel.com>
Reviewed-by: Volkin, Bradley D <bradley.d.volkin@intel.com> (v2)
Signed-off-by: Armin Reese <armin.c.reese@intel.com> (v1)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Previously we didn't have a clear understanding what is necessary
for a pipeline state to be properly initialized. So we had to improvise
and use a stripped out render copy.
Now we have a more clear understanding so switch out render copy based
frankenstate to state we can call golden state.
v2: - export intel_batch_state_offset
- add 3DSTATE_RASTER (Bradley Volkin)
Cc: Volkin, Bradley D <bradley.d.volkin@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
In null/golden context there are multiple state commands where
the actual state is always zero. For more compact batch representation
add a macro which just emits command and the rest of the state as zero.
v2: - Be more verbose about length bias (Bradley Volkin)
- strip out unrelated state_offset declaration (Bradley Volkin)
Cc: Volkin, Bradley D <bradley.d.volkin@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Currently our kernel side buffer object is only one page.
Limit the amount of dwords to 1024 to enforce this.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Those registers are big core registers and weren't really relevant for
VLV/CHV. Drop them from the dump then.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
SKL will have a whole separate display regs file, so merge
base_display.txt into each platform file.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Because quick-dump was only selecting a few files in lib/ and we move
stuff around and/or add new dependencies we were failing to provide the
necessary symbols to the shim library providing python bindings. And so
we had a run-time error:
Traceback (most recent call last):
File "./tools/quick_dump/quick_dump.py", line 17, in <module>
import chipset
File "/home/damien/gfx/sources/intel-gpu-tools/tools/quick_dump/chipset.py", line 28, in <module>
_chipset = swig_import_helper()
File "/home/damien/gfx/sources/intel-gpu-tools/tools/quick_dump/chipset.py", line 24, in swig_import_helper
_mod = imp.load_module('_chipset', fp, pathname, description)
File "/usr/lib64/python3.3/imp.py", line 183, in load_module
return load_dynamic(name, filename, file)
ImportError: /home/damien/gfx/sources/intel-gpu-tools/tools/quick_dump/_chipset.so: undefined symbol: kmstest_pipe_name
So, let's simplify maintainance and just link against the library we're
building and using elsewhere.
Signed-off-by: Damien Lespiau <damien.lespiau@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>
Add a bunc of symbolic sideband unit names so that you don't have to go
trawling through the sideband HAS every time you want to poke at
something with the tool. You can still specify the port manually though
if you know them by heart already.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Unlike the kernel IS_VALLEYVIEW() doesn't cover chv in igt. Add the
appropriate IS_CHERRYVIEW() checks to the various sideband poking tools.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
v2: a more generic fix to cover current and future platforms (Damien).
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Instead of building batch directly to memory, build into cmd and
state arrays. This representation allows us more flexibility in batch
state expression and batch generation/relocation.
As a bonus, we can also attach the line information that produced the
batch data to help debugging.
There is no change in the output states produced. This can be considered
as a preparatory patch to help introduce gen8 golden state.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Since relocations are variable size, depending upon generation, it is
easier to handle the resizing of the batch request inside the
BEGIN_BATCH macro. This still leaves us with having to resize commands
in a few places - which still need adaption for gen8+.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
version.h is now generated in the libs directory, so make sure it is
correctly included in the compiler flags.
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
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>
Each architecture file contains a list of the text files it requires, so
use this to add to the list of files to distribute.
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
