From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Roper Subject: Re: [PATCH 4/4] drm/i915: Intel-specific primary plane handling (v6) Date: Thu, 15 May 2014 14:25:51 -0700 Message-ID: <20140515212551.GA31484@intel.com> References: <1398877623-16930-1-git-send-email-matthew.d.roper@intel.com> <1398877623-16930-5-git-send-email-matthew.d.roper@intel.com> <20140515155228.GF27580@intel.com> <20140515163755.GD23405@intel.com> <20140515170048.GG27580@intel.com> <20140515193517.GE23405@intel.com> <20140515204952.GW8790@phenom.ffwll.local> <20140515205939.GF23405@intel.com> <20140515212039.GB8790@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id B2F636EF18 for ; Thu, 15 May 2014 14:25:01 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20140515212039.GB8790@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: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Thu, May 15, 2014 at 11:20:39PM +0200, Daniel Vetter wrote: > > > > Ah, you're right. I was conflating explicit disables (fb=0) with > > > > implicit disables (clipped to invisible). I think the v7 I just sent > > > > should handle this properly...for the implicit disable case we leave the > > > > fb pinned and pointed to by primary->fb. So when we switch to another > > > > fb (or explicitly disable with fb=0), we should unpin it properly. > > > > > > Do we have proper coverage for this fun in our primary plane helper tests? > > > This is the kind of complexity that freaks me out ;-) > > > -Daniel > > > > Was 'helper' in your question above a typo? The i-g-t tests I've > > written have been intended for use with this patch (i.e., i915-specific > > primary plane support), so I don't really have any tests that only test > > the lesser, helper-provided functionality (and drivers using the helpers > > shouldn't run into the things Ville is pointing out here because they > > can't disable the primary plane independent of the crtc). > > > > But assuming you meant the general i-g-t tests, yeah, I also posted a > > slightly updated version so that it now tries to set multiple fb's while > > the crtc is off. Since crtc=off causes the primary plane to be fully > > clipped and implicitly disabled, it should exercise these cases and > > catch the pin/unpin mistakes that Ville's review caught. > > Yeah, s/helper// ;-) For the tests, do you also have some that use the > implicit fb (i.e. fb = -1) with setcrtc? Just kinda for completeness. > -Daniel Yeah...turn off the crtc, set a few different fb's via setplane, then turn the crtc back on with drmModeSetCrtc(fb = -1) and test that it pops up with the right framebuffer set. Matt -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795