From 9a36d8ed33c481a99f69f8a2eeb22e3c7750e522 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Mon, 19 May 2014 16:37:38 -0300 Subject: [media] omap3isp: ccdc: Add basic support for interlaced video When the CCDC input is interlaced enable the alternate field order on the CCDC output video node. The field signal polarity is specified through platform data. Signed-off-by: Laurent Pinchart Tested-by: Enrico Butera Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- include/media/omap3isp.h | 3 +++ 1 file changed, 3 insertions(+) (limited to 'include/media') diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h index c9d06d9..398279d 100644 --- a/include/media/omap3isp.h +++ b/include/media/omap3isp.h @@ -57,6 +57,8 @@ enum { * 0 - Active high, 1 - Active low * @vs_pol: Vertical synchronization polarity * 0 - Active high, 1 - Active low + * @fld_pol: Field signal polarity + * 0 - Positive, 1 - Negative * @data_pol: Data polarity * 0 - Normal, 1 - One's complement */ @@ -65,6 +67,7 @@ struct isp_parallel_platform_data { unsigned int clk_pol:1; unsigned int hs_pol:1; unsigned int vs_pol:1; + unsigned int fld_pol:1; unsigned int data_pol:1; }; -- cgit v1.1 From f035eb4e976ef5a059e30bc91cfd310ff030a7d3 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Thu, 7 Aug 2014 03:47:14 -0300 Subject: [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: [] vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.117974] [ 403.117974] but task is already holding lock: [ 403.117976] (&mm->mmap_sem){++++++}, at: [] 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] [] validate_chain.isra.39+0x5fc/0x9a0 [ 403.118006] [] __lock_acquire+0x4d3/0xd30 [ 403.118010] [] lock_acquire+0xa7/0x160 [ 403.118014] [] might_fault+0x7c/0xb0 [ 403.118018] [] video_usercopy+0x425/0x610 [videodev] [ 403.118028] [] video_ioctl2+0x15/0x20 [videodev] [ 403.118034] [] v4l2_ioctl+0x184/0x1a0 [videodev] [ 403.118040] [] do_vfs_ioctl+0x2f0/0x4f0 [ 403.118307] [] SyS_ioctl+0x81/0xa0 [ 403.118311] [] system_call_fastpath+0x16/0x1b [ 403.118319] [ 403.118319] -> #0 (&dev->mutex#3){+.+.+.}: [ 403.118324] [] check_prevs_add+0x746/0x9f0 [ 403.118329] [] validate_chain.isra.39+0x5fc/0x9a0 [ 403.118333] [] __lock_acquire+0x4d3/0xd30 [ 403.118336] [] lock_acquire+0xa7/0x160 [ 403.118340] [] mutex_lock_interruptible_nested+0x64/0x640 [ 403.118344] [] vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118349] [] v4l2_mmap+0x62/0xa0 [videodev] [ 403.118354] [] mmap_region+0x3d0/0x5d0 [ 403.118359] [] do_mmap_pgoff+0x31d/0x400 [ 403.118363] [] vm_mmap_pgoff+0x90/0xc0 [ 403.118366] [] SyS_mmap_pgoff+0x1df/0x2a0 [ 403.118369] [] SyS_mmap+0x22/0x30 [ 403.118376] [] 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: [] 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] [] dump_stack+0x4e/0x7a [ 403.118445] [] print_circular_bug+0x1d5/0x2a0 [ 403.118449] [] check_prevs_add+0x746/0x9f0 [ 403.118455] [] ? find_vmap_area+0x42/0x70 [ 403.118459] [] validate_chain.isra.39+0x5fc/0x9a0 [ 403.118463] [] __lock_acquire+0x4d3/0xd30 [ 403.118468] [] lock_acquire+0xa7/0x160 [ 403.118472] [] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118476] [] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118480] [] mutex_lock_interruptible_nested+0x64/0x640 [ 403.118484] [] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118488] [] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118493] [] ? mark_held_locks+0x75/0xa0 [ 403.118497] [] vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118502] [] v4l2_mmap+0x62/0xa0 [videodev] [ 403.118506] [] mmap_region+0x3d0/0x5d0 [ 403.118510] [] do_mmap_pgoff+0x31d/0x400 [ 403.118513] [] vm_mmap_pgoff+0x90/0xc0 [ 403.118517] [] SyS_mmap_pgoff+0x1df/0x2a0 [ 403.118521] [] SyS_mmap+0x22/0x30 [ 403.118525] [] 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 Acked-by: Laurent Pinchart Acked-by: Marek Szyprowski Signed-off-by: Mauro Carvalho Chehab --- include/media/videobuf2-core.h | 2 ++ 1 file changed, 2 insertions(+) (limited to 'include/media') diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index fc910a6..5a10d8d 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -366,6 +366,7 @@ struct v4l2_fh; * cannot be started unless at least this number of buffers * have been queued into the driver. * + * @mmap_lock: private mutex used when buffers are allocated/freed/mmapped * @memory: current memory type used * @bufs: videobuf buffer structures * @num_buffers: number of allocated/used buffers @@ -399,6 +400,7 @@ struct vb2_queue { u32 min_buffers_needed; /* private: internal use only */ + struct mutex mmap_lock; enum v4l2_memory memory; struct vb2_buffer *bufs[VIDEO_MAX_FRAME]; unsigned int num_buffers; -- cgit v1.1 From 8dece35daf098e5d086b50724119ffbb24ceca7f Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 22 Aug 2014 07:00:42 -0500 Subject: [media] dm644x_ccdc: use unsigned long for fpc_table_addr The fpc_table_addr is used as an unsigned integer that stores an address. At the Kernel, the proper type for such integers is unsigned long. This generates lots of warnings when compiling on 64 bits. Signed-off-by: Mauro Carvalho Chehab --- include/media/davinci/dm644x_ccdc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'include/media') diff --git a/include/media/davinci/dm644x_ccdc.h b/include/media/davinci/dm644x_ccdc.h index 852e96c..984fb79 100644 --- a/include/media/davinci/dm644x_ccdc.h +++ b/include/media/davinci/dm644x_ccdc.h @@ -114,7 +114,7 @@ struct ccdc_fault_pixel { /* Number of fault pixel */ unsigned short fp_num; /* Address of fault pixel table */ - unsigned int fpc_table_addr; + unsigned long fpc_table_addr; }; /* Structure for CCDC configuration parameters for raw capture mode passed -- cgit v1.1 From ead130335f35fb732921ee0ffde6639be35aa108 Mon Sep 17 00:00:00 2001 From: Prabhakar Lad Date: Sat, 6 Sep 2014 12:26:49 -0300 Subject: [media] media: videobuf2-core.h: add a helper to get status of start_streaming() this patch adds a helper to get the status if start_streaming() was called successfully. Signed-off-by: Lad, Prabhakar Cc: Pawel Osciak Cc: Marek Szyprowski Cc: Kyungmin Park Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- include/media/videobuf2-core.h | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'include/media') diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index 5a10d8d..b3c9973 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -590,6 +590,15 @@ vb2_plane_size(struct vb2_buffer *vb, unsigned int plane_no) return 0; } +/** + * vb2_start_streaming_called() - return streaming status of driver + * @q: videobuf queue + */ +static inline bool vb2_start_streaming_called(struct vb2_queue *q) +{ + return q->start_streaming_called; +} + /* * The following functions are not part of the vb2 core API, but are simple * helper functions that you can use in your struct v4l2_file_operations, -- cgit v1.1 From 072f1a489efa348223db07730c4b946a4b1ca0cc Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Thu, 11 Sep 2014 19:43:46 -0300 Subject: [media] v4l: videobuf2: Fix typos in comments 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 Acked-by: Marek Szyprowski Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- include/media/videobuf2-core.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'include/media') diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index b3c9973..a8608ce 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -356,8 +356,8 @@ struct v4l2_fh; * @buf_struct_size: size of the driver-specific buffer structure; * "0" indicates the driver doesn't want to use a custom buffer * structure type, so sizeof(struct vb2_buffer) will is used - * @timestamp_flags: Timestamp flags; V4L2_BUF_FLAGS_TIMESTAMP_* and - * V4L2_BUF_FLAGS_TSTAMP_SRC_* + * @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. -- cgit v1.1 From 8db3e5df4b5aa5ab8ce1edb8ee59ca9f2c2e7cd9 Mon Sep 17 00:00:00 2001 From: "nibble.max" Date: Wed, 6 Aug 2014 01:40:01 -0300 Subject: [media] rc: add dvbsky rc keymap macro This RC will be used by DVBSky driver, added on the next patch. Signed-off-by: Nibble Max Signed-off-by: Mauro Carvalho Chehab --- include/media/rc-map.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/media') diff --git a/include/media/rc-map.h b/include/media/rc-map.h index 80f9518..e7a1514 100644 --- a/include/media/rc-map.h +++ b/include/media/rc-map.h @@ -135,6 +135,7 @@ void rc_map_init(void); #define RC_MAP_DM1105_NEC "rc-dm1105-nec" #define RC_MAP_DNTV_LIVE_DVBT_PRO "rc-dntv-live-dvbt-pro" #define RC_MAP_DNTV_LIVE_DVB_T "rc-dntv-live-dvb-t" +#define RC_MAP_DVBSKY "rc-dvbsky" #define RC_MAP_EMPTY "rc-empty" #define RC_MAP_EM_TERRATEC "rc-em-terratec" #define RC_MAP_ENCORE_ENLTV2 "rc-encore-enltv2" -- cgit v1.1