Re: [ANNOUNCE] 3.6.11.1-rt32

From: Carsten Emde
Date: Mon Apr 01 2013 - 23:21:18 EST


Steven,

I'm pleased to announce the 3.6.11.1-rt32 stable release.
Unfortunately, there is another compile error:
drivers/gpu/drm/i915/i915_gem.c: In function âi915_gem_wait_for_errorâ:
drivers/gpu/drm/i915/i915_gem.c:118:3: warning: passing argument 1 of ârt_spin_lockâ from incompatible pointer type [enabled by default]
In file included from include/linux/spinlock.h:273:0,
from include/linux/wait.h:24,
from include/linux/fs.h:396,
from include/drm/drmP.h:47,
from drivers/gpu/drm/i915/i915_gem.c:28:
include/linux/spinlock_rt.h:21:24: note: expected âstruct spinlock_t *â but argument is of type âstruct raw_spinlock_t *â
drivers/gpu/drm/i915/i915_gem.c:120:3: warning: passing argument 1 of ârt_spin_unlockâ from incompatible pointer type [enabled by default]
In file included from include/linux/spinlock.h:273:0,
from include/linux/wait.h:24,
from include/linux/fs.h:396,
from include/drm/drmP.h:47,
from drivers/gpu/drm/i915/i915_gem.c:28:
include/linux/spinlock_rt.h:24:24: note: expected âstruct spinlock_t *â but argument is of type âstruct raw_spinlock_t *â
drivers/gpu/drm/i915/i915_gem.c: In function âi915_gem_check_wedgeâ:
drivers/gpu/drm/i915/i915_gem.c:1890:3: warning: passing argument 1 of ârt_spin_lockâ from incompatible pointer type [enabled by default]
In file included from include/linux/spinlock.h:273:0,
from include/linux/wait.h:24,
from include/linux/fs.h:396,
from include/drm/drmP.h:47,
from drivers/gpu/drm/i915/i915_gem.c:28:
include/linux/spinlock_rt.h:21:24: note: expected âstruct spinlock_t *â but argument is of type âstruct raw_spinlock_t *â
drivers/gpu/drm/i915/i915_gem.c:1892:3: warning: passing argument 1 of ârt_spin_unlockâ from incompatible pointer type [enabled by default]
In file included from include/linux/spinlock.h:273:0,
from include/linux/wait.h:24,
from include/linux/fs.h:396,
from include/drm/drmP.h:47,
from drivers/gpu/drm/i915/i915_gem.c:28:
include/linux/spinlock_rt.h:24:24: note: expected âstruct spinlock_t *â but argument is of type âstruct raw_spinlock_t *â

I would propose to adopt the mechanism that Sebastian introduced in
3.8.4-rt2 (https://lkml.org/lkml/2013/3/26/600). The kernel compiles
and runs without any problem with the below patch on a system that
requires the i915 driver module.

-Carsten.



From: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
Subject: gpu/i915: don't open code these things

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
---
drivers/gpu/drm/i915/i915_gem.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)

Index: linux-3.6.11.1-rt32/drivers/gpu/drm/i915/i915_gem.c
===================================================================
--- linux-3.6.11.1-rt32.orig/drivers/gpu/drm/i915/i915_gem.c
+++ linux-3.6.11.1-rt32/drivers/gpu/drm/i915/i915_gem.c
@@ -90,7 +90,6 @@ i915_gem_wait_for_error(struct drm_devic
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct completion *x = &dev_priv->error_completion;
- unsigned long flags;
int ret;

if (!atomic_read(&dev_priv->mm.wedged))
@@ -115,9 +114,7 @@ i915_gem_wait_for_error(struct drm_devic
* end up waiting upon a subsequent completion event that
* will never happen.
*/
- spin_lock_irqsave(&x->wait.lock, flags);
- x->done++;
- spin_unlock_irqrestore(&x->wait.lock, flags);
+ complete(x);
}
return 0;
}
@@ -1884,12 +1881,9 @@ i915_gem_check_wedge(struct drm_i915_pri
if (atomic_read(&dev_priv->mm.wedged)) {
struct completion *x = &dev_priv->error_completion;
bool recovery_complete;
- unsigned long flags;

/* Give the error handler a chance to run. */
- spin_lock_irqsave(&x->wait.lock, flags);
- recovery_complete = x->done > 0;
- spin_unlock_irqrestore(&x->wait.lock, flags);
+ recovery_complete = completion_done(x);

/* Non-interruptible callers can't handle -EAGAIN, hence return
* -EIO unconditionally for these. */


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/