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

[Ben Widawsky]

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.