Re: [v2,35/35,media] omap: be sure that MMU is there for COMPILE_TEST
Hi Mauro, On Tue, 2014-08-26 at 18:55 -0300, Mauro Carvalho Chehab wrote: COMPILE_TEST fail on (some) archs without MMU. Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com This patch just landed in next-20140919 as commit 38a073116525 ([media] omap: be sure that MMU is there for COMPILE_TEST). --- drivers/media/platform/omap/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/omap/Kconfig b/drivers/media/platform/omap/Kconfig index 2253bf102ed9..05de442d24e4 100644 --- a/drivers/media/platform/omap/Kconfig +++ b/drivers/media/platform/omap/Kconfig @@ -3,7 +3,7 @@ config VIDEO_OMAP2_VOUT_VRFB config VIDEO_OMAP2_VOUT tristate OMAP2/OMAP3 V4L2-Display driver - depends on ARCH_OMAP2 || ARCH_OMAP3 || COMPILE_TEST + depends on ARCH_OMAP2 || ARCH_OMAP3 || (COMPILE_TEST HAS_MMU) There's no Kconfig symbol HAS_MMU. So this last test will always fail. Did you perhaps mean simply MMU? select VIDEOBUF_GEN select VIDEOBUF_DMA_CONTIG Paul Bolle -- 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/3] vb2: Buffers returned to videobuf2 from start_streaming in QUEUED state
On Fri, Sep 19, 2014 at 12:57:47AM +0300, Sakari Ailus wrote: @@ -1174,7 +1174,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum vb2_buffer_state state) if (WARN_ON(vb-state != VB2_BUF_STATE_ACTIVE)) return; - if (!q-start_streaming_called) { + if (q-done_buffers_queued_state) { if (WARN_ON(state != VB2_BUF_STATE_QUEUED)) state = VB2_BUF_STATE_QUEUED; } else if (WARN_ON(state != VB2_BUF_STATE_DONE This condition needs to be changed, too. I'll resend a corrected version. -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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
[next:master 6630/6742] drivers/media/platform/coda/coda-bit.c:231:4: error: implicit declaration of function 'kmalloc'
tree: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master head: 6a10bca9b608df445baa23c3bfafc510d93d425b commit: 8fdb4a28beeda1e6626c43b70cd0575512173c3a [6630/6742] Merge remote-tracking branch 'v4l-dvb/master' config: arm-imx_v6_v7_defconfig reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 8fdb4a28beeda1e6626c43b70cd0575512173c3a make.cross ARCH=arm imx_v6_v7_defconfig make.cross ARCH=arm All error/warnings: drivers/media/platform/coda/coda-bit.c: In function 'coda_fill_bitstream': drivers/media/platform/coda/coda-bit.c:231:4: error: implicit declaration of function 'kmalloc' [-Werror=implicit-function-declaration] ts = kmalloc(sizeof(*ts), GFP_KERNEL); ^ drivers/media/platform/coda/coda-bit.c:231:7: warning: assignment makes pointer from integer without a cast ts = kmalloc(sizeof(*ts), GFP_KERNEL); ^ drivers/media/platform/coda/coda-bit.c: In function 'coda_alloc_framebuffers': drivers/media/platform/coda/coda-bit.c:312:3: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration] kfree(name); ^ cc1: some warnings being treated as errors vim +/kmalloc +231 drivers/media/platform/coda/coda-bit.c 79924ca9 Philipp Zabel 2014-07-23 225 /* 79924ca9 Philipp Zabel 2014-07-23 226 * Source buffer is queued in the bitstream ringbuffer; 79924ca9 Philipp Zabel 2014-07-23 227 * queue the timestamp and mark source buffer as done 79924ca9 Philipp Zabel 2014-07-23 228 */ 79924ca9 Philipp Zabel 2014-07-23 229 src_buf = v4l2_m2m_src_buf_remove(ctx-fh.m2m_ctx); 79924ca9 Philipp Zabel 2014-07-23 230 79924ca9 Philipp Zabel 2014-07-23 231 ts = kmalloc(sizeof(*ts), GFP_KERNEL); 79924ca9 Philipp Zabel 2014-07-23 232 if (ts) { 79924ca9 Philipp Zabel 2014-07-23 233 ts-sequence = src_buf-v4l2_buf.sequence; 79924ca9 Philipp Zabel 2014-07-23 234 ts-timecode = src_buf-v4l2_buf.timecode; 79924ca9 Philipp Zabel 2014-07-23 235 ts-timestamp = src_buf-v4l2_buf.timestamp; 79924ca9 Philipp Zabel 2014-07-23 236 list_add_tail(ts-list, ctx-timestamp_list); 79924ca9 Philipp Zabel 2014-07-23 237 } 79924ca9 Philipp Zabel 2014-07-23 238 79924ca9 Philipp Zabel 2014-07-23 239 v4l2_m2m_buf_done(src_buf, VB2_BUF_STATE_DONE); 79924ca9 Philipp Zabel 2014-07-23 240 } else { 79924ca9 Philipp Zabel 2014-07-23 241 break; 79924ca9 Philipp Zabel 2014-07-23 242 } 79924ca9 Philipp Zabel 2014-07-23 243 } 79924ca9 Philipp Zabel 2014-07-23 244 } 79924ca9 Philipp Zabel 2014-07-23 245 79924ca9 Philipp Zabel 2014-07-23 246 void coda_bit_stream_end_flag(struct coda_ctx *ctx) 79924ca9 Philipp Zabel 2014-07-23 247 { 79924ca9 Philipp Zabel 2014-07-23 248 struct coda_dev *dev = ctx-dev; 79924ca9 Philipp Zabel 2014-07-23 249 79924ca9 Philipp Zabel 2014-07-23 250 ctx-bit_stream_param |= CODA_BIT_STREAM_END_FLAG; 79924ca9 Philipp Zabel 2014-07-23 251 f23797b6 Philipp Zabel 2014-08-06 252 /* If this context is currently running, update the hardware flag */ 79924ca9 Philipp Zabel 2014-07-23 253 if ((dev-devtype-product == CODA_960) 79924ca9 Philipp Zabel 2014-07-23 254 coda_isbusy(dev) 79924ca9 Philipp Zabel 2014-07-23 255 (ctx-idx == coda_read(dev, CODA_REG_BIT_RUN_INDEX))) { f23797b6 Philipp Zabel 2014-08-06 256 coda_write(dev, ctx-bit_stream_param, f23797b6 Philipp Zabel 2014-08-06 257 CODA_REG_BIT_BIT_STREAM_PARAM); 79924ca9 Philipp Zabel 2014-07-23 258 } 79924ca9 Philipp Zabel 2014-07-23 259 } 79924ca9 Philipp Zabel 2014-07-23 260 79924ca9 Philipp Zabel 2014-07-23 261 static void coda_parabuf_write(struct coda_ctx *ctx, int index, u32 value) 79924ca9 Philipp Zabel 2014-07-23 262 { 79924ca9 Philipp Zabel 2014-07-23 263 struct coda_dev *dev = ctx-dev; 79924ca9 Philipp Zabel 2014-07-23 264 u32 *p = ctx-parabuf.vaddr; 79924ca9 Philipp Zabel 2014-07-23 265 79924ca9 Philipp Zabel 2014-07-23 266 if (dev-devtype-product == CODA_DX6) 79924ca9 Philipp Zabel 2014-07-23 267 p[index] = value; 79924ca9 Philipp Zabel 2014-07-23 268 else 79924ca9 Philipp Zabel 2014-07-23 269 p[index ^ 1] = value; 79924ca9 Philipp Zabel 2014-07-23 270 } 79924ca9 Philipp Zabel 2014-07-23 271 79924ca9 Philipp Zabel 2014-07-23 272 static void coda_free_framebuffers(struct
Re: [PATCH 1/3] vb2: Buffers returned to videobuf2 from start_streaming in QUEUED state
On 09/18/2014 11:57 PM, Sakari Ailus wrote: Patch [media] v4l: vb2: Fix stream start and buffer completion race has a sets q-start_streaming_called before calling queue op start_streaming() in order to fix a bug. This has the side effect that buffers returned to videobuf2 in VB2_BUF_STATE_QUEUED will cause a WARN_ON() to be called. Add a new field called done_buffers_queued_state to struct vb2_queue, which must be set if the new state of buffers returned to videobuf2 must be VB2_BUF_STATE_QUEUED, i.e. buffers returned in start_streaming op. I posted a fix for this over a month ago: https://www.mail-archive.com/linux-media@vger.kernel.org/msg77871.html Unfortunately, the pull request with that patch (https://patchwork.linuxtv.org/patch/25162/) fell through the cracks as I discovered yesterday. Hopefully Mauro will pick up that pull request quickly. I prefer my patch since that avoids introducing yet another state variable. Regards, Hans Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Cc: Hans Verkuil hverk...@xs4all.nl --- drivers/media/v4l2-core/videobuf2-core.c |5 +++-- include/media/videobuf2-core.h |4 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 7e6aff6..202e2a5 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -1174,7 +1174,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum vb2_buffer_state state) if (WARN_ON(vb-state != VB2_BUF_STATE_ACTIVE)) return; - if (!q-start_streaming_called) { + if (q-done_buffers_queued_state) { if (WARN_ON(state != VB2_BUF_STATE_QUEUED)) state = VB2_BUF_STATE_QUEUED; } else if (WARN_ON(state != VB2_BUF_STATE_DONE @@ -1742,9 +1742,10 @@ static int vb2_start_streaming(struct vb2_queue *q) __enqueue_in_driver(vb); /* Tell the driver to start streaming */ - q-start_streaming_called = 1; + q-done_buffers_queued_state = q-start_streaming_called = 1; ret = call_qop(q, start_streaming, q, atomic_read(q-owned_by_drv_count)); + q-done_buffers_queued_state = 0; if (!ret) return 0; diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index 5a10d8d..7c0dac6 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -380,6 +380,9 @@ struct v4l2_fh; * @streaming: current streaming state * @start_streaming_called: start_streaming() was called successfully and we * started streaming. + * @done_buffers_queued_state: buffers returned to videobuf2 must go + * to VB2_BUF_STATE_QUEUED state. This is the case whilst + * the driver's start_streaming op is called. * @error: a fatal error occurred on the queue * @fileio: file io emulator internal data, used only if emulator is active * @threadio:thread io internal data, used only if thread is active @@ -418,6 +421,7 @@ struct vb2_queue { unsigned intstreaming:1; unsigned intstart_streaming_called:1; + unsigned intdone_buffers_queued_state:1; unsigned interror:1; struct vb2_fileio_data *fileio; -- 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/3] vb2: Buffers returned to videobuf2 from start_streaming in QUEUED state
Hi Hans, On Fri, Sep 19, 2014 at 10:13:57AM +0200, Hans Verkuil wrote: On 09/18/2014 11:57 PM, Sakari Ailus wrote: Patch [media] v4l: vb2: Fix stream start and buffer completion race has a sets q-start_streaming_called before calling queue op start_streaming() in order to fix a bug. This has the side effect that buffers returned to videobuf2 in VB2_BUF_STATE_QUEUED will cause a WARN_ON() to be called. Add a new field called done_buffers_queued_state to struct vb2_queue, which must be set if the new state of buffers returned to videobuf2 must be VB2_BUF_STATE_QUEUED, i.e. buffers returned in start_streaming op. I posted a fix for this over a month ago: https://www.mail-archive.com/linux-media@vger.kernel.org/msg77871.html Unfortunately, the pull request with that patch (https://patchwork.linuxtv.org/patch/25162/) fell through the cracks as I discovered yesterday. Hopefully Mauro will pick up that pull request quickly. I prefer my patch since that avoids introducing yet another state variable. Using less state variables is good, but with your patch returning buffers back to videobuf2 to state VB2_BUF_STATE_QUEUED is possible also after start_stream() has finished. That's probably a lesser problem, though. I'm fine with your patch as well. -- Cheers, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: coda-bit: Include linux/slab.h
From: Fabio Estevam fabio.este...@freescale.com coda-bit uses kmalloc/kfree functions, so the slab header needs to be included in order to fix the following build errors: drivers/media/platform/coda/coda-bit.c: In function 'coda_fill_bitstream': drivers/media/platform/coda/coda-bit.c:231:4: error: implicit declaration of function 'kmalloc' [-Werror=implicit-function-declaration] drivers/media/platform/coda/coda-bit.c: In function 'coda_alloc_framebuffers': drivers/media/platform/coda/coda-bit.c:312:3: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration] Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- drivers/media/platform/coda/coda-bit.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/coda/coda-bit.c b/drivers/media/platform/coda/coda-bit.c index 07fc91a..9b8ea8b 100644 --- a/drivers/media/platform/coda/coda-bit.c +++ b/drivers/media/platform/coda/coda-bit.c @@ -17,6 +17,7 @@ #include linux/kernel.h #include linux/platform_device.h #include linux/reset.h +#include linux/slab.h #include linux/videodev2.h #include media/v4l2-common.h -- 1.9.1 -- 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] [media] coda: coda-bit: Include linux/slab.h
Am Freitag, den 19.09.2014, 08:32 -0300 schrieb Fabio Estevam: From: Fabio Estevam fabio.este...@freescale.com coda-bit uses kmalloc/kfree functions, so the slab header needs to be included in order to fix the following build errors: drivers/media/platform/coda/coda-bit.c: In function 'coda_fill_bitstream': drivers/media/platform/coda/coda-bit.c:231:4: error: implicit declaration of function 'kmalloc' [-Werror=implicit-function-declaration] drivers/media/platform/coda/coda-bit.c: In function 'coda_alloc_framebuffers': drivers/media/platform/coda/coda-bit.c:312:3: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration] Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- drivers/media/platform/coda/coda-bit.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/coda/coda-bit.c b/drivers/media/platform/coda/coda-bit.c index 07fc91a..9b8ea8b 100644 --- a/drivers/media/platform/coda/coda-bit.c +++ b/drivers/media/platform/coda/coda-bit.c @@ -17,6 +17,7 @@ #include linux/kernel.h #include linux/platform_device.h #include linux/reset.h +#include linux/slab.h #include linux/videodev2.h #include media/v4l2-common.h Acked-by: Philipp Zabel p.za...@pengutronix.de thanks 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
[PATCH 1/2] em28xx: Get rid of some unused modprobe parameters at vbi code
There are two modprobe parameters for VBI that aren't used anywhere (one for debug, the other one related to the buffer size). Get rid of them! Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/drivers/media/usb/em28xx/em28xx-vbi.c b/drivers/media/usb/em28xx/em28xx-vbi.c index 6d7f657f6f55..34ee1e03a732 100644 --- a/drivers/media/usb/em28xx/em28xx-vbi.c +++ b/drivers/media/usb/em28xx/em28xx-vbi.c @@ -29,17 +29,6 @@ #include em28xx.h #include em28xx-v4l.h -static unsigned int vbibufs = 5; -module_param(vbibufs, int, 0644); -MODULE_PARM_DESC(vbibufs, number of vbi buffers, range 2-32); - -static unsigned int vbi_debug; -module_param(vbi_debug, int, 0644); -MODULE_PARM_DESC(vbi_debug, enable debug messages [vbi]); - -#define dprintk(level, fmt, arg...)if (vbi_debug = level) \ - printk(KERN_DEBUG %s: fmt, dev-core-name , ## arg) - /* -- */ static int vbi_queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt, -- 1.9.3 -- 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] em28xx: fix VBI handling logic
When both VBI and video are streaming, and video stream is stopped, a subsequent trial to restart it will fail, because S_FMT will return -EBUSY. That prevents applications like zvbi to work properly. Please notice that, while this fix it fully for zvbi, the best is to get rid of streaming_users and res_get logic as a hole. However, this single-line patch is better to be merged at -stable. Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/drivers/media/usb/em28xx/em28xx-video.c b/drivers/media/usb/em28xx/em28xx-video.c index 08569cbccd95..d75e7f82dfb9 100644 --- a/drivers/media/usb/em28xx/em28xx-video.c +++ b/drivers/media/usb/em28xx/em28xx-video.c @@ -1351,7 +1351,7 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void *priv, struct em28xx *dev = video_drvdata(file); struct em28xx_v4l2 *v4l2 = dev-v4l2; - if (v4l2-streaming_users 0) + if (vb2_is_busy(v4l2-vb_vidq)) return -EBUSY; vidioc_try_fmt_vid_cap(file, priv, f); -- 1.9.3 -- 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
[RFC PATCH] vb2: yet another attempt to fix the vb2/VBI/poll regression
After a long discussion on irc the decision was taken that poll() should: - return POLLERR when not streaming or when q-error is set - return POLLERR when streaming from a capture queue, but no buffers have been queued yet, and it is not part of an M2M device. The first rule is logical, the second less so. It emulates vb1 behavior that some applications might rely on. It is behavior that we don't want for output devices or M2M devices because calling STREAMON without QBUF makes a lot of sense for output devices, and for M2M devices I want to avoid causing a regression by potentially changing the behavior of M2M capture queues. We don't have legacy apps to support there, so let's make sure that those queue types remain unchanged. I do that by setting needs_buffers to false in v4l2_m2m_streamon. All M2M drivers use that function with the exception of s5p-mfc, but there STREAMON will return an error if not enough buffers are queued so it's not able to do STREAMON without a QBUF anyway. There will be a second version, since I need to update some comments in the header and adjust the spec, but I would like to get code reviews as soon as possible. Just explaining that second rule makes my head hurt, which is usually a bad sign. Hans Signed-off-by: Hans Verkuil hans.verk...@cisco.com diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c b/drivers/media/v4l2-core/v4l2-mem2mem.c index 80c588f..c8d2b5b 100644 --- a/drivers/media/v4l2-core/v4l2-mem2mem.c +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c @@ -463,6 +463,7 @@ int v4l2_m2m_streamon(struct file *file, struct v4l2_m2m_ctx *m2m_ctx, int ret; vq = v4l2_m2m_get_vq(m2m_ctx, type); + vq-needs_buffers = false; ret = vb2_streamon(vq, type); if (!ret) v4l2_m2m_try_schedule(m2m_ctx); diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 7e6aff6..efbf1ce 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -977,6 +977,7 @@ static int __reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req) * to the userspace. */ req-count = allocated_buffers; + q-needs_buffers = !V4L2_TYPE_IS_OUTPUT(q-type); return 0; } @@ -1801,6 +1802,7 @@ static int vb2_internal_qbuf(struct vb2_queue *q, struct v4l2_buffer *b) */ list_add_tail(vb-queued_entry, q-queued_list); q-queued_count++; + q-needs_buffers = false; vb-state = VB2_BUF_STATE_QUEUED; if (V4L2_TYPE_IS_OUTPUT(q-type)) { /* @@ -2583,10 +2585,18 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait) } /* -* There is nothing to wait for if no buffer has been queued and the -* queue isn't streaming, or if the error flag is set. +* There is nothing to wait for if the queue isn't streaming, or if the +* error flag is set. */ - if ((list_empty(q-queued_list) !vb2_is_streaming(q)) || q-error) + if (!vb2_is_streaming(q) || q-error) + return res | POLLERR; + /* +* For compatibility with vb1: if QBUF hasn't been called yet, then +* return POLLERR as well. This only affects capture queues, output +* queues will always initialize needs_buffers to false. M2M devices +* also set needs_buffers to false in v4l2_m2m_streamon(). +*/ + if (q-needs_buffers) return res | POLLERR; /* diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index 5a10d8d..1c218b1 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -419,6 +419,7 @@ struct vb2_queue { unsigned intstreaming:1; unsigned intstart_streaming_called:1; unsigned interror:1; + unsigned intneeds_buffers:1; struct vb2_fileio_data *fileio; struct vb2_threadio_data*threadio; -- 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] vb2: yet another attempt to fix the vb2/VBI/poll regression
On 09/19/2014 06:15 PM, Hans Verkuil wrote: After a long discussion on irc the decision was taken that poll() should: - return POLLERR when not streaming or when q-error is set - return POLLERR when streaming from a capture queue, but no buffers have been queued yet, and it is not part of an M2M device. The first rule is logical, the second less so. It emulates vb1 behavior that some applications might rely on. It is behavior that we don't want for output devices or M2M devices because calling STREAMON without QBUF makes a lot of sense for output devices, and for M2M devices I want to avoid causing a regression by potentially changing the behavior of M2M capture queues. We don't have legacy apps to support there, so let's make sure that those queue types remain unchanged. I do that by setting needs_buffers to false in v4l2_m2m_streamon. All M2M drivers use that function with the exception of s5p-mfc, but there STREAMON will return an error if not enough buffers are queued so it's not able to do STREAMON without a QBUF anyway. There will be a second version, since I need to update some comments in the header and adjust the spec, but I would like to get code reviews as soon as possible. Just explaining that second rule makes my head hurt, which is usually a bad sign. Hans Signed-off-by: Hans Verkuil hans.verk...@cisco.com diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c b/drivers/media/v4l2-core/v4l2-mem2mem.c index 80c588f..c8d2b5b 100644 --- a/drivers/media/v4l2-core/v4l2-mem2mem.c +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c @@ -463,6 +463,7 @@ int v4l2_m2m_streamon(struct file *file, struct v4l2_m2m_ctx *m2m_ctx, int ret; vq = v4l2_m2m_get_vq(m2m_ctx, type); + vq-needs_buffers = false; I'm going to drop this. Up to 3.16 all vb2 drivers would return POLLERR if no buffers were queued, so it was standard behavior. That simplifies the patch a bit. Hans ret = vb2_streamon(vq, type); if (!ret) v4l2_m2m_try_schedule(m2m_ctx); diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 7e6aff6..efbf1ce 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -977,6 +977,7 @@ static int __reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req) * to the userspace. */ req-count = allocated_buffers; + q-needs_buffers = !V4L2_TYPE_IS_OUTPUT(q-type); return 0; } @@ -1801,6 +1802,7 @@ static int vb2_internal_qbuf(struct vb2_queue *q, struct v4l2_buffer *b) */ list_add_tail(vb-queued_entry, q-queued_list); q-queued_count++; + q-needs_buffers = false; vb-state = VB2_BUF_STATE_QUEUED; if (V4L2_TYPE_IS_OUTPUT(q-type)) { /* @@ -2583,10 +2585,18 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait) } /* - * There is nothing to wait for if no buffer has been queued and the - * queue isn't streaming, or if the error flag is set. + * There is nothing to wait for if the queue isn't streaming, or if the + * error flag is set. */ - if ((list_empty(q-queued_list) !vb2_is_streaming(q)) || q-error) + if (!vb2_is_streaming(q) || q-error) + return res | POLLERR; + /* + * For compatibility with vb1: if QBUF hasn't been called yet, then + * return POLLERR as well. This only affects capture queues, output + * queues will always initialize needs_buffers to false. M2M devices + * also set needs_buffers to false in v4l2_m2m_streamon(). + */ + if (q-needs_buffers) return res | POLLERR; /* diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index 5a10d8d..1c218b1 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -419,6 +419,7 @@ struct vb2_queue { unsigned intstreaming:1; unsigned intstart_streaming_called:1; unsigned interror:1; + unsigned intneeds_buffers:1; struct vb2_fileio_data *fileio; struct vb2_threadio_data*threadio; -- 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: [media/em28xx] BUG: unable to handle kernel
Hi Fengguang, thank you for reporting this issue. Am 19.09.2014 um 03:41 schrieb Fengguang Wu: Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit a5c075cfd2386a4f3ab4f8ed2830ebee557d4b3f Author: Frank Schaefer fschaefer@googlemail.com AuthorDate: Mon Mar 24 16:33:25 2014 -0300 Commit: Mauro Carvalho Chehab m.che...@samsung.com CommitDate: Fri May 23 13:44:42 2014 -0300 [media] em28xx: move fields wq_trigger and streaming_started from struct em28xx to struct em28xx_audio Both wq_trigger and stream_started are used only to control the em28xx alsa streaming. They don't belong to em28xx common struct. Signed-off-by: Frank Schäfer fschaefer@googlemail.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com This patch affects the em28xx-alsa module (em28xx-audio.c) only. Now take a look at your kernel config: ... # # Webcam, TV (analog/digital) USB devices # CONFIG_VIDEO_EM28XX=y CONFIG_VIDEO_EM28XX_V4L2=y # CONFIG_VIDEO_EM28XX_ALSA is not set CONFIG_VIDEO_EM28XX_DVB=y CONFIG_VIDEO_EM28XX_RC=y ... The em28xx-alsa module is disabled. Attached dmesg for the parent commit, too. It looks like the parent is actually clean, just that the rcu-tortuture tests take too long time. +--+++---+ | | 3319e6f839 | a5c075cfd2 | next-20140917 | +--+++---+ | boot_successes | 0 | 0 | 0 | | boot_failures| 80 | 20 | 11 | | BUG:kernel_boot_hang | 80 | 1 | 1 | | BUG:unable_to_handle_kernel | 0 | 19 | 10 | | Oops | 0 | 19 | 10 | | EIP_is_at_af9005_usb_module_init | 0 | 19 | 10 | | Kernel_panic-not_syncing:Fatal_exception | 0 | 19 | 10 | | backtrace:af9005_usb_module_init | 0 | 19 | 10 | | backtrace:kernel_init_freeable | 0 | 19 | 10 | | backtrace:_usb_module_init | 0 | 19 | 10 | +--+++---+ [8.528015] usbcore: registered new interface driver dvb_usb_ttusb2 [8.529751] usbcore: registered new interface driver dvb_usb_af9005 [8.529751] usbcore: registered new interface driver dvb_usb_af9005 [8.531584] BUG: unable to handle kernel [8.531584] BUG: unable to handle kernel paging requestpaging request at 02e0 at 02e0 [8.533385] IP: [8.533385] IP: [7d9d67c6] af9005_usb_module_init+0x6b/0x9d [7d9d67c6] af9005_usb_module_init+0x6b/0x9d And this tells us what is going wrong: (gdb) list *(af9005_usb_module_init+0x83) 0x2d11 is in af9005_usb_module_init (drivers/media/usb/dvb-usb/af9005.c:1092). 1087if (rc_decode == NULL || rc_keys == NULL || rc_keys_size == NULL) { 1088err(af9005_rc_decode function not found, disabling remote); 1089af9005_properties.rc.legacy.rc_query = NULL; 1090} else { 1091af9005_properties.rc.legacy.rc_map_table = rc_keys; 1092af9005_properties.rc.legacy.rc_map_size = *rc_keys_size; 1093} 1094 1095return 0; 1096} So it happens in line 1092 when rc_keys_size is accessed. According to your kernel config you have CONFIG_MODULES disabled CONFIG_DVB_USB_AF9005 enabled CONFIG_DVB_USB_AF9005_REMOTE disabled So af9005 is compiled in without remote control support. Thus we should have hit the if-path, which also prints a message about the missing remote control support. Instead, we have hit the else path, which means that rc_decode, rc_keys and rc_keys_size are all != NULL, although they should be NULL. You can verify this by enabling CONFIG_DVB_USB_AF9005_REMOTE. That makes the issue disappear. Now let's go a few lines up to see where these pointers come from: 1084 rc_decode = symbol_request(af9005_rc_decode); 1085 rc_keys = symbol_request(rc_map_af9005_table); 1086 rc_keys_size = symbol_request(rc_map_af9005_table_size); So symbol_request() returns pointers.!= NULL A closer look at the definition of symbol_request() shows, that it does nothing if CONFIG_MODULES is disabled (it just returns its argument). One possibility to fix this bug would be to embrace these three lines with #ifdef CONFIG_DVB_USB_AF9005_REMOTE ... #endif
[media/dvb_usb_af9005] BUG: unable to handle kernel paging request (WAS: [media/em28xx] BUG: unable to handle kernel)
(adjusting the title and adding Luca Olivetti (dvb_usb_af9005 author) and Antti Palosaari) Am 19.09.2014 um 21:01 schrieb Frank Schäfer: Hi Fengguang, thank you for reporting this issue. Am 19.09.2014 um 03:41 schrieb Fengguang Wu: [...] [8.528015] usbcore: registered new interface driver dvb_usb_ttusb2 [8.529751] usbcore: registered new interface driver dvb_usb_af9005 [8.529751] usbcore: registered new interface driver dvb_usb_af9005 [8.531584] BUG: unable to handle kernel [8.531584] BUG: unable to handle kernel paging requestpaging request at 02e0 at 02e0 [8.533385] IP: [8.533385] IP: [7d9d67c6] af9005_usb_module_init+0x6b/0x9d [7d9d67c6] af9005_usb_module_init+0x6b/0x9d And this tells us what is going wrong: (gdb) list *(af9005_usb_module_init+0x83) 0x2d11 is in af9005_usb_module_init (drivers/media/usb/dvb-usb/af9005.c:1092). 1087if (rc_decode == NULL || rc_keys == NULL || rc_keys_size == NULL) { 1088err(af9005_rc_decode function not found, disabling remote); 1089af9005_properties.rc.legacy.rc_query = NULL; 1090} else { 1091af9005_properties.rc.legacy.rc_map_table = rc_keys; 1092af9005_properties.rc.legacy.rc_map_size = *rc_keys_size; 1093} 1094 1095return 0; 1096} So it happens in line 1092 when rc_keys_size is accessed. According to your kernel config you have CONFIG_MODULES disabled CONFIG_DVB_USB_AF9005 enabled CONFIG_DVB_USB_AF9005_REMOTE disabled So af9005 is compiled in without remote control support. Thus we should have hit the if-path, which also prints a message about the missing remote control support. Instead, we have hit the else path, which means that rc_decode, rc_keys and rc_keys_size are all != NULL, although they should be NULL. You can verify this by enabling CONFIG_DVB_USB_AF9005_REMOTE. That makes the issue disappear. Now let's go a few lines up to see where these pointers come from: 1084 rc_decode = symbol_request(af9005_rc_decode); 1085 rc_keys = symbol_request(rc_map_af9005_table); 1086 rc_keys_size = symbol_request(rc_map_af9005_table_size); So symbol_request() returns pointers.!= NULL A closer look at the definition of symbol_request() shows, that it does nothing if CONFIG_MODULES is disabled (it just returns its argument). One possibility to fix this bug would be to embrace these three lines with #ifdef CONFIG_DVB_USB_AF9005_REMOTE ... #endif Luca, what do you think ? This seems to be an ancient bug, which is known at least since 5 1/2 years: https://lkml.org/lkml/2009/2/4/350 Regards, Frank Schäfer [8.535613] *pde = [8.535613] *pde = [8.536416] Oops: [#1] [8.536416] Oops: [#1] PREEMPT PREEMPT DEBUG_PAGEALLOCDEBUG_PAGEALLOC [8.537863] CPU: 0 PID: 1 Comm: swapper Not tainted 3.15.0-rc6-00151-ga5c075c #1 [8.537863] CPU: 0 PID: 1 Comm: swapper Not tainted 3.15.0-rc6-00151-ga5c075c #1 [8.539827] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [8.539827] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [8.541519] task: 89c9a670 ti: 89c9c000 task.ti: 89c9c000 [8.541519] task: 89c9a670 ti: 89c9c000 task.ti: 89c9c000 [8.541519] EIP: 0060:[7d9d67c6] EFLAGS: 00010206 CPU: 0 [8.541519] EIP: 0060:[7d9d67c6] EFLAGS: 00010206 CPU: 0 [8.541519] EIP is at af9005_usb_module_init+0x6b/0x9d [8.541519] EIP is at af9005_usb_module_init+0x6b/0x9d [8.541519] EAX: 02e0 EBX: ECX: 0006 EDX: [8.541519] EAX: 02e0 EBX: ECX: 0006 EDX: [8.541519] ESI: EDI: 7da33ec8 EBP: 89c9df30 ESP: 89c9df2c [8.541519] ESI: EDI: 7da33ec8 EBP: 89c9df30 ESP: 89c9df2c [8.541519] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 [8.541519] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 [8.541519] CR0: 8005003b CR2: 02e0 CR3: 05a54000 CR4: 0690 [8.541519] CR0: 8005003b CR2: 02e0 CR3: 05a54000 CR4: 0690 [8.541519] Stack: [8.541519] Stack: [8.541519] 7d9d675b [8.541519] 7d9d675b 89c9df90 89c9df90 7d992a49 7d992a49 7d7d5914 7d7d5914 89c9df4c 89c9df4c 7be3a800 7be3a800 7d08c58c 7d08c58c 8a4c3968 8a4c3968 [8.541519] 89c9df80 [8.541519] 89c9df80 7be3a966 7be3a966 0192 0192 0006 0006 0006 0006 7d7d3ff4 7d7d3ff4 8a4c397a 8a4c397a 0200 0200 [8.541519] 7d6b1280 [8.541519] 7d6b1280 8a4c3979 8a4c3979 0006 0006 09a6 09a6 7da32db8 7da32db8 b13eec81 b13eec81 0006 0006 09a6 09a6 [8.541519] Call Trace: [8.541519] Call Trace: [8.541519] [7d9d675b] ? ttusb2_driver_init+0x16/0x16 [8.541519]
Re: [media/dvb_usb_af9005] BUG: unable to handle kernel paging request (WAS: [media/em28xx] BUG: unable to handle kernel)
El 19/09/14 21:22, Frank Schäfer ha escrit: So symbol_request() returns pointers.!= NULL A closer look at the definition of symbol_request() shows, that it does nothing if CONFIG_MODULES is disabled (it just returns its argument). One possibility to fix this bug would be to embrace these three lines with #ifdef CONFIG_DVB_USB_AF9005_REMOTE ... #endif Luca, what do you think ? This seems to be an ancient bug, which is known at least since 5 1/2 years: https://lkml.org/lkml/2009/2/4/350 Well, it's been a while so I don't remember the details, but I think the same now as then ;-) The idea behind CONFIG_DVB_USB_AF9005_REMOTE was to provide an alternative implementation (based on lirc, at the time it wasn't in the kernel), since this adapter doesn't decode the IR pulses by itself. In theory you could leave it undefined but still provide an implementation in a different module. Just adding #ifdef CONFIG_DVB_USB_AF9005_REMOTE would nuke the (futile?) effort. Now, since the problem seems to be with CONFIG_MODULES disabled, maybe you could combine both conditions #if defined(CONFIG_MODULE) || defined(CONFIG_DVB_USB_AF9005_REMOTE) Bye -- Luca -- 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
Fwd: kernel BUG at mm/slub.c on cx23885
Hauppauge HVR-5500 using the latest git build, keeps crashing with the following error: [ 2111.934790] kernel BUG at mm/slub.c:1416! [ 2111.934877] invalid opcode: [#1] PREEMPT SMP [ 2111.934993] Modules linked in: ftdi_sio usbserial xt_recent si2165(O) a8293(O) tda10071(O) tea5767(O) tuner(O) cx23885(OF) eeepc_wmi asus_wmi sparse_keymap led_class rfkill video kvm_amd kvm nls_iso8859_1 altera_ci(O) ext4 tda18271(O) microcode crc16 mbcache altera_stapl videobuf2_dvb(O) serio_raw videobuf2_dma_sg(O) jbd2 psmouse tveeprom(O) pcspkr cx2341x(O) k10temp evdev dvb_core(O) ip6t_REJECT mac_hid r8169 rc_core(O) mii videobuf2_memops(O) videobuf2_core(O) v4l2_common(O) xt_hl ip6t_rt radeon videodev(O) media(O) nf_conntrack_ipv6 nf_defrag_ipv6 snd_hda_codec_via snd_hda_codec_generic i2c_algo_bit snd_hda_intel ttm ipt_REJECT snd_hda_controller drm_kms_helper xt_LOG snd_hda_codec drm xt_limit snd_hwdep xt_tcpudp snd_pcm wmi sp5100_tco xt_addrtype snd_timer i2c_piix4 acpi_cpufreq snd hwmon button [ 2111.936816] i2c_core shpchp soundcore processor nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack ip6table_filter ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables crc32c_generic btrfs xor raid6_pq xts gf128mul algif_skcipher af_alg dm_crypt dm_mod hid_generic usbhid hid sd_mod crct10dif_generic crc_t10dif crct10dif_common atkbd libps2 ahci libahci libata ohci_pci ohci_hcd ehci_pci ehci_hcd usbcore scsi_mod usb_common i8042 serio vfat fat nls_cp437 [ 2111.938018] CPU: 1 PID: 2404 Comm: tvheadend Tainted: GF O 3.16.3-1-ARCH #1 [ 2111.938174] Hardware name: System manufacturer System Product Name/C60M1-I, BIOS 0305 08/07/2012 [ 2111.938350] task: 88009fff3d20 ti: 880229768000 task.ti: 880229768000 [ 2111.938499] RIP: 0010:[811a3120] [811a3120] new_slab+0x2e0/0x330 [ 2111.938673] RSP: 0018:88022976b928 EFLAGS: 00010002 [ 2111.938782] RAX: 88009fff3d20 RBX: 0001 RCX: 88022976b9d0 [ 2111.938924] RDX: RSI: 0004 RDI: 880236801c00 [ 2111.939065] RBP: 88022976ba48 R08: R09: 0004 [ 2111.939206] R10: 88022c7e41b0 R11: R12: 880236800f40 [ 2111.939346] R13: 0004 R14: 880236801c00 R15: 88023eff9c38 [ 2111.939489] FS: 7fa986c47780() GS:88023ed0() knlGS: [ 2111.939649] CS: 0010 DS: ES: CR0: 80050033 [ 2111.939765] CR2: 7f123d2bd4a0 CR3: 0002294d8000 CR4: 07e0 [ 2111.939905] Stack: [ 2111.939951] 811a56a4 88023ed17380 88009fff3d20 [ 2111.940123] 1c00 88009fff3d20 88023ed17390 [ 2111.940293] 0001 8802 812b2469 [ 2111.940463] Call Trace: [ 2111.940527] [811a56a4] ? __slab_alloc.isra.53+0x4f4/0x5e0 [ 2111.940664] [812b2469] ? sg_kmalloc+0x19/0x30 [ 2111.940779] [811558a0] ? __alloc_pages_nodemask+0x180/0xc20 [ 2111.940916] [811a5f93] __kmalloc+0x163/0x1c0 [ 2111.941028] [812b2469] ? sg_kmalloc+0x19/0x30 [ 2111.941142] [812b2469] sg_kmalloc+0x19/0x30 [ 2111.941252] [812b2330] __sg_alloc_table+0x70/0x160 [ 2111.941372] [812b2450] ? sg_kfree+0x30/0x30 [ 2111.941484] [812b277f] sg_alloc_table+0x1f/0x60 [ 2111.941600] [812b2844] sg_alloc_table_from_pages+0x84/0x1c0 [ 2111.941744] [a068e751] vb2_dma_sg_alloc+0x161/0xa10 [videobuf2_dma_sg] [ 2111.941906] [a06a] __vb2_queue_alloc+0x10a/0x600 [videobuf2_core] [ 2111.942065] [a06364eb] __reqbufs.isra.13+0x1ab/0x3f0 [videobuf2_core] [ 2111.942221] [a06f3200] ? vb2_dvb_start_feed+0xc0/0xc0 [videobuf2_dvb] [ 2111.942379] [a06372a7] __vb2_init_fileio+0xc7/0x370 [videobuf2_core] [ 2111.948071] [a06f3200] ? vb2_dvb_start_feed+0xc0/0xc0 [videobuf2_dvb] [ 2111.953792] [a0638ffe] vb2_thread_start+0xae/0x10b0 [videobuf2_core] [ 2111.959554] [a06f31c8] vb2_dvb_start_feed+0x88/0xc0 [videobuf2_dvb] [ 2111.965285] [a0673b82] dmx_section_feed_start_filtering+0xe2/0x190 [dvb_core] [ 2111.971032] [a0670eee] dvb_dmxdev_filter_start+0x20e/0x3d0 [dvb_core] [ 2111.976802] [a0671a20] dvb_demux_do_ioctl+0x4e0/0x640 [dvb_core] [ 2111.982414] [a066f985] dvb_usercopy+0x115/0x190 [dvb_core] [ 2111.987846] [a0671540] ? dvb_dmxdev_ts_callback+0xf0/0xf0 [dvb_core] [ 2111.993136] [810b65c4] ? add_wait_queue+0x44/0x50 [ 2111.998236] [81206a80] ? ep_ptable_queue_proc+0x60/0xa0 [ 2112.003169] [a066fe35] dvb_demux_ioctl+0x15/0x20 [dvb_core] [ 2112.007948] [811d4af0] do_vfs_ioctl+0x2d0/0x4b0 [ 2112.012531] [811df22e] ? __fget+0x6e/0xb0 [ 2112.016918] [811d4d51] SyS_ioctl+0x81/0xa0 [ 2112.021107] [81531129]
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Sep 20 04:00:27 CEST 2014 git branch: test git hash: f5281fc81e9a0a3e80b78720c5ae2ed06da3bfae gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-20-g7abd8a7 host hardware: x86_64 host os:3.16-2.slh.3-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: WARNINGS linux-3.12.23-i686: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16-i686: WARNINGS linux-3.17-rc1-i686: WARNINGS linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: WARNINGS linux-3.12.23-x86_64: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16-x86_64: WARNINGS linux-3.17-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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: USB: usbtv: Fixed all coding style issues in usbtv source files.
Fixed various coding styles, ignoring coding style error on line 5 for all files containing a link that is longer than 80 characters long. Signed-off-by: Amber Thrall amber.rose.thr...@gmail.com --- drivers/media/usb/usbtv/usbtv-audio.c | 1 + drivers/media/usb/usbtv/usbtv-core.c | 1 + drivers/media/usb/usbtv/usbtv-video.c | 3 +++ 3 files changed, 5 insertions(+) diff --git a/drivers/media/usb/usbtv/usbtv-audio.c b/drivers/media/usb/usbtv/usbtv-audio.c index 2d8795f..78c12d2 100644 --- a/drivers/media/usb/usbtv/usbtv-audio.c +++ b/drivers/media/usb/usbtv/usbtv-audio.c @@ -311,6 +311,7 @@ static int snd_usbtv_card_trigger(struct snd_pcm_substream *substream, int cmd) static snd_pcm_uframes_t snd_usbtv_pointer(struct snd_pcm_substream *substream) { struct usbtv *chip = snd_pcm_substream_chip(substream); + return chip-snd_buffer_pos; } diff --git a/drivers/media/usb/usbtv/usbtv-core.c b/drivers/media/usb/usbtv/usbtv-core.c index bf25ecf..29428be 100644 --- a/drivers/media/usb/usbtv/usbtv-core.c +++ b/drivers/media/usb/usbtv/usbtv-core.c @@ -108,6 +108,7 @@ usbtv_video_fail: static void usbtv_disconnect(struct usb_interface *intf) { struct usbtv *usbtv = usb_get_intfdata(intf); + usb_set_intfdata(intf, NULL); if (!usbtv) diff --git a/drivers/media/usb/usbtv/usbtv-video.c b/drivers/media/usb/usbtv/usbtv-video.c index 3d6ed1f..9d3525f 100644 --- a/drivers/media/usb/usbtv/usbtv-video.c +++ b/drivers/media/usb/usbtv/usbtv-video.c @@ -263,6 +263,7 @@ static void usbtv_chunk_to_vbuf(u32 *frame, __be32 *src, int chunk_no, int odd) int part_index = (line * 2 + !odd) * 3 + (part_no % 3); u32 *dst = frame[part_index * USBTV_CHUNK/2]; + memcpy(dst, src, USBTV_CHUNK/2 * sizeof(*src)); src += USBTV_CHUNK/2; } @@ -407,6 +408,7 @@ static void usbtv_stop(struct usbtv *usbtv) /* Cancel running transfers. */ for (i = 0; i USBTV_ISOC_TRANSFERS; i++) { struct urb *ip = usbtv-isoc_urbs[i]; + if (ip == NULL) continue; usb_kill_urb(ip); @@ -560,6 +562,7 @@ static int usbtv_g_input(struct file *file, void *priv, unsigned int *i) static int usbtv_s_input(struct file *file, void *priv, unsigned int i) { struct usbtv *usbtv = video_drvdata(file); + return usbtv_select_input(usbtv, i); } -- 2.1.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