Age | Commit message (Collapse) | Author | Files | Lines |
|
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
When I moved code around here:
commit 57bc7631e161a7bdcf7f68e1a46049dcb49c2256
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Thu May 23 11:09:55 2013 -0700
lib/intel_mmio: Fix the fix
I accidently dropped the intel_gen() for the PCI id.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67289
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
|
|
commit 16e44f5499e1754dfb10fc62b22675f5aa6ac781
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Apr 3 00:22:41 2013 +0200
lib: fixup register access on gen2/3
THis fix was incorrect for a few reasons:
1. It didn't reflect the state in mmio_data.safe
2. It skipped forcewake on gen6+ which is both incorrect and
unnecessary (for gen<6).
3. It had 2 goto done, the second of which was impossible to hit.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
|
|
I screwed this up in my recent patch:
commit c7b6ec50007e2e524a208572c34faf1380eeab1b
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Wed Apr 24 19:05:18 2013 -0700
clean warnings: Silence unused (or private) functions
I've clarified the functions now, and added the proper call from the
python script.
Time to get a regression tester for our tools?
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
|
|
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
|
|
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
|
|
With the introduction of the forcewake dance:
commit cac8f8b52621f246a7cff412f340a7db28cb1b99
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Thu Jul 28 13:40:19 2011 -0700
forcewake: Add mmio code to do proper forcewake stuff for gen6
We lost the ability to do register access when either debugfs isn't
mounted, or when the driver isn't loaded. The latter can be beneficial
in debugging situations.
This patch will allow the driver to still do mmio (leaving forcewake
management up to the callers) provided that the i915 driver appears to
not be loaded (according to sysfs)
Requested by Jesse.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
|
|
This wreaked havoc with intel_reg_dumper since it's been broken in
commit c6fe31bc473a7ae44bc42bad7da5faca3c924821
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date: Thu Jun 21 14:31:34 2012 -0300
intel_reg_dumper: use intel_register_access_init/fini
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
It's split up into two parts, with the gtt pte range in between.
Without this I couldn't read the ADPA register ...
|
|
In the future, we may like to enable wc mapping of at least the GATT,
and so causing a conflict if we attempt to map the entire bar as uc-
here. Obviously we need a better fallback plan, but for the moment only
attempt to map the portion of the pci space that we use for register
access.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
On my system, sys/fcntl.h contains exactly one line:
#include <fcntl.h>
So there's really no need to #ifdef it. Also, intel_mmio.c already
included <fcntl.h>; there's no need to include it twice.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Added the Android.mk file as per Android make system. Also had to modify
the headers with the proper location for fcntl.h as per the Android
bionic headers location
Signed-off-by: Sateesh Kavuri <sateesh.kavuri@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Rearrange register access init and fini so that we properly accomodate
platforms without forcewake.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
|
|
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
<fcntl.h> is the POSIX standard specified header for open(), so should
be available on all platforms.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Hooks to allow safe accesses from userspace. Can revert to old behavior
by using unsafe access.
|
|
|
|
... and test for what we mean instead.
Reported-by: Diego Celix <dcelix@gmail.com>
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>
|