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?
