[SPAM] [PATCH 1/3] drm/radeon/kms: fence cleanup + more reliable GPU lockup detection V2
From: Jerome Glisse jgli...@redhat.com
This patch cleanup the fence code, it drops the timeout field of
fence as the time to complete each IB is unpredictable and shouldn't
be bound.
The fence cleanup lead to GPU lockup detection improvement, this
patch introduce a callback, allowing to do asic specific test for
lockup detection. In this patch the CP is use as a first indicator
of GPU lockup. If CP doesn't make progress during 1second we assume
we are facing a GPU lockup.
To avoid overhead of testing GPU lockup frequently due to fence
taking time to be signaled we query the lockup callback every
500msec. There is plenty code comment explaining the design choise
inside the code.
This have been tested mostly on R3XX/R5XX hw, in normal running
destkop (compiz firefox, quake3 running) the lockup callback wasn't
call once (1 hour session). Also tested with forcing GPU lockup and
lockup was reported after the 1s CP activity timeout.
V2 switch to 500ms timeout so GPU lockup get call at least 2 times
in less than 2sec.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/evergreen.c|6 ++
drivers/gpu/drm/radeon/r100.c | 84 +++
drivers/gpu/drm/radeon/r300.c | 27 -
drivers/gpu/drm/radeon/r600.c | 33 +-
drivers/gpu/drm/radeon/radeon.h | 102 ++--
drivers/gpu/drm/radeon/radeon_asic.h | 20 ++-
drivers/gpu/drm/radeon/radeon_fence.c | 75 +---
drivers/gpu/drm/radeon/rv770.c|6 --
8 files changed, 248 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index bd2e7aa..8988df7 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -490,6 +490,12 @@ int evergreen_mc_init(struct radeon_device *rdev)
return 0;
}
+bool evergreen_gpu_is_lockup(struct radeon_device *rdev)
+{
+ /* FIXME: implement for evergreen */
+ return false;
+}
+
int evergreen_gpu_reset(struct radeon_device *rdev)
{
/* FIXME: implement for evergreen */
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 91eb762..96a6370 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1772,6 +1772,90 @@ int r100_rb2d_reset(struct radeon_device *rdev)
return -1;
}
+void r100_gpu_lockup_update(struct r100_gpu_lockup *lockup, struct radeon_cp
*cp)
+{
+ lockup-last_cp_rptr = cp-rptr;
+ lockup-last_jiffies = jiffies;
+}
+
+/**
+ * r100_gpu_cp_is_lockup() - check if CP is lockup by recording information
+ * @rdev: radeon device structure
+ * @lockup:r100_gpu_lockup structure holding CP lockup tracking
informations
+ * @cp:radeon_cp structure holding CP information
+ *
+ * We don't need to initialize the lockup tracking information as we will
either
+ * have CP rptr to a different value of jiffies wrap around which will force
+ * initialization of the lockup tracking informations.
+ *
+ * A possible false positivie is if we get call after while and last_cp_rptr ==
+ * the current CP rptr, even if it's unlikely it might happen. To avoid this
+ * if the elapsed time since last call is bigger than 2 second than we return
+ * false and update the tracking information. Due to this the caller must call
+ * r100_gpu_cp_is_lockup several time in less than 2sec for lockup to be
reported
+ * the fencing code should be cautious about that.
+ *
+ * Caller should write to the ring to force CP to do something so we don't get
+ * false positive when CP is just gived nothing to do.
+ *
+ **/
+bool r100_gpu_cp_is_lockup(struct radeon_device *rdev, struct r100_gpu_lockup
*lockup, struct radeon_cp *cp)
+{
+ unsigned long cjiffies, elapsed;
+
+ cjiffies = jiffies;
+ if (!time_after(cjiffies, lockup-last_jiffies)) {
+ /* likely a wrap around */
+ lockup-last_jiffies = jiffies;
+ return false;
+ }
+ if (cp-rptr != lockup-last_cp_rptr) {
+ /* CP is still working no lockup */
+ lockup-last_cp_rptr = cp-rptr;
+ lockup-last_jiffies = jiffies;
+ return false;
+ }
+ elapsed = jiffies_to_msecs(cjiffies - lockup-last_jiffies);
+ if (elapsed = 3000) {
+ /* very likely the improbable case where current
+* rptr is equal to last recorded, a while ago, rptr
+* this is more likely a false positive update tracking
+* information which should force us to be recall at
+* latter point
+*/
+ lockup-last_cp_rptr = cp-rptr;
+ lockup-last_jiffies = jiffies;
+ return false;
+ }
+ if (elapsed = 1000) {
+ dev_err(rdev-dev, GPU lockup CP stall for more than
%lumsec\n, elapsed);
+
Re: [SPAM] [PATCH 1/3] drm/radeon/kms: fence cleanup + more reliable GPU lockup detection V2
2010/3/1 y:
From: Jerome Glisse jgli...@redhat.com
This patch cleanup the fence code, it drops the timeout field of
fence as the time to complete each IB is unpredictable and shouldn't
be bound.
The fence cleanup lead to GPU lockup detection improvement, this
patch introduce a callback, allowing to do asic specific test for
lockup detection. In this patch the CP is use as a first indicator
of GPU lockup. If CP doesn't make progress during 1second we assume
we are facing a GPU lockup.
To avoid overhead of testing GPU lockup frequently due to fence
taking time to be signaled we query the lockup callback every
500msec. There is plenty code comment explaining the design choise
inside the code.
This have been tested mostly on R3XX/R5XX hw, in normal running
destkop (compiz firefox, quake3 running) the lockup callback wasn't
call once (1 hour session). Also tested with forcing GPU lockup and
lockup was reported after the 1s CP activity timeout.
V2 switch to 500ms timeout so GPU lockup get call at least 2 times
in less than 2sec.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/evergreen.c | 6 ++
drivers/gpu/drm/radeon/r100.c | 84 +++
drivers/gpu/drm/radeon/r300.c | 27 -
drivers/gpu/drm/radeon/r600.c | 33 +-
drivers/gpu/drm/radeon/radeon.h | 102 ++--
drivers/gpu/drm/radeon/radeon_asic.h | 20 ++-
drivers/gpu/drm/radeon/radeon_fence.c | 75 +---
drivers/gpu/drm/radeon/rv770.c | 6 --
8 files changed, 248 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index bd2e7aa..8988df7 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -490,6 +490,12 @@ int evergreen_mc_init(struct radeon_device *rdev)
return 0;
}
+bool evergreen_gpu_is_lockup(struct radeon_device *rdev)
+{
+ /* FIXME: implement for evergreen */
+ return false;
+}
+
int evergreen_gpu_reset(struct radeon_device *rdev)
{
/* FIXME: implement for evergreen */
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 91eb762..96a6370 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1772,6 +1772,90 @@ int r100_rb2d_reset(struct radeon_device *rdev)
return -1;
}
+void r100_gpu_lockup_update(struct r100_gpu_lockup *lockup, struct radeon_cp
*cp)
+{
+ lockup-last_cp_rptr = cp-rptr;
+ lockup-last_jiffies = jiffies;
+}
+
+/**
+ * r100_gpu_cp_is_lockup() - check if CP is lockup by recording information
+ * @rdev: radeon device structure
+ * @lockup: r100_gpu_lockup structure holding CP lockup tracking
informations
+ * @cp: radeon_cp structure holding CP information
+ *
+ * We don't need to initialize the lockup tracking information as we will
either
+ * have CP rptr to a different value of jiffies wrap around which will force
+ * initialization of the lockup tracking informations.
+ *
+ * A possible false positivie is if we get call after while and last_cp_rptr
==
+ * the current CP rptr, even if it's unlikely it might happen. To avoid this
+ * if the elapsed time since last call is bigger than 2 second than we return
+ * false and update the tracking information. Due to this the caller must
call
+ * r100_gpu_cp_is_lockup several time in less than 2sec for lockup to be
reported
+ * the fencing code should be cautious about that.
+ *
+ * Caller should write to the ring to force CP to do something so we don't
get
+ * false positive when CP is just gived nothing to do.
+ *
+ **/
+bool r100_gpu_cp_is_lockup(struct radeon_device *rdev, struct
r100_gpu_lockup *lockup, struct radeon_cp *cp)
+{
+ unsigned long cjiffies, elapsed;
+
+ cjiffies = jiffies;
+ if (!time_after(cjiffies, lockup-last_jiffies)) {
+ /* likely a wrap around */
+ lockup-last_jiffies = jiffies;
+ return false;
+ }
+ if (cp-rptr != lockup-last_cp_rptr) {
+ /* CP is still working no lockup */
+ lockup-last_cp_rptr = cp-rptr;
+ lockup-last_jiffies = jiffies;
+ return false;
+ }
+ elapsed = jiffies_to_msecs(cjiffies - lockup-last_jiffies);
+ if (elapsed = 3000) {
+ /* very likely the improbable case where current
+ * rptr is equal to last recorded, a while ago, rptr
+ * this is more likely a false positive update tracking
+ * information which should force us to be recall at
+ * latter point
+ */
+ lockup-last_cp_rptr = cp-rptr;
+ lockup-last_jiffies = jiffies;
+ return false;
+ }
+
Re: [SPAM] [PATCH 1/3] drm/radeon/kms: fence cleanup + more reliable GPU lockup detection V2
On Tue, Mar 02, 2010 at 10:13:19AM +0100, Erik Andrén wrote:
2010/3/1 y:
From: Jerome Glisse jgli...@redhat.com
This patch cleanup the fence code, it drops the timeout field of
fence as the time to complete each IB is unpredictable and shouldn't
be bound.
The fence cleanup lead to GPU lockup detection improvement, this
patch introduce a callback, allowing to do asic specific test for
lockup detection. In this patch the CP is use as a first indicator
of GPU lockup. If CP doesn't make progress during 1second we assume
we are facing a GPU lockup.
To avoid overhead of testing GPU lockup frequently due to fence
taking time to be signaled we query the lockup callback every
500msec. There is plenty code comment explaining the design choise
inside the code.
This have been tested mostly on R3XX/R5XX hw, in normal running
destkop (compiz firefox, quake3 running) the lockup callback wasn't
call once (1 hour session). Also tested with forcing GPU lockup and
lockup was reported after the 1s CP activity timeout.
V2 switch to 500ms timeout so GPU lockup get call at least 2 times
in less than 2sec.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/evergreen.c | 6 ++
drivers/gpu/drm/radeon/r100.c | 84 +++
drivers/gpu/drm/radeon/r300.c | 27 -
drivers/gpu/drm/radeon/r600.c | 33 +-
drivers/gpu/drm/radeon/radeon.h | 102
++--
drivers/gpu/drm/radeon/radeon_asic.h | 20 ++-
drivers/gpu/drm/radeon/radeon_fence.c | 75 +---
drivers/gpu/drm/radeon/rv770.c | 6 --
8 files changed, 248 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index bd2e7aa..8988df7 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -490,6 +490,12 @@ int evergreen_mc_init(struct radeon_device *rdev)
return 0;
}
+bool evergreen_gpu_is_lockup(struct radeon_device *rdev)
+{
+ /* FIXME: implement for evergreen */
+ return false;
+}
+
int evergreen_gpu_reset(struct radeon_device *rdev)
{
/* FIXME: implement for evergreen */
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 91eb762..96a6370 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1772,6 +1772,90 @@ int r100_rb2d_reset(struct radeon_device *rdev)
return -1;
}
+void r100_gpu_lockup_update(struct r100_gpu_lockup *lockup, struct
radeon_cp *cp)
+{
+ lockup-last_cp_rptr = cp-rptr;
+ lockup-last_jiffies = jiffies;
+}
+
+/**
+ * r100_gpu_cp_is_lockup() - check if CP is lockup by recording information
+ * @rdev: radeon device structure
+ * @lockup: r100_gpu_lockup structure holding CP lockup tracking
informations
+ * @cp: radeon_cp structure holding CP information
+ *
+ * We don't need to initialize the lockup tracking information as we will
either
+ * have CP rptr to a different value of jiffies wrap around which will
force
+ * initialization of the lockup tracking informations.
+ *
+ * A possible false positivie is if we get call after while and
last_cp_rptr ==
+ * the current CP rptr, even if it's unlikely it might happen. To avoid
this
+ * if the elapsed time since last call is bigger than 2 second than we
return
+ * false and update the tracking information. Due to this the caller must
call
+ * r100_gpu_cp_is_lockup several time in less than 2sec for lockup to be
reported
+ * the fencing code should be cautious about that.
+ *
+ * Caller should write to the ring to force CP to do something so we don't
get
+ * false positive when CP is just gived nothing to do.
+ *
+ **/
+bool r100_gpu_cp_is_lockup(struct radeon_device *rdev, struct
r100_gpu_lockup *lockup, struct radeon_cp *cp)
+{
+ unsigned long cjiffies, elapsed;
+
+ cjiffies = jiffies;
+ if (!time_after(cjiffies, lockup-last_jiffies)) {
+ /* likely a wrap around */
+ lockup-last_jiffies = jiffies;
+ return false;
+ }
+ if (cp-rptr != lockup-last_cp_rptr) {
+ /* CP is still working no lockup */
+ lockup-last_cp_rptr = cp-rptr;
+ lockup-last_jiffies = jiffies;
+ return false;
+ }
+ elapsed = jiffies_to_msecs(cjiffies - lockup-last_jiffies);
+ if (elapsed = 3000) {
+ /* very likely the improbable case where current
+ * rptr is equal to last recorded, a while ago, rptr
+ * this is more likely a false positive update tracking
+ * information which should force us to be recall at
+
[Bug 25506] radeon kms causes 33 second boot delay on kernel v2.6.32
http://bugs.freedesktop.org/show_bug.cgi?id=25506 Paul de Vrieze pau...@gentoo.org changed: What|Removed |Added CC||pau...@gentoo.org --- Comment #19 from Paul de Vrieze pau...@gentoo.org 2010-03-02 01:30:58 PST --- *** Bug 26596 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26596] Mobility Radeon X1700 (r5xx familly) kernel boot/ module load error (regression)
http://bugs.freedesktop.org/show_bug.cgi?id=26596 Paul de Vrieze pau...@gentoo.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #11 from Paul de Vrieze pau...@gentoo.org 2010-03-02 01:30:58 PST --- *** This bug has been marked as a duplicate of bug 25506 *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM: fix headers_check warnings
On Sat, Feb 27, 2010 at 14:57:36 +0530, Jaswinder Singh Rajput wrote:
Fixed following headers_check warnings:
CHECK include/drm (14 files)
include/drm/drm_mode.h:84: found __[us]{8,16,32,64} type without #include
linux/types.h
include/drm/i915_drm.h:119: found __[us]{8,16,32,64} type without #include
linux/types.h
include/drm/mga_drm.h:260: found __[us]{8,16,32,64} type without #include
linux/types.h
include/drm/radeon_drm.h:758: found __[us]{8,16,32,64} type without #include
linux/types.h
include/drm/via_drm.h:117: found __[us]{8,16,32,64} type without #include
linux/types.h
These files are shared with BSD, afaik, and they get the linux/types.h
include from drm.h.
Cheers,
Julien
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] drm/ttm: add pool wc/uc page allocator
On Tue, 2010-03-02 at 00:32 +0200, Pauli Nieminen wrote: bo allocation is still too expensive operation for dma buffers in classic mesa. It takes quite a lot cpu time in bind memory (agp system) and ttm_mem_global functions. Would it be possible to move some parts those expensive operations into pool fill and pool free code? Maybe we need userspace BO sub-allocation and/or caching. At least for the 'DMA' buffers it should be simple for userspace to keep a round robin list of buffers. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: catch atombios infinite loop and break out of it
In somecase the atombios code might lead to infinite loop because
the GPU is in broken state, this patch track the jump history and
will abort atombios execution if we are stuck executing the same
jump for more than 1sec. Note that otherwise in some case we might
enter an infinite loop in the kernel context which is bad.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/atom.c | 59
drivers/gpu/drm/radeon/atom.h |2 +-
2 files changed, 48 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
index d75788f..b7fe660 100644
--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -52,15 +52,17 @@
typedef struct {
struct atom_context *ctx;
-
uint32_t *ps, *ws;
int ps_shift;
uint16_t start;
+ unsigned last_jump;
+ unsigned long last_jump_jiffies;
+ bool abort;
} atom_exec_context;
int atom_debug = 0;
-static void atom_execute_table_locked(struct atom_context *ctx, int index,
uint32_t * params);
-void atom_execute_table(struct atom_context *ctx, int index, uint32_t *
params);
+static int atom_execute_table_locked(struct atom_context *ctx, int index,
uint32_t * params);
+int atom_execute_table(struct atom_context *ctx, int index, uint32_t * params);
static uint32_t atom_arg_mask[8] =
{ 0x, 0x, 0x00, 0x, 0xFF, 0xFF00, 0xFF,
@@ -604,12 +606,17 @@ static void atom_op_beep(atom_exec_context *ctx, int
*ptr, int arg)
static void atom_op_calltable(atom_exec_context *ctx, int *ptr, int arg)
{
int idx = U8((*ptr)++);
+ int r = 0;
+
if (idx ATOM_TABLE_NAMES_CNT)
SDEBUG( table: %d (%s)\n, idx, atom_table_names[idx]);
else
SDEBUG( table: %d\n, idx);
if (U16(ctx-ctx-cmd_table + 4 + 2 * idx))
- atom_execute_table_locked(ctx-ctx, idx, ctx-ps +
ctx-ps_shift);
+ r = atom_execute_table_locked(ctx-ctx, idx, ctx-ps +
ctx-ps_shift);
+ if (r) {
+ ctx-abort = true;
+ }
}
static void atom_op_clear(atom_exec_context *ctx, int *ptr, int arg)
@@ -673,6 +680,8 @@ static void atom_op_eot(atom_exec_context *ctx, int *ptr,
int arg)
static void atom_op_jump(atom_exec_context *ctx, int *ptr, int arg)
{
int execute = 0, target = U16(*ptr);
+ unsigned long cjiffies;
+
(*ptr) += 2;
switch (arg) {
case ATOM_COND_ABOVE:
@@ -700,8 +709,25 @@ static void atom_op_jump(atom_exec_context *ctx, int *ptr,
int arg)
if (arg != ATOM_COND_ALWAYS)
SDEBUG( taken: %s\n, execute ? yes : no);
SDEBUG( target: 0x%04X\n, target);
- if (execute)
+ if (execute) {
+ if (ctx-last_jump == (ctx-start + target)) {
+ cjiffies = jiffies;
+ if (time_after(cjiffies, ctx-last_jump_jiffies)) {
+ cjiffies -= ctx-last_jump_jiffies;
+ if ((jiffies_to_msecs(cjiffies) 1000)) {
+ DRM_ERROR(atombios stuck in loop for
more than 1sec aborting\n);
+ ctx-abort = true;
+ }
+ } else {
+ /* jiffies wrap around we will just wait a
little longer */
+ ctx-last_jump_jiffies = jiffies;
+ }
+ } else {
+ ctx-last_jump = ctx-start + target;
+ ctx-last_jump_jiffies = jiffies;
+ }
*ptr = ctx-start + target;
+ }
}
static void atom_op_mask(atom_exec_context *ctx, int *ptr, int arg)
@@ -1104,7 +1130,7 @@ static struct {
atom_op_shr, ATOM_ARG_MC}, {
atom_op_debug, 0},};
-static void atom_execute_table_locked(struct atom_context *ctx, int index,
uint32_t * params)
+static int atom_execute_table_locked(struct atom_context *ctx, int index,
uint32_t * params)
{
int base = CU16(ctx-cmd_table + 4 + 2 * index);
int len, ws, ps, ptr;
@@ -1112,7 +1138,7 @@ static void atom_execute_table_locked(struct atom_context
*ctx, int index, uint3
atom_exec_context ectx;
if (!base)
- return;
+ return -EINVAL;
len = CU16(base + ATOM_CT_SIZE_PTR);
ws = CU8(base + ATOM_CT_WS_PTR);
@@ -1125,6 +1151,8 @@ static void atom_execute_table_locked(struct atom_context
*ctx, int index, uint3
ectx.ps_shift = ps / 4;
ectx.start = base;
ectx.ps = params;
+ ectx.abort = false;
+ ectx.last_jump = 0;
if (ws)
ectx.ws = kzalloc(4 * ws, GFP_KERNEL);
else
@@ -1137,6 +1165,11 @@ static void atom_execute_table_locked(struct
atom_context *ctx, int index, uint3
SDEBUG(%s @ 0x%04X\n,
[PATCH 1/3] drm/radeon/kms: fence cleanup + more reliable GPU lockup detection V3
This patch cleanup the fence code, it drops the timeout field of
fence as the time to complete each IB is unpredictable and shouldn't
be bound.
The fence cleanup lead to GPU lockup detection improvement, this
patch introduce a callback, allowing to do asic specific test for
lockup detection. In this patch the CP is use as a first indicator
of GPU lockup. If CP doesn't make progress during 1second we assume
we are facing a GPU lockup.
To avoid overhead of testing GPU lockup frequently due to fence
taking time to be signaled we query the lockup callback every
500msec. There is plenty code comment explaining the design choise
inside the code.
This have been tested mostly on R3XX/R5XX hw, in normal running
destkop (compiz firefox, quake3 running) the lockup callback wasn't
call once (1 hour session). Also tested with forcing GPU lockup and
lockup was reported after the 1s CP activity timeout.
V2 switch to 500ms timeout so GPU lockup get call at least 2 times
in less than 2sec.
V3 store last jiffies in fence struct so on ERESTART, EBUSY we keep
track of how long we already wait for a given fence
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/Makefile |2 +-
drivers/gpu/drm/radeon/evergreen.c|6 ++
drivers/gpu/drm/radeon/r100.c | 84 ++
drivers/gpu/drm/radeon/r300.c | 27 -
drivers/gpu/drm/radeon/r600.c | 33 +-
drivers/gpu/drm/radeon/radeon.h | 104 +++--
drivers/gpu/drm/radeon/radeon_asic.h | 20 ++-
drivers/gpu/drm/radeon/radeon_fence.c | 102 +---
drivers/gpu/drm/radeon/rv770.c|6 --
9 files changed, 277 insertions(+), 107 deletions(-)
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 0adf49e..ed38262 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -63,6 +63,6 @@ radeon-y += radeon_device.o radeon_kms.o \
evergreen.o
radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
-radeon-$(CONFIG_VGA_SWITCHEROO) += radone_atpx_handler.o
+radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
obj-$(CONFIG_DRM_RADEON)+= radeon.o
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index bd2e7aa..8988df7 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -490,6 +490,12 @@ int evergreen_mc_init(struct radeon_device *rdev)
return 0;
}
+bool evergreen_gpu_is_lockup(struct radeon_device *rdev)
+{
+ /* FIXME: implement for evergreen */
+ return false;
+}
+
int evergreen_gpu_reset(struct radeon_device *rdev)
{
/* FIXME: implement for evergreen */
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 91eb762..96a6370 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1772,6 +1772,90 @@ int r100_rb2d_reset(struct radeon_device *rdev)
return -1;
}
+void r100_gpu_lockup_update(struct r100_gpu_lockup *lockup, struct radeon_cp
*cp)
+{
+ lockup-last_cp_rptr = cp-rptr;
+ lockup-last_jiffies = jiffies;
+}
+
+/**
+ * r100_gpu_cp_is_lockup() - check if CP is lockup by recording information
+ * @rdev: radeon device structure
+ * @lockup:r100_gpu_lockup structure holding CP lockup tracking
informations
+ * @cp:radeon_cp structure holding CP information
+ *
+ * We don't need to initialize the lockup tracking information as we will
either
+ * have CP rptr to a different value of jiffies wrap around which will force
+ * initialization of the lockup tracking informations.
+ *
+ * A possible false positivie is if we get call after while and last_cp_rptr ==
+ * the current CP rptr, even if it's unlikely it might happen. To avoid this
+ * if the elapsed time since last call is bigger than 2 second than we return
+ * false and update the tracking information. Due to this the caller must call
+ * r100_gpu_cp_is_lockup several time in less than 2sec for lockup to be
reported
+ * the fencing code should be cautious about that.
+ *
+ * Caller should write to the ring to force CP to do something so we don't get
+ * false positive when CP is just gived nothing to do.
+ *
+ **/
+bool r100_gpu_cp_is_lockup(struct radeon_device *rdev, struct r100_gpu_lockup
*lockup, struct radeon_cp *cp)
+{
+ unsigned long cjiffies, elapsed;
+
+ cjiffies = jiffies;
+ if (!time_after(cjiffies, lockup-last_jiffies)) {
+ /* likely a wrap around */
+ lockup-last_jiffies = jiffies;
+ return false;
+ }
+ if (cp-rptr != lockup-last_cp_rptr) {
+ /* CP is still working no lockup */
+ lockup-last_cp_rptr = cp-rptr;
+ lockup-last_jiffies = jiffies;
+ return false;
+ }
+ elapsed = jiffies_to_msecs(cjiffies - lockup-last_jiffies);
+ if
Re: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep (w. timeout) until wake_up
W dniu 1 marca 2010 17:37 użytkownik Michel Dänzer mic...@daenzer.net napisał: On Sat, 2010-02-27 at 10:33 +0100, Rafał Miłecki wrote: W dniu 26 lutego 2010 20:01 użytkownik Ville Syrjälä syrj...@sci.fi napisał: Disabling the condition check doesn't make sense. You could use a completion. init_completion(vbl_irq); enable_vbl_irq(); wait_for_completion(vbl_irq); disable_vbl_irq(); and call complete(vbl_irq) in the interrupt handler. The same would of course work with just some flag or counter and a wait queue. Ouch, I can see it gone bad already. Firstly I simply just wanted to avoid condition in wait_event_*. It looked unnecessary as I got interrupts (signals). So this code runs in user process context? If so, it should return to userspace ASAP on signal receipt, otherwise e.g. smoothness of X mouse movement may suffer. If that's a problem, then maybe the code should run in a different context, e.g. a tasklet or some kind of worker kernel thread. It has nothing to do with userspace. Please see my previous description: W dniu 26 lutego 2010 13:16 użytkownik Rafał Miłecki zaj...@gmail.com napisał: W dniu 26 lutego 2010 12:55 użytkownik Thomas Gleixner Sleeping in the timer handler ? In which context runs this timer handler ? We have our struct delayed_work which we first init and then we use queue_delayed_work to start this timer. So it's not real-real timer as struct timer_list. So this is actually delayed_work handler. Sorry (again) for my bad naming. It's delayed_work. -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/radeon/kms: prepare for more reclocking operations
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/gpu/drm/radeon/radeon_pm.c | 39 ++-
1 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index d800b86..4f37b52 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -28,6 +28,7 @@
#define RADEON_RECLOCK_DELAY_MS 200
#define RADEON_WAIT_VBLANK_TIMEOUT 200
+static bool radeon_pm_debug_check_in_vbl(struct radeon_device *rdev, bool
finish);
static void radeon_pm_set_clocks_locked(struct radeon_device *rdev);
static void radeon_pm_set_clocks(struct radeon_device *rdev);
static void radeon_pm_idle_work_handler(struct work_struct *work);
@@ -179,6 +180,16 @@ static void radeon_get_power_state(struct radeon_device
*rdev,
rdev-pm.requested_power_state-non_clock_info.pcie_lanes);
}
+static inline void radeon_sync_with_vblank(struct radeon_device *rdev)
+{
+ if (rdev-pm.active_crtcs) {
+ rdev-pm.vblank_sync = false;
+ wait_event_timeout(
+ rdev-irq.vblank_queue, rdev-pm.vblank_sync,
+ msecs_to_jiffies(RADEON_WAIT_VBLANK_TIMEOUT));
+ }
+}
+
static void radeon_set_power_state(struct radeon_device *rdev)
{
/* if *_clock_mode are the same, *_power_state are as well */
@@ -189,11 +200,28 @@ static void radeon_set_power_state(struct radeon_device
*rdev)
rdev-pm.requested_clock_mode-sclk,
rdev-pm.requested_clock_mode-mclk,
rdev-pm.requested_power_state-non_clock_info.pcie_lanes);
+
/* set pcie lanes */
+ /* TODO */
+
/* set voltage */
+ /* TODO */
+
/* set engine clock */
+ radeon_sync_with_vblank(rdev);
+ radeon_pm_debug_check_in_vbl(rdev, false);
radeon_set_engine_clock(rdev, rdev-pm.requested_clock_mode-sclk);
+ radeon_pm_debug_check_in_vbl(rdev, true);
+
+#if 0
/* set memory clock */
+ if (rdev-asic-set_memory_clock) {
+ radeon_sync_with_vblank(rdev);
+ radeon_pm_debug_check_in_vbl(rdev, false);
+ radeon_set_memory_clock(rdev,
rdev-pm.requested_clock_mode-mclk);
+ radeon_pm_debug_check_in_vbl(rdev, true);
+ }
+#endif
rdev-pm.current_power_state = rdev-pm.requested_power_state;
rdev-pm.current_clock_mode = rdev-pm.requested_clock_mode;
@@ -333,10 +361,7 @@ static void radeon_pm_set_clocks_locked(struct
radeon_device *rdev)
break;
}
- /* check if we are in vblank */
- radeon_pm_debug_check_in_vbl(rdev, false);
radeon_set_power_state(rdev);
- radeon_pm_debug_check_in_vbl(rdev, true);
rdev-pm.planned_action = PM_ACTION_NONE;
}
@@ -353,12 +378,7 @@ static void radeon_pm_set_clocks(struct radeon_device
*rdev)
rdev-pm.req_vblank |= (1 1);
drm_vblank_get(rdev-ddev, 1);
}
- if (rdev-pm.active_crtcs) {
- rdev-pm.vblank_sync = false;
- wait_event_timeout(
- rdev-irq.vblank_queue, rdev-pm.vblank_sync,
- msecs_to_jiffies(RADEON_WAIT_VBLANK_TIMEOUT));
- }
+ radeon_pm_set_clocks_locked(rdev);
if (rdev-pm.req_vblank (1 0)) {
rdev-pm.req_vblank = ~(1 0);
drm_vblank_put(rdev-ddev, 0);
@@ -368,7 +388,6 @@ static void radeon_pm_set_clocks(struct radeon_device *rdev)
drm_vblank_put(rdev-ddev, 1);
}
- radeon_pm_set_clocks_locked(rdev);
mutex_unlock(rdev-cp.mutex);
}
--
1.6.4.2
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm/radeon/kms: switch to condition waiting for reclocking
We tried to implement interruptible waiting with timeout (it was broken
anyway) which was not a good idea as explained by Andrew. It's possible
to avoid using additional variable but actually it inroduces using more
complex in-kernel tools. So simply add one variable for condition.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/gpu/drm/radeon/r100.c |2 ++
drivers/gpu/drm/radeon/r600.c |2 ++
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_pm.c |8 +---
drivers/gpu/drm/radeon/rs600.c |2 ++
5 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 91eb762..73f9a79 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -312,10 +312,12 @@ int r100_irq_process(struct radeon_device *rdev)
/* Vertical blank interrupts */
if (status RADEON_CRTC_VBLANK_STAT) {
drm_handle_vblank(rdev-ddev, 0);
+ rdev-pm.vblank_sync = true;
wake_up(rdev-irq.vblank_queue);
}
if (status RADEON_CRTC2_VBLANK_STAT) {
drm_handle_vblank(rdev-ddev, 1);
+ rdev-pm.vblank_sync = true;
wake_up(rdev-irq.vblank_queue);
}
if (status RADEON_FP_DETECT_STAT) {
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index c522901..5b56a1b 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2765,6 +2765,7 @@ restart_ih:
case 0: /* D1 vblank */
if (disp_int LB_D1_VBLANK_INTERRUPT) {
drm_handle_vblank(rdev-ddev, 0);
+ rdev-pm.vblank_sync = true;
wake_up(rdev-irq.vblank_queue);
disp_int = ~LB_D1_VBLANK_INTERRUPT;
DRM_DEBUG(IH: D1 vblank\n);
@@ -2786,6 +2787,7 @@ restart_ih:
case 0: /* D2 vblank */
if (disp_int LB_D2_VBLANK_INTERRUPT) {
drm_handle_vblank(rdev-ddev, 1);
+ rdev-pm.vblank_sync = true;
wake_up(rdev-irq.vblank_queue);
disp_int = ~LB_D2_VBLANK_INTERRUPT;
DRM_DEBUG(IH: D2 vblank\n);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 829e26e..0d7caee 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -687,6 +687,7 @@ struct radeon_pm {
booldownclocked;
int active_crtcs;
int req_vblank;
+ boolvblank_sync;
fixed20_12 max_bandwidth;
fixed20_12 igp_sideport_mclk;
fixed20_12 igp_system_mclk;
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index d4d1c39..d800b86 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -353,10 +353,12 @@ static void radeon_pm_set_clocks(struct radeon_device
*rdev)
rdev-pm.req_vblank |= (1 1);
drm_vblank_get(rdev-ddev, 1);
}
- if (rdev-pm.active_crtcs)
- wait_event_interruptible_timeout(
- rdev-irq.vblank_queue, 0,
+ if (rdev-pm.active_crtcs) {
+ rdev-pm.vblank_sync = false;
+ wait_event_timeout(
+ rdev-irq.vblank_queue, rdev-pm.vblank_sync,
msecs_to_jiffies(RADEON_WAIT_VBLANK_TIMEOUT));
+ }
if (rdev-pm.req_vblank (1 0)) {
rdev-pm.req_vblank = ~(1 0);
drm_vblank_put(rdev-ddev, 0);
diff --git a/drivers/gpu/drm/radeon/rs600.c b/drivers/gpu/drm/radeon/rs600.c
index 47f046b..ac7c27a 100644
--- a/drivers/gpu/drm/radeon/rs600.c
+++ b/drivers/gpu/drm/radeon/rs600.c
@@ -392,10 +392,12 @@ int rs600_irq_process(struct radeon_device *rdev)
/* Vertical blank interrupts */
if (G_007EDC_LB_D1_VBLANK_INTERRUPT(r500_disp_int)) {
drm_handle_vblank(rdev-ddev, 0);
+ rdev-pm.vblank_sync = true;
wake_up(rdev-irq.vblank_queue);
}
if (G_007EDC_LB_D2_VBLANK_INTERRUPT(r500_disp_int)) {
drm_handle_vblank(rdev-ddev, 1);
+ rdev-pm.vblank_sync = true;
wake_up(rdev-irq.vblank_queue);
}
if (G_007EDC_DC_HOT_PLUG_DETECT1_INTERRUPT(r500_disp_int)) {
Re: [git pull] drm request 2
On Tue, 2 Mar 2010, Linus Torvalds wrote: I disabled it in the merge, since I had to fix up that file anyway. But please don't make me do these so-called evil merges where I end up modifying the thing I merge. Never mind. I've unpulled the whole effin' mess since it doesn't even compile: drivers/gpu/drm/nouveau/nouveau_acpi.c:191: error: redefinition of ‘nouveau_register_dsm_handler’ drivers/gpu/drm/nouveau/nouveau_drv.h:859: note: previous definition of ‘nouveau_register_dsm_handler’ was here drivers/gpu/drm/nouveau/nouveau_acpi.c:202: error: redefinition of ‘nouveau_unregister_dsm_handler’ drivers/gpu/drm/nouveau/nouveau_drv.h:860: note: previous definition of ‘nouveau_unregister_dsm_handler’ was here because not only was that VGA_SWITCHEROO Kconfig default the wrong way around, the thing had clearly never ever been tested at all. Why does sh*t like this even make it to me? Was this ever at all in -next? I assume not, since that would have picked up on basic compile failures. Grr. Things like this is what makes me go Ok, there's always the next merge window, maybe it will have gotten some testing by then. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 2
On Tue, 2 Mar 2010, Linus Torvalds wrote: It's still code. And if the user didn't ask for it, it should damn well not be there. And I repeat: unless the feature cures cancer, it's not on by default. Sometimes we split up _old_ features as config options, or do things that are meant to be turned off only for embedded people. THEN we use that whole 'default y' thing, because doing a make oldconfig should give you the same configuration you had before. But if it's not an old feature that used to not have a config option at all, and it doesn't cure cancer, you never EVER do default y. Because when I do make oldconfig, and I see a Y default, it makes me go I'm not pulling that piece of sh*t. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 2
On Mon, 1 Mar 2010, Dave Airlie wrote: Same tree as yesterday with a warning + PPC build fix + fix for build on x86 after PPC (I think I just validated Ingo). Why is VGA_SWITCHEROO enabled by default? We don't do things like that. New drivers and new features are _not_ enabled by default, unless there is some overriding reason why they should be. And I don't see that reason. Please stop doing that. The whole default y is a f*cking disease. Yes, a developer always thinks that _his_ new code is so special and important that it should be enabled by default, BUT HE IS WRONG. So remember: unless your new feature cures cancer, it should damn well not be enabled by default. I disabled it in the merge, since I had to fix up that file anyway. But please don't make me do these so-called evil merges where I end up modifying the thing I merge. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 2
On Tue, 2 Mar 2010, Dave Airlie wrote: because it does nothing on anything except the laptops in question and on those it does nothing except add a control file in debugfs? It's still code. And if the user didn't ask for it, it should damn well not be there. So how am I supposed to indicate to distro vendors that something should be turned on? If you think that distro kernel maintainers really understand every config option that goes past, I've got a bridge. User configurations is _not_ your job. Your job is to make sure that the kernel works, and people who don't ask for new feaures don't get them. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 2
Never mind. I've unpulled the whole effin' mess since it doesn't even compile: drivers/gpu/drm/nouveau/nouveau_acpi.c:191: error: redefinition of ‘nouveau_register_dsm_handler’ drivers/gpu/drm/nouveau/nouveau_drv.h:859: note: previous definition of ‘nouveau_register_dsm_handler’ was here drivers/gpu/drm/nouveau/nouveau_acpi.c:202: error: redefinition of ‘nouveau_unregister_dsm_handler’ drivers/gpu/drm/nouveau/nouveau_drv.h:860: note: previous definition of ‘nouveau_unregister_dsm_handler’ was here because not only was that VGA_SWITCHEROO Kconfig default the wrong way around, the thing had clearly never ever been tested at all. Why does sh*t like this even make it to me? Was this ever at all in -next? I assume not, since that would have picked up on basic compile failures. Grr. Things like this is what makes me go Ok, there's always the next merge window, maybe it will have gotten some testing by then. Linux next didn't pick up this build failure, wierdly neither did the powerpc build I did with this turned off, because ACPI was also off on ppc, it was in linux-next for at least 2 days, and from what I can see that found the ppc problems, it never found the x86 option since it was on by default. I'm going to just rip the nouveau bits out of the patch, btw nouveau is in staging, so you are being a bit OTT, calm down. Dave.-- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 2
x86 after PPC (I think I just validated Ingo). Why is VGA_SWITCHEROO enabled by default? because it does nothing on anything except the laptops in question and on those it does nothing except add a control file in debugfs? So how am I supposed to indicate to distro vendors that something should be turned on? If you think that distro kernel maintainers really understand every config option that goes past, I've got a bridge. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 2
On Wed, 3 Mar 2010, Dave Airlie wrote: Did I mention that driver is in STAGING? Staging is for _improving_ the quality of the drivers, not for making it worse. We still very much have quality standards. The staging tree is for things to get in that don't quite _reach_ the standards we expect, but it's not a blanket excuse for not testing things. And yes, I expect that stuff can be a bit rough during the merge window, after all, the whole point is that we can fix things up. But quite frankly, if _I_ find problems on the few machines I personally build and test on, then what does that say about the bigger picture? IOW, I refuse to pull code that doesn't even work for me. If I did, where would we end up? What do you think should be my minimal quality requirements, if Oh, it doesn't even build for me is too much to ask for? So if I find code that doesn't work, I'm not going to just say whatever. I'm going to reject it. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 2
On Wed, Mar 3, 2010 at 9:40 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, 3 Mar 2010, Dave Airlie wrote: Did I mention that driver is in STAGING? Staging is for _improving_ the quality of the drivers, not for making it worse. We still very much have quality standards. The staging tree is for things to get in that don't quite _reach_ the standards we expect, but it's not a blanket excuse for not testing things. And yes, I expect that stuff can be a bit rough during the merge window, after all, the whole point is that we can fix things up. But quite frankly, if _I_ find problems on the few machines I personally build and test on, then what does that say about the bigger picture? IOW, I refuse to pull code that doesn't even work for me. If I did, where would we end up? What do you think should be my minimal quality requirements, if Oh, it doesn't even build for me is too much to ask for? So if I find code that doesn't work, I'm not going to just say whatever. I'm going to reject it. So can we get linux-next builds to build with *your* Kconfig? This should cut down the amount of crap you see considerably. I'm not saying we have too many configuration options and testing them all is insane, granted I admit I should have found this one since I do generally try and build with nouveau on here. I've sent a new pull, take it or not it builds here at least under staging/acpi/vga_switcheroo off Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 2
0/3/3 Dave Airlie airl...@linux.ie: Never mind. I've unpulled the whole effin' mess since it doesn't even compile: drivers/gpu/drm/nouveau/nouveau_acpi.c:191: error: redefinition of ‘nouveau_register_dsm_handler’ drivers/gpu/drm/nouveau/nouveau_drv.h:859: note: previous definition of ‘nouveau_register_dsm_handler’ was here drivers/gpu/drm/nouveau/nouveau_acpi.c:202: error: redefinition of ‘nouveau_unregister_dsm_handler’ drivers/gpu/drm/nouveau/nouveau_drv.h:860: note: previous definition of ‘nouveau_unregister_dsm_handler’ was here because not only was that VGA_SWITCHEROO Kconfig default the wrong way around, the thing had clearly never ever been tested at all. Why does sh*t like this even make it to me? Was this ever at all in -next? I assume not, since that would have picked up on basic compile failures. Grr. Things like this is what makes me go Ok, there's always the next merge window, maybe it will have gotten some testing by then. Linux next didn't pick up this build failure, wierdly neither did the powerpc build I did with this turned off, because ACPI was also off on ppc, it was in linux-next for at least 2 days, and from what I can see that found the ppc problems, it never found the x86 option since it was on by default. I'm going to just rip the nouveau bits out of the patch, btw nouveau is in staging, so you are being a bit OTT, calm down.\ Anyways sfr just confirmed linux-next doesn't build CONFIG_STAGING drivers so again that wouldn't have helped. So you made us pull nouveau into staging, now you are giving out because staging drivers have issues? In any case I've fixed the default y and the STAGING build in my tree. Did I mention that driver is in STAGING? Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm request 3
Fixes for default y + CONFIG_STAGING + CONFIG_DRM_NOUVEAU enabled. Dave. The following changes since commit 60b341b778cc2929df16c0a504c91621b3c6a4ad: Linus Torvalds (1): Linux 2.6.33 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus Alex Deucher (34): drm/radeon/kms: add radeon i2c algo drm/radeon/kms: add support for hw i2c on r1xx-r5xx drm/radeon/kms: add workaround for rn50/rv100 servers drm/radeon/kms: add support for hardcoded edids in rom (v2) drm/radeon/kms: clean up some low-hanging magic numbers drm/radeon/kms: rework pll algo selection drm/radeon/kms: add pll quirk for toshiba laptop panel drm/radeon/kms/atom: clean up spread spectrum code drm/radeon/kms/atom: add a helper function to get the radeon connector priv drm/radeon/kms/r600: reduce gpu cache flushing drm/radeon/kms: consolidate crtc count in rdev drm/radeon/kms: add functions to get current pcie lanes drm/radeon/kms: pull power mode info from bios tables (v3) drm/radeon/kms: add a power state type based on power state flags drm/radeon/kms: add code to select power state drm/radeon/kms: use power states for dynamic reclocking drm/radeon/kms: dynclks fixes drm/radeon/kms: take the pm mutex when using hw i2c drm/radeon/kms: update atombios.h to latest upstream. drm/radeon/kms: add initial Evergreen support (Radeon HD 5xxx) drm/radeon/kms: fix prescale calculations drm/radeon/kms/atom: replace 0/1 in crtc code with ATOM_DISABLE/ATOM_ENABLE drm/radeon/kms/evergreen: fix multi-head drm/radeon/kms/evergreen: adapt to i2c changes drm/radeon/r600: fix warnings in CS checker drm/radeon/kms: add LVDS pll quirk for Dell Studio 15 drm/radeon/kms: remove HDP flushes from fence emit (v2) drm/radeon/kms: remove unused r600_gart_clear_page drm/radeon/rv740: fix backend setup drm/radeon: fixes for r6xx/r7xx gfx init drm/radeon/kms/evergreen: fix typo in cursor code drm/radeon/kms: update new pll algo drm/radeon/kms/atom: fix shr/shl ops drm/radeon: fix typo in Makefile Andy Shevchenko (1): drivers/gpu/drm/drm_fb_helper.c: don't use private implementation of atoi() Ben Skeggs (17): drm/nv50: switch to indirect push buffer controls drm/nouveau: remove PUSHBUF_CAL macro drm/nv50: make pushbuf dma object cover entire vm drm/nouveau: new gem pushbuf interface, bump to 0.0.16 drm/nouveau: allow retrieval of vbios image from debugfs drm/nouveau: rename parsed_dcb_gpio to dcb_gpio_table drm/nouveau: merge parsed_dcb and bios_parsed_dcb into dcb_table drm/nouveau: merge nvbios and nouveau_bios_info drm/nouveau: reorganise bios header, add dcb connector type enums drm/nouveau: parse dcb gpio/connector tables after encoders drm/nouveau: check for known dcb connector types drm/nouveau: construct a connector table for cards that lack a real one drm/nouveau: use dcb connector table for creating drm connectors drm/nv50: enable hpd on any connector we know the gpio line for drm/nouveau: use dcb connector types throughout the driver drm/nouveau: support version 0x20 displayport tables drm/nouveau: report unknown connector state if lid closed Chris Wilson (2): drm/i915: Replace open-coded eviction in i915_gem_idle() drm/i915: Record batch buffer following GPU error Daniel Vetter (11): drm/i915: overlay: nuke readback to flush wc caches drm/i915: overlay: drop superflous gpu flushes drm/i915: move a gtt flush to the correct place drm/i915: blow away userspace mappings before fence change drm/i915: reuse i915_gem_object_put_fence_reg for fence stealing code drm/i915: fixup active list locking in object_unbind drm/i915: extract fence stealing code drm/i915: ensure lru ordering of fence_list drm/i915: reuse i915_gpu_idle helper drm/i915: clean-up i915_gem_flush_gpu_write_domain drm/i915: check for multiple write domains in pin_and_relocate Dave Airlie (23): drm/radeon/kms: switch all KMS driver ioctls to unlocked. drm/radeon/kms: use udelay for short delays drm: switch all GEM/KMS ioctls to unlocked ioctl status. drm/kms: fix fb_changed = true else statement drm/radeon/kms: check for valid PCI bios and not OF rom drm/radeon/kms: set gart pages to invalid on unbind and point to dummy page drm/radeon/kms: flush HDP cache on GART table updates. [rfc] drm/radeon/kms: pm debugging check for vbl. Merge remote branch 'korg/drm-core-next' into drm-next-stage Merge remote branch 'anholt/drm-intel-next' into drm-next-stage fb: for framebuffer handover don't exit the loop early. Merge remote branch 'korg/drm-radeon-testing' into
Re: [git pull] drm request 2
On Wed, 3 Mar 2010, Dave Airlie wrote: So can we get linux-next builds to build with *your* Kconfig? This should cut down the amount of crap you see considerably. No. Dave, _think_ about what you're saying. The absolute last thing we want to do is to make it easier for crap to flow through the system. We don't want to make it easier to hide problems. I think we might want to instead extend on the tests that linux-next does. For example, STAGING should generally always compile. There are exceptions - major change the world changes where staging drivers might not be updated in as timely a manner as other drivers, but they should be exceptions, not the rule. If a driver really doesn't even compile, it should be marked BROKEN, not STAGING. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26852] New: Build libkms against in-tree xf86drm.h
http://bugs.freedesktop.org/show_bug.cgi?id=26852 Summary: Build libkms against in-tree xf86drm.h Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: libdrm AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: chalserog...@gmail.com Created an attachment (id=33703) -- (http://bugs.freedesktop.org/attachment.cgi?id=33703) Add include dir to libkms Makefile libkms includes files which include xf86drm.h, but doesn't include the in-tree xf86drm.h in the library include path. This means it will build against the installed header in /usr/include which is probably not the expected behaviour, or if built in a clean chroot will simply fail to build. Trivial patch attached to fix. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26852] Build libkms against in-tree xf86drm.h
http://bugs.freedesktop.org/show_bug.cgi?id=26852 Sérgio M. B. ser...@sergiomb.no-ip.org changed: What|Removed |Added CC||ser...@sergiomb.no-ip.org --- Comment #1 from Sérgio M. B. ser...@sergiomb.no-ip.org 2010-03-02 20:13:53 PST --- The question is, if libkms depends on kernel ? and yes I thinks so . Therefore, if libkms , depends on kernel should use xf86drm.h of /usr/include. In this point of view, libkms should know deal with different kernels or even warn if kernel version is not good. built in a clean chroot will simply fail to build , I think that solves install kernel-sources first . Note: this is my opinion, may not be write. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Mon, Mar 1, 2010 at 7:18 PM, Michal Suchanek hramr...@centrum.cz wrote: On 21 November 2009 05:27, Dave Airlie airl...@gmail.com wrote: At the moment the problem with fbset is what to do with it in the dual head case. Currently we create an fb console that is lowest common size of the two heads and set native modes on both, Does that mean that fbset is supposed to work (set resolution) on drmfb? No we've never hooked it up but it could be made work. Now if a user runs fbset, I'm not sure what the right answer is, a) pick a head in advance via sysfs maybe and set it on that. b) try and set the mode on both heads cloned (what to do if there is no common mode is another issue). I would say it's time to support multihead with fbset properly. That is people would need new fbset which sees both (all) heads, and fbset can then choose the head itself (and people can make it do something different when they don't like the default). It should also support setting up rotation on each head. For old fbset setting something visible is probably good enough. Schemes which would make a multihead setup look like a single screen get complicated quite easily. Perhaps an option to turn off some outputs so that the native resolution of one output is used (instead of clone) would work. I've only really got two answer for this: (a) hook up another /dev/dri/card_fb device and use the current KMS ioctls to control the framebuffer, have the drm callback into fbdev/fbcon to mention resizes etc. Or add one or two info gathering ioctls and allow use of the /dev/dri/control device to control stuff. (b) add a lot of ioctls to KMS fbdev device, which implement some sort of sane multi-output settings. Now the second sounds like a lot of work if not the correct solution, you basically needs a way to pretty much expose what the KMS ioctls expose on the fb device, and then upgrade fbset to make sense of it all. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14574] using a displayport connector results in stack in dmesg and blank screen
http://bugzilla.kernel.org/show_bug.cgi?id=14574 --- Comment #5 from Wil Reichert wil.reich...@gmail.com 2010-03-03 05:46:14 --- Created an attachment (id=25334) -- (http://bugzilla.kernel.org/attachment.cgi?id=25334) dmesg from 2.6.33 and dp connector Just tried again with the same hardware and the final 2.6.33 kernel. Stack from dmesg is gone but screen still blanks with 5 thin vertical lines across it. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14574] using a displayport connector results in stack in dmesg and blank screen
http://bugzilla.kernel.org/show_bug.cgi?id=14574 --- Comment #6 from Wil Reichert wil.reich...@gmail.com 2010-03-03 05:47:40 --- Created an attachment (id=25335) -- (http://bugzilla.kernel.org/attachment.cgi?id=25335) dmesg from 2.6.33 and dvi connector For reference, same boot w/ dvi connector -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell Inspiron 700m
BugLink: https://bugs.launchpad.net/bugs/515246
Sony VGN-BX196VP and Dell Inspiron 700m report lid status as closed
when it is open. This leads to a no connectors reported error at startup.
Blacklisting them, to always return a connected status for the default
lvds connector.
Signed-off-by: Surbhi Palande surbhi.pala...@canonical.com
---
Due to lack of hardware, I have not tested this patch on my own. Further
testing shall be helpful.
drivers/gpu/drm/i915/intel_lvds.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index c2e8a45..b94a5e5 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -643,6 +643,20 @@ static const struct dmi_system_id bad_lid_status[] = {
DMI_MATCH(DMI_BOARD_NAME, M5x0N),
},
},
+ {
+ .ident = Sony VGN-BX196VP,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Sony Corporation),
+ DMI_MATCH(DMI_BOARD_NAME, VGN-BX196VP),
+ },
+ },
+ {
+ .ident = Dell Inspiron 700m,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Dell Inc),
+ DMI_MATCH(DMI_BOARD_NAME, Inspiron 700m),
+ },
+ },
{ }
};
--
1.6.3.3
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
This patch fixes the no connectors reported bug on Sony VGN-BX196VP and
Thanks !
Regards,
Surbhi.
From 47edbf7437388b23562f12888c36af6b59f56eec Mon Sep 17 00:00:00 2001
From: Surbhi Palande surbhi.pala...@canonical.com
Date: Mon, 22 Feb 2010 22:39:28 +0200
Subject: [PATCH] drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell
Inspiron 700m
BugLink: https://bugs.launchpad.net/bugs/515246
Sony VGN-BX196VP and Dell Inspiron 700m report lid status as closed
when it is open. This leads to a no connectors reported error at startup.
Blacklisting them, to always return a connected status for the default
lvds connector.
Signed-off-by: Surbhi Palande surbhi.pala...@canonical.com
---
drivers/gpu/drm/i915/intel_lvds.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index c2e8a45..b94a5e5 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -643,6 +643,20 @@ static const struct dmi_system_id bad_lid_status[] = {
DMI_MATCH(DMI_BOARD_NAME, M5x0N),
},
},
+ {
+ .ident = Sony VGN-BX196VP,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Sony Corporation),
+ DMI_MATCH(DMI_BOARD_NAME, VGN-BX196VP),
+ },
+ },
+ {
+ .ident = Dell Inspiron 700m,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Dell Inc),
+ DMI_MATCH(DMI_BOARD_NAME, Inspiron 700m),
+ },
+ },
{ }
};
--
1.6.3.3
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
