Re: intel-gpu-tools patches for read/write MMIO

[Daniel Vetter <daniel.vetter@intel.com>]

On 30/01/2013 18:13, Jesse Barnes wrote:
> On Tue, 29 Jan 2013 17:12:53 -0800
> Ben Widawsky <ben@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@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 ...

>
>> 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.

Cheers, Daniel
Intel Semiconductor AG
Registered No. 020.30.913.786-7
Registered Office: World Trade Center, Leutschenbachstrasse 95, 8050 Zurich, Switzerland

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.