RFC April Tools: complete intel reg tool overhaul
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest1 patch 1 replyIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/1 | intel_reg: introduce one intel_reg tool to rule them alltools/ tools/ tools/ +2 more | +3838 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH i-g-t 0/1] April Tools: complete intel reg tool overhaul
Hi all -
I think having several overlapping register read/write/dump/etc. tools is just silly. I've been working on unsillifying the situation a bit on the background, in the idle moments ("while my kernel's compiling").
Here's what I got: a replacement for
intel_reg_dumper
quick_dump.py
intel_reg_read
intel_reg_write
intel_iosf_sb_read
intel_iosf_sb_write
intel_dpio_read
intel_dpio_write
intel_reg_snapshot
intel_vga_read
intel_vga_write
I'm calling it "intel_reg". It's a busybox-like tool that understands the subcommands
dump
read
write
decode
snapshot
The read, write and decode subcommands understand register references in the form [(PORTNAME|PORTNUM|MMIO-OFFSET):](REGNAME|REGADDR) letting you address all registers on all platforms. For example,
$ intel_reg read DPIO:TX2_CH0_DW10 $ intel_reg write 0x70000 0xffff
The register "spec", i.e. the registers known by name and their mapping to address, sideband port or mmio offset, is completely separated from the decoding. The spec can be provided through quick_dump.py compatible files (although it should not be difficult to add other formats). Quick addition of new registers to dump is just as easy as for quick_dump.py. As fallback, all the registers currently known by intel_reg_dumper are built-in.
The decoding is done based on the resolved address, initially using the same functionality currently available in intel_reg_dumper.
Now all the decoding and name<->address mapping is available for *all* subcommands. All subcommands use the same output format (which, admittedly, I didn't polish yet, but that's a few lines of printfs). For dumping a bunch of registers with with --count, we also get the names for all:
$ intel_reg read --count 2 BLC_PWM_CPU_CTL2 0x00048250 (BLC_PWM_CPU_CTL2): 0x80000000 enable 1, pipe A 0x00048254 (BLC_PWM_CPU_CTL): 0x00000206 cycle 518
intel_reg_decode.c is mostly a copy of intel_reg_dumper.c, otherwise this is fairly small amount of code for the functionality, compared to everything it's aiming to replace.
It's mostly done, probably with plenty of bikeshedding potential, so I stopped short from the polishing stage. Let's hear it.
TODO consists of eating a previously done dump and re-decoding the values with possibly updated decode code, bash completion for the commands and register names, and also replacing intel_audio_dump which has become a monster.
BR,
Jani.
Jani Nikula (1):
intel_reg: introduce one intel_reg tool to rule them all
tools/Makefile.sources | 6 + tools/intel_reg.c | 658 +++++++++++ tools/intel_reg_decode.c | 2697 ++++++++++++++++++++++++++++++++++++++++++++++ tools/intel_reg_spec.c | 409 +++++++ tools/intel_reg_spec.h | 68 ++ 5 files changed, 3838 insertions(+) create mode 100644 tools/intel_reg.c create mode 100644 tools/intel_reg_decode.c create mode 100644 tools/intel_reg_spec.c create mode 100644 tools/intel_reg_spec.h
Signature · 6 lines
2.1.4 _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx