On Thu, Feb 13, 2014 at 05:42:52PM +0200, ville.syrjala@xxxxxxxxxxxxxxx wrote: > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
