drm/doc: Update drm_framebuffer docs

- Move the intro section into a DOC comment, and update it slightly.
- kernel-doc for struct drm_framebuffer!

v2:
- Copypaste fail (Sean).
- Explain the linear @offsets clearer (Ville).

Cc: Sean Paul <seanpaul@chromium.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-12-git-send-email-daniel.vetter@ffwll.ch
This commit is contained in:
Daniel Vetter 2016-08-12 22:48:48 +02:00
parent 7520a277d9
commit 750fb8c439
3 changed files with 130 additions and 37 deletions

View file

@ -27,6 +27,41 @@
#include "drm_crtc_internal.h"
/**
* DOC: overview
*
* Frame buffers are abstract memory objects that provide a source of pixels to
* scanout to a CRTC. Applications explicitly request the creation of frame
* buffers through the DRM_IOCTL_MODE_ADDFB(2) ioctls and receive an opaque
* handle that can be passed to the KMS CRTC control, plane configuration and
* page flip functions.
*
* Frame buffers rely on the underlying memory manager for allocating backing
* storage. When creating a frame buffer applications pass a memory handle
* (or a list of memory handles for multi-planar formats) through the
* struct &drm_mode_fb_cmd2 argument. For drivers using GEM as their userspace
* buffer management interface this would be a GEM handle. Drivers are however
* free to use their own backing storage object handles, e.g. vmwgfx directly
* exposes special TTM handles to userspace and so expects TTM handles in the
* create ioctl and not GEM handles.
*
* Framebuffers are tracked with struct &drm_framebuffer. They are published
* using drm_framebuffer_init() - after calling that function userspace can use
* and access the framebuffer object. The helper function
* drm_helper_mode_fill_fb_struct() can be used to pre-fill the required
* metadata fields.
*
* The lifetime of a drm framebuffer is controlled with a reference count,
* drivers can grab additional references with drm_framebuffer_reference() and
* drop them again with drm_framebuffer_unreference(). For driver-private
* framebuffers for which the last reference is never dropped (e.g. for the
* fbdev framebuffer when the struct struct &drm_framebuffer is embedded into
* the fbdev helper struct) drivers can manually clean up a framebuffer at
* module unload time with drm_framebuffer_unregister_private(). But doing this
* is not recommended, and it's better to have a normal free-standing struct
* &drm_framebuffer.
*/
/**
* drm_mode_addfb - add an FB to the graphics configuration
* @dev: drm device for the ioctl