[Intel-gfx] [PATCH 11/22] drm/i915: Don't pass plane+plane_state to intel_pin_and_fence_fb_obj()

[Daniel Vetter]

On Thu, Oct 15, 2015 at 12:36:43PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 15, 2015 at 10:08:53AM +0100, Chris Wilson wrote:
> > On Wed, Oct 14, 2015 at 07:29:03PM +0300, ville.syrjala at linux.intel.com wrote:
> > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > 
> > > intel_pin_and_fence_fb_obj() only needs the framebuffer, and the desird
> > > rotation (to find the right GTT view for it), so no need to pass all
> > > kinds of plane stuff.
> > 
> > imho this is a mistep, I think using the plane-state to not only pass
> > the full description of the plane being bound (which may have additional
> > information like the need for fencing for fbc as well as alternative
> > views, i.e. it is a lot more versatile) but also allows us to track the
> > binding for the plane-state and tie the VMA to lifetime of the plane.
> > 
> > i.e. I think intel_pin_and_fence_fb_obj would be better described as
> > intel_plane_state_pin_vma (and correspondingly
> > intel_plane_state_unpin_vma).
> > 
> > Yes, intel_fbdev.c is a wart to any proposed interface.
> 
> The current code is just too ugly to live IMO (due to fbdev, yes), so
> I think we want this for now. We can always wrap it up in fancier
> clothing for users that actually have a plane state once someone comes
> up with some real code that needs it.

To handle this we could make intel_pin_and_fence_fb return the vma for
callers to store in the plane state eventually, with errors encoded using
ERR_PTR. That way we can keep intel_fbdev.c as is and still store the vma
in the plane state.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch