mirror of
https://github.com/FEX-Emu/linux.git
synced 2024-12-20 00:11:22 +00:00
drm/i915: Clear the vblank status bit before polling for the next vblank
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>
This commit is contained in:
parent
4f233eff6f
commit
300387c0b5
@ -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),
|
||||
|
Loading…
Reference in New Issue
Block a user