aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorBen Skeggs <bskeggs@redhat.com>2010-01-05 21:00:02 -0500
committerDave Airlie <airlied@redhat.com>2010-01-10 23:41:16 -0500
commitdc8d76cac942e7344a72ad18afb90fa46cf20bb4 (patch)
tree0516fdca404bc9a87271710a93159bfda5a04c77
parent1959ca80e1f88b82c1cb7227f437910768ab0c94 (diff)
drm/nv50: prevent a possible ctxprog hang
The below is mainly an educated guess at what's going on, docs would sure be handy... NVIDIA? :P It appears it's possible for a ctxprog to run even while a GPU exception is pending. The GF8 and up ctxprogs appear to have a small snippet of code which detects this, and stalls the ctxprog until it's been handled, which essentially looks like: if (r2 & 0x00008000) { r0 |= 0x80000000; while (r0 & 0x80000000) {} } I don't know of any way that flag would get cleared unless the driver intervenes (and indeed, in the cases I've seen the hang, nothing steps in to automagically clear it for us). This patch causes the driver to clear the flag during the PGRAPH IRQ handler. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-rw-r--r--drivers/gpu/drm/nouveau/nouveau_irq.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/drivers/gpu/drm/nouveau/nouveau_irq.c b/drivers/gpu/drm/nouveau/nouveau_irq.c
index 370c72c968d1..919a619ca7fa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_irq.c
+++ b/drivers/gpu/drm/nouveau/nouveau_irq.c
@@ -635,6 +635,7 @@ nv50_pgraph_irq_handler(struct drm_device *dev)
635 635
636 if ((nv_rd32(dev, 0x400500) & isb) != isb) 636 if ((nv_rd32(dev, 0x400500) & isb) != isb)
637 nv_wr32(dev, 0x400500, nv_rd32(dev, 0x400500) | isb); 637 nv_wr32(dev, 0x400500, nv_rd32(dev, 0x400500) | isb);
638 nv_wr32(dev, 0x400824, nv_rd32(dev, 0x400824) & ~(1 << 31));
638 } 639 }
639 640
640 nv_wr32(dev, NV03_PMC_INTR_0, NV_PMC_INTR_0_PGRAPH_PENDING); 641 nv_wr32(dev, NV03_PMC_INTR_0, NV_PMC_INTR_0_PGRAPH_PENDING);