On Mon, May 19, 2014 at 02:49:59PM +0530, Arun Murthy wrote: > 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. > > Here only one sprite update followed by the primary enable/disable can be > achieved atomically. But I feel update of all planes are to be considered, > i.e > update of planes per pipe basis to achieve atomicity. > > > 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. > > This can be achieved easily by checking the previous vblank time in > drm_get_last_vblanktimestamp(), using this the next vblank time cab be > predicted. Using these with the hardcoded value 100usec, a check can be > made to continue or to wait for a vblank. For waiting for a vblank instead > of adding new function just use the available intel_wait_for_vblank(). > > last_vblank = drm_get_last_vblanktimestamp(); > curr_time = do_getttimeofday(); > if ((last_vblank + VBLANK_TIME_INTERVAL) - curr_time.tv_usec > 100) > /* acquire lock and proceed*/ > else > /* wait for one vblank, acquire lock and proceed */ Sure, if your aim is to make it less robust. -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
