Re: [PATCH 4/4] drm/i915: Intel-specific primary plane handling (v6)

[Matt Roper <matthew.d.roper@intel.com>]

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