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

[Daniel Vetter]

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