Re: [v2,35/35,media] omap: be sure that MMU is there for COMPILE_TEST

2014-09-19 Thread Paul Bolle
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

2014-09-19 Thread Sakari Ailus
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'

2014-09-19 Thread kbuild test robot
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

2014-09-19 Thread Hans Verkuil
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

2014-09-19 Thread Sakari Ailus
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

2014-09-19 Thread 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
-- 
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

2014-09-19 Thread Philipp Zabel
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

2014-09-19 Thread Mauro Carvalho Chehab
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

2014-09-19 Thread Mauro Carvalho Chehab
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

2014-09-19 Thread Hans Verkuil
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

2014-09-19 Thread Hans Verkuil
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

2014-09-19 Thread Frank Schäfer
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)

2014-09-19 Thread Frank Schäfer
(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)

2014-09-19 Thread Luca Olivetti
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

2014-09-19 Thread beta992
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

2014-09-19 Thread Hans Verkuil
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.

2014-09-19 Thread Amber Thrall
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