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:05:57 +0200 Message-ID: <20120419080557.GC4256@phenom.ffwll.local> References: <1334723519-32141-1-git-send-email-jy0922.shim@samsung.com> <20120418084634.GC5315@phenom.ffwll.local> <4F8E9361.3080004@samsung.com> <4F8ECA08.2080601@stericsson.com> <20120418142607.GR4917@intel.com> <20120418143659.GB20469@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail-ey0-f177.google.com (mail-ey0-f177.google.com [209.85.215.177]) by gabe.freedesktop.org (Postfix) with ESMTP id 47E569EB0C for ; Thu, 19 Apr 2012 01:05:00 -0700 (PDT) Received: by eaak13 with SMTP id k13so2123199eaa.36 for ; Thu, 19 Apr 2012 01:04:59 -0700 (PDT) Content-Disposition: inline In-Reply-To: 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: Kristian =?iso-8859-1?Q?H=F8gsberg?= Cc: "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On Wed, Apr 18, 2012 at 09:24:58PM -0400, Kristian H=F8gsberg wrote: > One thing that's not clear to me is how we would enable a sprite > without going through the atomic modeset again. If the atomic modeset > is all about calculating bandwidth requirements etc, then enabling a > sprite will affect that and it may or may not be possible based on the > current configuration. However, enabling a sprite from one frame to > another is something that we would want to do as part of the nuclear > pageflip. So I'm not sure how this would work... maybe we could have > a prepare_sprite_enable type ioctl that verifies that it's possible to > add the sprite plane to the current configuration. Then if that > succeeds, we can use the nuclear pageflip to enable the sprite plane. Sprites also have an ugly issue wrt finer-grained locking: If we move to per-crtc locking, the nuclear pageflip would only need to take the crtc mutex it operates on. But the if we move a sprite from one crtc to another one, we'd need to lock both crtcs, and the easiest solution for the lock ordering problem this causes is to require that all code which needs more than one crtc look needs the big modeset lock. Which would be painful for pageflip. Also, most sprites/overlays can't be switched in one step from one crtc to another, so these pageflips would run synchronous. Which is not the point of pageflipping. So I think a prepare_sprite ioctl which changes the crtc association (and checks memory bandwidth and other constrains) but does not display anything would be good to support the nuclear pageflip without jumping through too many hoops in the kernel. Nuclear pageflip would need to support pageflippping from/to NULL framebuffers on planes then to signal switching a plane on/off. Maybe we could even do that for the main crtc fb (and add a background color), e.g. for video watch to avoid scanning out black bars. -Daniel -- = Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48