I missed a few paragraphs in the docbook that need to be pulled into
the fbdev vfunc docs.
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/gpu.tmpl | 72 +-
include/drm/drm_crtc.h | 18 ++-
2 files changed, 18 insertions(+), 72 deletions(-)
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 5698c93dae8b..0c02ba0d0750 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -986,10 +986,7 @@ int max_width, max_height;
!Idrivers/gpu/drm/drm_atomic.c
- Frame Buffer Creation
- struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
-struct drm_file *file_priv,
-struct drm_mode_fb_cmd2
*mode_cmd);
+ Frame Buffer Abstraction
Frame buffers are abstract memory objects that provide a source of
pixels to scanout to a CRTC. Applications explicitly request the
@@ -1008,73 +1005,6 @@ int max_width, max_height;
and so expects TTM handles in the create ioctl and not GEM handles.
-Drivers must first validate the requested frame buffer parameters
passed
-through the mode_cmd argument. In particular this is where invalid
-sizes, pixel formats or pitches can be caught.
-
-
-If the parameters are deemed valid, drivers then create, initialize and
-return an instance of struct drm_framebuffer.
-If desired the instance can be embedded in a larger driver-specific
- structure. Drivers must fill its width,
- height, pitches,
-offsets, depth,
-bits_per_pixel and
-pixel_format fields from the values passed
-through the drm_mode_fb_cmd2 argument. They
-should call the drm_helper_mode_fill_fb_struct
-helper function to do so.
-
-
-
- The initialization of the new framebuffer instance is finalized with a
- call to drm_framebuffer_init which takes a pointer
- to DRM frame buffer operations (struct
- drm_framebuffer_funcs). Note that this function
- publishes the framebuffer and so from this point on it can be accessed
- concurrently from other threads. Hence it must be the last step in the
- driver's framebuffer initialization sequence. Frame buffer operations
- are
-
-
-int (*create_handle)(struct drm_framebuffer *fb,
-struct drm_file *file_priv, unsigned int
*handle);
-
- Create a handle to the frame buffer underlying memory object. If
- the frame buffer uses a multi-plane format, the handle will
- reference the memory object associated with the first plane.
-
-
- Drivers call drm_gem_handle_create to create
- the handle.
-
-
-
-void (*destroy)(struct drm_framebuffer
*framebuffer);
-
- Destroy the frame buffer object and frees all associated
- resources. Drivers must call
- drm_framebuffer_cleanup to free resources
- allocated by the DRM core for the frame buffer object, and must
- make sure to unreference all memory objects associated with the
- frame buffer. Handles created by the
- create_handle operation are released by
- the DRM core.
-
-
-
-int (*dirty)(struct drm_framebuffer *framebuffer,
-struct drm_file *file_priv, unsigned flags, unsigned color,
-struct drm_clip_rect *clips, unsigned num_clips);
-
- This optional operation notifies the driver that a region of the
- frame buffer has changed in response to a DRM_IOCTL_MODE_DIRTYFB
- ioctl call.
-
-
-
-
-
The lifetime of a drm framebuffer is controlled with a reference count,
drivers can grab additional references with
drm_framebuffer_referenceand drop them
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 4f587a5bc88f..6fe14a773def 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -172,7 +172,9 @@ struct drm_framebuffer_funcs {
* Clean up framebuffer resources, specifically also unreference the
* backing storage. The core guarantees to call this function for every
* framebuffer successfully created by ->fb_create() in
-* &drm_mode_config_funcs.
+* &drm_mode_config_funcs. Drivers must also call
+* drm_framebuffer_cleanup() to release DRM core resources for this
+* framebuffer.
*/
void (*destroy)(struct drm_framebuffer *framebuffer);
@@ -187,6 +189,9 @@ struct drm_framebuffer_funcs {
* copying the
