From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Murthy, Arun R" <arun.r.murthy@intel.com>
Subject: Re: [PATCH v8 3/9] drm/i915: Make sprite updates atomic
Date: Mon, 19 May 2014 16:19:51 +0530
Message-ID: <5379E1CF.2090709@intel.com>
References: <1398767752-619-1-git-send-email-ville.syrjala@linux.intel.com>
 <1398767752-619-4-git-send-email-ville.syrjala@linux.intel.com>
 <CAHofq8MHrbki1XtXeMZGSDSABnu4LUkZDfbYWCvU5Nng0AjM5g@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
 by gabe.freedesktop.org (Postfix) with ESMTP id 038986E6E4
 for <intel-gfx@lists.freedesktop.org>; Mon, 19 May 2014 03:50:20 -0700 (PDT)
In-Reply-To: <CAHofq8MHrbki1XtXeMZGSDSABnu4LUkZDfbYWCvU5Nng0AjM5g@mail.gmail.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: intel-gfx-bounces@lists.freedesktop.org
Sender: "Intel-gfx" <intel-gfx-bounces@lists.freedesktop.org>
To: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>, ville.syrjala@linux.intel.com
List-Id: intel-gfx@lists.freedesktop.org


> 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 (curr_time.tv_usec - (last_vblank +  VBLANK_TIME_INTERVAL) > 100)
     /* acquire lock and proceed*/
else
     /* wait for one vblank, acquire lock and proceed */

Thanks and Regards,
Arun R Murthy
--------------------