With the header cleanup we can now give this header a suitable name,
since it now really only contains register access and other I/O
functions and assorted definitions.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only include what the header itself needs. The big fish here is
intel-gpu-tools.h. More will follow.
One ugly thing removed here is the duplicated GEN6_TD_CTL #define, one
of which was broken.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The tool formerly only dumped the aperture size, which is fine, but not
everything interesting. Most of the patch is just the variable rename.
The real work happens with using the BAR0 size divided by 2 instead of
the BAR2 size.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
This finishes the objective in the last patch which was to actually deal
with physical addresses, and not the PTEs.
GEN6+ Provided support for physical addresses above 4GB. I'm not
actually sure what Ironlake supported, and don't feel like firing up the
timemachine.
v2: Add support for gen4, gen5, and haswell.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
The GTT PTEs that the tool is trying to compare is really about
addresses, and not the PTE itself. To accomplish this, make which
calculates the physical address we actually want.
This commit itself doesn't change any functionality; just the wording in
the code.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Vincent sent me a patch which I think didn't go far enough.
Honestly, I don't even know what this tool does.
Reported-by: Cheah, Vincent Beng Keat <vincent.beng.keat.cheah@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Rather than use the common mmio segment which will be in future
restricted to just the registers and so exclude the GTT portion on all
architectures, explicitly mmap the GTT ourselves. Repeat this mmapping
with a couple of flags until we matching the existing kernel mapping.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is vital in a multi-GPU system so that we only test the Intel card
and not the discrete GPUs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A few of the tools can be performed post-mortem from a different system,
so it is useful to be able to compile those tools on those foreign
systems. Obviously, any program to interact with the PCI device or talk
to GEM will fail on a non-Intel system.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
