On Wed, Jan 30, 2013 at 9:30 AM, Jesse Barnes <jesse.barnes at intel.com> wrote: > 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 As I've said previous, having some kind of tool like this makes it easier for others to maintain their own, potentially confidential register sets/bit decoding.
