Skip to contentSkip to conversation

April Tools: complete intel reg tool overhaul

RFC PATCH In review Jani Nikula 2 participants 3 messages Apr 1, 2015 – Apr 7, 2015

lore
Share & tools
lore
#1 lore raw

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
index 6ca1228b8122..2477eb9bbe86 100644
@@ -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.

#0 lore raw

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
#2 lore raw
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_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.

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_dump which 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