Half of the users actually don't want just no tracing, but need to
avoid the forcewake dance for correctness. So add new variants
__I915_READ and __I915_WRITE for that.
Also improve the _NOTRACE variants to do the forcewake dance.
Currently not required because the only user is the i2c code, which
On 12/21/2011 10:31 AM, Eric Anholt wrote:
> They don't fix our problems alone, but we're told to set them.
>
> Signed-off-by: Eric Anholt
> ---
>
> I think this is -next material, since it's not clearly fixing a bug.
>
> drivers/gpu/drm/i915/i915_reg.h |4
> drivers/gpu/drm/i915
On Wed, Dec 14, 2011 at 03:34:38PM +, Chris Wilson wrote:
> On Wed, 14 Dec 2011 13:57:40 +0100, Daniel Vetter
> wrote:
> > v2: Don't try to enable ppgtt on pre-snb.
> >
> > Signed-off-by: Daniel Vetter
> > Reviewed-by: Ben Widawsky
> > ---
> > +void i915_gem_init_ppgtt(struct drm_device *d
On Wed, Dec 14, 2011 at 03:24:49PM +, Chris Wilson wrote:
> On Wed, 14 Dec 2011 13:57:24 +0100, Daniel Vetter
> wrote:
> > Better be paranoid. The wmb should flush the wc writes, and
> > the chipset_flush hopefully flushes any mch buffers. There've been a
> > few overlay hangs I've never real
On Wed, Dec 14, 2011 at 03:06:34PM +, Chris Wilson wrote:
> On Wed, 14 Dec 2011 13:57:06 +0100, Daniel Vetter
> wrote:
> > ... like for forcewake, which protects everything _but_ display.
> > Expect more things (like gtt abstractions, rings, inter-ring sync)
> > to come.
>
> The only thing t
On Wed, Dec 21, 2011 at 16:46, Daniel Vetter wrote:
> On Wed, Dec 21, 2011 at 10:09:30AM -0800, Eric Anholt wrote:
> > I was once again embarassed while explaining to either Ken or Paul
> > about how we handle reusing the intel_decode.c file in two trees.
> > Here's my attempt at a solution to th
On Wed, 21 Dec 2011 19:54:10 +0100, Udo Steinberg wrote:
> Hi,
>
> With Linux-3.2-rc6 I'm frequently seeing GPU hangs when large amounts of
> text scroll in an xterm, such as when extracting a tar archive. Such as this
> one (note the timestamps):
Can you try with semaphores disabled?
i915.sema
On Wed, Dec 21, 2011 at 10:09:30AM -0800, Eric Anholt wrote:
> I was once again embarassed while explaining to either Ken or Paul
> about how we handle reusing the intel_decode.c file in two trees.
> Here's my attempt at a solution to the problem: Move the code into
> libdrm, and try to give it an
They don't fix our problems alone, but we're told to set them.
Signed-off-by: Eric Anholt
---
I think this is -next material, since it's not clearly fixing a bug.
drivers/gpu/drm/i915/i915_reg.h |4
drivers/gpu/drm/i915/intel_display.c |4
2 files changed, 8 insertions(+
I'd rather be able to use c99 variable declarations (there's a lot of
awful code layout due to being c90ish), but I'll leave that for later.
---
intel/intel_decode.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 8d
---
intel/intel_decode.c | 55 +
1 files changed, 28 insertions(+), 27 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index e61d5ed..f7ce205 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -110,7 +110,7 @@ in
---
intel/Makefile.am | 13 ++---
1 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/intel/Makefile.am b/intel/Makefile.am
index 1af0187..801210f 100644
--- a/intel/Makefile.am
+++ b/intel/Makefile.am
@@ -36,23 +36,14 @@ libdrm_intel_la_LDFLAGS = -version-number 1:0:0
-no-u
It was producing an unused code warning. I'm tempted to just remove
it, since it's unused, but I *might* use it soon.
---
intel/intel_decode.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index e8410d0..dbbcd38 100644
--- a/
---
intel/intel_decode.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 1e63295..1b5f858 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -89,6 +89,10 @@ static float int_as_float(uint32_t intval)
stat
Some comments weren't wrapped, and for some reason uint32_t *data got
an extra space (while other instances of "type *identifier" didn't),
and the indentation of the opcode-list structs got trashed.
---
intel/intel_decode.c | 339 +-
1 files changed
There was plenty of dropped useful data, and some horribly
mis-formatted data.
---
intel/intel_decode.c | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 1b5f858..8d6ea55 100644
--- a/intel/intel_decode.c
+++ b
My plan is to use this drm_intel_dump_batchbuffer() interface for the
current GPU tools, and the current Mesa batch dumping usage, while
eventually building more interesting interfaces for other uses.
Warnings are currently suppressed by using a helper lib with CFLAGS
set manually, because the cod
We've got a different (better) set of warning flags in place in this
tree.
---
intel/intel_decode.c | 106 +++---
1 files changed, 57 insertions(+), 49 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index f7ce205..1e63295 100644
This will make these macros reusable from intel_decode.c, which
doesn't have a bufmgr_gem context, without faking the struct. We
should generally only be using these macros from bufmgr_gem context
setup anyway.
---
intel/intel_bufmgr_gem.c | 17 ++
intel/intel_chipset.h| 72 ++
I was once again embarassed while explaining to either Ken or Paul
about how we handle reusing the intel_decode.c file in two trees.
Here's my attempt at a solution to the problem: Move the code into
libdrm, and try to give it an API that we won't have to continually
rev as we throw the kitchen sin
These will be used by intel_decode.c, and were taken from intel-gpu-tools.
---
intel/intel_chipset.h | 38 +-
1 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 5d417da..e3a30fc 100644
--- a/inte
21 matches
Mail list logo
