drm/i915: Clear the vblank status bit before polling for the next vblank
authorChris Wilson <chris@chris-wilson.co.uk>
Sun, 5 Sep 2010 19:25:43 +0000 (20:25 +0100)
committerChris Wilson <chris@chris-wilson.co.uk>
Mon, 6 Sep 2010 22:09:51 +0000 (23:09 +0100)
The vblank status bit is a sticky bit that must be cleared with a write
of '1' prior to polling for the next vblank.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
jbarnes: I'd still rather see a lock, but I think you're right that
we don't generally wait in code that needs not to miss an interrupt.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
drivers/gpu/drm/i915/intel_display.c

index 11a3394f5fe17bb772cb381de1708ad77ae14499..3fc767bcbaa0ebb598bed542975d9e66fa502069 100644 (file)
@@ -990,6 +990,22 @@ void intel_wait_for_vblank(struct drm_device *dev, int pipe)
        struct drm_i915_private *dev_priv = dev->dev_private;
        int pipestat_reg = (pipe == 0 ? PIPEASTAT : PIPEBSTAT);
 
+       /* Clear existing vblank status. Note this will clear any other
+        * sticky status fields as well.
+        *
+        * This races with i915_driver_irq_handler() with the result
+        * that either function could miss a vblank event.  Here it is not
+        * fatal, as we will either wait upon the next vblank interrupt or
+        * timeout.  Generally speaking intel_wait_for_vblank() is only
+        * called during modeset at which time the GPU should be idle and
+        * should *not* be performing page flips and thus not waiting on
+        * vblanks...
+        * Currently, the result of us stealing a vblank from the irq
+        * handler is that a single frame will be skipped during swapbuffers.
+        */
+       I915_WRITE(pipestat_reg,
+                  I915_READ(pipestat_reg) | PIPE_VBLANK_INTERRUPT_STATUS);
+
        /* Wait for vblank interrupt bit to set */
        if (wait_for((I915_READ(pipestat_reg) &
                      PIPE_VBLANK_INTERRUPT_STATUS),