aboutsummaryrefslogtreecommitdiffstats
path: root/include/media/videobuf2-core.h
AgeCommit message (Collapse)AuthorFilesLines
2015-10-05[media] DocBook: Fix remaining issues with VB2 core documentationHEADmasterMauro Carvalho Chehab1-6/+8
Right now, "private:" tag should be lower-case, otherwise the scripts/kernel-doc won't do the right thing. Also, no fields after "private:" should be documented. As we don't want to strip the documentation, let's untag. This way, it will be seen only at the file, and not at the DocBooks. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-10-01[media] DocBook: fix most of warnings at videobuf2-core.hMauro Carvalho Chehab1-1/+5
include/media/videobuf2-core.h:112: warning: No description found for parameter 'get_dmabuf' include/media/videobuf2-core.h:146: warning: No description found for parameter 'm' include/media/videobuf2-core.h:146: warning: Excess struct/union/enum/typedef member 'mem_offset' description in 'vb2_plane' There are still several warnings, but those are hard to fix, as they're actually a bug at DocBook. Those should be fixed on separate patches. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-10-01[media] media: videobuf2: Restructure vb2_bufferJunghak Sung1-24/+42
Remove v4l2 stuff - v4l2_buf, v4l2_plane - from struct vb2_buffer. Add new member variables - bytesused, length, offset, userptr, fd, data_offset - to struct vb2_plane in order to cover all information of v4l2_plane. struct vb2_plane { <snip> unsigned int bytesused; unsigned int length; union { unsigned int offset; unsigned long userptr; int fd; } m; unsigned int data_offset; } Replace v4l2_buf with new member variables - index, type, memory - which are common fields for buffer management. struct vb2_buffer { <snip> unsigned int index; unsigned int type; unsigned int memory; unsigned int num_planes; struct vb2_plane planes[VIDEO_MAX_PLANES]; <snip> }; v4l2 specific fields - flags, field, timestamp, timecode, sequence - are moved to vb2_v4l2_buffer in videobuf2-v4l2.c struct vb2_v4l2_buffer { struct vb2_buffer vb2_buf; __u32 flags; __u32 field; struct timeval timestamp; struct v4l2_timecode timecode; __u32 sequence; }; Signed-off-by: Junghak Sung <jh1009.sung@samsung.com> Signed-off-by: Geunyoung Kim <nenggun.kim@samsung.com> Acked-by: Seung-Woo Kim <sw0312.kim@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-10-01[media] media: videobuf2: Replace videobuf2-core with videobuf2-v4l2Junghak Sung1-1/+1
Make videobuf2-v4l2 as a wrapper of videobuf2-core for v4l2-use. And replace videobuf2-core.h with videobuf2-v4l2.h. This renaming change should be accompanied by the modifications of all device drivers that include videobuf2-core.h. It can be done with just running this shell script. replace() { str1=$1 str2=$2 dir=$3 for file in $(find $dir -name *.h -o -name *.c -o -name Makefile) do echo $file sed "s/$str1/$str2/g" $file > $file.out mv $file.out $file done } replace "videobuf2-core" "videobuf2-v4l2" "include/media/" replace "videobuf2-core" "videobuf2-v4l2" "drivers/media/" replace "videobuf2-core" "videobuf2-v4l2" "drivers/usb/gadget/" replace "videobuf2-core" "videobuf2-v4l2" "drivers/staging/media/" Signed-off-by: Junghak Sung <jh1009.sung@samsung.com> Signed-off-by: Geunyoung Kim <nenggun.kim@samsung.com> Acked-by: Seung-Woo Kim <sw0312.kim@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-09-05Merge tag 'media/v4.3-1' of ↵Linus Torvalds1-4/+6
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media updates from Mauro Carvalho Chehab: - new DVB frontend drivers: ascot2e, cxd2841er, horus3a, lnbh25 - new HDMI capture driver: tc358743 - new driver for NetUP DVB new boards (netup_unidvb) - IR support for DVBSky cards (smipcie-ir) - Coda driver has gain macroblock tiling support - Renesas R-Car gains JPEG codec driver - new DVB platform driver for STi boards: c8sectpfe - added documentation for the media core kABI to device-drivers DocBook - lots of driver fixups, cleanups and improvements * tag 'media/v4.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (297 commits) [media] c8sectpfe: Remove select on undefined LIBELF_32 [media] i2c: fix platform_no_drv_owner.cocci warnings [media] cx231xx: Use wake_up_interruptible() instead of wake_up_interruptible_nr() [media] tc358743: only queue subdev notifications if devnode is set [media] tc358743: add missing Kconfig dependency/select [media] c8sectpfe: Use %pad to print 'dma_addr_t' [media] DocBook media: Fix typo "the the" in xml files [media] tc358743: make reset gpio optional [media] tc358743: set direction of reset gpio using devm_gpiod_get [media] dvbdev: document most of the functions/data structs [media] dvb_frontend.h: document the struct dvb_frontend [media] dvb-frontend.h: document struct dtv_frontend_properties [media] dvb-frontend.h: document struct dvb_frontend_ops [media] dvb: Use DVBFE_ALGO_HW where applicable [media] dvb_frontend.h: document struct analog_demod_ops [media] dvb_frontend.h: Document struct dvb_tuner_ops [media] Docbook: Document struct analog_parameters [media] dvb_frontend.h: get rid of dvbfe_modcod [media] add documentation for struct dvb_tuner_info [media] dvb_frontend: document dvb_frontend_tune_settings ...
2015-08-22[media] videobuf2-core: Add it to device-drivers DocBookMauro Carvalho Chehab1-4/+6
Most of the stuff at videobuf2-core are ok for adding it to DocBook. Two notes here: 1) As videobuf2-core will be soon be changed, better to not spend too much efforts right now, as things will change soon; 2) struct vb2_queue has a number of private elements that are documented. As Kernel nano documentation format handles "private:" arguments, we need to put them on a separate comment block or to remove. Keeping the comments is obviously better ;) Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Acked-by: Jonathan Corbet <corbet@lwn.net>
2015-07-17[media] vb2: Only requeue buffers immediately once streaming is startedSakari Ailus1-0/+2
Buffers can be returned back to videobuf2 in driver's streamon handler. In this case vb2_buffer_done() with buffer state VB2_BUF_STATE_QUEUED will cause the driver's buf_queue vb2 operation to be called, queueing the same buffer again only to be returned to videobuf2 using vb2_buffer_done() and so on. Add a new buffer state VB2_BUF_STATE_REQUEUEING which, when used as the state argument to vb2_buffer_done(), will result in buffers queued to the driver. Using VB2_BUF_STATE_QUEUED will leave the buffer to videobuf2, as it was before "[media] vb2: allow requeuing buffers while streaming". Fixes: ce0eff016f72 ("[media] vb2: allow requeuing buffers while streaming") [mchehab@osg.samsung.com: fix warning: enumeration value 'VB2_BUF_STATE_REQUEUEING' not handled in switch] Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Cc: stable@vger.kernel.org # for v4.1 Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-05-12[media] videobuf2: return -EPIPE from DQBUF after the last bufferPhilipp Zabel1-0/+13
If the last buffer was dequeued from a capture queue, let poll return immediately and let DQBUF return -EPIPE to signal there will no more buffers to dequeue until STREAMOFF. The driver signals the last buffer by setting the V4L2_BUF_FLAG_LAST. To reenable dequeuing on the capture queue, the driver must explicitly call vb2_clear_last_buffer_queued. The last buffer queued flag is cleared automatically during STREAMOFF. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Kamil Debski <k.debski@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-04-10[media] vb2: add allow_zero_bytesused flag to the vb2_queue structKamil Debski1-0/+2
The vb2: fix bytesused == 0 handling (8a75ffb) patch changed the behavior of __fill_vb2_buffer function, so that if bytesused is 0 it is set to the size of the buffer. However, bytesused set to 0 is used by older codec drivers as as indication used to mark the end of stream. To keep backward compatibility, this patch adds a flag passed to the vb2_queue_init function - allow_zero_bytesused. If the flag is set upon initialization of the queue, the videobuf2 keeps the value of bytesused intact in the OUTPUT queue and passes it to the driver. Reported-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Kamil Debski <k.debski@samsung.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-04-10[media] vb2: split the io_flags member of vb2_queue into a bit fieldKamil Debski1-13/+5
This patch splits the io_flags member of vb2_queue into a bit field. Instead of an enum with flags separate bit fields were introduced. Signed-off-by: Kamil Debski <k.debski@samsung.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2014-11-25[media] vb2: add dma_dir to the alloc memopHans Verkuil1-1/+3
This is needed for the next patch where the dma-sg alloc memop needs to know the dma_dir. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Pawel Osciak <pawel@osciak.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2014-11-25[media] vb2: replace 'write' by 'dma_dir'Hans Verkuil1-2/+4
The 'write' argument is very ambiguous. I first assumed that if it is 1, then we're doing video output but instead it meant the reverse. Since it is used to setup the dma_dir value anyway it is now replaced by the correct dma_dir value which is unambiguous. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Pawel Osciak <pawel@osciak.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2014-11-25[media] videobuf2-core.h: improve documentationHans Verkuil1-15/+17
Document that drivers can access/modify the buffer contents in buf_prepare and buf_finish. That was not clearly stated before. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Pawel Osciak <pawel@osciak.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2014-10-09Merge branch 'patchwork' into v4l_for_linusmedia/v3.18-rc1Mauro Carvalho Chehab1-2/+13
* patchwork: (544 commits) [media] ir-hix5hd2: fix build on c6x arch [media] pt3: fix DTV FE I2C driver load error paths Revert "[media] media: em28xx - remove reset_resume interface" [media] exynos4-is: fix some warnings when compiling on arm64 [media] usb drivers: use %zu instead of %zd [media] pci drivers: use %zu instead of %zd [media] dvb-frontends: use %zu instead of %zd [media] s5p-mfc: Fix several printk warnings [media] s5p_mfc_opr: Fix warnings [media] ti-vpe: Fix typecast [media] s3c-camif: fix dma_addr_t printks [media] s5p_mfc_opr_v6: get rid of warnings when compiled with 64 bits [media] s5p_mfc_opr_v5: Fix lots of warnings on x86_64 [media] em28xx: Fix identation [media] drxd: remove a dead code [media] saa7146: remove return after BUG() [media] cx88: remove return after BUG() [media] cx88: fix cards table CodingStyle [media] radio-sf16fmr2: declare some structs as static [media] radio-sf16fmi: declare pnp_attached as static ... Conflicts: Documentation/DocBook/media/v4l/compat.xml
2014-09-23[media] v4l: videobuf2: Fix typos in commentsLaurent Pinchart1-2/+2
The buffer flags are incorrectly referred to as V4L2_BUF_FLAGS_* instead of V4L2_BUF_FLAG_* in comments. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2014-09-21[media] vb2: fix VBI/poll regressionHans Verkuil1-0/+4
The recent conversion of saa7134 to vb2 unconvered a poll() bug that broke the teletext applications alevt and mtt. These applications expect that calling poll() without having called VIDIOC_STREAMON will cause poll() to return POLLERR. That did not happen in vb2. This patch fixes that behavior. It also fixes what should happen when poll() is called when STREAMON is called but no buffers have been queued. In that case poll() will also return POLLERR, but only for capture queues since output queues will always return POLLOUT anyway in that situation. This brings the vb2 behavior in line with the old videobuf behavior. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2014-09-21[media] videobuf2-core.h: fix commentHans Verkuil1-1/+1
The comment for start_streaming that tells the developer with which vb2 state buffers should be returned to vb2 gave the wrong state. Very confusing. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2014-09-21[media] media: videobuf2-core.h: add a helper to get status of start_streaming()Prabhakar Lad1-0/+9
this patch adds a helper to get the status if start_streaming() was called successfully. Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Cc: Pawel Osciak <pawel@osciak.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2014-08-21[media] videobuf2: fix lockdep warningHans Verkuil1-0/+2
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-07-25[media] vb2: fix videobuf2-core.h commentsHans Verkuil1-6/+10
A lot of work was done in vb2 to regulate how drivers and the vb2 core handle buffer ownership, but inexplicably the videobuf2-core.h comments were never updated. Do so now. The same was true for the replacement of the -ENOBUFS mechanism by the min_buffers_needed field. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-07-17[media] v4l: vb2: Add fatal error condition flagLaurent Pinchart1-0/+3
When a fatal error occurs that render the device unusable, the only options for a driver to signal the error condition to userspace is to set the V4L2_BUF_FLAG_ERROR flag when dequeuing buffers and to return an error from the buffer prepare handler when queuing buffers. The buffer error flag indicates a transient error and can't be used by applications to detect fatal errors. Returning an error from vb2_qbuf() is thus the only real indication that a fatal error occurred. However, this is difficult to handle for multithreaded applications that requeue buffers from a thread other than the control thread. In particular the poll() call in the control thread will not notify userspace of the error. This patch adds an explicit mechanism to report fatal errors to userspace. Drivers can call the vb2_queue_error() function to signal a fatal error. From this moment on, buffer preparation will return -EIO to userspace, and vb2_poll() will set the POLLERR flag and return immediately. The error flag is cleared when cancelling the queue, either at stream off time (through vb2_streamoff) or when releasing the queue with vb2_queue_release(). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-05-25[media] v4l: vb2: Add a function to discard all DONE buffersLaurent Pinchart1-0/+1
When suspending a device while a video stream is active all buffers marked as done but not dequeued yet will be kept across suspend and given back to userspace after resume. This will result in outdated buffers being dequeued. Introduce a new vb2 function to mark all done buffers as erroneous instead, to be used by drivers at resume time. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Sakari Ailus <sakari.ailus@iki.fi> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-04-23[media] vb2: stop_streaming should return voidHans Verkuil1-1/+1
The vb2 core ignores any return code from the stop_streaming op. And there really isn't anything it can do anyway in case of an error. So change the return type to void and update any drivers that implement it. The int return gave drivers the idea that this operation could actually fail, but that's really not the case. The pwc amd sdr-msi3101 drivers both had this construction: if (mutex_lock_interruptible(&s->v4l2_lock)) return -ERESTARTSYS; This has been updated to just call mutex_lock(). The stop_streaming op expects this to really stop streaming and I very much doubt this will work reliably if stop_streaming just returns without really stopping the DMA. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Pawel Osciak <pawel@osciak.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-04-16[media] vb2: add thread supportHans Verkuil1-0/+32
In order to implement vb2 DVB support you need to be able to start a kernel thread that queues and dequeues buffers, calling a callback function for every buffer. This patch adds support for that. It's based on drivers/media/v4l2-core/videobuf-dvb.c, but with all the DVB specific stuff stripped out, thus making it much more generic. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-04-16[media] vb2: add vb2_fileio_is_active and check it more oftenHans Verkuil1-0/+17
Added a vb2_fileio_is_active inline function that returns true if fileio is in progress. Check for this too in mmap() (you don't want apps mmap()ing buffers used by fileio) and expbuf() (same reason). In addition drivers should be able to check for this in queue_setup() to return an error if an attempt is made to read() or write() with V4L2_FIELD_ALTERNATE being configured. This is illegal (there is no way to pass the TOP/BOTTOM information around using file I/O). However, in order to be able to check for this the init_fileio function needs to set q->fileio early on, before the buffers are allocated. So switch to using internal functions (__reqbufs, vb2_internal_qbuf and vb2_internal_streamon) to skip the fileio check. Well, that's why the internal functions were created... Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Pawel Osciak <pawel@osciak.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-03-11[media] vb2: only call start_streaming if sufficient buffers are queuedHans Verkuil1-4/+10
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-03-11[media] vb2: rename queued_count to owned_by_drv_countHans Verkuil1-2/+2
'queued_count' is a bit vague since it is not clear to which queue it refers to: the vb2 internal list of buffers or the driver-owned list of buffers. Rename to make it explicit. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Pawel Osciak <pawel@osciak.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-03-11[media] vb2: consistent usage of periods in videobuf2-core.hHans Verkuil1-20/+20
Sometimes sentences in comments ended with a period, and sometimes they didn't. Add periods. No other changes. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-03-11[media] vb2: call buf_finish from __queue_cancelHans Verkuil1-1/+9
If a queue was canceled, then the buf_finish op was never called for the pending buffers. So add this call to queue_cancel. Before calling buf_finish set the buffer state to PREPARED, which is the correct state. That way the states DONE and ERROR will only be seen in buf_finish if streaming is in progress. Since buf_finish can now be called from non-streaming state we need to adapt the handful of drivers that actually need to know this. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-03-11[media] vb2: change result code of buf_finish to voidHans Verkuil1-1/+1
The buf_finish op should always work, so change the return type to void. Update the few drivers that use it. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Pawel Osciak <pawel@osciak.com> Reviewed-by: Pawel Osciak <pawel@osciak.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-03-11[media] vb2: add debugging code to check for unbalanced opsHans Verkuil1-0/+43
When a vb2_queue is freed check if all the mem_ops and queue ops were balanced. So the number of calls to e.g. buf_finish has to match the number of calls to buf_prepare, etc. This code is only enabled if CONFIG_VIDEO_ADV_DEBUG is set. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Pawel Osciak <pawel@osciak.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-03-05[media] v4l: Add timestamp source flags, mask and document themSakari Ailus1-0/+2
Some devices do not produce timestamps that correspond to the end of the frame. The user space should be informed on the matter. This patch achieves that by adding buffer flags (and a mask) for timestamp sources since more possible timestamping points are expected than just two. A three-bit mask is defined (V4L2_BUF_FLAG_TSTAMP_SRC_MASK) and two of the eight possible values is are defined V4L2_BUF_FLAG_TSTAMP_SRC_EOF for end of frame (value zero) V4L2_BUF_FLAG_TSTAMP_SRC_SOE for start of exposure (next value). Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Kamil Debski <k.debski@samsung.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-03-05[media] v4l: Rename vb2_queue.timestamp_type as timestamp_flagsSakari Ailus1-1/+1
The timestamp_type field used to contain only the timestamp type. Soon it will be used for timestamp source flags as well. Rename the field accordingly. [m.chehab@samsung.com: do the change also to drivers/staging/media and at s2255] Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-01-07[media] vb2: retry start_streaming in case of insufficient buffersHans Verkuil1-4/+11
If start_streaming returns -ENOBUFS, then it will be retried the next time a buffer is queued. This means applications no longer need to know how many buffers need to be queued before STREAMON can be called. This is particularly useful for output stream I/O. If a DMA engine needs at least X buffers before it can start streaming, then for applications to get a buffer out as soon as possible they need to know the minimum number of buffers to queue before STREAMON can be called. You can't just try STREAMON after every buffer since on failure STREAMON will dequeue all your buffers. (Is that a bug or a feature? Frankly, I'm not sure). This patch simplifies applications substantially: they can just call STREAMON at the beginning and then start queuing buffers and the DMA engine will kick in automagically once enough buffers are available. This also fixes using write() to stream video: the fileio implementation calls streamon without having any queued buffers, which will fail today for any driver that requires a minimum number of buffers. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2014-01-07[media] vb2: push the mmap semaphore down to __buf_prepare()Hans Verkuil1-0/+2
Rather than taking the mmap semaphore at a relatively high-level function, push it down to the place where it is really needed. It was placed in vb2_queue_or_prepare_buf() to prevent racing with other vb2 calls. The only way I can see that a race can happen is when two threads queue the same buffer. The solution for that it to introduce a PREPARING state. Moving it down offers opportunities to simplify the code. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-12-09[media] videobuf2: Add missing lock held on vb2_fop_releaseRicardo Ribalda1-0/+1
vb2_fop_release does not hold the lock although it is modifying the queue->owner field. This could lead to race conditions on the vb2_perform_io function when multiple applications are accessing the video device via read/write API: [ 308.297741] BUG: unable to handle kernel NULL pointer dereference at 0000000000000260 [ 308.297759] IP: [<ffffffffa07a9fd2>] vb2_perform_fileio+0x372/0x610 [videobuf2_core] [ 308.297794] PGD 159719067 PUD 158119067 PMD 0 [ 308.297812] Oops: 0000 #1 SMP [ 308.297826] Modules linked in: qt5023_video videobuf2_dma_sg qtec_xform videobuf2_vmalloc videobuf2_memops videobuf2_core qtec_white qtec_mem gpio_xilinx qtec_cmosis qtec_pcie fglrx(PO) spi_xilinx spi_bitbang qt5023 [ 308.297888] CPU: 1 PID: 2189 Comm: java Tainted: P O 3.11.0-qtec-standard #1 [ 308.297919] Hardware name: QTechnology QT5022/QT5022, BIOS PM_2.1.0.309 X64 05/23/2013 [ 308.297952] task: ffff8801564e1690 ti: ffff88014dc02000 task.ti: ffff88014dc02000 [ 308.297962] RIP: 0010:[<ffffffffa07a9fd2>] [<ffffffffa07a9fd2>] vb2_perform_fileio+0x372/0x610 [videobuf2_core] [ 308.297985] RSP: 0018:ffff88014dc03df8 EFLAGS: 00010202 [ 308.297995] RAX: 0000000000000000 RBX: ffff880158a23000 RCX: dead000000100100 [ 308.298003] RDX: 0000000000000000 RSI: dead000000200200 RDI: 0000000000000000 [ 308.298012] RBP: ffff88014dc03e58 R08: 0000000000000000 R09: 0000000000000001 [ 308.298020] R10: ffffea00051e8380 R11: ffff88014dc03fd8 R12: ffff880158a23070 [ 308.298029] R13: ffff8801549040b8 R14: 0000000000198000 R15: 0000000001887e60 [ 308.298040] FS: 00007f65130d5700(0000) GS:ffff88015ed00000(0000) knlGS:0000000000000000 [ 308.298049] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 308.298057] CR2: 0000000000000260 CR3: 0000000159630000 CR4: 00000000000007e0 [ 308.298064] Stack: [ 308.298071] ffff880156416c00 0000000000198000 0000000000000000 ffff880100000001 [ 308.298087] ffff88014dc03f50 00000000810a79ca 0002000000000001 ffff880154904718 [ 308.298101] ffff880156416c00 0000000000198000 ffff880154904338 ffff88014dc03f50 [ 308.298116] Call Trace: [ 308.298143] [<ffffffffa07aa3c4>] vb2_read+0x14/0x20 [videobuf2_core] [ 308.298198] [<ffffffffa07aa494>] vb2_fop_read+0xc4/0x120 [videobuf2_core] [ 308.298252] [<ffffffff8154ee9e>] v4l2_read+0x7e/0xc0 [ 308.298296] [<ffffffff8116e639>] vfs_read+0xa9/0x160 [ 308.298312] [<ffffffff8116e882>] SyS_read+0x52/0xb0 [ 308.298328] [<ffffffff81784179>] tracesys+0xd0/0xd5 [ 308.298335] Code: e5 d6 ff ff 83 3d be 24 00 00 04 89 c2 4c 8b 45 b0 44 8b 4d b8 0f 8f 20 02 00 00 85 d2 75 32 83 83 78 03 00 00 01 4b 8b 44 c5 48 <8b> 88 60 02 00 00 85 c9 0f 84 b0 00 00 00 8b 40 58 89 c2 41 89 [ 308.298487] RIP [<ffffffffa07a9fd2>] vb2_perform_fileio+0x372/0x610 [videobuf2_core] [ 308.298507] RSP <ffff88014dc03df8> [ 308.298514] CR2: 0000000000000260 [ 308.298526] ---[ end trace e8f01717c96d1e41 ]--- Signed-off-by: Ricardo Ribalda <ricardo.ribalda@gmail.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-29[media] videobuf2: Add support for file access mode flags for DMABUF exportingPhilipp Zabel1-1/+1
Currently it is not possible for userspace to map a DMABUF exported buffer with write permissions. This patch allows to also pass O_RDONLY/O_RDWR when exporting the buffer, so that userspace may map it with write permissions. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-09-26[media] videobuf2: Fix vb2_write prototypeRicardo Ribalda1-2/+2
struct v4_file_operations defines the data param as const char __user *data but on vb2 is defined as char __user *data. This patch fixes the warnings produced by this. ie: drivers/qtec/qtec_xform.c:817:2: warning: initialization from incompatible pointer type [enabled by default] drivers/qtec/qtec_xform.c:817:2: warning: (near initialization for ‘qtec_xform_v4l_fops.write’) [enabled by default] Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-08-18[media] media: vb2: Clarify queue_setup() and buf_prepare() usage documentationLaurent Pinchart1-4/+7
Explain how the two operations must handle formats and validate buffer sizes when used with VIDIOC_CREATE_BUFS. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-03-21[media] videobuf2: add gfp_flagsHans Verkuil1-2/+8
Some drivers have special memory requirements for their buffers, usually related to DMA (e.g. GFP_DMA or __GFP_DMA32). Make it possible to specify additional GFP flags for those buffers by adding a gfp_flags field to vb2_queue. Note that this field will be replaced in the future with a different mechanism, but that is still work in progress and we need this feature now so we won't be able to convert drivers with such requirements to vb2. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Federico Vaga <federico.vaga@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2013-03-05[media] vb2: Add support for non monotonic timestampsKamil Debski1-0/+1
Not all drivers use monotonic timestamps. This patch adds a way to set the timestamp type per every queue. In addition, set proper timestamp type in drivers that I am sure that use either MONOTONIC or COPY timestamps. Other drivers will correctly report UNKNOWN timestamp type instead of assuming that all drivers use monotonic timestamps. Signed-off-by: Kamil Debski <k.debski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-11-25[media] v4l: vb2: add buffer exporting via dmabufTomasz Stanislawski1-0/+4
This patch adds extension to videobuf2-core. It allow to export an mmap buffer as a DMABUF file descriptor. Signed-off-by: Tomasz Stanislawski <t.stanislaws@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Tested-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-11-25[media] v4l: vb2: add prepare/finish callbacks to allocatorsMarek Szyprowski1-0/+7
This patch adds support for prepare/finish callbacks in VB2 allocators. These callback are used for buffer flushing. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Tested-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-11-25[media] v4l: vb2: add support for shared buffer (dma_buf)Sumit Semwal1-0/+27
This patch adds support for DMABUF memory type in videobuf2. It calls relevant APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations. For this version, the support is for videobuf2 as a user of the shared buffer; so the allocation of the buffer is done outside of V4L2. [A sample allocator of dma-buf shared buffer is given at [1]] [1]: Rob Clark's DRM: https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf [original work in the PoC for buffer sharing] Signed-off-by: Tomasz Stanislawski <t.stanislaws@samsung.com> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Tested-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-09-27[media] videobuf2-core: Replace BUG_ON and return an error at vb2_queue_init()Ezequiel Garcia1-1/+1
This replaces BUG_ON() calls with WARN_ON(), and returns EINVAL if some parameter is NULL, as suggested by Jonathan and Mauro. The BUG_ON() call is too drastic to be used in this case. See the full discussion here: http://www.spinics.net/lists/linux-media/msg52462.html Signed-off-by: Ezequiel Garcia <elezegarcia@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-07-06[media] videobuf2-core: add helper functionsHans Verkuil1-0/+41
Add helper functions to make it easier to adapt drivers to vb2. These helpers take care of core locking and check if the filehandle is the owner of the queue. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-07-06[media] v4l2-dev/ioctl.c: add vb2_queue support to video_deviceHans Verkuil1-0/+13
This prepares struct video_device for easier integration with vb2. It also introduces a new lock that protects the vb2_queue. It is up to the driver to use it or not. And the driver can associate an owner filehandle with the queue to check whether queuing requests are permitted for the calling filehandle. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-11-03[media] vb2: add vb2_get_unmapped_area in vb2 coreScott Jiang1-0/+7
no mmu system needs get_unmapped_area file operations to do mmap Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-11-03[media] V4L: vb2: add support for buffers of different sizes on a single queueGuennadi Liakhovetski1-12/+23
The two recently added ioctl()s VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF allow user-space applications to allocate video buffers of different sizes and hand them over to the driver for fast switching between different frame formats. This patch adds support for buffers of different sizes on the same buffer-queue to vb2. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-11-03[media] V4L: vb2: prepare to support multi-size buffersGuennadi Liakhovetski1-3/+3
In preparation for the forthcoming VIDIOC_CREATE_BUFS ioctl add a "const struct v4l2_format *" argument to the .queue_setup() vb2 operation. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Privacy Policy