From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFCv3 11/14] drm/i915: Intel-specific primary plane handling Date: Wed, 19 Mar 2014 15:37:40 +0100 Message-ID: <20140319143740.GE30571@phenom.ffwll.local> References: <1395188579-17191-1-git-send-email-matthew.d.roper@intel.com> <1395188579-17191-12-git-send-email-matthew.d.roper@intel.com> <20140319121126.GY30571@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by gabe.freedesktop.org (Postfix) with ESMTP id 0D41C6EE3F for ; Wed, 19 Mar 2014 07:37:45 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id d17so6742825eek.1 for ; Wed, 19 Mar 2014 07:37:44 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20140319121126.GY30571@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Matt Roper Cc: Intel Graphics Development , dri-devel@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Wed, Mar 19, 2014 at 01:11:26PM +0100, Daniel Vetter wrote: > On Tue, Mar 18, 2014 at 05:22:56PM -0700, Matt Roper wrote: > > Intel hardware allows the primary plane to be disabled independently of > > the CRTC. Provide custom primary plane handling to allow this. > > > > Cc: Intel Graphics Development > > Signed-off-by: Matt Roper > > Overall this is imo a new feature since it exposes primary plane disabling > to userspace. Which means I want a crc based igt for this. Two interesting > cases imo: > > 1) Partially visible primary plane behind an overlay plane. Disabling it > should change those areas from the primary plane to grey or something, so > easy to check with CRCs. > > 2) Primary plane + cursor, disable primary plane. Then check that the > cursor is still working. Same for overlay sprites. > > At least on all currently supported platforms we don't have unified planes > in the hardware, so imo it's worth to check that this works properly. One big reason I've forgotten why I really want testcase for this is that historically our code has fallen over in _really_ bad ways without a primary fb. fastboot has brought a lot of these issues to light (since we occasionally fail to wrap up the firmware's fb properly). So having a bit of a baseline testcase so that we can easily add regression tests for specific bugs once we inevitably run into them is good prep work, too. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch