From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH i-g-t 3/3] kms_universal_plane: Universal plane testing Date: Fri, 11 Apr 2014 13:57:33 +0200 Message-ID: <20140411115733.GG9262@phenom.ffwll.local> References: <1397175876-3216-1-git-send-email-matthew.d.roper@intel.com> <1397175985-3328-1-git-send-email-matthew.d.roper@intel.com> <1397175985-3328-4-git-send-email-matthew.d.roper@intel.com> <20140411092239.GC9262@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by gabe.freedesktop.org (Postfix) with ESMTP id A7B5D6ED7B for ; Fri, 11 Apr 2014 04:57:37 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id e49so4116135eek.3 for ; Fri, 11 Apr 2014 04:57:35 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20140411092239.GC9262@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-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Fri, Apr 11, 2014 at 11:22:39AM +0200, Daniel Vetter wrote: > On Thu, Apr 10, 2014 at 05:26:25PM -0700, Matt Roper wrote: > > Add a simple test to exercise universal plane support. > > > > Signed-off-by: Matt Roper > > Looks like a good functional test, but I think we need to add a bit more > api nastiness still. So no functional tests with CRCs, but just tests to > make sure the kernel doesn't fall over. > > - primary plane set_plane calls vs. legacy setcrtc primary plane updates. > We'll very likely have mixed userspace (e.g. boot splash vs. display > manager). E.g. disable primary plane (but keep everything working), then > setCrtc a new plane framebuffer. > > - primary plane vs. other ioctls. Might be easier to extend existing tests > for this. E.g. doing a pageflip ioctl if the primary plane is off > (might need to decide what we really want to do and if we decide that it > should enable the primary plane then we need a CRC based test to make > sure that the transition is perfect). > > Or primary plane changes vs. dpms and suspend/resume. For those > functional checks based on CRC would be good to make sure we properly > restore everything. > > - Maybe exercise some of the checks in the primary plane helper to make > sure they work. In the future we'll probably lift those limitations (not > on current hw afaik though), but then we can adjust those tests to skip > on these platforms. > > - Anything else that was pointed out in review or was tricky while > developing this stuff. More ideas! My main concern is interactions with existing features when the primary plane is disabled and no other plane/cursor enabled, i.e. when we scan out a solid black. - solid black vs. dpms for all connector/pipe pairings. The modeset sequence is different for different connectors and my gut says not enabling the primary plane might cause trouble. - solid black vs. vblank events. When transition through a "no planes" situation we need to make sure that vblank events keep on working. A testcase (maybe in combination of some of the dpms and susped/resume case above too) would be good. I'll leave it to you to somewhat sensibly group all these ideas into real testcases ;-) For further inspiration maybe look at the corner cases existing kms_* tests exercise a bit. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch