linux/include/media/videobuf2-core.h

1229 lines
47 KiB
C
Raw Normal View History

/*
* videobuf2-core.h - Video Buffer 2 Core Framework
*
* Copyright (C) 2010 Samsung Electronics
*
* Author: Pawel Osciak <pawel@osciak.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation.
*/
#ifndef _MEDIA_VIDEOBUF2_CORE_H
#define _MEDIA_VIDEOBUF2_CORE_H
#include <linux/mm_types.h>
#include <linux/mutex.h>
#include <linux/poll.h>
#include <linux/dma-buf.h>
#include <linux/bitops.h>
#include <media/media-request.h>
#define VB2_MAX_FRAME (32)
#define VB2_MAX_PLANES (8)
/**
* enum vb2_memory - type of memory model used to make the buffers visible
* on userspace.
*
* @VB2_MEMORY_UNKNOWN: Buffer status is unknown or it is not used yet on
* userspace.
* @VB2_MEMORY_MMAP: The buffers are allocated by the Kernel and it is
* memory mapped via mmap() ioctl. This model is
* also used when the user is using the buffers via
* read() or write() system calls.
* @VB2_MEMORY_USERPTR: The buffers was allocated in userspace and it is
* memory mapped via mmap() ioctl.
* @VB2_MEMORY_DMABUF: The buffers are passed to userspace via DMA buffer.
*/
enum vb2_memory {
VB2_MEMORY_UNKNOWN = 0,
VB2_MEMORY_MMAP = 1,
VB2_MEMORY_USERPTR = 2,
VB2_MEMORY_DMABUF = 4,
};
struct vb2_fileio_data;
struct vb2_threadio_data;
/**
* struct vb2_mem_ops - memory handling/memory allocator operations.
* @alloc: allocate video memory and, optionally, allocator private data,
* return ERR_PTR() on failure or a pointer to allocator private,
* per-buffer data on success; the returned private structure
* will then be passed as @buf_priv argument to other ops in this
* structure. Additional gfp_flags to use when allocating the
* are also passed to this operation. These flags are from the
* gfp_flags field of vb2_queue. The size argument to this function
* shall be *page aligned*.
* @put: inform the allocator that the buffer will no longer be used;
* usually will result in the allocator freeing the buffer (if
* no other users of this buffer are present); the @buf_priv
* argument is the allocator private per-buffer structure
* previously returned from the alloc callback.
* @get_dmabuf: acquire userspace memory for a hardware operation; used for
* DMABUF memory types.
* @get_userptr: acquire userspace memory for a hardware operation; used for
* USERPTR memory types; vaddr is the address passed to the
* videobuf layer when queuing a video buffer of USERPTR type;
* should return an allocator private per-buffer structure
* associated with the buffer on success, ERR_PTR() on failure;
* the returned private structure will then be passed as @buf_priv
* argument to other ops in this structure.
* @put_userptr: inform the allocator that a USERPTR buffer will no longer
* be used.
* @attach_dmabuf: attach a shared &struct dma_buf for a hardware operation;
* used for DMABUF memory types; dev is the alloc device
* dbuf is the shared dma_buf; returns ERR_PTR() on failure;
* allocator private per-buffer structure on success;
* this needs to be used for further accesses to the buffer.
* @detach_dmabuf: inform the exporter of the buffer that the current DMABUF
* buffer is no longer used; the @buf_priv argument is the
* allocator private per-buffer structure previously returned
* from the attach_dmabuf callback.
* @map_dmabuf: request for access to the dmabuf from allocator; the allocator
* of dmabuf is informed that this driver is going to use the
* dmabuf.
* @unmap_dmabuf: releases access control to the dmabuf - allocator is notified
* that this driver is done using the dmabuf for now.
* @prepare: called every time the buffer is passed from userspace to the
* driver, useful for cache synchronisation, optional.
* @finish: called every time the buffer is passed back from the driver
* to the userspace, also optional.
* @vaddr: return a kernel virtual address to a given memory buffer
* associated with the passed private structure or NULL if no
* such mapping exists.
* @cookie: return allocator specific cookie for a given memory buffer
* associated with the passed private structure or NULL if not
* available.
* @num_users: return the current number of users of a memory buffer;
* return 1 if the videobuf layer (or actually the driver using
* it) is the only user.
* @mmap: setup a userspace mapping for a given memory buffer under
* the provided virtual memory region.
*
* Those operations are used by the videobuf2 core to implement the memory
* handling/memory allocators for each type of supported streaming I/O method.
*
* .. note::
* #) Required ops for USERPTR types: get_userptr, put_userptr.
*
* #) Required ops for MMAP types: alloc, put, num_users, mmap.
*
* #) Required ops for read/write access types: alloc, put, num_users, vaddr.
*
* #) Required ops for DMABUF types: attach_dmabuf, detach_dmabuf,
* map_dmabuf, unmap_dmabuf.
*/
struct vb2_mem_ops {
dma-mapping: use unsigned long for dma_attrs The dma-mapping core and the implementations do not change the DMA attributes passed by pointer. Thus the pointer can point to const data. However the attributes do not have to be a bitfield. Instead unsigned long will do fine: 1. This is just simpler. Both in terms of reading the code and setting attributes. Instead of initializing local attributes on the stack and passing pointer to it to dma_set_attr(), just set the bits. 2. It brings safeness and checking for const correctness because the attributes are passed by value. Semantic patches for this change (at least most of them): virtual patch virtual context @r@ identifier f, attrs; @@ f(..., - struct dma_attrs *attrs + unsigned long attrs , ...) { ... } @@ identifier r.f; @@ f(..., - NULL + 0 ) and // Options: --all-includes virtual patch virtual context @r@ identifier f, attrs; type t; @@ t f(..., struct dma_attrs *attrs); @@ identifier r.f; @@ f(..., - NULL + 0 ) Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.com Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Acked-by: Vineet Gupta <vgupta@synopsys.com> Acked-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> Acked-by: Mark Salter <msalter@redhat.com> [c6x] Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> [cris] Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [drm] Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com> Acked-by: Joerg Roedel <jroedel@suse.de> [iommu] Acked-by: Fabien Dessenne <fabien.dessenne@st.com> [bdisp] Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> [vb2-core] Acked-by: David Vrabel <david.vrabel@citrix.com> [xen] Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [xen swiotlb] Acked-by: Joerg Roedel <jroedel@suse.de> [iommu] Acked-by: Richard Kuo <rkuo@codeaurora.org> [hexagon] Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [m68k] Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> [s390] Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> [avr32] Acked-by: Vineet Gupta <vgupta@synopsys.com> [arc] Acked-by: Robin Murphy <robin.murphy@arm.com> [arm64 and dma-iommu] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-08-04 04:46:00 +08:00
void *(*alloc)(struct device *dev, unsigned long attrs,
unsigned long size,
enum dma_data_direction dma_dir,
gfp_t gfp_flags);
void (*put)(void *buf_priv);
struct dma_buf *(*get_dmabuf)(void *buf_priv, unsigned long flags);
void *(*get_userptr)(struct device *dev, unsigned long vaddr,
unsigned long size,
enum dma_data_direction dma_dir);
void (*put_userptr)(void *buf_priv);
void (*prepare)(void *buf_priv);
void (*finish)(void *buf_priv);
void *(*attach_dmabuf)(struct device *dev,
struct dma_buf *dbuf,
unsigned long size,
enum dma_data_direction dma_dir);
void (*detach_dmabuf)(void *buf_priv);
int (*map_dmabuf)(void *buf_priv);
void (*unmap_dmabuf)(void *buf_priv);
void *(*vaddr)(void *buf_priv);
void *(*cookie)(void *buf_priv);
unsigned int (*num_users)(void *buf_priv);
int (*mmap)(void *buf_priv, struct vm_area_struct *vma);
};
/**
* struct vb2_plane - plane information.
* @mem_priv: private data with this plane.
* @dbuf: dma_buf - shared buffer object.
* @dbuf_mapped: flag to show whether dbuf is mapped or not
* @bytesused: number of bytes occupied by data in the plane (payload).
* @length: size of this plane (NOT the payload) in bytes.
* @min_length: minimum required size of this plane (NOT the payload) in bytes.
* @length is always greater or equal to @min_length.
* @m: Union with memtype-specific data.
* @m.offset: when memory in the associated struct vb2_buffer is
* %VB2_MEMORY_MMAP, equals the offset from the start of
* the device memory for this plane (or is a "cookie" that
* should be passed to mmap() called on the video node).
* @m.userptr: when memory is %VB2_MEMORY_USERPTR, a userspace pointer
* pointing to this plane.
* @m.fd: when memory is %VB2_MEMORY_DMABUF, a userspace file
* descriptor associated with this plane.
* @data_offset: offset in the plane to the start of data; usually 0,
* unless there is a header in front of the data.
*
* Should contain enough information to be able to cover all the fields
* of &struct v4l2_plane at videodev2.h.
*/
struct vb2_plane {
void *mem_priv;
struct dma_buf *dbuf;
unsigned int dbuf_mapped;
unsigned int bytesused;
unsigned int length;
unsigned int min_length;
union {
unsigned int offset;
unsigned long userptr;
int fd;
} m;
unsigned int data_offset;
};
/**
* enum vb2_io_modes - queue access methods.
* @VB2_MMAP: driver supports MMAP with streaming API.
* @VB2_USERPTR: driver supports USERPTR with streaming API.
* @VB2_READ: driver supports read() style access.
* @VB2_WRITE: driver supports write() style access.
* @VB2_DMABUF: driver supports DMABUF with streaming API.
*/
enum vb2_io_modes {
VB2_MMAP = BIT(0),
VB2_USERPTR = BIT(1),
VB2_READ = BIT(2),
VB2_WRITE = BIT(3),
VB2_DMABUF = BIT(4),
};
/**
* enum vb2_buffer_state - current video buffer state.
* @VB2_BUF_STATE_DEQUEUED: buffer under userspace control.
* @VB2_BUF_STATE_IN_REQUEST: buffer is queued in media request.
* @VB2_BUF_STATE_PREPARING: buffer is being prepared in videobuf.
* @VB2_BUF_STATE_QUEUED: buffer queued in videobuf, but not in driver.
* @VB2_BUF_STATE_ACTIVE: buffer queued in driver and possibly used
* in a hardware operation.
* @VB2_BUF_STATE_DONE: buffer returned from driver to videobuf, but
* not yet dequeued to userspace.
* @VB2_BUF_STATE_ERROR: same as above, but the operation on the buffer
* has ended with an error, which will be reported
* to the userspace when it is dequeued.
*/
enum vb2_buffer_state {
VB2_BUF_STATE_DEQUEUED,
VB2_BUF_STATE_IN_REQUEST,
VB2_BUF_STATE_PREPARING,
VB2_BUF_STATE_QUEUED,
VB2_BUF_STATE_ACTIVE,
VB2_BUF_STATE_DONE,
VB2_BUF_STATE_ERROR,
};
struct vb2_queue;
/**
* struct vb2_buffer - represents a video buffer.
* @vb2_queue: pointer to &struct vb2_queue with the queue to
* which this driver belongs.
* @index: id number of the buffer.
* @type: buffer type.
* @memory: the method, in which the actual data is passed.
* @num_planes: number of planes in the buffer
* on an internal driver queue.
* @timestamp: frame timestamp in ns.
media: vb2: keep a reference to the request until dqbuf When vb2_buffer_done is called the buffer is unbound from the request and put. The media_request_object_put also 'put's the request reference. If the application has already closed the request fd, then that means that the request reference at that point goes to 0 and the whole request is released. This means that the control handler associated with the request is also freed and that causes this kernel oops: [174705.995401] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908 [174705.995411] in_atomic(): 1, irqs_disabled(): 1, pid: 28071, name: vivid-000-vid-o [174705.995416] 2 locks held by vivid-000-vid-o/28071: [174705.995420] #0: 000000001ea3a232 (&dev->mutex#3){....}, at: vivid_thread_vid_out+0x3f5/0x550 [vivid] [174705.995447] #1: 00000000e30a0d1e (&(&q->done_lock)->rlock){....}, at: vb2_buffer_done+0x92/0x1d0 [videobuf2_common] [174705.995460] Preemption disabled at: [174705.995461] [<0000000000000000>] (null) [174705.995472] CPU: 11 PID: 28071 Comm: vivid-000-vid-o Tainted: G W 4.20.0-rc1-test-no #88 [174705.995476] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017 [174705.995481] Call Trace: [174705.995500] dump_stack+0x46/0x60 [174705.995512] ___might_sleep.cold.79+0xe1/0xf1 [174705.995523] __mutex_lock+0x50/0x8f0 [174705.995531] ? find_held_lock+0x2d/0x90 [174705.995536] ? find_held_lock+0x2d/0x90 [174705.995542] ? find_held_lock+0x2d/0x90 [174705.995564] ? v4l2_ctrl_handler_free.part.13+0x44/0x1d0 [videodev] [174705.995576] v4l2_ctrl_handler_free.part.13+0x44/0x1d0 [videodev] [174705.995590] v4l2_ctrl_request_release+0x1c/0x30 [videodev] [174705.995600] media_request_clean+0x64/0xe0 [media] [174705.995609] media_request_release+0x19/0x40 [media] [174705.995617] vb2_buffer_done+0xef/0x1d0 [videobuf2_common] [174705.995630] vivid_thread_vid_out+0x2c1/0x550 [vivid] [174705.995645] ? vivid_stop_generating_vid_cap+0x1c0/0x1c0 [vivid] [174705.995653] kthread+0x113/0x130 [174705.995659] ? kthread_park+0x80/0x80 [174705.995667] ret_from_fork+0x35/0x40 The vb2_buffer_done function can be called from interrupt context, so anything that sleeps is not allowed. The solution is to increment the request refcount when the buffer is queued and decrement it when the buffer is dequeued. Releasing the request is fine if that happens from VIDIOC_DQBUF. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-11-28 16:37:45 +08:00
* @request: the request this buffer is associated with.
* @req_obj: used to bind this buffer to a request. This
* request object has a refcount.
*/
struct vb2_buffer {
struct vb2_queue *vb2_queue;
unsigned int index;
unsigned int type;
unsigned int memory;
unsigned int num_planes;
u64 timestamp;
media: vb2: keep a reference to the request until dqbuf When vb2_buffer_done is called the buffer is unbound from the request and put. The media_request_object_put also 'put's the request reference. If the application has already closed the request fd, then that means that the request reference at that point goes to 0 and the whole request is released. This means that the control handler associated with the request is also freed and that causes this kernel oops: [174705.995401] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908 [174705.995411] in_atomic(): 1, irqs_disabled(): 1, pid: 28071, name: vivid-000-vid-o [174705.995416] 2 locks held by vivid-000-vid-o/28071: [174705.995420] #0: 000000001ea3a232 (&dev->mutex#3){....}, at: vivid_thread_vid_out+0x3f5/0x550 [vivid] [174705.995447] #1: 00000000e30a0d1e (&(&q->done_lock)->rlock){....}, at: vb2_buffer_done+0x92/0x1d0 [videobuf2_common] [174705.995460] Preemption disabled at: [174705.995461] [<0000000000000000>] (null) [174705.995472] CPU: 11 PID: 28071 Comm: vivid-000-vid-o Tainted: G W 4.20.0-rc1-test-no #88 [174705.995476] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017 [174705.995481] Call Trace: [174705.995500] dump_stack+0x46/0x60 [174705.995512] ___might_sleep.cold.79+0xe1/0xf1 [174705.995523] __mutex_lock+0x50/0x8f0 [174705.995531] ? find_held_lock+0x2d/0x90 [174705.995536] ? find_held_lock+0x2d/0x90 [174705.995542] ? find_held_lock+0x2d/0x90 [174705.995564] ? v4l2_ctrl_handler_free.part.13+0x44/0x1d0 [videodev] [174705.995576] v4l2_ctrl_handler_free.part.13+0x44/0x1d0 [videodev] [174705.995590] v4l2_ctrl_request_release+0x1c/0x30 [videodev] [174705.995600] media_request_clean+0x64/0xe0 [media] [174705.995609] media_request_release+0x19/0x40 [media] [174705.995617] vb2_buffer_done+0xef/0x1d0 [videobuf2_common] [174705.995630] vivid_thread_vid_out+0x2c1/0x550 [vivid] [174705.995645] ? vivid_stop_generating_vid_cap+0x1c0/0x1c0 [vivid] [174705.995653] kthread+0x113/0x130 [174705.995659] ? kthread_park+0x80/0x80 [174705.995667] ret_from_fork+0x35/0x40 The vb2_buffer_done function can be called from interrupt context, so anything that sleeps is not allowed. The solution is to increment the request refcount when the buffer is queued and decrement it when the buffer is dequeued. Releasing the request is fine if that happens from VIDIOC_DQBUF. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-11-28 16:37:45 +08:00
struct media_request *request;
struct media_request_object req_obj;
/* private: internal use only
*
* state: current buffer state; do not change
* synced: this buffer has been synced for DMA, i.e. the
* 'prepare' memop was called. It is cleared again
* after the 'finish' memop is called.
* prepared: this buffer has been prepared, i.e. the
* buf_prepare op was called. It is cleared again
* after the 'buf_finish' op is called.
* copied_timestamp: the timestamp of this capture buffer was copied
* from an output buffer.
* queued_entry: entry on the queued buffers list, which holds
* all buffers queued from userspace
* done_entry: entry on the list that stores all buffers ready
* to be dequeued to userspace
* vb2_plane: per-plane information; do not change
*/
enum vb2_buffer_state state;
unsigned int synced:1;
unsigned int prepared:1;
unsigned int copied_timestamp:1;
struct vb2_plane planes[VB2_MAX_PLANES];
struct list_head queued_entry;
struct list_head done_entry;
#ifdef CONFIG_VIDEO_ADV_DEBUG
/*
* Counters for how often these buffer-related ops are
* called. Used to check for unbalanced ops.
*/
u32 cnt_mem_alloc;
u32 cnt_mem_put;
u32 cnt_mem_get_dmabuf;
u32 cnt_mem_get_userptr;
u32 cnt_mem_put_userptr;
u32 cnt_mem_prepare;
u32 cnt_mem_finish;
u32 cnt_mem_attach_dmabuf;
u32 cnt_mem_detach_dmabuf;
u32 cnt_mem_map_dmabuf;
u32 cnt_mem_unmap_dmabuf;
u32 cnt_mem_vaddr;
u32 cnt_mem_cookie;
u32 cnt_mem_num_users;
u32 cnt_mem_mmap;
u32 cnt_buf_out_validate;
u32 cnt_buf_init;
u32 cnt_buf_prepare;
u32 cnt_buf_finish;
u32 cnt_buf_cleanup;
u32 cnt_buf_queue;
u32 cnt_buf_request_complete;
/* This counts the number of calls to vb2_buffer_done() */
u32 cnt_buf_done;
#endif
};
/**
* struct vb2_ops - driver-specific callbacks.
*
* These operations are not called from interrupt context except where
* mentioned specifically.
*
* @queue_setup: called from VIDIOC_REQBUFS() and VIDIOC_CREATE_BUFS()
* handlers before memory allocation. It can be called
* twice: if the original number of requested buffers
* could not be allocated, then it will be called a
* second time with the actually allocated number of
* buffers to verify if that is OK.
* The driver should return the required number of buffers
* in \*num_buffers, the required number of planes per
* buffer in \*num_planes, the size of each plane should be
* set in the sizes\[\] array and optional per-plane
* allocator specific device in the alloc_devs\[\] array.
* When called from VIDIOC_REQBUFS(), \*num_planes == 0,
* the driver has to use the currently configured format to
* determine the plane sizes and \*num_buffers is the total
* number of buffers that are being allocated. When called
* from VIDIOC_CREATE_BUFS(), \*num_planes != 0 and it
* describes the requested number of planes and sizes\[\]
* contains the requested plane sizes. In this case
* \*num_buffers are being allocated additionally to
* q->num_buffers. If either \*num_planes or the requested
* sizes are invalid callback must return %-EINVAL.
* @wait_prepare: release any locks taken while calling vb2 functions;
* it is called before an ioctl needs to wait for a new
* buffer to arrive; required to avoid a deadlock in
* blocking access type.
* @wait_finish: reacquire all locks released in the previous callback;
* required to continue operation after sleeping while
* waiting for a new buffer to arrive.
* @buf_out_validate: called when the output buffer is prepared or queued
* to a request; drivers can use this to validate
* userspace-provided information; this is required only
* for OUTPUT queues.
* @buf_init: called once after allocating a buffer (in MMAP case)
* or after acquiring a new USERPTR buffer; drivers may
* perform additional buffer-related initialization;
* initialization failure (return != 0) will prevent
* queue setup from completing successfully; optional.
* @buf_prepare: called every time the buffer is queued from userspace
* and from the VIDIOC_PREPARE_BUF() ioctl; drivers may
* perform any initialization required before each
* hardware operation in this callback; drivers can
* access/modify the buffer here as it is still synced for
* the CPU; drivers that support VIDIOC_CREATE_BUFS() must
* also validate the buffer size; if an error is returned,
* the buffer will not be queued in driver; optional.
* @buf_finish: called before every dequeue of the buffer back to
* userspace; the buffer is synced for the CPU, so drivers
* can access/modify the buffer contents; drivers may
* perform any operations required before userspace
* accesses the buffer; optional. The buffer state can be
* one of the following: %DONE and %ERROR occur while
* streaming is in progress, and the %PREPARED state occurs
* when the queue has been canceled and all pending
* buffers are being returned to their default %DEQUEUED
* state. Typically you only have to do something if the
* state is %VB2_BUF_STATE_DONE, since in all other cases
* the buffer contents will be ignored anyway.
* @buf_cleanup: called once before the buffer is freed; drivers may
* perform any additional cleanup; optional.
* @start_streaming: called once to enter 'streaming' state; the driver may
* receive buffers with @buf_queue callback
* before @start_streaming is called; the driver gets the
* number of already queued buffers in count parameter;
* driver can return an error if hardware fails, in that
* case all buffers that have been already given by
* the @buf_queue callback are to be returned by the driver
* by calling vb2_buffer_done() with %VB2_BUF_STATE_QUEUED.
* If you need a minimum number of buffers before you can
* start streaming, then set
* &vb2_queue->min_buffers_needed. If that is non-zero
* then @start_streaming won't be called until at least
* that many buffers have been queued up by userspace.
* @stop_streaming: called when 'streaming' state must be disabled; driver
* should stop any DMA transactions or wait until they
* finish and give back all buffers it got from &buf_queue
* callback by calling vb2_buffer_done() with either
* %VB2_BUF_STATE_DONE or %VB2_BUF_STATE_ERROR; may use
* vb2_wait_for_all_buffers() function
* @buf_queue: passes buffer vb to the driver; driver may start
* hardware operation on this buffer; driver should give
* the buffer back by calling vb2_buffer_done() function;
* it is always called after calling VIDIOC_STREAMON()
* ioctl; might be called before @start_streaming callback
* if user pre-queued buffers before calling
* VIDIOC_STREAMON().
* @buf_request_complete: a buffer that was never queued to the driver but is
* associated with a queued request was canceled.
* The driver will have to mark associated objects in the
* request as completed; required if requests are
* supported.
*/
struct vb2_ops {
int (*queue_setup)(struct vb2_queue *q,
unsigned int *num_buffers, unsigned int *num_planes,
unsigned int sizes[], struct device *alloc_devs[]);
void (*wait_prepare)(struct vb2_queue *q);
void (*wait_finish)(struct vb2_queue *q);
int (*buf_out_validate)(struct vb2_buffer *vb);
int (*buf_init)(struct vb2_buffer *vb);
int (*buf_prepare)(struct vb2_buffer *vb);
void (*buf_finish)(struct vb2_buffer *vb);
void (*buf_cleanup)(struct vb2_buffer *vb);
int (*start_streaming)(struct vb2_queue *q, unsigned int count);
void (*stop_streaming)(struct vb2_queue *q);
void (*buf_queue)(struct vb2_buffer *vb);
void (*buf_request_complete)(struct vb2_buffer *vb);
};
/**
* struct vb2_buf_ops - driver-specific callbacks.
*
* @verify_planes_array: Verify that a given user space structure contains
* enough planes for the buffer. This is called
* for each dequeued buffer.
* @init_buffer: given a &vb2_buffer initialize the extra data after
* struct vb2_buffer.
* For V4L2 this is a &struct vb2_v4l2_buffer.
* @fill_user_buffer: given a &vb2_buffer fill in the userspace structure.
* For V4L2 this is a &struct v4l2_buffer.
* @fill_vb2_buffer: given a userspace structure, fill in the &vb2_buffer.
* If the userspace structure is invalid, then this op
* will return an error.
* @copy_timestamp: copy the timestamp from a userspace structure to
* the &struct vb2_buffer.
*/
struct vb2_buf_ops {
int (*verify_planes_array)(struct vb2_buffer *vb, const void *pb);
void (*init_buffer)(struct vb2_buffer *vb);
void (*fill_user_buffer)(struct vb2_buffer *vb, void *pb);
int (*fill_vb2_buffer)(struct vb2_buffer *vb, struct vb2_plane *planes);
void (*copy_timestamp)(struct vb2_buffer *vb, const void *pb);
};
/**
* struct vb2_queue - a videobuf queue.
*
* @type: private buffer type whose content is defined by the vb2-core
* caller. For example, for V4L2, it should match
* the types defined on &enum v4l2_buf_type.
* @io_modes: supported io methods (see &enum vb2_io_modes).
* @alloc_devs: &struct device memory type/allocator-specific per-plane device
* @dev: device to use for the default allocation context if the driver
* doesn't fill in the @alloc_devs array.
dma-mapping: use unsigned long for dma_attrs The dma-mapping core and the implementations do not change the DMA attributes passed by pointer. Thus the pointer can point to const data. However the attributes do not have to be a bitfield. Instead unsigned long will do fine: 1. This is just simpler. Both in terms of reading the code and setting attributes. Instead of initializing local attributes on the stack and passing pointer to it to dma_set_attr(), just set the bits. 2. It brings safeness and checking for const correctness because the attributes are passed by value. Semantic patches for this change (at least most of them): virtual patch virtual context @r@ identifier f, attrs; @@ f(..., - struct dma_attrs *attrs + unsigned long attrs , ...) { ... } @@ identifier r.f; @@ f(..., - NULL + 0 ) and // Options: --all-includes virtual patch virtual context @r@ identifier f, attrs; type t; @@ t f(..., struct dma_attrs *attrs); @@ identifier r.f; @@ f(..., - NULL + 0 ) Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.com Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Acked-by: Vineet Gupta <vgupta@synopsys.com> Acked-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> Acked-by: Mark Salter <msalter@redhat.com> [c6x] Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> [cris] Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [drm] Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com> Acked-by: Joerg Roedel <jroedel@suse.de> [iommu] Acked-by: Fabien Dessenne <fabien.dessenne@st.com> [bdisp] Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> [vb2-core] Acked-by: David Vrabel <david.vrabel@citrix.com> [xen] Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [xen swiotlb] Acked-by: Joerg Roedel <jroedel@suse.de> [iommu] Acked-by: Richard Kuo <rkuo@codeaurora.org> [hexagon] Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [m68k] Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> [s390] Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> [avr32] Acked-by: Vineet Gupta <vgupta@synopsys.com> [arc] Acked-by: Robin Murphy <robin.murphy@arm.com> [arm64 and dma-iommu] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-08-04 04:46:00 +08:00
* @dma_attrs: DMA attributes to use for the DMA.
* @bidirectional: when this flag is set the DMA direction for the buffers of
* this queue will be overridden with %DMA_BIDIRECTIONAL direction.
* This is useful in cases where the hardware (firmware) writes to
* a buffer which is mapped as read (%DMA_TO_DEVICE), or reads from
* buffer which is mapped for write (%DMA_FROM_DEVICE) in order
* to satisfy some internal hardware restrictions or adds a padding
* needed by the processing algorithm. In case the DMA mapping is
* not bidirectional but the hardware (firmware) trying to access
* the buffer (in the opposite direction) this could lead to an
* IOMMU protection faults.
* @fileio_read_once: report EOF after reading the first buffer
* @fileio_write_immediately: queue buffer after each write() call
* @allow_zero_bytesused: allow bytesused == 0 to be passed to the driver
* @quirk_poll_must_check_waiting_for_buffers: Return %EPOLLERR at poll when QBUF
* has not been called. This is a vb1 idiom that has been adopted
* also by vb2.
* @supports_requests: this queue supports the Request API.
* @requires_requests: this queue requires the Request API. If this is set to 1,
* then supports_requests must be set to 1 as well.
* @uses_qbuf: qbuf was used directly for this queue. Set to 1 the first
* time this is called. Set to 0 when the queue is canceled.
* If this is 1, then you cannot queue buffers from a request.
* @uses_requests: requests are used for this queue. Set to 1 the first time
* a request is queued. Set to 0 when the queue is canceled.
* If this is 1, then you cannot queue buffers directly.
* @lock: pointer to a mutex that protects the &struct vb2_queue. The
* driver can set this to a mutex to let the v4l2 core serialize
* the queuing ioctls. If the driver wants to handle locking
* itself, then this should be set to NULL. This lock is not used
* by the videobuf2 core API.
* @owner: The filehandle that 'owns' the buffers, i.e. the filehandle
* that called reqbufs, create_buffers or started fileio.
* This field is not used by the videobuf2 core API, but it allows
* drivers to easily associate an owner filehandle with the queue.
* @ops: driver-specific callbacks
* @mem_ops: memory allocator specific callbacks
* @buf_ops: callbacks to deliver buffer information.
* between user-space and kernel-space.
* @drv_priv: driver private data.
* @subsystem_flags: Flags specific to the subsystem (V4L2/DVB/etc.). Not used
* by the vb2 core.
* @buf_struct_size: size of the driver-specific buffer structure;
* "0" indicates the driver doesn't want to use a custom buffer
* structure type. for example, ``sizeof(struct vb2_v4l2_buffer)``
* will be used for v4l2.
* @timestamp_flags: Timestamp flags; ``V4L2_BUF_FLAG_TIMESTAMP_*`` and
* ``V4L2_BUF_FLAG_TSTAMP_SRC_*``
* @gfp_flags: additional gfp flags used when allocating the buffers.
* Typically this is 0, but it may be e.g. %GFP_DMA or %__GFP_DMA32
* to force the buffer allocation to a specific memory zone.
[media] vb2: only call start_streaming if sufficient buffers are queued In commit 02f142ecd24aaf891324ffba8527284c1731b561 support was added to start_streaming to return -ENOBUFS if insufficient buffers were queued for the DMA engine to start. The vb2 core would attempt calling start_streaming again if another buffer would be queued up. Later analysis uncovered problems with the queue management if start_streaming would return an error: the buffers are enqueued to the driver before the start_streaming op is called, so after an error they are never returned to the vb2 core. The solution for this is to let the driver return them to the vb2 core in case of an error while starting the DMA engine. However, in the case of -ENOBUFS that would be weird: it is not a real error, it just says that more buffers are needed. Requiring start_streaming to give them back only to have them requeued again the next time the application calls QBUF is inefficient. This patch changes this mechanism: it adds a 'min_buffers_needed' field to vb2_queue that drivers can set with the minimum number of buffers required to start the DMA engine. The start_streaming op is only called if enough buffers are queued. The -ENOBUFS handling has been dropped in favor of this new method. Drivers are expected to return buffers back to vb2 core with state QUEUED if start_streaming would return an error. The vb2 core checks for this and produces a warning if that didn't happen and it will forcefully reclaim such buffers to ensure that the internal vb2 core state remains consistent and all buffer-related resources have been correctly freed and all op calls have been balanced. __reqbufs() has been updated to check that at least min_buffers_needed buffers could be allocated. If fewer buffers were allocated then __reqbufs will free what was allocated and return -ENOMEM. Based on a suggestion from Pawel Osciak. __create_bufs() doesn't do that check, since the use of __create_bufs assumes some advance scenario where the user might want more control. Instead streamon will check if enough buffers were allocated to prevent streaming with fewer than the minimum required number of buffers. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-02-25 00:51:03 +08:00
* @min_buffers_needed: the minimum number of buffers needed before
* @start_streaming can be called. Used when a DMA engine
[media] vb2: only call start_streaming if sufficient buffers are queued In commit 02f142ecd24aaf891324ffba8527284c1731b561 support was added to start_streaming to return -ENOBUFS if insufficient buffers were queued for the DMA engine to start. The vb2 core would attempt calling start_streaming again if another buffer would be queued up. Later analysis uncovered problems with the queue management if start_streaming would return an error: the buffers are enqueued to the driver before the start_streaming op is called, so after an error they are never returned to the vb2 core. The solution for this is to let the driver return them to the vb2 core in case of an error while starting the DMA engine. However, in the case of -ENOBUFS that would be weird: it is not a real error, it just says that more buffers are needed. Requiring start_streaming to give them back only to have them requeued again the next time the application calls QBUF is inefficient. This patch changes this mechanism: it adds a 'min_buffers_needed' field to vb2_queue that drivers can set with the minimum number of buffers required to start the DMA engine. The start_streaming op is only called if enough buffers are queued. The -ENOBUFS handling has been dropped in favor of this new method. Drivers are expected to return buffers back to vb2 core with state QUEUED if start_streaming would return an error. The vb2 core checks for this and produces a warning if that didn't happen and it will forcefully reclaim such buffers to ensure that the internal vb2 core state remains consistent and all buffer-related resources have been correctly freed and all op calls have been balanced. __reqbufs() has been updated to check that at least min_buffers_needed buffers could be allocated. If fewer buffers were allocated then __reqbufs will free what was allocated and return -ENOMEM. Based on a suggestion from Pawel Osciak. __create_bufs() doesn't do that check, since the use of __create_bufs assumes some advance scenario where the user might want more control. Instead streamon will check if enough buffers were allocated to prevent streaming with fewer than the minimum required number of buffers. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-02-25 00:51:03 +08:00
* cannot be started unless at least this number of buffers
* have been queued into the driver.
*/
/*
* Private elements (won't appear at the uAPI book):
[media] videobuf2: fix lockdep warning The following lockdep warning has been there ever since commit a517cca6b24fc54ac209e44118ec8962051662e3 one year ago: [ 403.117947] ====================================================== [ 403.117949] [ INFO: possible circular locking dependency detected ] [ 403.117953] 3.16.0-rc6-test-media #961 Not tainted [ 403.117954] ------------------------------------------------------- [ 403.117956] v4l2-ctl/15377 is trying to acquire lock: [ 403.117959] (&dev->mutex#3){+.+.+.}, at: [<ffffffffa005a6c3>] vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.117974] [ 403.117974] but task is already holding lock: [ 403.117976] (&mm->mmap_sem){++++++}, at: [<ffffffff8118291f>] vm_mmap_pgoff+0x6f/0xc0 [ 403.117987] [ 403.117987] which lock already depends on the new lock. [ 403.117987] [ 403.117990] [ 403.117990] the existing dependency chain (in reverse order) is: [ 403.117992] [ 403.117992] -> #1 (&mm->mmap_sem){++++++}: [ 403.117997] [<ffffffff810d733c>] validate_chain.isra.39+0x5fc/0x9a0 [ 403.118006] [<ffffffff810d8bc3>] __lock_acquire+0x4d3/0xd30 [ 403.118010] [<ffffffff810d9da7>] lock_acquire+0xa7/0x160 [ 403.118014] [<ffffffff8118c9ec>] might_fault+0x7c/0xb0 [ 403.118018] [<ffffffffa0028a25>] video_usercopy+0x425/0x610 [videodev] [ 403.118028] [<ffffffffa0028c25>] video_ioctl2+0x15/0x20 [videodev] [ 403.118034] [<ffffffffa0022764>] v4l2_ioctl+0x184/0x1a0 [videodev] [ 403.118040] [<ffffffff811d77d0>] do_vfs_ioctl+0x2f0/0x4f0 [ 403.118307] [<ffffffff811d7a51>] SyS_ioctl+0x81/0xa0 [ 403.118311] [<ffffffff8199dc69>] system_call_fastpath+0x16/0x1b [ 403.118319] [ 403.118319] -> #0 (&dev->mutex#3){+.+.+.}: [ 403.118324] [<ffffffff810d6a96>] check_prevs_add+0x746/0x9f0 [ 403.118329] [<ffffffff810d733c>] validate_chain.isra.39+0x5fc/0x9a0 [ 403.118333] [<ffffffff810d8bc3>] __lock_acquire+0x4d3/0xd30 [ 403.118336] [<ffffffff810d9da7>] lock_acquire+0xa7/0x160 [ 403.118340] [<ffffffff81999664>] mutex_lock_interruptible_nested+0x64/0x640 [ 403.118344] [<ffffffffa005a6c3>] vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118349] [<ffffffffa0022122>] v4l2_mmap+0x62/0xa0 [videodev] [ 403.118354] [<ffffffff81197270>] mmap_region+0x3d0/0x5d0 [ 403.118359] [<ffffffff8119778d>] do_mmap_pgoff+0x31d/0x400 [ 403.118363] [<ffffffff81182940>] vm_mmap_pgoff+0x90/0xc0 [ 403.118366] [<ffffffff81195cef>] SyS_mmap_pgoff+0x1df/0x2a0 [ 403.118369] [<ffffffff810085c2>] SyS_mmap+0x22/0x30 [ 403.118376] [<ffffffff8199dc69>] system_call_fastpath+0x16/0x1b [ 403.118381] [ 403.118381] other info that might help us debug this: [ 403.118381] [ 403.118383] Possible unsafe locking scenario: [ 403.118383] [ 403.118385] CPU0 CPU1 [ 403.118387] ---- ---- [ 403.118388] lock(&mm->mmap_sem); [ 403.118391] lock(&dev->mutex#3); [ 403.118394] lock(&mm->mmap_sem); [ 403.118397] lock(&dev->mutex#3); [ 403.118400] [ 403.118400] *** DEADLOCK *** [ 403.118400] [ 403.118403] 1 lock held by v4l2-ctl/15377: [ 403.118405] #0: (&mm->mmap_sem){++++++}, at: [<ffffffff8118291f>] vm_mmap_pgoff+0x6f/0xc0 [ 403.118411] [ 403.118411] stack backtrace: [ 403.118415] CPU: 0 PID: 15377 Comm: v4l2-ctl Not tainted 3.16.0-rc6-test-media #961 [ 403.118418] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013 [ 403.118420] ffffffff82a6c9d0 ffff8800af37fb00 ffffffff819916a2 ffffffff82a6c9d0 [ 403.118425] ffff8800af37fb40 ffffffff810d5715 ffff8802308e4200 0000000000000000 [ 403.118429] ffff8802308e4a48 ffff8802308e4a48 ffff8802308e4200 0000000000000001 [ 403.118433] Call Trace: [ 403.118441] [<ffffffff819916a2>] dump_stack+0x4e/0x7a [ 403.118445] [<ffffffff810d5715>] print_circular_bug+0x1d5/0x2a0 [ 403.118449] [<ffffffff810d6a96>] check_prevs_add+0x746/0x9f0 [ 403.118455] [<ffffffff8119c172>] ? find_vmap_area+0x42/0x70 [ 403.118459] [<ffffffff810d733c>] validate_chain.isra.39+0x5fc/0x9a0 [ 403.118463] [<ffffffff810d8bc3>] __lock_acquire+0x4d3/0xd30 [ 403.118468] [<ffffffff810d9da7>] lock_acquire+0xa7/0x160 [ 403.118472] [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118476] [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118480] [<ffffffff81999664>] mutex_lock_interruptible_nested+0x64/0x640 [ 403.118484] [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118488] [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118493] [<ffffffff810d8055>] ? mark_held_locks+0x75/0xa0 [ 403.118497] [<ffffffffa005a6c3>] vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118502] [<ffffffffa0022122>] v4l2_mmap+0x62/0xa0 [videodev] [ 403.118506] [<ffffffff81197270>] mmap_region+0x3d0/0x5d0 [ 403.118510] [<ffffffff8119778d>] do_mmap_pgoff+0x31d/0x400 [ 403.118513] [<ffffffff81182940>] vm_mmap_pgoff+0x90/0xc0 [ 403.118517] [<ffffffff81195cef>] SyS_mmap_pgoff+0x1df/0x2a0 [ 403.118521] [<ffffffff810085c2>] SyS_mmap+0x22/0x30 [ 403.118525] [<ffffffff8199dc69>] system_call_fastpath+0x16/0x1b The reason is that vb2_fop_mmap and vb2_fop_get_unmapped_area take the core lock while they are called with the mmap_sem semaphore held. But elsewhere in the code the core lock is taken first but calls to copy_to/from_user() can take the mmap_sem semaphore as well, potentially causing a classical A-B/B-A deadlock. However, the mmap/get_unmapped_area calls really shouldn't take the core lock at all. So what would happen if they don't take the core lock anymore? There are two situations that need to be taken into account: calling mmap while new buffers are being added and calling mmap while buffers are being deleted. The first case works almost fine without a lock: in all cases mmap relies on correctly filled-in q->num_buffers/q->num_planes values and those are only updated by reqbufs and create_buffers *after* any new buffers have been initialized completely. Except in one case: if an error occurred while allocating the buffers it will increase num_buffers and rely on __vb2_queue_free to decrease it again. So there is a short period where the buffer information may be wrong. The second case definitely does pose a problem: buffers may be in the process of being deleted, without the internal structure being updated. In order to fix this a new mutex is added to vb2_queue that is taken when buffers are allocated or deleted, and in vb2_mmap. That way vb2_mmap won't get stale buffer data. Note that this is a problem only for MEMORY_MMAP, so even though __qbuf_userptr and __qbuf_dmabuf also mess around with buffers (mem_priv in particular), this doesn't clash with vb2_mmap or vb2_get_unmapped_area since those are MMAP specific. As an additional bonus the hack in __buf_prepare, the USERPTR case, can be removed as well since mmap() no longer takes the core lock. All in all a much cleaner solution. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-08-07 14:47:14 +08:00
* @mmap_lock: private mutex used when buffers are allocated/freed/mmapped
* @memory: current memory type used
* @dma_dir: DMA mapping direction.
* @bufs: videobuf buffer structures
* @num_buffers: number of allocated/used buffers
* @queued_list: list of buffers currently queued from userspace
[media] vb2: only call start_streaming if sufficient buffers are queued In commit 02f142ecd24aaf891324ffba8527284c1731b561 support was added to start_streaming to return -ENOBUFS if insufficient buffers were queued for the DMA engine to start. The vb2 core would attempt calling start_streaming again if another buffer would be queued up. Later analysis uncovered problems with the queue management if start_streaming would return an error: the buffers are enqueued to the driver before the start_streaming op is called, so after an error they are never returned to the vb2 core. The solution for this is to let the driver return them to the vb2 core in case of an error while starting the DMA engine. However, in the case of -ENOBUFS that would be weird: it is not a real error, it just says that more buffers are needed. Requiring start_streaming to give them back only to have them requeued again the next time the application calls QBUF is inefficient. This patch changes this mechanism: it adds a 'min_buffers_needed' field to vb2_queue that drivers can set with the minimum number of buffers required to start the DMA engine. The start_streaming op is only called if enough buffers are queued. The -ENOBUFS handling has been dropped in favor of this new method. Drivers are expected to return buffers back to vb2 core with state QUEUED if start_streaming would return an error. The vb2 core checks for this and produces a warning if that didn't happen and it will forcefully reclaim such buffers to ensure that the internal vb2 core state remains consistent and all buffer-related resources have been correctly freed and all op calls have been balanced. __reqbufs() has been updated to check that at least min_buffers_needed buffers could be allocated. If fewer buffers were allocated then __reqbufs will free what was allocated and return -ENOMEM. Based on a suggestion from Pawel Osciak. __create_bufs() doesn't do that check, since the use of __create_bufs assumes some advance scenario where the user might want more control. Instead streamon will check if enough buffers were allocated to prevent streaming with fewer than the minimum required number of buffers. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-02-25 00:51:03 +08:00
* @queued_count: number of buffers queued and ready for streaming.
* @owned_by_drv_count: number of buffers owned by the driver
* @done_list: list of buffers ready to be dequeued to userspace
* @done_lock: lock to protect done_list list
* @done_wq: waitqueue for processes waiting for buffers ready to be dequeued
* @streaming: current streaming state
* @start_streaming_called: @start_streaming was called successfully and we
[media] vb2: only call start_streaming if sufficient buffers are queued In commit 02f142ecd24aaf891324ffba8527284c1731b561 support was added to start_streaming to return -ENOBUFS if insufficient buffers were queued for the DMA engine to start. The vb2 core would attempt calling start_streaming again if another buffer would be queued up. Later analysis uncovered problems with the queue management if start_streaming would return an error: the buffers are enqueued to the driver before the start_streaming op is called, so after an error they are never returned to the vb2 core. The solution for this is to let the driver return them to the vb2 core in case of an error while starting the DMA engine. However, in the case of -ENOBUFS that would be weird: it is not a real error, it just says that more buffers are needed. Requiring start_streaming to give them back only to have them requeued again the next time the application calls QBUF is inefficient. This patch changes this mechanism: it adds a 'min_buffers_needed' field to vb2_queue that drivers can set with the minimum number of buffers required to start the DMA engine. The start_streaming op is only called if enough buffers are queued. The -ENOBUFS handling has been dropped in favor of this new method. Drivers are expected to return buffers back to vb2 core with state QUEUED if start_streaming would return an error. The vb2 core checks for this and produces a warning if that didn't happen and it will forcefully reclaim such buffers to ensure that the internal vb2 core state remains consistent and all buffer-related resources have been correctly freed and all op calls have been balanced. __reqbufs() has been updated to check that at least min_buffers_needed buffers could be allocated. If fewer buffers were allocated then __reqbufs will free what was allocated and return -ENOMEM. Based on a suggestion from Pawel Osciak. __create_bufs() doesn't do that check, since the use of __create_bufs assumes some advance scenario where the user might want more control. Instead streamon will check if enough buffers were allocated to prevent streaming with fewer than the minimum required number of buffers. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-02-25 00:51:03 +08:00
* started streaming.
* @error: a fatal error occurred on the queue
* @waiting_for_buffers: used in poll() to check if vb2 is still waiting for
* buffers. Only set for capture queues if qbuf has not yet been
* called since poll() needs to return %EPOLLERR in that situation.
* @is_multiplanar: set if buffer type is multiplanar
* @is_output: set if buffer type is output
* @copy_timestamp: set if vb2-core should set timestamps
* @last_buffer_dequeued: used in poll() and DQBUF to immediately return if the
* last decoded buffer was already dequeued. Set for capture queues
* when a buffer with the %V4L2_BUF_FLAG_LAST is dequeued.
* @fileio: file io emulator internal data, used only if emulator is active
* @threadio: thread io internal data, used only if thread is active
*/
struct vb2_queue {
unsigned int type;
unsigned int io_modes;
struct device *dev;
dma-mapping: use unsigned long for dma_attrs The dma-mapping core and the implementations do not change the DMA attributes passed by pointer. Thus the pointer can point to const data. However the attributes do not have to be a bitfield. Instead unsigned long will do fine: 1. This is just simpler. Both in terms of reading the code and setting attributes. Instead of initializing local attributes on the stack and passing pointer to it to dma_set_attr(), just set the bits. 2. It brings safeness and checking for const correctness because the attributes are passed by value. Semantic patches for this change (at least most of them): virtual patch virtual context @r@ identifier f, attrs; @@ f(..., - struct dma_attrs *attrs + unsigned long attrs , ...) { ... } @@ identifier r.f; @@ f(..., - NULL + 0 ) and // Options: --all-includes virtual patch virtual context @r@ identifier f, attrs; type t; @@ t f(..., struct dma_attrs *attrs); @@ identifier r.f; @@ f(..., - NULL + 0 ) Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.com Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Acked-by: Vineet Gupta <vgupta@synopsys.com> Acked-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> Acked-by: Mark Salter <msalter@redhat.com> [c6x] Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> [cris] Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [drm] Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com> Acked-by: Joerg Roedel <jroedel@suse.de> [iommu] Acked-by: Fabien Dessenne <fabien.dessenne@st.com> [bdisp] Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> [vb2-core] Acked-by: David Vrabel <david.vrabel@citrix.com> [xen] Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [xen swiotlb] Acked-by: Joerg Roedel <jroedel@suse.de> [iommu] Acked-by: Richard Kuo <rkuo@codeaurora.org> [hexagon] Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [m68k] Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> [s390] Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> [avr32] Acked-by: Vineet Gupta <vgupta@synopsys.com> [arc] Acked-by: Robin Murphy <robin.murphy@arm.com> [arm64 and dma-iommu] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-08-04 04:46:00 +08:00
unsigned long dma_attrs;
unsigned bidirectional:1;
unsigned fileio_read_once:1;
unsigned fileio_write_immediately:1;
unsigned allow_zero_bytesused:1;
unsigned quirk_poll_must_check_waiting_for_buffers:1;
unsigned supports_requests:1;
unsigned requires_requests:1;
unsigned uses_qbuf:1;
unsigned uses_requests:1;
struct mutex *lock;
void *owner;
const struct vb2_ops *ops;
const struct vb2_mem_ops *mem_ops;
const struct vb2_buf_ops *buf_ops;
void *drv_priv;
u32 subsystem_flags;
unsigned int buf_struct_size;
u32 timestamp_flags;
gfp_t gfp_flags;
[media] vb2: only call start_streaming if sufficient buffers are queued In commit 02f142ecd24aaf891324ffba8527284c1731b561 support was added to start_streaming to return -ENOBUFS if insufficient buffers were queued for the DMA engine to start. The vb2 core would attempt calling start_streaming again if another buffer would be queued up. Later analysis uncovered problems with the queue management if start_streaming would return an error: the buffers are enqueued to the driver before the start_streaming op is called, so after an error they are never returned to the vb2 core. The solution for this is to let the driver return them to the vb2 core in case of an error while starting the DMA engine. However, in the case of -ENOBUFS that would be weird: it is not a real error, it just says that more buffers are needed. Requiring start_streaming to give them back only to have them requeued again the next time the application calls QBUF is inefficient. This patch changes this mechanism: it adds a 'min_buffers_needed' field to vb2_queue that drivers can set with the minimum number of buffers required to start the DMA engine. The start_streaming op is only called if enough buffers are queued. The -ENOBUFS handling has been dropped in favor of this new method. Drivers are expected to return buffers back to vb2 core with state QUEUED if start_streaming would return an error. The vb2 core checks for this and produces a warning if that didn't happen and it will forcefully reclaim such buffers to ensure that the internal vb2 core state remains consistent and all buffer-related resources have been correctly freed and all op calls have been balanced. __reqbufs() has been updated to check that at least min_buffers_needed buffers could be allocated. If fewer buffers were allocated then __reqbufs will free what was allocated and return -ENOMEM. Based on a suggestion from Pawel Osciak. __create_bufs() doesn't do that check, since the use of __create_bufs assumes some advance scenario where the user might want more control. Instead streamon will check if enough buffers were allocated to prevent streaming with fewer than the minimum required number of buffers. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-02-25 00:51:03 +08:00
u32 min_buffers_needed;
struct device *alloc_devs[VB2_MAX_PLANES];
/* private: internal use only */
[media] videobuf2: fix lockdep warning The following lockdep warning has been there ever since commit a517cca6b24fc54ac209e44118ec8962051662e3 one year ago: [ 403.117947] ====================================================== [ 403.117949] [ INFO: possible circular locking dependency detected ] [ 403.117953] 3.16.0-rc6-test-media #961 Not tainted [ 403.117954] ------------------------------------------------------- [ 403.117956] v4l2-ctl/15377 is trying to acquire lock: [ 403.117959] (&dev->mutex#3){+.+.+.}, at: [<ffffffffa005a6c3>] vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.117974] [ 403.117974] but task is already holding lock: [ 403.117976] (&mm->mmap_sem){++++++}, at: [<ffffffff8118291f>] vm_mmap_pgoff+0x6f/0xc0 [ 403.117987] [ 403.117987] which lock already depends on the new lock. [ 403.117987] [ 403.117990] [ 403.117990] the existing dependency chain (in reverse order) is: [ 403.117992] [ 403.117992] -> #1 (&mm->mmap_sem){++++++}: [ 403.117997] [<ffffffff810d733c>] validate_chain.isra.39+0x5fc/0x9a0 [ 403.118006] [<ffffffff810d8bc3>] __lock_acquire+0x4d3/0xd30 [ 403.118010] [<ffffffff810d9da7>] lock_acquire+0xa7/0x160 [ 403.118014] [<ffffffff8118c9ec>] might_fault+0x7c/0xb0 [ 403.118018] [<ffffffffa0028a25>] video_usercopy+0x425/0x610 [videodev] [ 403.118028] [<ffffffffa0028c25>] video_ioctl2+0x15/0x20 [videodev] [ 403.118034] [<ffffffffa0022764>] v4l2_ioctl+0x184/0x1a0 [videodev] [ 403.118040] [<ffffffff811d77d0>] do_vfs_ioctl+0x2f0/0x4f0 [ 403.118307] [<ffffffff811d7a51>] SyS_ioctl+0x81/0xa0 [ 403.118311] [<ffffffff8199dc69>] system_call_fastpath+0x16/0x1b [ 403.118319] [ 403.118319] -> #0 (&dev->mutex#3){+.+.+.}: [ 403.118324] [<ffffffff810d6a96>] check_prevs_add+0x746/0x9f0 [ 403.118329] [<ffffffff810d733c>] validate_chain.isra.39+0x5fc/0x9a0 [ 403.118333] [<ffffffff810d8bc3>] __lock_acquire+0x4d3/0xd30 [ 403.118336] [<ffffffff810d9da7>] lock_acquire+0xa7/0x160 [ 403.118340] [<ffffffff81999664>] mutex_lock_interruptible_nested+0x64/0x640 [ 403.118344] [<ffffffffa005a6c3>] vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118349] [<ffffffffa0022122>] v4l2_mmap+0x62/0xa0 [videodev] [ 403.118354] [<ffffffff81197270>] mmap_region+0x3d0/0x5d0 [ 403.118359] [<ffffffff8119778d>] do_mmap_pgoff+0x31d/0x400 [ 403.118363] [<ffffffff81182940>] vm_mmap_pgoff+0x90/0xc0 [ 403.118366] [<ffffffff81195cef>] SyS_mmap_pgoff+0x1df/0x2a0 [ 403.118369] [<ffffffff810085c2>] SyS_mmap+0x22/0x30 [ 403.118376] [<ffffffff8199dc69>] system_call_fastpath+0x16/0x1b [ 403.118381] [ 403.118381] other info that might help us debug this: [ 403.118381] [ 403.118383] Possible unsafe locking scenario: [ 403.118383] [ 403.118385] CPU0 CPU1 [ 403.118387] ---- ---- [ 403.118388] lock(&mm->mmap_sem); [ 403.118391] lock(&dev->mutex#3); [ 403.118394] lock(&mm->mmap_sem); [ 403.118397] lock(&dev->mutex#3); [ 403.118400] [ 403.118400] *** DEADLOCK *** [ 403.118400] [ 403.118403] 1 lock held by v4l2-ctl/15377: [ 403.118405] #0: (&mm->mmap_sem){++++++}, at: [<ffffffff8118291f>] vm_mmap_pgoff+0x6f/0xc0 [ 403.118411] [ 403.118411] stack backtrace: [ 403.118415] CPU: 0 PID: 15377 Comm: v4l2-ctl Not tainted 3.16.0-rc6-test-media #961 [ 403.118418] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013 [ 403.118420] ffffffff82a6c9d0 ffff8800af37fb00 ffffffff819916a2 ffffffff82a6c9d0 [ 403.118425] ffff8800af37fb40 ffffffff810d5715 ffff8802308e4200 0000000000000000 [ 403.118429] ffff8802308e4a48 ffff8802308e4a48 ffff8802308e4200 0000000000000001 [ 403.118433] Call Trace: [ 403.118441] [<ffffffff819916a2>] dump_stack+0x4e/0x7a [ 403.118445] [<ffffffff810d5715>] print_circular_bug+0x1d5/0x2a0 [ 403.118449] [<ffffffff810d6a96>] check_prevs_add+0x746/0x9f0 [ 403.118455] [<ffffffff8119c172>] ? find_vmap_area+0x42/0x70 [ 403.118459] [<ffffffff810d733c>] validate_chain.isra.39+0x5fc/0x9a0 [ 403.118463] [<ffffffff810d8bc3>] __lock_acquire+0x4d3/0xd30 [ 403.118468] [<ffffffff810d9da7>] lock_acquire+0xa7/0x160 [ 403.118472] [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118476] [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118480] [<ffffffff81999664>] mutex_lock_interruptible_nested+0x64/0x640 [ 403.118484] [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118488] [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118493] [<ffffffff810d8055>] ? mark_held_locks+0x75/0xa0 [ 403.118497] [<ffffffffa005a6c3>] vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118502] [<ffffffffa0022122>] v4l2_mmap+0x62/0xa0 [videodev] [ 403.118506] [<ffffffff81197270>] mmap_region+0x3d0/0x5d0 [ 403.118510] [<ffffffff8119778d>] do_mmap_pgoff+0x31d/0x400 [ 403.118513] [<ffffffff81182940>] vm_mmap_pgoff+0x90/0xc0 [ 403.118517] [<ffffffff81195cef>] SyS_mmap_pgoff+0x1df/0x2a0 [ 403.118521] [<ffffffff810085c2>] SyS_mmap+0x22/0x30 [ 403.118525] [<ffffffff8199dc69>] system_call_fastpath+0x16/0x1b The reason is that vb2_fop_mmap and vb2_fop_get_unmapped_area take the core lock while they are called with the mmap_sem semaphore held. But elsewhere in the code the core lock is taken first but calls to copy_to/from_user() can take the mmap_sem semaphore as well, potentially causing a classical A-B/B-A deadlock. However, the mmap/get_unmapped_area calls really shouldn't take the core lock at all. So what would happen if they don't take the core lock anymore? There are two situations that need to be taken into account: calling mmap while new buffers are being added and calling mmap while buffers are being deleted. The first case works almost fine without a lock: in all cases mmap relies on correctly filled-in q->num_buffers/q->num_planes values and those are only updated by reqbufs and create_buffers *after* any new buffers have been initialized completely. Except in one case: if an error occurred while allocating the buffers it will increase num_buffers and rely on __vb2_queue_free to decrease it again. So there is a short period where the buffer information may be wrong. The second case definitely does pose a problem: buffers may be in the process of being deleted, without the internal structure being updated. In order to fix this a new mutex is added to vb2_queue that is taken when buffers are allocated or deleted, and in vb2_mmap. That way vb2_mmap won't get stale buffer data. Note that this is a problem only for MEMORY_MMAP, so even though __qbuf_userptr and __qbuf_dmabuf also mess around with buffers (mem_priv in particular), this doesn't clash with vb2_mmap or vb2_get_unmapped_area since those are MMAP specific. As an additional bonus the hack in __buf_prepare, the USERPTR case, can be removed as well since mmap() no longer takes the core lock. All in all a much cleaner solution. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-08-07 14:47:14 +08:00
struct mutex mmap_lock;
unsigned int memory;
enum dma_data_direction dma_dir;
struct vb2_buffer *bufs[VB2_MAX_FRAME];
unsigned int num_buffers;
struct list_head queued_list;
[media] vb2: only call start_streaming if sufficient buffers are queued In commit 02f142ecd24aaf891324ffba8527284c1731b561 support was added to start_streaming to return -ENOBUFS if insufficient buffers were queued for the DMA engine to start. The vb2 core would attempt calling start_streaming again if another buffer would be queued up. Later analysis uncovered problems with the queue management if start_streaming would return an error: the buffers are enqueued to the driver before the start_streaming op is called, so after an error they are never returned to the vb2 core. The solution for this is to let the driver return them to the vb2 core in case of an error while starting the DMA engine. However, in the case of -ENOBUFS that would be weird: it is not a real error, it just says that more buffers are needed. Requiring start_streaming to give them back only to have them requeued again the next time the application calls QBUF is inefficient. This patch changes this mechanism: it adds a 'min_buffers_needed' field to vb2_queue that drivers can set with the minimum number of buffers required to start the DMA engine. The start_streaming op is only called if enough buffers are queued. The -ENOBUFS handling has been dropped in favor of this new method. Drivers are expected to return buffers back to vb2 core with state QUEUED if start_streaming would return an error. The vb2 core checks for this and produces a warning if that didn't happen and it will forcefully reclaim such buffers to ensure that the internal vb2 core state remains consistent and all buffer-related resources have been correctly freed and all op calls have been balanced. __reqbufs() has been updated to check that at least min_buffers_needed buffers could be allocated. If fewer buffers were allocated then __reqbufs will free what was allocated and return -ENOMEM. Based on a suggestion from Pawel Osciak. __create_bufs() doesn't do that check, since the use of __create_bufs assumes some advance scenario where the user might want more control. Instead streamon will check if enough buffers were allocated to prevent streaming with fewer than the minimum required number of buffers. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-02-25 00:51:03 +08:00
unsigned int queued_count;
atomic_t owned_by_drv_count;
struct list_head done_list;
spinlock_t done_lock;
wait_queue_head_t done_wq;
unsigned int streaming:1;
[media] vb2: only call start_streaming if sufficient buffers are queued In commit 02f142ecd24aaf891324ffba8527284c1731b561 support was added to start_streaming to return -ENOBUFS if insufficient buffers were queued for the DMA engine to start. The vb2 core would attempt calling start_streaming again if another buffer would be queued up. Later analysis uncovered problems with the queue management if start_streaming would return an error: the buffers are enqueued to the driver before the start_streaming op is called, so after an error they are never returned to the vb2 core. The solution for this is to let the driver return them to the vb2 core in case of an error while starting the DMA engine. However, in the case of -ENOBUFS that would be weird: it is not a real error, it just says that more buffers are needed. Requiring start_streaming to give them back only to have them requeued again the next time the application calls QBUF is inefficient. This patch changes this mechanism: it adds a 'min_buffers_needed' field to vb2_queue that drivers can set with the minimum number of buffers required to start the DMA engine. The start_streaming op is only called if enough buffers are queued. The -ENOBUFS handling has been dropped in favor of this new method. Drivers are expected to return buffers back to vb2 core with state QUEUED if start_streaming would return an error. The vb2 core checks for this and produces a warning if that didn't happen and it will forcefully reclaim such buffers to ensure that the internal vb2 core state remains consistent and all buffer-related resources have been correctly freed and all op calls have been balanced. __reqbufs() has been updated to check that at least min_buffers_needed buffers could be allocated. If fewer buffers were allocated then __reqbufs will free what was allocated and return -ENOMEM. Based on a suggestion from Pawel Osciak. __create_bufs() doesn't do that check, since the use of __create_bufs assumes some advance scenario where the user might want more control. Instead streamon will check if enough buffers were allocated to prevent streaming with fewer than the minimum required number of buffers. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-02-25 00:51:03 +08:00
unsigned int start_streaming_called:1;
unsigned int error:1;
unsigned int waiting_for_buffers:1;
unsigned int waiting_in_dqbuf:1;
unsigned int is_multiplanar:1;
unsigned int is_output:1;
unsigned int copy_timestamp:1;
unsigned int last_buffer_dequeued:1;
struct vb2_fileio_data *fileio;
struct vb2_threadio_data *threadio;
#ifdef CONFIG_VIDEO_ADV_DEBUG
/*
* Counters for how often these queue-related ops are
* called. Used to check for unbalanced ops.
*/
u32 cnt_queue_setup;
u32 cnt_wait_prepare;
u32 cnt_wait_finish;
u32 cnt_start_streaming;
u32 cnt_stop_streaming;
#endif
};
/**
* vb2_plane_vaddr() - Return a kernel virtual address of a given plane.
* @vb: pointer to &struct vb2_buffer to which the plane in
* question belongs to.
* @plane_no: plane number for which the address is to be returned.
*
* This function returns a kernel virtual address of a given plane if
* such a mapping exist, NULL otherwise.
*/
void *vb2_plane_vaddr(struct vb2_buffer *vb, unsigned int plane_no);
/**
* vb2_plane_cookie() - Return allocator specific cookie for the given plane.
* @vb: pointer to &struct vb2_buffer to which the plane in
* question belongs to.
* @plane_no: plane number for which the cookie is to be returned.
*
* This function returns an allocator specific cookie for a given plane if
* available, NULL otherwise. The allocator should provide some simple static
* inline function, which would convert this cookie to the allocator specific
* type that can be used directly by the driver to access the buffer. This can
* be for example physical address, pointer to scatter list or IOMMU mapping.
*/
void *vb2_plane_cookie(struct vb2_buffer *vb, unsigned int plane_no);
/**
* vb2_buffer_done() - inform videobuf that an operation on a buffer
* is finished.
* @vb: pointer to &struct vb2_buffer to be used.
* @state: state of the buffer, as defined by &enum vb2_buffer_state.
* Either %VB2_BUF_STATE_DONE if the operation finished
* successfully, %VB2_BUF_STATE_ERROR if the operation finished
* with an error or %VB2_BUF_STATE_QUEUED.
*
* This function should be called by the driver after a hardware operation on
* a buffer is finished and the buffer may be returned to userspace. The driver
* cannot use this buffer anymore until it is queued back to it by videobuf
* by the means of &vb2_ops->buf_queue callback. Only buffers previously queued
* to the driver by &vb2_ops->buf_queue can be passed to this function.
*
* While streaming a buffer can only be returned in state DONE or ERROR.
* The &vb2_ops->start_streaming op can also return them in case the DMA engine
* cannot be started for some reason. In that case the buffers should be
* returned with state QUEUED to put them back into the queue.
*/
void vb2_buffer_done(struct vb2_buffer *vb, enum vb2_buffer_state state);
/**
* vb2_discard_done() - discard all buffers marked as DONE.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
*
* This function is intended to be used with suspend/resume operations. It
* discards all 'done' buffers as they would be too old to be requested after
* resume.
*
* Drivers must stop the hardware and synchronize with interrupt handlers and/or
* delayed works before calling this function to make sure no buffer will be
* touched by the driver and/or hardware.
*/
void vb2_discard_done(struct vb2_queue *q);
/**
* vb2_wait_for_all_buffers() - wait until all buffers are given back to vb2.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
*
* This function will wait until all buffers that have been given to the driver
* by &vb2_ops->buf_queue are given back to vb2 with vb2_buffer_done(). It
* doesn't call &vb2_ops->wait_prepare/&vb2_ops->wait_finish pair.
* It is intended to be called with all locks taken, for example from
* &vb2_ops->stop_streaming callback.
*/
int vb2_wait_for_all_buffers(struct vb2_queue *q);
/**
* vb2_core_querybuf() - query video buffer information.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
* @index: id number of the buffer.
* @pb: buffer struct passed from userspace.
*
* Videobuf2 core helper to implement VIDIOC_QUERYBUF() operation. It is called
* internally by VB2 by an API-specific handler, like ``videobuf2-v4l2.h``.
*
* The passed buffer should have been verified.
*
* This function fills the relevant information for the userspace.
*
* Return: returns zero on success; an error code otherwise.
*/
void vb2_core_querybuf(struct vb2_queue *q, unsigned int index, void *pb);
/**
* vb2_core_reqbufs() - Initiate streaming.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
* @memory: memory type, as defined by &enum vb2_memory.
* @count: requested buffer count.
*
* Videobuf2 core helper to implement VIDIOC_REQBUF() operation. It is called
* internally by VB2 by an API-specific handler, like ``videobuf2-v4l2.h``.
*
* This function:
*
* #) verifies streaming parameters passed from the userspace;
* #) sets up the queue;
* #) negotiates number of buffers and planes per buffer with the driver
* to be used during streaming;
* #) allocates internal buffer structures (&struct vb2_buffer), according to
* the agreed parameters;
* #) for MMAP memory type, allocates actual video memory, using the
* memory handling/allocation routines provided during queue initialization.
*
* If req->count is 0, all the memory will be freed instead.
*
* If the queue has been allocated previously by a previous vb2_core_reqbufs()
* call and the queue is not busy, memory will be reallocated.
*
* Return: returns zero on success; an error code otherwise.
*/
int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
unsigned int *count);
/**
* vb2_core_create_bufs() - Allocate buffers and any required auxiliary structs
* @q: pointer to &struct vb2_queue with videobuf2 queue.
* @memory: memory type, as defined by &enum vb2_memory.
* @count: requested buffer count.
* @requested_planes: number of planes requested.
* @requested_sizes: array with the size of the planes.
*
* Videobuf2 core helper to implement VIDIOC_CREATE_BUFS() operation. It is
* called internally by VB2 by an API-specific handler, like
* ``videobuf2-v4l2.h``.
*
* This function:
*
* #) verifies parameter sanity;
* #) calls the &vb2_ops->queue_setup queue operation;
* #) performs any necessary memory allocations.
*
* Return: returns zero on success; an error code otherwise.
*/
int vb2_core_create_bufs(struct vb2_queue *q, enum vb2_memory memory,
unsigned int *count, unsigned int requested_planes,
const unsigned int requested_sizes[]);
/**
* vb2_core_prepare_buf() - Pass ownership of a buffer from userspace
* to the kernel.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
* @index: id number of the buffer.
* @pb: buffer structure passed from userspace to
* &v4l2_ioctl_ops->vidioc_prepare_buf handler in driver.
*
* Videobuf2 core helper to implement VIDIOC_PREPARE_BUF() operation. It is
* called internally by VB2 by an API-specific handler, like
* ``videobuf2-v4l2.h``.
*
* The passed buffer should have been verified.
*
* This function calls vb2_ops->buf_prepare callback in the driver
* (if provided), in which driver-specific buffer initialization can
* be performed.
*
* Return: returns zero on success; an error code otherwise.
*/
int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb);
/**
* vb2_core_qbuf() - Queue a buffer from userspace
*
* @q: pointer to &struct vb2_queue with videobuf2 queue.
* @index: id number of the buffer
* @pb: buffer structure passed from userspace to
* v4l2_ioctl_ops->vidioc_qbuf handler in driver
* @req: pointer to &struct media_request, may be NULL.
*
* Videobuf2 core helper to implement VIDIOC_QBUF() operation. It is called
* internally by VB2 by an API-specific handler, like ``videobuf2-v4l2.h``.
*
* This function:
*
* #) If @req is non-NULL, then the buffer will be bound to this
* media request and it returns. The buffer will be prepared and
* queued to the driver (i.e. the next two steps) when the request
* itself is queued.
* #) if necessary, calls &vb2_ops->buf_prepare callback in the driver
* (if provided), in which driver-specific buffer initialization can
* be performed;
* #) if streaming is on, queues the buffer in driver by the means of
* &vb2_ops->buf_queue callback for processing.
*
* Return: returns zero on success; an error code otherwise.
*/
int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb,
struct media_request *req);
/**
* vb2_core_dqbuf() - Dequeue a buffer to the userspace
* @q: pointer to &struct vb2_queue with videobuf2 queue
* @pindex: pointer to the buffer index. May be NULL
* @pb: buffer structure passed from userspace to
* v4l2_ioctl_ops->vidioc_dqbuf handler in driver.
* @nonblocking: if true, this call will not sleep waiting for a buffer if no
* buffers ready for dequeuing are present. Normally the driver
* would be passing (file->f_flags & O_NONBLOCK) here.
*
* Videobuf2 core helper to implement VIDIOC_DQBUF() operation. It is called
* internally by VB2 by an API-specific handler, like ``videobuf2-v4l2.h``.
*
* This function:
*
* #) calls buf_finish callback in the driver (if provided), in which
* driver can perform any additional operations that may be required before
* returning the buffer to userspace, such as cache sync,
* #) the buffer struct members are filled with relevant information for
* the userspace.
*
* Return: returns zero on success; an error code otherwise.
*/
[media] vb2: fix nasty vb2_thread regression The vb2_thread implementation was made generic and was moved from videobuf2-v4l2.c to videobuf2-core.c in commit af3bac1a. Unfortunately that clearly was never tested since it broke read() causing NULL address references. The root cause was confused handling of vb2_buffer vs v4l2_buffer (the pb pointer in various core functions). The v4l2_buffer no longer exists after moving the code into the core and it is no longer needed. However, the vb2_thread code passed a pointer to a vb2_buffer to the core functions were a v4l2_buffer pointer was expected and vb2_thread expected that the vb2_buffer fields would be filled in correctly. This is obviously wrong since v4l2_buffer != vb2_buffer. Note that the pb pointer is a void pointer, so no type-checking took place. This patch fixes this problem: 1) allow pb to be NULL for vb2_core_(d)qbuf. The vb2_thread code will use a NULL pointer here since they don't care about v4l2_buffer anyway. 2) let vb2_core_dqbuf pass back the index of the received buffer. This is all vb2_thread needs: this index is the index into the q->bufs array and vb2_thread just gets the vb2_buffer from there. 3) the fileio->b pointer (that originally contained a v4l2_buffer) is removed altogether since it is no longer needed. Tested with vivid and the cobalt driver. Cc: stable@vger.kernel.org # Kernel >= 4.3 Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reported-by: Matthias Schwarzott <zzam@gentoo.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2016-01-27 20:08:42 +08:00
int vb2_core_dqbuf(struct vb2_queue *q, unsigned int *pindex, void *pb,
bool nonblocking);
/**
* vb2_core_streamon() - Implements VB2 stream ON logic
*
* @q: pointer to &struct vb2_queue with videobuf2 queue
* @type: type of the queue to be started.
* For V4L2, this is defined by &enum v4l2_buf_type type.
*
* Videobuf2 core helper to implement VIDIOC_STREAMON() operation. It is called
* internally by VB2 by an API-specific handler, like ``videobuf2-v4l2.h``.
*
* Return: returns zero on success; an error code otherwise.
*/
int vb2_core_streamon(struct vb2_queue *q, unsigned int type);
/**
* vb2_core_streamoff() - Implements VB2 stream OFF logic
*
* @q: pointer to &struct vb2_queue with videobuf2 queue
* @type: type of the queue to be started.
* For V4L2, this is defined by &enum v4l2_buf_type type.
*
* Videobuf2 core helper to implement VIDIOC_STREAMOFF() operation. It is
* called internally by VB2 by an API-specific handler, like
* ``videobuf2-v4l2.h``.
*
* Return: returns zero on success; an error code otherwise.
*/
int vb2_core_streamoff(struct vb2_queue *q, unsigned int type);
/**
* vb2_core_expbuf() - Export a buffer as a file descriptor.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
* @fd: pointer to the file descriptor associated with DMABUF
* (set by driver).
* @type: buffer type.
* @index: id number of the buffer.
* @plane: index of the plane to be exported, 0 for single plane queues
* @flags: file flags for newly created file, as defined at
* include/uapi/asm-generic/fcntl.h.
* Currently, the only used flag is %O_CLOEXEC.
* is supported, refer to manual of open syscall for more details.
*
*
* Videobuf2 core helper to implement VIDIOC_EXPBUF() operation. It is called
* internally by VB2 by an API-specific handler, like ``videobuf2-v4l2.h``.
*
* Return: returns zero on success; an error code otherwise.
*/
int vb2_core_expbuf(struct vb2_queue *q, int *fd, unsigned int type,
unsigned int index, unsigned int plane, unsigned int flags);
/**
* vb2_core_queue_init() - initialize a videobuf2 queue
* @q: pointer to &struct vb2_queue with videobuf2 queue.
* This structure should be allocated in driver
*
* The &vb2_queue structure should be allocated by the driver. The driver is
* responsible of clearing it's content and setting initial values for some
* required entries before calling this function.
*
* .. note::
*
* The following fields at @q should be set before calling this function:
* &vb2_queue->ops, &vb2_queue->mem_ops, &vb2_queue->type.
*/
int vb2_core_queue_init(struct vb2_queue *q);
/**
* vb2_core_queue_release() - stop streaming, release the queue and free memory
* @q: pointer to &struct vb2_queue with videobuf2 queue.
*
* This function stops streaming and performs necessary clean ups, including
* freeing video buffer memory. The driver is responsible for freeing
* the &struct vb2_queue itself.
*/
void vb2_core_queue_release(struct vb2_queue *q);
/**
* vb2_queue_error() - signal a fatal error on the queue
* @q: pointer to &struct vb2_queue with videobuf2 queue.
*
* Flag that a fatal unrecoverable error has occurred and wake up all processes
* waiting on the queue. Polling will now set %EPOLLERR and queuing and dequeuing
* buffers will return %-EIO.
*
* The error flag will be cleared when canceling the queue, either from
* vb2_streamoff() or vb2_queue_release(). Drivers should thus not call this
* function before starting the stream, otherwise the error flag will remain set
* until the queue is released when closing the device node.
*/
void vb2_queue_error(struct vb2_queue *q);
/**
* vb2_mmap() - map video buffers into application address space.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
* @vma: pointer to &struct vm_area_struct with the vma passed
* to the mmap file operation handler in the driver.
*
* Should be called from mmap file operation handler of a driver.
* This function maps one plane of one of the available video buffers to
* userspace. To map whole video memory allocated on reqbufs, this function
* has to be called once per each plane per each buffer previously allocated.
*
* When the userspace application calls mmap, it passes to it an offset returned
* to it earlier by the means of &v4l2_ioctl_ops->vidioc_querybuf handler.
* That offset acts as a "cookie", which is then used to identify the plane
* to be mapped.
*
* This function finds a plane with a matching offset and a mapping is performed
* by the means of a provided memory operation.
*
* The return values from this function are intended to be directly returned
* from the mmap handler in driver.
*/
int vb2_mmap(struct vb2_queue *q, struct vm_area_struct *vma);
#ifndef CONFIG_MMU
/**
* vb2_get_unmapped_area - map video buffers into application address space.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
* @addr: memory address.
* @len: buffer size.
* @pgoff: page offset.
* @flags: memory flags.
*
* This function is used in noMMU platforms to propose address mapping
* for a given buffer. It's intended to be used as a handler for the
* &file_operations->get_unmapped_area operation.
*
* This is called by the mmap() syscall routines will call this
* to get a proposed address for the mapping, when ``!CONFIG_MMU``.
*/
unsigned long vb2_get_unmapped_area(struct vb2_queue *q,
unsigned long addr,
unsigned long len,
unsigned long pgoff,
unsigned long flags);
#endif
/**
* vb2_core_poll() - implements poll syscall() logic.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
* @file: &struct file argument passed to the poll
* file operation handler.
* @wait: &poll_table wait argument passed to the poll
* file operation handler.
*
* This function implements poll file operation handler for a driver.
* For CAPTURE queues, if a buffer is ready to be dequeued, the userspace will
* be informed that the file descriptor of a video device is available for
* reading.
* For OUTPUT queues, if a buffer is ready to be dequeued, the file descriptor
* will be reported as available for writing.
*
* The return values from this function are intended to be directly returned
* from poll handler in driver.
*/
__poll_t vb2_core_poll(struct vb2_queue *q, struct file *file,
poll_table *wait);
/**
* vb2_read() - implements read() syscall logic.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
* @data: pointed to target userspace buffer
* @count: number of bytes to read
* @ppos: file handle position tracking pointer
* @nonblock: mode selector (1 means blocking calls, 0 means nonblocking)
*/
size_t vb2_read(struct vb2_queue *q, char __user *data, size_t count,
loff_t *ppos, int nonblock);
/**
* vb2_read() - implements write() syscall logic.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
* @data: pointed to target userspace buffer
* @count: number of bytes to write
* @ppos: file handle position tracking pointer
* @nonblock: mode selector (1 means blocking calls, 0 means nonblocking)
*/
size_t vb2_write(struct vb2_queue *q, const char __user *data, size_t count,
loff_t *ppos, int nonblock);
/**
* typedef vb2_thread_fnc - callback function for use with vb2_thread.
*
* @vb: pointer to struct &vb2_buffer.
* @priv: pointer to a private data.
*
* This is called whenever a buffer is dequeued in the thread.
*/
typedef int (*vb2_thread_fnc)(struct vb2_buffer *vb, void *priv);
/**
* vb2_thread_start() - start a thread for the given queue.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
* @fnc: &vb2_thread_fnc callback function.
* @priv: priv pointer passed to the callback function.
* @thread_name:the name of the thread. This will be prefixed with "vb2-".
*
* This starts a thread that will queue and dequeue until an error occurs
* or vb2_thread_stop() is called.
*
* .. attention::
*
* This function should not be used for anything else but the videobuf2-dvb
* support. If you think you have another good use-case for this, then please
* contact the linux-media mailing list first.
*/
int vb2_thread_start(struct vb2_queue *q, vb2_thread_fnc fnc, void *priv,
const char *thread_name);
/**
* vb2_thread_stop() - stop the thread for the given queue.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
*/
int vb2_thread_stop(struct vb2_queue *q);
/**
* vb2_is_streaming() - return streaming status of the queue.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
*/
static inline bool vb2_is_streaming(struct vb2_queue *q)
{
return q->streaming;
}
/**
* vb2_fileio_is_active() - return true if fileio is active.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
*
* This returns true if read() or write() is used to stream the data
* as opposed to stream I/O. This is almost never an important distinction,
* except in rare cases. One such case is that using read() or write() to
* stream a format using %V4L2_FIELD_ALTERNATE is not allowed since there
* is no way you can pass the field information of each buffer to/from
* userspace. A driver that supports this field format should check for
* this in the &vb2_ops->queue_setup op and reject it if this function returns
* true.
*/
static inline bool vb2_fileio_is_active(struct vb2_queue *q)
{
return q->fileio;
}
/**
* vb2_is_busy() - return busy status of the queue.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
*
* This function checks if queue has any buffers allocated.
*/
static inline bool vb2_is_busy(struct vb2_queue *q)
{
return (q->num_buffers > 0);
}
/**
* vb2_get_drv_priv() - return driver private data associated with the queue.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
*/
static inline void *vb2_get_drv_priv(struct vb2_queue *q)
{
return q->drv_priv;
}
/**
* vb2_set_plane_payload() - set bytesused for the plane @plane_no.
* @vb: pointer to &struct vb2_buffer to which the plane in
* question belongs to.
* @plane_no: plane number for which payload should be set.
* @size: payload in bytes.
*/
static inline void vb2_set_plane_payload(struct vb2_buffer *vb,
unsigned int plane_no, unsigned long size)
{
if (plane_no < vb->num_planes)
vb->planes[plane_no].bytesused = size;
}
/**
* vb2_get_plane_payload() - get bytesused for the plane plane_no
* @vb: pointer to &struct vb2_buffer to which the plane in
* question belongs to.
* @plane_no: plane number for which payload should be set.
*/
static inline unsigned long vb2_get_plane_payload(struct vb2_buffer *vb,
unsigned int plane_no)
{
if (plane_no < vb->num_planes)
return vb->planes[plane_no].bytesused;
return 0;
}
/**
* vb2_plane_size() - return plane size in bytes.
* @vb: pointer to &struct vb2_buffer to which the plane in
* question belongs to.
* @plane_no: plane number for which size should be returned.
*/
static inline unsigned long
vb2_plane_size(struct vb2_buffer *vb, unsigned int plane_no)
{
if (plane_no < vb->num_planes)
return vb->planes[plane_no].length;
return 0;
}
/**
* vb2_start_streaming_called() - return streaming status of driver.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
*/
static inline bool vb2_start_streaming_called(struct vb2_queue *q)
{
return q->start_streaming_called;
}
/**
* vb2_clear_last_buffer_dequeued() - clear last buffer dequeued flag of queue.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
*/
static inline void vb2_clear_last_buffer_dequeued(struct vb2_queue *q)
{
q->last_buffer_dequeued = false;
}
/**
* vb2_get_buffer() - get a buffer from a queue
* @q: pointer to &struct vb2_queue with videobuf2 queue.
* @index: buffer index
*
* This function obtains a buffer from a queue, by its index.
* Keep in mind that there is no refcounting involved in this
* operation, so the buffer lifetime should be taken into
* consideration.
*/
static inline struct vb2_buffer *vb2_get_buffer(struct vb2_queue *q,
unsigned int index)
{
if (index < q->num_buffers)
return q->bufs[index];
return NULL;
}
/*
* The following functions are not part of the vb2 core API, but are useful
* functions for videobuf2-*.
*/
/**
* vb2_buffer_in_use() - return true if the buffer is in use and
* the queue cannot be freed (by the means of VIDIOC_REQBUFS(0)) call.
*
* @vb: buffer for which plane size should be returned.
* @q: pointer to &struct vb2_queue with videobuf2 queue.
*/
bool vb2_buffer_in_use(struct vb2_queue *q, struct vb2_buffer *vb);
/**
* vb2_verify_memory_type() - Check whether the memory type and buffer type
* passed to a buffer operation are compatible with the queue.
*
* @q: pointer to &struct vb2_queue with videobuf2 queue.
* @memory: memory model, as defined by enum &vb2_memory.
* @type: private buffer type whose content is defined by the vb2-core
* caller. For example, for V4L2, it should match
* the types defined on enum &v4l2_buf_type.
*/
int vb2_verify_memory_type(struct vb2_queue *q,
enum vb2_memory memory, unsigned int type);
/**
* vb2_request_object_is_buffer() - return true if the object is a buffer
*
* @obj: the request object.
*/
bool vb2_request_object_is_buffer(struct media_request_object *obj);
/**
* vb2_request_buffer_cnt() - return the number of buffers in the request
*
* @req: the request.
*/
unsigned int vb2_request_buffer_cnt(struct media_request *req);
#endif /* _MEDIA_VIDEOBUF2_CORE_H */