Hey Ben,
For your quick dump mechanism yours, there are also some consideration that you might have left out - overlapping IRQ and some other registers that have the same offset for both render and display (since base_interrupt, base_power doesn?t include other VLV IRQ/Power register sets not part of current base tables. On top of that there are also some registers that are still missing in accordance bspecs. Are you going to add that in upon pushing it to the master branch? If not, then I have volunteered to help you get all the registers ready setup for you.
I don?t think there is any other patches required on our side. Oh yes before I forget, there is some BAR memory mapping fixes for VLV in order for it to work - intel_gtt.c
for (f = 0; flag[f] != 0; f++) {
if (IS_GEN3(devid)) {
/* 915/945 chips has GTT range in bar 3 */
if (pci_device_map_range(pci_dev,
pci_dev->regions[3].base_addr,
pci_dev->regions[3].size,
flag[f],
(void **)>t) == 0)
break;
} else {
int offset;
if (IS_G4X(devid) || IS_GEN5(devid) || IS_VALLEYVIEW(devid))
offset = MB(2);
else
offset = KB(512);
if (pci_device_map_range(pci_dev,
pci_dev->regions[0].base_addr + offset,
offset,
flag[f],
(void **)>t) == 0)
break;
}
}
In between, I'm also in the process of creating a personal repo to keep our own internal bad version of intel_reg_read / write as for now so we can carry on with our internal testing and providing a quick solution temporary for our customer to read/write MMIO regs. I have a problem, creating an account in people.freedesktop.org. The link below simply does not provide me much information. By the way, I did apply membership in Xorg foundation based to some other link where I came across, but I don't seems to be able help neither. Am I missing anything?
(http://www.freedesktop.org/wiki/Infrastructure/git/RepositoryAdmin)
Thanks.
...vincent
-----Original Message-----
From: Ben Widawsky [mailto:benjamin.widawsky at intel.com]
Sent: Thursday, January 31, 2013 1:53 AM
To: Barnes, Jesse
Cc: Vetter, Daniel; Ben Widawsky; intel-gfx at lists.freedesktop.org; Cheah, Vincent Beng Keat; Ung, Teng En; Teres Alexis, Alan Previn
Subject: Re: intel-gpu-tools patches for read/write MMIO
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.
