[Intel-gfx] [PATCH 00/10] [RFC v2] quick dump

[Ben Widawsky]

On Mon, Feb 04, 2013 at 04:10:55PM +0100, Daniel Vetter wrote:
> On Sun, Feb 03, 2013 at 10:13:10AM -0800, Ben Widawsky wrote:
> > On Sun, Feb 03, 2013 at 12:22:25PM +0000, Chris Wilson wrote:
> > > On Sun, Feb 03, 2013 at 10:29:15AM +0100, Jesse Barnes wrote:
> > > > On Sat,  2 Feb 2013 16:07:52 -0800
> > > > Ben Widawsky <ben at bwidawsk.net> wrote:
> > > > 
> > > > > This is my second attempt at winning approval for the series. First one
> > > > > was: https://patchwork.kernel.org/patch/1493131/
> > > > > 
> > > > > In spending the time to rework this tool, I've begun to lose my belief
> > > > > in some of the original motivations I had.  Even if you don't want to
> > > > > review, but just like (or dislike) what you see, I'd appreciate such
> > > > > comments.
> > > > 
> > > > I'd like to see it land in i-g-t.  Having the regs defined in a text or
> > > > xml file is an improvement over what we have today, and is easier to
> > > > extend.  At first the advantage of reg_dumper was that it parsed out
> > > > the bitfields of the various regs.  But we didn't keep up with that,
> > > > and also haven't kept up with the regs on new platforms as well as we
> > > > could.  Text files would make that easier, and xml files might bring
> > > > back the bit field parsing, which would be extra nice.
> > > 
> > > Completely agree. For me the big improvement would be being able to use
> > > the bspec register names or our internal approximation thereof rather
> > > than having to loop up the actual addresses every time. 
> > > 
> > > Having the name database available in python should make building
> > > integrated little snippets to parse traces which are also python
> > > accessible.
> > > -Chris
> > 
> > It's really nice to get support from you. A mix of fever and staring at
> > the same code too long can really make someone go crazy. Still, a few
> > concerns left from me, one of which I accidentally left out of the
> > description.
> > 
> > - Someone needs to give me a yes or no on the m4 extension macros. This
> >   will block any pushing.
> > - The build kind of sucks on Arch because of Arch's choices regarding
> >   python libraries. To build this on Arch, you must run something like:
> >   ./autogen.sh PYTHON_LDFLAGS="-L/usr/lib/python3.3 -lpython3.3m"
> >   I really don't like autogen not working out of the box. Perhaps I need
> >   to add an AC_ flag to default this tool to off? What do others think?
> >   Does it work properly on other distros? How to handle this?
> > - Ideally, I'd like someone to send me some fixes for valleyview
> >   definitions if they're needed. I am not sure.
> > 
> > Jesse, if you can send me a list of DPIO offsets to read, I'll add the
> > appropriate patch. (It can wait until you get back).
> 
> Yeah, I like. Can't help you with the autfoo though :( And no opinion on
> the m4 macro stuff, I guess you need to poke our legal guys quickly for
> this.

Okay, I think I've satisfied myself, from the project page:
http://savannah.gnu.org/projects/autoconf-archive/

"Every single one of those macros can be re-used without imposing any
restrictions whatsoever on the licensing of the generated configure
script. In particular, it is possible to use all those macros in
configure scripts that are meant for non-free software"

> 
> The only thing to ponder imo is whether we should add intel_ prefixes to
> the tools and add all the new files to the install target (probably need
> tos shove the data files somewhere in var then). Without that we need to
> ask bug reporters to install latest git and run the dumper tools from
> there.
> 
> Otoh we do ask them to grab latest i-g-t git almost every time, anyway ...
> -Daniel

I've gone back and forth as to whether or not I want to robustly support
this from "make install." I'm not really too certain of the correct way
to install python scripts, so I've mostly punted on this. My feeling for
now is, let's make it work in tree, and when it becomes more useful,
make sure it works with make install.

> > 
> > -- 
> > Ben Widawsky, Intel Open Source Technology Center
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Ben Widawsky, Intel Open Source Technology Center