From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFC PATCH] drm: Add plane event Date: Thu, 19 Apr 2012 10:10:50 +0200 Message-ID: <20120419081049.GD4256@phenom.ffwll.local> References: <20120418084634.GC5315@phenom.ffwll.local> <4F8E9361.3080004@samsung.com> <4F8ECA08.2080601@stericsson.com> <20120418142607.GR4917@intel.com> <20120418143659.GB20469@phenom.ffwll.local> <4F8ED977.9090706@stericsson.com> <20120418152757.GD20469@phenom.ffwll.local> <20120418160610.GS4917@intel.com> <20120418181942.GT4917@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by gabe.freedesktop.org (Postfix) with ESMTP id 1A0EB9EC68 for ; Thu, 19 Apr 2012 01:09:52 -0700 (PDT) Received: by wgbds1 with SMTP id ds1so1247987wgb.0 for ; Thu, 19 Apr 2012 01:09:52 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20120418181942.GT4917@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Cc: "hoegsberg@gmail.com" , "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On Wed, Apr 18, 2012 at 09:19:42PM +0300, Ville Syrj=E4l=E4 wrote: > On Wed, Apr 18, 2012 at 07:06:10PM +0300, Ville Syrj=E4l=E4 wrote: > > On Wed, Apr 18, 2012 at 05:27:57PM +0200, Daniel Vetter wrote: > > > Also, I'm toying around with ideas to split up the big modeset lock s= uch > > > that operations that only touch the crtc (like pageflip, plane change= s and > > > cursor changes) do not take the big modeset lock but only a per-crtc > > > mutex. > > = > > Plane operations might well involve multiple CRTCs (when moving the > > planes between pipes for example). You have to be careful with the > > locking order when doing stuff like that. One option would be to > > always take the per-CRTC locks in the same order (based on the > > object ID for example). > = > Multiple locks will also cause problems for the atomic mode set. The > full device state may be needed to evaluate whether a certain change > is allowed, which means any change happening in parallel can screw > things up. Imo we can simply demand that any operation which touches more than 1 crtc needs the big modeset lock. So atomic modeset would still take this look, but modeset is a really rare operation, so no point to optimize for it. The only issue I see is with switching a sprite from one crtc to another, with that design this would also require the big modeset look. But Kristian just brought up the idea of a prepare_sprite ioctl, so we could do the crtc switch there, and userspace could run this ioctl asynchronous in a separate thread to avoid stalls (e.g. on the old gen2 intel overlay a crtc switch takes 2 full vblanks to disable and 1 full vblank to set up on the new crtc, then another vblank to show anything). The nuclear pageflip would then only touch one single crtc, so never get stalled by other modeset operations. -Daniel -- = Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48