Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

drm: Consolidate dumb buffer docs

Put the callback docs into struct drm_driver, and the small overview
into a DOC comment.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161114115825.22050-7-daniel.vetter@ffwll.ch

+67 -69
+2 -40
Documentation/gpu/drm-kms.rst
··· 72 72 Dumb Buffer Objects 73 73 =================== 74 74 75 - The KMS API doesn't standardize backing storage object creation and 76 - leaves it to driver-specific ioctls. Furthermore actually creating a 77 - buffer object even for GEM-based drivers is done through a 78 - driver-specific ioctl - GEM only has a common userspace interface for 79 - sharing and destroying objects. While not an issue for full-fledged 80 - graphics stacks that include device-specific userspace components (in 81 - libdrm for instance), this limit makes DRM-based early boot graphics 82 - unnecessarily complex. 83 - 84 - Dumb objects partly alleviate the problem by providing a standard API to 85 - create dumb buffers suitable for scanout, which can then be used to 86 - create KMS frame buffers. 87 - 88 - To support dumb objects drivers must implement the dumb_create, 89 - dumb_destroy and dumb_map_offset operations. 90 - 91 - - int (\*dumb_create)(struct drm_file \*file_priv, struct 92 - drm_device \*dev, struct drm_mode_create_dumb \*args); 93 - The dumb_create operation creates a driver object (GEM or TTM 94 - handle) suitable for scanout based on the width, height and depth 95 - from the struct :c:type:`struct drm_mode_create_dumb 96 - <drm_mode_create_dumb>` argument. It fills the argument's 97 - handle, pitch and size fields with a handle for the newly created 98 - object and its line pitch and size in bytes. 99 - 100 - - int (\*dumb_destroy)(struct drm_file \*file_priv, struct 101 - drm_device \*dev, uint32_t handle); 102 - The dumb_destroy operation destroys a dumb object created by 103 - dumb_create. 104 - 105 - - int (\*dumb_map_offset)(struct drm_file \*file_priv, struct 106 - drm_device \*dev, uint32_t handle, uint64_t \*offset); 107 - The dumb_map_offset operation associates an mmap fake offset with 108 - the object given by the handle and returns it. Drivers must use the 109 - :c:func:`drm_gem_create_mmap_offset()` function to associate 110 - the fake offset as described in ?. 111 - 112 - Note that dumb objects may not be used for gpu acceleration, as has been 113 - attempted on some ARM embedded platforms. Such drivers really must have 114 - a hardware-specific ioctl to allocate suitable buffer objects. 75 + .. kernel-doc:: drivers/gpu/drm/drm_dumb_buffers.c 76 + :doc: overview 115 77 116 78 Plane Abstraction 117 79 =================
+18 -28
drivers/gpu/drm/drm_dumb_buffers.c
··· 28 28 #include "drm_crtc_internal.h" 29 29 30 30 /** 31 - * drm_mode_create_dumb_ioctl - create a dumb backing storage buffer 32 - * @dev: DRM device 33 - * @data: ioctl data 34 - * @file_priv: DRM file info 31 + * DOC: overview 35 32 * 36 - * This creates a new dumb buffer in the driver's backing storage manager (GEM, 37 - * TTM or something else entirely) and returns the resulting buffer handle. This 38 - * handle can then be wrapped up into a framebuffer modeset object. 33 + * The KMS API doesn't standardize backing storage object creation and leaves it 34 + * to driver-specific ioctls. Furthermore actually creating a buffer object even 35 + * for GEM-based drivers is done through a driver-specific ioctl - GEM only has 36 + * a common userspace interface for sharing and destroying objects. While not an 37 + * issue for full-fledged graphics stacks that include device-specific userspace 38 + * components (in libdrm for instance), this limit makes DRM-based early boot 39 + * graphics unnecessarily complex. 39 40 * 40 - * Note that userspace is not allowed to use such objects for render 41 - * acceleration - drivers must create their own private ioctls for such a use 42 - * case. 41 + * Dumb objects partly alleviate the problem by providing a standard API to 42 + * create dumb buffers suitable for scanout, which can then be used to create 43 + * KMS frame buffers. 43 44 * 44 - * Called by the user via ioctl. 45 + * To support dumb objects drivers must implement the dumb_create, 46 + * dumb_destroy and dumb_map_offset operations from struct &drm_driver. See 47 + * there for further details. 45 48 * 46 - * Returns: 47 - * Zero on success, negative errno on failure. 49 + * Note that dumb objects may not be used for gpu acceleration, as has been 50 + * attempted on some ARM embedded platforms. Such drivers really must have 51 + * a hardware-specific ioctl to allocate suitable buffer objects. 48 52 */ 53 + 49 54 int drm_mode_create_dumb_ioctl(struct drm_device *dev, 50 55 void *data, struct drm_file *file_priv) 51 56 { ··· 115 110 return dev->driver->dumb_map_offset(file_priv, dev, args->handle, &args->offset); 116 111 } 117 112 118 - /** 119 - * drm_mode_destroy_dumb_ioctl - destroy a dumb backing strage buffer 120 - * @dev: DRM device 121 - * @data: ioctl data 122 - * @file_priv: DRM file info 123 - * 124 - * This destroys the userspace handle for the given dumb backing storage buffer. 125 - * Since buffer objects must be reference counted in the kernel a buffer object 126 - * won't be immediately freed if a framebuffer modeset object still uses it. 127 - * 128 - * Called by the user via ioctl. 129 - * 130 - * Returns: 131 - * Zero on success, negative errno on failure. 132 - */ 133 113 int drm_mode_destroy_dumb_ioctl(struct drm_device *dev, 134 114 void *data, struct drm_file *file_priv) 135 115 {
+47 -1
include/drm/drm_drv.h
··· 328 328 /* vga arb irq handler */ 329 329 void (*vgaarb_irq)(struct drm_device *dev, bool state); 330 330 331 - /* dumb alloc support */ 331 + /** 332 + * @dumb_create: 333 + * 334 + * This creates a new dumb buffer in the driver's backing storage manager (GEM, 335 + * TTM or something else entirely) and returns the resulting buffer handle. This 336 + * handle can then be wrapped up into a framebuffer modeset object. 337 + * 338 + * Note that userspace is not allowed to use such objects for render 339 + * acceleration - drivers must create their own private ioctls for such a use 340 + * case. 341 + * 342 + * Width, height and depth are specified in the &drm_mode_create_dumb 343 + * argument. The callback needs to fill the handle, pitch and size for 344 + * the created buffer. 345 + * 346 + * Called by the user via ioctl. 347 + * 348 + * Returns: 349 + * 350 + * Zero on success, negative errno on failure. 351 + */ 332 352 int (*dumb_create)(struct drm_file *file_priv, 333 353 struct drm_device *dev, 334 354 struct drm_mode_create_dumb *args); 355 + /** 356 + * @dumb_map_offset: 357 + * 358 + * Allocate an offset in the drm device node's address space to be able to 359 + * memory map a dumb buffer. GEM-based drivers must use 360 + * drm_gem_create_mmap_offset() to implement this. 361 + * 362 + * Called by the user via ioctl. 363 + * 364 + * Returns: 365 + * 366 + * Zero on success, negative errno on failure. 367 + */ 335 368 int (*dumb_map_offset)(struct drm_file *file_priv, 336 369 struct drm_device *dev, uint32_t handle, 337 370 uint64_t *offset); 371 + /** 372 + * @dumb_destroy: 373 + * 374 + * This destroys the userspace handle for the given dumb backing storage buffer. 375 + * Since buffer objects must be reference counted in the kernel a buffer object 376 + * won't be immediately freed if a framebuffer modeset object still uses it. 377 + * 378 + * Called by the user via ioctl. 379 + * 380 + * Returns: 381 + * 382 + * Zero on success, negative errno on failure. 383 + */ 338 384 int (*dumb_destroy)(struct drm_file *file_priv, 339 385 struct drm_device *dev, 340 386 uint32_t handle);