From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH v8 3/9] drm/i915: Make sprite updates atomic Date: Mon, 19 May 2014 13:46:57 +0300 Message-ID: <20140519104657.GY27580@intel.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id 6BBAC6E409 for ; Mon, 19 May 2014 03:47:02 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Arun Murthy Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org 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 =3D drm_get_last_vblanktimestamp(); > curr_time =3D 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=E4l=E4 Intel OTC