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@xxxxxxxxxx>
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
