[PATCH v2] [media] m2m: fix bad unlock balance
This patch removes unnecessary mutex queue unlock/lock sequence causing bad
unlock balance in v4l2_m2m_poll when the last buffer on the destination
queue has been dequeued and adds spin lock protection for the done list
list_empty calls.
[ 144.990873] =
[ 144.995584] [ BUG: bad unlock balance detected! ]
[ 145.000301] 4.1.0-00137-ga105070 #98 Tainted: GW
[ 145.006140] -
[ 145.010851] demux:sink/487 is trying to release lock (dev-dev_mutex) at:
[ 145.017785] [808cc578] mutex_unlock+0x18/0x1c
[ 145.022322] but there are no more locks to release!
[ 145.027205]
[ 145.027205] other info that might help us debug this:
[ 145.033741] no locks held by demux:sink/487.
[ 145.038015]
[ 145.038015] stack backtrace:
[ 145.042385] CPU: 2 PID: 487 Comm: demux:sink Tainted: GW
4.1.0-00137-ga105070 #98
[ 145.051089] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 145.057622] Backtrace:
[ 145.060102] [80014a4c] (dump_backtrace) from [80014cc4]
(show_stack+0x20/0x24)
[ 145.067679] r6:80cedf78 r5: r4: r3:
[ 145.073421] [80014ca4] (show_stack) from [808c61e0]
(dump_stack+0x8c/0xa4)
[ 145.080661] [808c6154] (dump_stack) from [80072b64]
(print_unlock_imbalance_bug+0xb8/0xe8)
[ 145.089277] r6:808cc578 r5:ac6cd050 r4:ac38e400 r3:0001
[ 145.095020] [80072aac] (print_unlock_imbalance_bug) from [80077db4]
(lock_release+0x1a4/0x250)
[ 145.103983] r6:808cc578 r5:ac6cd050 r4:ac38e400 r3:
[ 145.109728] [80077c10] (lock_release) from [808cc470]
(__mutex_unlock_slowpath+0xc4/0x1b4)
[ 145.118344] r9:acb27a41 r8: r7:81553814 r6:808cc578 r5:60030013
r4:ac6cd01c
[ 145.126190] [808cc3ac] (__mutex_unlock_slowpath) from [808cc578]
(mutex_unlock+0x18/0x1c)
[ 145.134720] r7: r6:aced7cd4 r5:0041 r4:acb87800
[ 145.140468] [808cc560] (mutex_unlock) from [805a98b8]
(v4l2_m2m_fop_poll+0x5c/0x64)
[ 145.148494] [805a985c] (v4l2_m2m_fop_poll) from [805955a0]
(v4l2_poll+0x6c/0xa0)
[ 145.156243] r6:aced7bec r5: r4:ac6cc380 r3:805a985c
[ 145.161991] [80595534] (v4l2_poll) from [80156edc]
(do_sys_poll+0x230/0x4c0)
[ 145.169391] r5: r4:aced7be4
[ 145.173013] [80156cac] (do_sys_poll) from [801574a8]
(SyS_ppoll+0x1d4/0x1fc)
[ 145.180414] r10: r9:aced6000 r8: r7: r6:75c04538
r5:0002
[ 145.188338] r4:
[ 145.190906] [801572d4] (SyS_ppoll) from [800108c0]
(ret_fast_syscall+0x0/0x54)
[ 145.198481] r8:80010aa4 r7:0150 r6:75c04538 r5:0002 r4:0008
Signed-off-by: Zahari Doychev zahari.doyc...@linux.com
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index ec3ad4e..2f7291c 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -583,32 +583,25 @@ unsigned int v4l2_m2m_poll(struct file *file, struct
v4l2_m2m_ctx *m2m_ctx,
goto end;
}
- if (m2m_ctx-m2m_dev-m2m_ops-unlock)
- m2m_ctx-m2m_dev-m2m_ops-unlock(m2m_ctx-priv);
- else if (m2m_ctx-q_lock)
- mutex_unlock(m2m_ctx-q_lock);
-
+ spin_lock_irqsave(src_q-done_lock, flags);
if (list_empty(src_q-done_list))
poll_wait(file, src_q-done_wq, wait);
+ spin_unlock_irqrestore(src_q-done_lock, flags);
+
+ spin_lock_irqsave(dst_q-done_lock, flags);
if (list_empty(dst_q-done_list)) {
/*
* If the last buffer was dequeued from the capture queue,
* return immediately. DQBUF will return -EPIPE.
*/
- if (dst_q-last_buffer_dequeued)
+ if (dst_q-last_buffer_dequeued) {
+ spin_unlock_irqrestore(dst_q-done_lock, flags);
return rc | POLLIN | POLLRDNORM;
+ }
poll_wait(file, dst_q-done_wq, wait);
}
-
- if (m2m_ctx-m2m_dev-m2m_ops-lock)
- m2m_ctx-m2m_dev-m2m_ops-lock(m2m_ctx-priv);
- else if (m2m_ctx-q_lock) {
- if (mutex_lock_interruptible(m2m_ctx-q_lock)) {
- rc |= POLLERR;
- goto end;
- }
- }
+ spin_unlock_irqrestore(dst_q-done_lock, flags);
spin_lock_irqsave(src_q-done_lock, flags);
if (!list_empty(src_q-done_list))
--
2.5.0
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [media] m2m: fix bad unlock balance
On Fri, Aug 14, 2015 at 01:57:51PM +0200, Hans Verkuil wrote: On 08/12/2015 05:50 PM, Kamil Debski wrote: Hi, On 12 August 2015 at 13:42, Marek Szyprowski m.szyprow...@samsung.com wrote: Hello Hans, I'm sorry for a delay. Once again I've been busy with some other internal stuff. On 2015-07-28 11:02, Hans Verkuil wrote: Kamil, Marek, Why does v4l2_m2m_poll unlock and lock in that function? I've checked the code and indeed the poll_wait() function doesn't do anything that should not be done with queue mutex being taken. I don't remember if it was always like that. You are right that the unlocklock code should be removed. Zahari is right that the locking is unbalanced, but I don't see the reason for the unlock/lock sequence in the first place. I'm wondering if that shouldn't just be removed. Am I missing something? Instead, I would expect to see a spin_lock_irqsave(src/dst_q-done_lock, flags) around the list_empty(src/dst_q-done_list) calls. Indeed, that's another thing that should be fixed in this function. I looks that commit c16218402a000bb25c1277c43ae98c11bcb59bd1 ([media] videobuf2: return -EPIPE from DQBUF after the last buffer) is the root cause of both issues (unballanced locking and lack of spinlock protection), while the unnecessary queue unlock/lock sequence was there from the beginning. I am all with Marek on this. Unlock/lock was there from the beginning, it is not necessary. I agree also that spin_lock/unlock should be added for the list_empty call. Zahari, will you make a new version of this patch with the suggested changes? yes I will do it. Regards Zahari Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [media] coda: fix sequence counter increment
On Tue, Jul 28, 2015 at 12:25:31PM +0200, Philipp Zabel wrote: Am Dienstag, den 28.07.2015, 10:54 +0200 schrieb Hans Verkuil: On 07/08/2015 05:49 PM, Philipp Zabel wrote: Hi Zahari, Am Mittwoch, den 08.07.2015, 15:37 +0200 schrieb Zahari Doychev: The coda context queue sequence counter is incremented only if the vb2 source buffer payload is non zero. This makes possible to signal EOS otherwise the condition in coda_buf_is_end_of_stream is never met or more precisely buf-v4l2_buf.sequence == (ctx-qsequence - 1) never happens. Signed-off-by: Zahari Doychev zahari.doyc...@linux.com I think we should instead avoid calling coda_bitstream_queue with zero payload buffers altogether and dump them in coda_fill_bitstream already. Philipp, is this still outstanding or did you fix this already according to the suggestion you made above? Just wondering whether to set this bug report to 'Rejected' or 'Changes Requested'. Changes requested. Ok, I will send a corected version of the patch. regards Zahari Is this something I should do myself for coda patches in the future? regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] coda: drop zero payload bitstream buffers
The buffers with zero payload are now dumped in coda_fill_bitstream and not
passed to coda_bitstream_queue. This avoids unnecessary fifo addition and
buffer sequence counter increment.
Signed-off-by: Zahari Doychev zahari.doyc...@linux.com
---
drivers/media/platform/coda/coda-bit.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/media/platform/coda/coda-bit.c
b/drivers/media/platform/coda/coda-bit.c
index 3d434a4..fd7819d 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -256,6 +256,13 @@ void coda_fill_bitstream(struct coda_ctx *ctx, bool
streaming)
continue;
}
+ /* Dump empty buffers */
+ if (!vb2_get_plane_payload(src_buf, 0)) {
+ src_buf = v4l2_m2m_src_buf_remove(ctx-fh.m2m_ctx);
+ v4l2_m2m_buf_done(src_buf, VB2_BUF_STATE_DONE);
+ continue;
+ }
+
/* Buffer start position */
start = ctx-bitstream_fifo.kfifo.in
ctx-bitstream_fifo.kfifo.mask;
--
2.4.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] RFC: m2m device fixes
Hi, These patches fix some problems that I am experiencing when decoding video using the coda driver. The first one fixes the video playback termination and the second a kernel bug due to mutex unlock balance. Regards Zahari Zahari Doychev (2): [media] coda: fix sequence counter increment [media] m2m: fix bad unlock balance drivers/media/platform/coda/coda-bit.c | 3 ++- drivers/media/v4l2-core/v4l2-mem2mem.c | 19 ++- 2 files changed, 12 insertions(+), 10 deletions(-) -- 2.4.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [media] coda: fix sequence counter increment
The coda context queue sequence counter is incremented only if the vb2 source buffer payload is non zero. This makes possible to signal EOS otherwise the condition in coda_buf_is_end_of_stream is never met or more precisely buf-v4l2_buf.sequence == (ctx-qsequence - 1) never happens. Signed-off-by: Zahari Doychev zahari.doyc...@linux.com --- drivers/media/platform/coda/coda-bit.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/coda/coda-bit.c b/drivers/media/platform/coda/coda-bit.c index 109797b..d33f187 100644 --- a/drivers/media/platform/coda/coda-bit.c +++ b/drivers/media/platform/coda/coda-bit.c @@ -189,7 +189,8 @@ static int coda_bitstream_queue(struct coda_ctx *ctx, if (n src_size) return -ENOSPC; - src_buf-v4l2_buf.sequence = ctx-qsequence++; + if (src_size) + src_buf-v4l2_buf.sequence = ctx-qsequence++; return 0; } -- 2.4.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [media] m2m: fix bad unlock balance
This commit fixes bad unlock balance when polling. v4l2_m2m_poll is called
with mutex hold but the function releases the mutex and returns.
This leads to the bad unlock because after the call of v4l2_m2m_poll in
v4l2_m2m_fop_poll the mutex is again unlocked. This patch makes sure that
the v4l2_m2m_poll returns always with balanced locks.
[ 144.990873] =
[ 144.995584] [ BUG: bad unlock balance detected! ]
[ 145.000301] 4.1.0-00137-ga105070 #98 Tainted: GW
[ 145.006140] -
[ 145.010851] demux:sink/487 is trying to release lock (dev-dev_mutex) at:
[ 145.017785] [808cc578] mutex_unlock+0x18/0x1c
[ 145.022322] but there are no more locks to release!
[ 145.027205]
[ 145.027205] other info that might help us debug this:
[ 145.033741] no locks held by demux:sink/487.
[ 145.038015]
[ 145.038015] stack backtrace:
[ 145.042385] CPU: 2 PID: 487 Comm: demux:sink Tainted: GW
4.1.0-00137-ga105070 #98
[ 145.051089] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 145.057622] Backtrace:
[ 145.060102] [80014a4c] (dump_backtrace) from [80014cc4]
(show_stack+0x20/0x24)
[ 145.067679] r6:80cedf78 r5: r4: r3:
[ 145.073421] [80014ca4] (show_stack) from [808c61e0]
(dump_stack+0x8c/0xa4)
[ 145.080661] [808c6154] (dump_stack) from [80072b64]
(print_unlock_imbalance_bug+0xb8/0xe8)
[ 145.089277] r6:808cc578 r5:ac6cd050 r4:ac38e400 r3:0001
[ 145.095020] [80072aac] (print_unlock_imbalance_bug) from [80077db4]
(lock_release+0x1a4/0x250)
[ 145.103983] r6:808cc578 r5:ac6cd050 r4:ac38e400 r3:
[ 145.109728] [80077c10] (lock_release) from [808cc470]
(__mutex_unlock_slowpath+0xc4/0x1b4)
[ 145.118344] r9:acb27a41 r8: r7:81553814 r6:808cc578 r5:60030013
r4:ac6cd01c
[ 145.126190] [808cc3ac] (__mutex_unlock_slowpath) from [808cc578]
(mutex_unlock+0x18/0x1c)
[ 145.134720] r7: r6:aced7cd4 r5:0041 r4:acb87800
[ 145.140468] [808cc560] (mutex_unlock) from [805a98b8]
(v4l2_m2m_fop_poll+0x5c/0x64)
[ 145.148494] [805a985c] (v4l2_m2m_fop_poll) from [805955a0]
(v4l2_poll+0x6c/0xa0)
[ 145.156243] r6:aced7bec r5: r4:ac6cc380 r3:805a985c
[ 145.161991] [80595534] (v4l2_poll) from [80156edc]
(do_sys_poll+0x230/0x4c0)
[ 145.169391] r5: r4:aced7be4
[ 145.173013] [80156cac] (do_sys_poll) from [801574a8]
(SyS_ppoll+0x1d4/0x1fc)
[ 145.180414] r10: r9:aced6000 r8: r7: r6:75c04538
r5:0002
[ 145.188338] r4:
[ 145.190906] [801572d4] (SyS_ppoll) from [800108c0]
(ret_fast_syscall+0x0/0x54)
[ 145.198481] r8:80010aa4 r7:0150 r6:75c04538 r5:0002 r4:0008
Signed-off-by: Zahari Doychev zahari.doyc...@linux.com
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index dc853e5..5392fb4 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -583,16 +583,8 @@ unsigned int v4l2_m2m_poll(struct file *file, struct
v4l2_m2m_ctx *m2m_ctx,
if (list_empty(src_q-done_list))
poll_wait(file, src_q-done_wq, wait);
- if (list_empty(dst_q-done_list)) {
- /*
-* If the last buffer was dequeued from the capture queue,
-* return immediately. DQBUF will return -EPIPE.
-*/
- if (dst_q-last_buffer_dequeued)
- return rc | POLLIN | POLLRDNORM;
-
+ if (list_empty(dst_q-done_list) !dst_q-last_buffer_dequeued)
poll_wait(file, dst_q-done_wq, wait);
- }
if (m2m_ctx-m2m_dev-m2m_ops-lock)
m2m_ctx-m2m_dev-m2m_ops-lock(m2m_ctx-priv);
@@ -603,6 +595,15 @@ unsigned int v4l2_m2m_poll(struct file *file, struct
v4l2_m2m_ctx *m2m_ctx,
}
}
+ if (list_empty(dst_q-done_list) dst_q-last_buffer_dequeued) {
+ /*
+* If the last buffer was dequeued from the capture queue,
+* return immediately. DQBUF will return -EPIPE.
+*/
+ rc |= POLLIN | POLLRDNORM;
+ goto end;
+ }
+
spin_lock_irqsave(src_q-done_lock, flags);
if (!list_empty(src_q-done_list))
src_vb = list_first_entry(src_q-done_list, struct vb2_buffer,
--
2.4.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using the coda driver with Gstreamer
Hi Fabio, On Mon, Dec 01, 2014 at 05:17:40PM -0200, Fabio Estevam wrote: On Tue, Nov 18, 2014 at 4:41 PM, Nicolas Dufresne nicolas.dufre...@collabora.com wrote: Ok, let us know when the switch is made. Assuming your goal is to get the HW decoder working, you should test with simpler pipeline. In your specific case, you should try and get this pipeline to preroll: gst-launch-1.0 \ filesrc location=/home/H264_test1_Talk inghead_mp4_480x360.mp4 \ ! qtdemux ! h264parse ! v4l2video1dec ! fakesink After applying Philipp's dts patch: http://www.spinics.net/lists/arm-kernel/msg382314.html ,I am able to play the video clip with the following Gstreamer pipeline: gst-launch-1.0 filesrc location=/home/H264_test1_Talkinghead_mp4_480x360.mp4 ! qtdemux ! h264parse ! v4l2video1dec ! videoconvert ! fbdevsink I am using this pipeline with gstreamer 1.4.5 and current media branch but I am getting very poor performance 1-2 fps when playing 800x400 video. Is it possible that fbdevsink is too slow for that? Does anyone know what is going wrong? Regards, Zahari Video Type: root@imx6q-dmo-edm-qmx6:/# gst-discoverer-1.0 linux_800x480.mov -v Analyzing file:///DemoVideos/linux_800x480.mov Done discovering file:///DemoVideos/linux_800x480.mov Missing plugins (gstreamer|1.0|gst-discoverer-1.0|MPEG-4 AAC decoder|decoder-audio/mpeg, mpegversion=(int)4, framed=(boolean)true, stream-format=(string)raw, level=(string)2, base-profile=(string)lc, profile=(string)lc) Topology: container: video/quicktime audio: audio/mpeg, mpegversion=(int)4, framed=(boolean)true, stream-format=(string)raw, level=(string)2, base-profile=(string)lc, profile=(string)lc, codec_data=(buffer)120856e500, rate=(int)44100, channels=(int)1 Codec: audio/mpeg, mpegversion=(int)4, framed=(boolean)true, stream-format=(string)raw, level=(string)2, base-profile=(string)lc, profile=(string)lc, codec_data=(buffer)120856e500, rate=(int)44100, channels=(int)1 Additional info: None Stream ID: (null) Language: unknown Channels: 1 Sample rate: 44100 Depth: 0 Bitrate: 0 Max bitrate: 0 Tags: None video: video/x-h264, stream-format=(string)avc, alignment=(string)au, level=(string)3.1, profile=(string)high, codec_data=(buffer)0164001fffe100176764001facd940c83da10303e9ea600f18319601000668ebe3cb22c0, width=(int)800, height=(int)480, framerate=(fraction)3/1001, pixel-aspect-ratio=(fraction)1/1 Codec: video/x-h264, stream-format=(string)avc, alignment=(string)au, level=(string)3.1, profile=(string)high, codec_data=(buffer)0164001fffe100176764001facd940c83da10303e9ea600f18319601000668ebe3cb22c0, width=(int)800, height=(int)480, framerate=(fraction)3/1001, pixel-aspect-ratio=(fraction)1/1 Additional info: None Stream ID: 0b5ab36c52878431d95e588951bfa2cf80c530ad5deda45bf3f9fdd5a4d4a48f/001 Width: 800 Height: 480 Depth: 24 Frame rate: 3/1001 Pixel aspect ratio: 1/1 Interlaced: false Bitrate: 496256 Max bitrate: 10069 Tags: taglist, application-name=(string)Lavf55.7.100, container-format=(string)Quicktime, video-codec=(string)H.264, language-code=(string)en, bitrate=(uint)496256, minimum-bitrate=(uint)10069, maximum-bitrate=(uint)10069; Properties: Duration: 0:03:12.00600 Seekable: yes Tags: application name: Lavf55.7.100 container format: Quicktime video codec: H.264 language code: en bitrate: 496256 minimum bitrate: 10069 maximum bitrate: 10069 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using the coda driver with Gstreamer
On Wed, Feb 18, 2015 at 08:34:43AM -0500, Nicolas Dufresne wrote: Le 2015-02-18 03:42, Zahari Doychev a écrit : gst-launch-1.0 filesrc location=/home/H264_test1_Talkinghead_mp4_480x360.mp4 ! qtdemux ! h264parse ! v4l2video1dec ! videoconvert ! fbdevsink I am using this pipeline with gstreamer 1.4.5 and current media branch but I am getting very poor performance 1-2 fps when playing 800x400 video. Is it possible that fbdevsink is too slow for that? Does anyone know what is going wrong? In this context, you most likely have a conversion happening in videoconvert followed by a copy at fbdevsink. Framebuffer device is not a very good solution if performance matter (no possible zero-copy). Specially if the selected framebuffer color format does not match the decoded format. So can you tell me if there are some drivers and plugins that can do this in efficient way. Is there some work going on in this directions. I suppose glimagesink maybe will be a good way to go. Regards, Zahari -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 00/26] i.MX5/6 IPUv3 CSI/IC
Hi Philipp, can you tell which kernel tree I have to use for this patch set? Thanks and Regards, Zahari On Thu, Jun 12, 2014 at 07:06:14PM +0200, Philipp Zabel wrote: Hi, attached is a series of our work in progress i.MX6 capture drivers. I'm posting this now in reaction to Steve's i.MX6 Video capture series, as a reference for further discussion. Of the Image Converter (IC) we only use the postprocessor task, with tiling for larger frames, to implement v4l2 mem2mem scaler/colorspace converter and deinterlacer devices. The capture code capture code already uses the media controller framework and creates a subdevice representing the CSI, but the path to memory is fixed to IDMAC via SMFC, which is the only possible path for grayscale and and anything with multiple output ports connected to the CSIs (such as the CSI2IPU gasket on i.MX6) doesn't work yet. Also, I think the CSI subdevice driver should be completely separate from the capture driver. regards Philipp Philipp Zabel (16): gpu: ipu-v3: Add function to setup CP channel as interlaced gpu: ipu-v3: Add ipu_cpmem_get_buffer function gpu: ipu-v3: Add support for partial interleaved YCbCr 4:2:0 (NV12) format gpu: ipu-v3: Add support for planar YUV 4:2:2 (YUV422P) format imx-drm: currently only IPUv3 is supported, make it mandatory [media] Add i.MX SoC wide media device driver [media] imx-ipu: Add i.MX IPUv3 capture driver [media] ipuv3-csi: Skip 3 lines for NTSC BT.656 [media] imx-ipuv3-csi: Add support for temporarily stopping the stream on sync loss [media] imx-ipuv3-csi: Export sync lock event to userspace [media] v4l2-subdev.h: Add lock status notification [media] v4l2-subdev: Export v4l2_subdev_fops mfd: syscon: add child device support [media] imx: Add video switch ARM: dts: Add IPU aliases on i.MX6 ARM: dts: imx6qdl: Add mipi_ipu1/2 multiplexers, mipi_csi, and their connections Sascha Hauer (10): gpu: ipu-v3: Add IC support gpu: ipu-v3: Register IC with IPUv3 [media] imx-ipu: add ipu media common code [media] imx-ipu: Add i.MX IPUv3 scaler driver [media] imx-ipu: Add i.MX IPUv3 deinterlacer driver [media] v4l2: subdev: Add v4l2_device_register_subdev_node function [media] v4l2: Fix V4L2_CID_PIXEL_RATE [media] v4l2 async: remove from notifier list [media] ipuv3-csi: Pass ipucsi to v4l2_media_subdev_s_power [media] ipuv3-csi: make subdev controls available on video device Documentation/devicetree/bindings/mfd/syscon.txt | 11 + arch/arm/boot/dts/imx6dl.dtsi| 182 +++ arch/arm/boot/dts/imx6q.dtsi | 119 ++ arch/arm/boot/dts/imx6qdl.dtsi |9 + drivers/gpu/ipu-v3/Makefile |2 +- drivers/gpu/ipu-v3/ipu-common.c | 119 ++ drivers/gpu/ipu-v3/ipu-ic.c | 1227 +++ drivers/gpu/ipu-v3/ipu-prv.h |6 + drivers/media/platform/Kconfig |4 + drivers/media/platform/Makefile |1 + drivers/media/platform/imx/Kconfig | 50 + drivers/media/platform/imx/Makefile |6 + drivers/media/platform/imx/imx-ipu-scaler.c | 825 +++ drivers/media/platform/imx/imx-ipu-vdic.c| 716 + drivers/media/platform/imx/imx-ipu.c | 313 drivers/media/platform/imx/imx-ipu.h | 36 + drivers/media/platform/imx/imx-ipuv3-csi.c | 1729 ++ drivers/media/platform/imx/imx-media.c | 174 +++ drivers/media/platform/imx/imx-video-switch.c| 347 + drivers/media/v4l2-core/v4l2-async.c |1 + drivers/media/v4l2-core/v4l2-ctrls.c |8 +- drivers/media/v4l2-core/v4l2-device.c| 63 +- drivers/media/v4l2-core/v4l2-subdev.c|1 + drivers/mfd/syscon.c |3 + drivers/staging/imx-drm/Kconfig |7 +- include/media/imx.h | 25 + include/media/v4l2-device.h |5 + include/media/v4l2-subdev.h |3 + include/video/imx-ipu-v3.h | 16 + 29 files changed, 5976 insertions(+), 32 deletions(-) create mode 100644 drivers/gpu/ipu-v3/ipu-ic.c create mode 100644 drivers/media/platform/imx/Kconfig create mode 100644 drivers/media/platform/imx/Makefile create mode 100644 drivers/media/platform/imx/imx-ipu-scaler.c create mode 100644 drivers/media/platform/imx/imx-ipu-vdic.c create mode 100644 drivers/media/platform/imx/imx-ipu.c create mode 100644 drivers/media/platform/imx/imx-ipu.h create mode 100644 drivers/media/platform/imx/imx-ipuv3-csi.c create mode 100644 drivers/media/platform/imx/imx-media.c create mode 100644 drivers/media/platform/imx/imx-video-switch.c create mode 100644
