summaryrefslogtreecommitdiffstats
path: root/Kbuild
diff options
context:
space:
mode:
authorBen Skeggs <bskeggs@redhat.com>2010-01-06 12:00:02 +1000
committerBen Skeggs <bskeggs@redhat.com>2010-01-11 09:06:42 +1000
commit7978b9cfa59133a34aaad420e447c2a29d5c6152 (patch)
treeefd038c8a66706dac953371295fea68d1bf4212e /Kbuild
parentbbb8c3d8820893694a3567716adb3b6f6ba2b7d0 (diff)
downloadlinux-stable-7978b9cfa59133a34aaad420e447c2a29d5c6152.tar.gz
linux-stable-7978b9cfa59133a34aaad420e447c2a29d5c6152.tar.bz2
linux-stable-7978b9cfa59133a34aaad420e447c2a29d5c6152.zip
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>
Diffstat (limited to 'Kbuild')
0 files changed, 0 insertions, 0 deletions