On Wed, Sep 26, 2012 at 11:40:26AM -0700, Ben Widawsky wrote: > On Wed, 26 Sep 2012 13:51:01 +0200 > Daniel Vetter <daniel at ffwll.ch> wrote: > > > On Sat, Sep 22, 2012 at 01:58:37PM -0700, Ben Widawsky wrote: > > > On 2012-09-22 11:05, Daniel Vetter wrote: > > > >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. > > > > > > It doesn't scale. It scales better than reg_dumper was my goal and > > > point (IMO). > > > > > > The exact problem that was trying to be solved is Valleyview (and I > > > assure you there will be more such products coming). Valleyview took > > > a huge chunk of well known registers, and changed their offsets. > > > Modifying this in reg dumper is of course possible, but it's > > > tedious. I wanted to have easy to modify text files with an easy > > > python front end (the offsets could even be applied in the script > > > extremely easily). > > > > If the issue is just the base-address moving around, I think we could > > solve that with some refactoring ... > > -Daniel > > That's exactly an example of the problem it's trying to solve. When > working on new platforms (which is happening much more frequently then > it used to), we shouldn't have to refactor an existing tool to make it > do what we want in preparation for power-on, or even worse, during > power-on. I want something quick, and dirty that gets the information I > need, and migrate it over time to intel_reg_dumper. Furthermore, doing > the range dump can be trivially added with your scripting language of > choice. > > Almost as important, it takes away from the maintenance burden on a > useful tool like reg_dumper for one off platforms like the stupid vlv > we are currently working with (ie. things which will never ship). > > I'm not sure at this point if you're genuinely opposed, or just looking > for holes to poke. Maybe you can clarify, because frankly, I'm using > this tool for my own needs, and whether or not I push it is fairly > don't care. Not genuinely opposed, but questioning the usefulness of such a script as a tool to be used for end-users (which most of the i-g-t/tools programs are for). If you want I think it'd make sense to move it to scripts as a noinst_PYTHON thing (we have a few of those already). I'll merge such a patch. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
