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
