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

[Ben Widawsky]

On Tue, Jan 29, 2013 at 7:27 PM, Teres Alexis, Alan Previn
<alan.previn.teres.alexis at intel.com> wrote:
> Vincent, quick realization:
>
> If we patch VLV support on Ben's branch, (i.e. QuickDump style - separate txt-file tables of register lists that have the correct absolute register offsets), then we should ensure intel_reg_dumper / intel_panel_fitter is removed (since that one is broken for VLV in its current incarnation)... which is what was wrong with our patch. Our patch for Ben's branch - we added the +180000 into the primitive functions and though that worked for the intel_reg_dumper / intel_panel_fitter, we ended up breaking Quick-dump . But this would be okay for main 1.3 tree. Basically these approaches are mutually exclusive (Quick-dump vs the intel_reg_dumper and alike tools).
>
> So what needs to happen is:
>
> 1. Daniel / Ben needs agree on what to go with for master igt (i.e. remove intel_panel_fitter, intel_reg_dumper etc  and replace with Quick-dump). I think the future is probably Quick-dump.
> 2. If they go with Quick-Dump, we can use Ben's stuff as is - no changes required - but we'll have to ensure that for individual register read / write, user uses the absolute MMIO offset.
>         - in this case, no patch is required from our side (except the BAR memory mapping fixes for VLV - there was some other things here).
>         - over time, we can add, additional VLV tables for QuickDump (since base_interrupt, base_power doesn't include other VLV IRQ/Power register sets not part of current base tables).
> 3. If they go with maintaining the intel_reg_dumper (for now),
>         - then we need to either add the +180000 in our primitive functions - which we don't really like OR modify the intel_reg_dumper / intel_panel_fitter/ etc with more "if(VALLEYVIEW)" and reference a new set of register tables with the VLV absolute offsets.
>
> Lets wait for Ben and Daniel to give the go-ahead (I doubt we'll have to decide on #3, I think they'll lean towards #2).
>
> Daniel, Ben - let us know when QuickDump is going live - we'll skip our patches for now - but we'll probably maintain our own internal bad version of intel_reg_read / write for now so we can carry on with our internal testing.
>
> ...alan
>
WRT  #1 = it seems to be a useful, easy to maintain tool, where groups
like ISG can easily carry around there on stuff. I also suspect it
will just be overlapped with xml parsing if we ever get bspec XML.
When discussing this today.

In regards to #2, and #3 though - because it's out of the main
directory and relies on fairly standard tools (reg, dpio read/write) -
there is no reason one couldn't easily maintain it out of tree. I
don't think that's ideal, but it should be almost trivial (it doesn't
even require any Makefile merging IIRC). I haven't rebased it in a few
months, so take that with a grain of salt.

You should probably wait until Daniel puts his foot firmly down. I've
asked him in that case that he find the resource to fix up reg_dumper
to his ideas.

Daniel: Honestly, I'm fine with you putting your foot down as long as
you have a plan to make this stuff what we need it to be in the near
term.

[snip]