[Intel-gfx] [PATCH v4 3/5] drm/i915: Make sprite updates atomic
Chris Wilson
chris at chris-wilson.co.uk
Thu Feb 13 17:01:52 CET 2014
On Thu, Feb 13, 2014 at 05:42:52PM +0200, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
>
> Add a mechanism by which we can evade the leading edge of vblank. This
> guarantees that no two sprite register writes will straddle on either
> side of the vblank start, and that means all the writes will be latched
> together in one atomic operation.
>
> We do the vblank evade by checking the scanline counter, and if it's too
> close to the start of vblank (too close has been hardcoded to 100usec
> for now), we will wait for the vblank start to pass. In order to
> eliminate random delayes from the rest of the system, we operate with
> interrupts disabled, except when waiting for the vblank obviously.
>
> Note that we now go digging through pipe_to_crtc_mapping[] in the
> vblank interrupt handler, which is a bit dangerous since we set up
> interrupts before the crtcs. However in this case since it's the vblank
> interrupt, we don't actually unmask it until some piece of code
> requests it.
>
> v2: preempt_check_resched() calls after local_irq_enable() (Jesse)
> Hook up the vblank irq stuff on BDW as well
> v3: Pass intel_crtc instead of drm_crtc (Daniel)
> Warn if crtc.mutex isn't locked (Daniel)
> Add an explicit compiler barrier and document the barriers (Daniel)
> Note the irq vs. modeset setup madness in the commit message (Daniel)
> v4: Use prepare_to_wait() & co. directly and eliminate vbl_received
intel_pipe_update_start / intel_pipe_update_end are unbalanced (end()
does too much in the cases where start() failed.)
intel_pipe_update_start should check for min <= 0 (i.e.
usecs_to_scanline() returns a value greater than vblank_start).
intel_pipe_update_end() could do a sanity check that it is in the same
frame as start() and so give us warning when the code is broken.
Looks like drm_handle_vblank() could be moved to
intel_pipe_handle_vblank() for a small refactoring win.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list