[Intel-gfx] [RFC] [PATCH] quick_dump: A dump utility different than reg_dumper

[Ben Widawsky]

On Sat, Sep 22, 2012 at 08:05:04PM +0200, Daniel Vetter wrote:
> On Fri, Sep 21, 2012 at 12:46:05PM -0700, Ben Widawsky wrote:
> > intel_reg_dumper is cool. However, doing bit decoding and dealing with
> > moving registers from generation to generation (and in some cases just
> > steppings) becomes a bit of a burden over time. It's also not completely
> > necessary when doing the not-so-uncommon diff against some other BIOS
> > debug.
> > 
> > While I do not want this tool to replace intel_reg_dumper, I think it
> > has it's uses. The target is particularly for power-on like situations
> > where we want to easily add profiles with new registers, and not lose
> > the old information. Doing this in the existing reg dumper can be a bit
> > tedious and sometimes error prone. It also is a nice place to add
> > registers which may or may not actually be useful. Ones which prove
> > useful over time should get moved to reg dumper.
> > 
> > The tool provides a fast way to add new registers, and register profiles
> > as we bring up new platforms, or try to share debug information. This is
> > accomplished by defining python tuples in text files, and adding them to
> > profiles, which are just a list of the files containing tuples.
> > 
> > I defined a few "base" files which is essentially the previous
> > reg_dumper registers + some other interesting ones. These are
> > automatically used unless the user supplies the "baseless" option. The
> > base should be pretty decent for all recent generation chips with the
> > exception of valleyview. On top of this, I provided some starter
> > profiles: ivybridge, sandybridge, and valleyview.
> > 
> > NOTE: the valleyview profile is currently a work in progress.
> > 
> > So to get a quick sandybridge dump for instance:
> > sudo ./quick_dump.py sandybridge
> > 
> > Feedback please.
> 
> I've wasted a few brain-cycles on the dump problem recently, too - pimping
> intel_reg_dumper is rather obviously a pain. Two ideas:
> 
> - create a script that slurps in internal Bspec xml. The issue here is
>   that I don't know how to handle regs with read-sideeffects (yep, we have
>   those). Maybe manual blacklist. The upside is that this would hopefully
>   allow auto-decoding of the bitfields (if we pimp the xml slurper
>   sufficiently). Also, if we can get at the xml for the open-source Bspec,
>   we could use this tool to auto-create a per-gen open-source reg slurper.
>   Generally I fear that this approach is too messy and noisy and hence
>   intel_reg_dumper pimping probably better.
> 
> - Another idea is to just dump entire register blocks for functional
>   units with a header per block (e.g. "PLANE_A") and then offset : value
>   hexvalue paris per line. That might be useful for quick&dirty comparison
>   for bringup.
> 
> And a quick comment on your approach here: I'm not too sure whether the
> file-base register block approach scales, respectively why exactly this is
> better than frobbing the reg_dumper tool. Since that one has the concept
> of register blocks already, too.
> 
> Cheers, Daniel

The current plan I believe was to rebase this, test it, update for VLV
and push. Any complaints?