Re: [PATCH v8 3/9] drm/i915: Make sprite updates atomic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux