April Tools: complete intel reg tool overhaul
RFC PATCH 1/1 intel_reg: introduce one intel_reg tool to rule them all
In reply to Jani Nikula 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 Rings
| sed 's/Ring/Tool/g'
We should do fine with fewer intel register access related tools.
--- 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
tools/Makefile.sources +6 -0
@@ -5,6 +5,7 @@ noinst_PROGRAMS = \ bin_PROGRAMS = \ intel_audio_dump \ + intel_reg \ intel_backlight \ intel_bios_dumper \ intel_bios_reader \
@@ -40,6 +41,11 @@ dist_bin_SCRIPTS = intel_gpu_abrt intel_dump_decode_SOURCES = \ intel_dump_decode.c +intel_reg_SOURCES = \ + intel_reg.c \ + intel_reg_decode.c \ + intel_reg_spec.c + intel_error_decode_SOURCES = \ intel_error_decode.c
tools/intel_reg.c new file +658 -0
658 lines not on this page · raw message
tools/intel_reg_decode.c new file +2697 -0
2,324 lines not on this page · raw message
tools/intel_reg_spec.c new file +409 -0
409 lines not on this page · raw message
tools/intel_reg_spec.h new file +68 -0
68 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Signature · 6 lines
2.1.4 _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Part of the diff is not shown here. View the raw message.
cover 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
Quoted 57 lines · Jani Nikula
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_writeI'm calling it "
intel_reg". It's a busybox-like tool that understands the subcommands
dump
read
write
decode
snapshotThe 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 0xffffThe 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.pycompatible files (although it should not be difficult to add other formats). Quick addition of new registers to dump is just as easy as forquick_dump.py. As fallback, all the registers currently known byintel_reg_dumperare 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.cis mostly a copy ofintel_reg_dumper.c, otherwise this is fairly small amount of code for the functionality, compared to everything it's aiming to replace.
Quoted 7 lines
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_dumpwhich has become a monster.
Tbh I didn't read through the entire thing, but imo having a unified interface is very much required and this is awesome work. Imo better to push this and ignore any requests for color changes. One thing is missing
thought: A bunch of patches on top which replace all the current tools with bash scripts which calls a suitable subcommand of intel_reg. Otherwise we'll keep adding divergent changes all over. But with that imo just go ahead an push it.
-Daniel
Signature · 7 lines
Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx