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@xxxxxxxxxxxxxxx wrote: > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
