[Intel-gfx] intel-gpu-tools patches for read/write MMIO

[Jesse Barnes]

On Wed, 30 Jan 2013 18:25:39 +0100
Daniel Vetter <daniel.vetter at intel.com> wrote:

> On 30/01/2013 18:13, Jesse Barnes wrote:
> > On Tue, 29 Jan 2013 17:12:53 -0800
> > Ben Widawsky <ben at bwidawsk.net> wrote:
> >
> >> On Tue, Jan 29, 2013 at 09:15:22PM +0100, Daniel Vetter wrote:
> >>> On 29/01/2013 21:01, Jesse Barnes wrote:
> >>>> Can you just post them externally tointel-gfx at lists.freedesktop.org?
> >>>> It's best to use git send-email to do it, that way the changelogs are
> >>>> preserved and posted to the ml along with the patches.
> >>> Public intel-gfx is already on the cc list, just in case you get the
> >>> urge to spill some secrets ;-)
> >>>> Not sure if there's a bunch of duplication between the two, but you
> >>>> could split them up a bit.
> >>>>
> >>>> I still don't like the idea of silently adding the display offset on
> >>>> vlv; these are just debug tools and the developer should get the
> >>>> absolute offset they asked for no matter what.
> >>> On that topic of silently adding display offset - with Ville's
> >>> kernel work we'll have switched away completely from such tricks in
> >>> the kernel. So I think i-g-t shouldn't automatically add the offset.
> >>>
> >>> Which essentially just leaves us with intel_reg_dumper. Now for that
> >>> I'm somewhat hopefully that we will be able to (eventually) dump
> >>> registers using the bspec xml sources (there should be bspec xmls
> >>> around for just the open-source approved parts). In the meantime,
> >>> can't we just adjust the relevant offsets of the register blocks?
> >>> IIrc their all somewhat usefully grouped together, so this would
> >>> amount to adding a quick function to add the offset to a given table
> >>> (put keep all the names) and then feed the adjusted table to the
> >>> dumper functions ...
> > The big downside of using the bspec stuff is it'll be a huge rename
> > effort for us, and will likely get renamed and changed in the bspec
> > over time, breaking things.
> Which is why autogenerating headers makes imo no sense. But register 
> dumping and decoding for debug purposes is a different thing and I'm 
> hopeful that using bspec xmls cut allow us to cut down a lot of boring 
> work in that area ...

Ah ok I didn't catch that distinction.  I think I agree, though we'll
be stuck with mapping the bspec regs back to the other names we're
familiar with too.  But it's definitely easier to deal with going
forward.

> 
> >
> >> As we discussed in private, even if we get to the point of having bspec
> >> xml, we would still want a tool similar to the one that was proposed for
> >> parsing the XML (as opposed to the text). Reg dumper as has been
> >> mentioned in several threads is pretty inflexible, and a pain to modify
> >> for person use.
> >>
> >> As we also discussed in private, I'd like Jesse to either fight or not
> >> for this because I don't think he has to butt heads with you enough.
> > For reg_dumper I'd prefer something like Ben's work, which just takes
> > text files describing what's being dumped, so we can better handle
> > dumping subsets of regs and have different files for different
> > platforms.
> Essentially I'm only against the magic register offset adjustment, since 
> that doesn't work due to some aliased registers. I'm happy with any of 
> the other ideas tossed around here. If we come up with different tools, 
> maybe adding a wrapper script to pick the right one (e.g. binary 
> reg_dumper for older platfroms, textfile-driven dumper for newer 
> platforms) would be nice. Otherwise we'll inevitably have a few 
> unnecessary round-trips in bug reports.

Ok so let's get Ben to push his stuff.  If we get bspec xml bits we can
extend his tool to use them as well.

Jesse