I see that the patch is in 2.6.36. However, for me on 965g, it only fixes the bug if the kernel is compiled as fully preemptible. If the kernel is compiled with voluntary preemption, there is still a 30-100 ms latency introduced every 10 seconds. drm_mms_helper.poll=0 does help.
shining on #intel-gfx asked me to play with latencytrace. Unfortunately, this isn't useful: irqsoff and sched_switch yield no smoking guns, and preemptoff is only available with the fully preemptible kernel.

If I thought I had resolved the bug, I would have closed the report. This is still open because we hold the mode mutex around the output polling and cursor manipulation, causing the stalls. The two workarounds (a) optionally disable the output polling and (b) remove the worst offender. The locking design remains less than optimal.

I started using a radeon card on my desktop a few days ago and started experiencing this problem again but I wasn't able to get any of the workarounds to work this time.
I tried to deactivate polling with the drm_kms_helper.poll=0 trick but it didn't work. I even went as far as removing all calls to queue_delayed_work() from drivers/gpu/drm/drm_crtc_helper.c but it didn't work. After digging a while I noticed that a daemon called upowerd reads from /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-VGA-1/status every 30sec and that cause the stall.
upowerd is a dependency on kde but I can't find any setting in kde to disable this polling. Killing the upowerd process works but I assume that has some negative consequence.

I tested 3.2.1. While xrandr is much faster (and I get less blocks during starting of wine applications which request that a lot) I now get intermittent blocks of X every 10-30 seconds. The blocks last several seconds and make working completely impossible.
I switched back to a 3.1 kernel and the problem is gone, with xrandr being slow again.
xf86-video-intel-2.17.0
libdrm-2.4.27
mesa-7.11.2
not blocking: linux 3.1.10
blocking: linux 3.2.1