On Mon, Dec 14, 2015 at 04:58:13PM +0100, Thierry Reding wrote:
> On Tue, Dec 08, 2015 at 09:49:19AM +0100, Daniel Vetter wrote:
> [...]
> > @@ -187,6 +189,9 @@ struct drm_framebuffer_funcs {
> > * copying the current screen contents to a private buffer and blending
> > * between that and the new contents.
> > *
> > + * GEM based drivers should call drm_gem_handle_create() to create the
> > + * handle.
> > + *
> > * RETURNS:
> > *
> > * 0 on success or a negative error code on failure.
> > @@ -1727,6 +1732,17 @@ struct drm_mode_config_funcs {
> > * requested metadata, but most of that is left to the driver. See
> > * struct &drm_mode_fb_cmd2 for details.
> > *
> > + * If the parameters are deemed valid and the backing storage objects in
> > + * the underlying memory manager all exists then the drivers to allocate
>
> "... all exist, then the driver allocates a new &drm_framebuffer structure
> ..."?
>
> > + * a new &drm_framebuffer structure, subclassed to contain
> > + * driver-specific information (like the internal native buffer object
> > + * references). It also needs to fill out all relevant metadata, which
> > + * should by done by calling drm_helper_mode_fill_fb_struct().
>
> "should be done"
>
> > + *
> > + * The initializing is finalized by calling drm_framebuffer_init(),
>
> "The initialization"
>
> Other than that, looks good:
>
> Reviewed-by: Thierry Reding <treding at nvidia.com>
All fixed up on both this and the previous patch applied, thanks a lot for
your review.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
