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]
