From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFC] [PATCH] quick_dump: A dump utility different than reg_dumper Date: Thu, 27 Sep 2012 13:51:59 +0200 Message-ID: <20120927115159.GB2098@bremse> References: <1348256765-1611-1-git-send-email-ben@bwidawsk.net> <20120922180504.GA6800@phenom.ffwll.local> <617390e2a10e9c1fd7682455538f9659@bwidawsk.net> <20120926115101.GC1980@bremse> <20120926114026.0000211b@unknown> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by gabe.freedesktop.org (Postfix) with ESMTP id E06FE9E802 for ; Thu, 27 Sep 2012 04:52:05 -0700 (PDT) Received: by bkwj4 with SMTP id j4so1497371bkw.36 for ; Thu, 27 Sep 2012 04:52:05 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20120926114026.0000211b@unknown> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Ben Widawsky Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Wed, Sep 26, 2012 at 11:40:26AM -0700, Ben Widawsky wrote: > On Wed, 26 Sep 2012 13:51:01 +0200 > Daniel Vetter 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