cron job: media_tree daily build: WARNINGS

2016-04-22 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 Apr 23 04:00:24 CEST 2016
git branch: test
git hash:   e07d46e7e0da86c146f199dae76f879096bc436a
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3413-g618cd5c
host hardware:  x86_64
host os:4.4.0-164

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-bf561: 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: 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: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-i686: WARNINGS
linux-4.6-rc1-i686: 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: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-x86_64: WARNINGS
linux-4.6-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

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


Re: [PATCHv3 08/12] media/platform: convert drivers to use the new vb2_queue dev field

2016-04-22 Thread Laurent Pinchart
Hi Hans,

Thank you for the patch.

On Friday 22 Apr 2016 10:38:15 Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Stop using alloc_ctx and just fill in the device pointer.
> 
> Signed-off-by: Hans Verkuil 
> Cc: Laurent Pinchart 
> Cc: Mikhail Ulyanov 
> Cc: Guennadi Liakhovetski 
> Cc: Javier Martin 
> Cc: Jonathan Corbet 
> ---
>  drivers/media/platform/m2m-deinterlace.c| 15 ++-
>  drivers/media/platform/marvell-ccic/mcam-core.c | 24 +
>  drivers/media/platform/marvell-ccic/mcam-core.h |  2 --
>  drivers/media/platform/mx2_emmaprp.c| 17 +++--
>  drivers/media/platform/omap3isp/ispvideo.c  | 12 ++--
>  drivers/media/platform/omap3isp/ispvideo.h  |  1 -
>  drivers/media/platform/rcar_jpu.c   | 22 --
>  drivers/media/platform/sh_veu.c | 17 +++--
>  drivers/media/platform/sh_vou.c | 14 ++
>  9 files changed, 17 insertions(+), 107 deletions(-)

For the omap3isp and rcar_jpu drivers, pending a fix for the problem I 
mentioned in a reply to patch 01/12,

Reviewed-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart

--
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: [PATCHv3 07/12] media/platform: convert drivers to use the new vb2_queue dev field

2016-04-22 Thread Laurent Pinchart
Hi Hans,

Thank you for the patch.

On Friday 22 Apr 2016 10:38:14 Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Stop using alloc_ctx and just fill in the device pointer.
> 
> Signed-off-by: Hans Verkuil 
> Cc: Fabien Dessenne 
> Cc: Benoit Parrot 
> Cc: Laurent Pinchart 
> #
> #total: 0 errors, 0 warnings, 10 lines checked
> #
> #Your patch has no obvious style problems and is ready for submission.

This shouldn't be part of the commit message.

(And please see below for two additional comments)

> ---
>  drivers/media/platform/sti/bdisp/bdisp-v4l2.c | 18 --
>  drivers/media/platform/sti/bdisp/bdisp.h  |  2 --
>  drivers/media/platform/ti-vpe/cal.c   | 15 +--
>  drivers/media/platform/ti-vpe/vpe.c   | 20 
>  drivers/media/platform/vsp1/vsp1_video.c  | 18 +++---
>  drivers/media/platform/vsp1/vsp1_video.h  |  1 -
>  drivers/media/platform/xilinx/xilinx-dma.c| 11 +--
>  drivers/media/platform/xilinx/xilinx-dma.h|  2 --
>  8 files changed, 13 insertions(+), 74 deletions(-)
> 
> diff --git a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
> b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c index d12a419..b3e8b5a
> 100644
> --- a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
> +++ b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
> @@ -439,7 +439,7 @@ static void bdisp_ctrls_delete(struct bdisp_ctx *ctx)
> 
>  static int bdisp_queue_setup(struct vb2_queue *vq,
>unsigned int *nb_buf, unsigned int *nb_planes,
> -  unsigned int sizes[], void *allocators[])
> +  unsigned int sizes[], void *alloc_ctxs[])
>  {
>   struct bdisp_ctx *ctx = vb2_get_drv_priv(vq);
>   struct bdisp_frame *frame = ctx_get_frame(ctx, vq->type);
> @@ -453,7 +453,6 @@ static int bdisp_queue_setup(struct vb2_queue *vq,
>   dev_err(ctx->bdisp_dev->dev, "Invalid format\n");
>   return -EINVAL;
>   }
> - allocators[0] = ctx->bdisp_dev->alloc_ctx;
> 
>   if (*nb_planes)
>   return sizes[0] < frame->sizeimage ? -EINVAL : 0;
> @@ -553,6 +552,7 @@ static int queue_init(void *priv,
>   src_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
>   src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
>   src_vq->lock = &ctx->bdisp_dev->lock;
> + src_vq->dev = ctx->bdisp_dev->v4l2_dev.dev;
> 
>   ret = vb2_queue_init(src_vq);
>   if (ret)
> @@ -567,6 +567,7 @@ static int queue_init(void *priv,
>   dst_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
>   dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
>   dst_vq->lock = &ctx->bdisp_dev->lock;
> + dst_vq->dev = ctx->bdisp_dev->v4l2_dev.dev;
> 
>   return vb2_queue_init(dst_vq);
>  }
> @@ -1269,8 +1270,6 @@ static int bdisp_remove(struct platform_device *pdev)
> 
>   bdisp_hw_free_filters(bdisp->dev);
> 
> - vb2_dma_contig_cleanup_ctx(bdisp->alloc_ctx);
> -
>   pm_runtime_disable(&pdev->dev);
> 
>   bdisp_debugfs_remove(bdisp);
> @@ -1371,18 +1370,11 @@ static int bdisp_probe(struct platform_device *pdev)
> goto err_dbg;
>   }
> 
> - /* Continuous memory allocator */
> - bdisp->alloc_ctx = vb2_dma_contig_init_ctx(dev);
> - if (IS_ERR(bdisp->alloc_ctx)) {
> - ret = PTR_ERR(bdisp->alloc_ctx);
> - goto err_pm;
> - }
> -
>   /* Filters */
>   if (bdisp_hw_alloc_filters(bdisp->dev)) {
>   dev_err(bdisp->dev, "no memory for filters\n");
>   ret = -ENOMEM;
> - goto err_vb2_dma;
> + goto err_pm;
>   }
> 
>   /* Register */
> @@ -1401,8 +1393,6 @@ static int bdisp_probe(struct platform_device *pdev)
> 
>  err_filter:
>   bdisp_hw_free_filters(bdisp->dev);
> -err_vb2_dma:
> - vb2_dma_contig_cleanup_ctx(bdisp->alloc_ctx);
>  err_pm:
>   pm_runtime_put(dev);
>  err_dbg:
> diff --git a/drivers/media/platform/sti/bdisp/bdisp.h
> b/drivers/media/platform/sti/bdisp/bdisp.h index 0cf9857..b3fbf99 100644
> --- a/drivers/media/platform/sti/bdisp/bdisp.h
> +++ b/drivers/media/platform/sti/bdisp/bdisp.h
> @@ -175,7 +175,6 @@ struct bdisp_dbg {
>   * @id: device index
>   * @m2m:memory-to-memory V4L2 device information
>   * @state:  flags used to synchronize m2m and capture mode operation
> - * @alloc_ctx:  videobuf2 memory allocator context
>   * @clock:  IP clock
>   * @regs:   registers
>   * @irq_queue:  interrupt handler waitqueue
> @@ -193,7 +192,6 @@ struct bdisp_dev {
>   u16 id;
>   struct bdisp_m2m_device m2m;
>   unsigned long   state;
> - struct vb2_alloc_ctx*alloc_ctx;
>   struct clk  *clock;
>   void __iomem*regs;
>   wait_queue_head_t   irq_queue;
> diff --git a/drivers/media/platform/ti-vpe/cal.c
> b/drivers/media/platform/ti-vpe/cal.c index 82001e6..51ebf32 100644
> --- a/driver

Re: [PATCHv3 05/12] staging/media: convert drivers to use the new vb2_queue dev field

2016-04-22 Thread Laurent Pinchart
Hi Hans,

Thank you for the patch.

On Friday 22 Apr 2016 10:38:12 Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Stop using alloc_ctx and just fill in the device pointer.
> 
> Signed-off-by: Hans Verkuil 
> Cc: "Lad, Prabhakar" 
> Cc: Laurent Pinchart 

Pending a fix for the problem I mentioned in a reply to patch 01/12,

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/staging/media/davinci_vpfe/vpfe_video.c | 10 +-
>  drivers/staging/media/davinci_vpfe/vpfe_video.h |  2 --
>  drivers/staging/media/omap4iss/iss_video.c  | 10 +-
>  drivers/staging/media/omap4iss/iss_video.h  |  1 -
>  4 files changed, 2 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> b/drivers/staging/media/davinci_vpfe/vpfe_video.c index ea3ddec..77e66e7
> 100644
> --- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> +++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
> @@ -542,7 +542,6 @@ static int vpfe_release(struct file *file)
>   video->io_usrs = 0;
>   /* Free buffers allocated */
>   vb2_queue_release(&video->buffer_queue);
> - vb2_dma_contig_cleanup_ctx(video->alloc_ctx);
>   }
>   /* Decrement device users counter */
>   video->usrs--;
> @@ -1115,7 +1114,6 @@ vpfe_buffer_queue_setup(struct vb2_queue *vq,
> 
>   *nplanes = 1;
>   sizes[0] = size;
> - alloc_ctxs[0] = video->alloc_ctx;
>   v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev,
>"nbuffers=%d, size=%lu\n", *nbuffers, size);
>   return 0;
> @@ -1350,12 +1348,6 @@ static int vpfe_reqbufs(struct file *file, void
> *priv, video->memory = req_buf->memory;
> 
>   /* Initialize videobuf2 queue as per the buffer type */
> - video->alloc_ctx = vb2_dma_contig_init_ctx(vpfe_dev->pdev);
> - if (IS_ERR(video->alloc_ctx)) {
> - v4l2_err(&vpfe_dev->v4l2_dev, "Failed to get the context\n");
> - return PTR_ERR(video->alloc_ctx);
> - }
> -
>   q = &video->buffer_queue;
>   q->type = req_buf->type;
>   q->io_modes = VB2_MMAP | VB2_USERPTR;
> @@ -1365,11 +1357,11 @@ static int vpfe_reqbufs(struct file *file, void
> *priv, q->mem_ops = &vb2_dma_contig_memops;
>   q->buf_struct_size = sizeof(struct vpfe_cap_buffer);
>   q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> + q->dev = vpfe_dev->pdev;
> 
>   ret = vb2_queue_init(q);
>   if (ret) {
>   v4l2_err(&vpfe_dev->v4l2_dev, "vb2_queue_init() failed\n");
> - vb2_dma_contig_cleanup_ctx(vpfe_dev->pdev);
>   return ret;
>   }
> 
> diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.h
> b/drivers/staging/media/davinci_vpfe/vpfe_video.h index 653334d..aaec440
> 100644
> --- a/drivers/staging/media/davinci_vpfe/vpfe_video.h
> +++ b/drivers/staging/media/davinci_vpfe/vpfe_video.h
> @@ -123,8 +123,6 @@ struct vpfe_video_device {
>   /* Used to store pixel format */
>   struct v4l2_format  fmt;
>   struct vb2_queuebuffer_queue;
> - /* allocator-specific contexts for each plane */
> - struct vb2_alloc_ctx *alloc_ctx;
>   /* Queue of filled frames */
>   struct list_headdma_queue;
>   spinlock_t  irqlock;
> diff --git a/drivers/staging/media/omap4iss/iss_video.c
> b/drivers/staging/media/omap4iss/iss_video.c index cf8da23..3c077e3 100644
> --- a/drivers/staging/media/omap4iss/iss_video.c
> +++ b/drivers/staging/media/omap4iss/iss_video.c
> @@ -310,8 +310,6 @@ static int iss_video_queue_setup(struct vb2_queue *vq,
>   if (sizes[0] == 0)
>   return -EINVAL;
> 
> - alloc_ctxs[0] = video->alloc_ctx;
> -
>   *count = min(*count, video->capture_mem / PAGE_ALIGN(sizes[0]));
> 
>   return 0;
> @@ -1017,13 +1015,6 @@ static int iss_video_open(struct file *file)
>   goto done;
>   }
> 
> - video->alloc_ctx = vb2_dma_contig_init_ctx(video->iss->dev);
> - if (IS_ERR(video->alloc_ctx)) {
> - ret = PTR_ERR(video->alloc_ctx);
> - omap4iss_put(video->iss);
> - goto done;
> - }
> -
>   q = &handle->queue;
> 
>   q->type = video->type;
> @@ -1033,6 +1024,7 @@ static int iss_video_open(struct file *file)
>   q->mem_ops = &vb2_dma_contig_memops;
>   q->buf_struct_size = sizeof(struct iss_buffer);
>   q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> + q->dev = video->iss->dev;
> 
>   ret = vb2_queue_init(q);
>   if (ret) {
> diff --git a/drivers/staging/media/omap4iss/iss_video.h
> b/drivers/staging/media/omap4iss/iss_video.h index c8bd295..d7e05d0 100644
> --- a/drivers/staging/media/omap4iss/iss_video.h
> +++ b/drivers/staging/media/omap4iss/iss_video.h
> @@ -170,7 +170,6 @@ struct iss_video {
>   spinlock_t qlock;   /* protects dmaqueue and error */
>   struct list_head dmaqueue;
>   enum iss_video_dmaqu

Re: [PATCHv3 01/12] vb2: add a dev field to use for the default allocation context

2016-04-22 Thread Laurent Pinchart
Hi Hans,

Thank you for the patch.

On Friday 22 Apr 2016 10:38:08 Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> The allocation context is nothing more than a per-plane device pointer
> to use when allocating buffers. So just provide a dev pointer in vb2_queue
> for that purpose and drivers can skip allocating/releasing/filling in
> the allocation context unless they require different per-plane device
> pointers as used by some Samsung SoCs.
> 
> Signed-off-by: Hans Verkuil 
> Cc: Laurent Pinchart 
> Cc: Sakari Ailus 
> Cc: Mauro Carvalho Chehab 
> Cc: Florian Echtler 
> Cc: Federico Vaga 
> Cc: "Lad, Prabhakar" 
> Cc: Scott Jiang 
> Cc: Philipp Zabel 
> Cc: Fabien Dessenne 
> Cc: Benoit Parrot 
> Cc: Mikhail Ulyanov 
> Cc: Guennadi Liakhovetski 
> Cc: Javier Martin 
> Cc: Jonathan Corbet 
> Cc: Ludovic Desroches 
> Cc: Sergei Shtylyov 
> Cc: Kyungmin Park 
> Cc: Sylwester Nawrocki 
> ---
>  drivers/media/v4l2-core/videobuf2-core.c | 16 +---
>  include/media/videobuf2-core.h   |  3 +++
>  2 files changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> b/drivers/media/v4l2-core/videobuf2-core.c index 5d016f4..88b5e48 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -206,8 +206,9 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
>   for (plane = 0; plane < vb->num_planes; ++plane) {
>   unsigned long size = PAGE_ALIGN(vb->planes[plane].length);
> 
> - mem_priv = call_ptr_memop(vb, alloc, q->alloc_ctx[plane],
> -   size, dma_dir, q->gfp_flags);
> + mem_priv = call_ptr_memop(vb, alloc,
> + q->alloc_ctx[plane] ? : &q->dev,
> + size, dma_dir, q->gfp_flags);

While the videobuf2-dma-sg allocation context indeed only contains a pointer 
to the device, the videobuf2-dma-contig context also contains a dma_attrs. 
This patch will break the videobuf2-dma-contig alloc implementation.

>   if (IS_ERR_OR_NULL(mem_priv))
>   goto free;
> 
> @@ -1131,9 +1132,10 @@ static int __qbuf_userptr(struct vb2_buffer *vb,
> const void *pb) vb->planes[plane].data_offset = 0;
> 
>   /* Acquire each plane's memory */
> - mem_priv = call_ptr_memop(vb, get_userptr, q->alloc_ctx[plane],
> -   planes[plane].m.userptr,
> -   planes[plane].length, dma_dir);
> + mem_priv = call_ptr_memop(vb, get_userptr,
> + q->alloc_ctx[plane] ? : &q->dev,
> + planes[plane].m.userptr,
> + planes[plane].length, dma_dir);
>   if (IS_ERR_OR_NULL(mem_priv)) {
>   dprintk(1, "failed acquiring userspace "
>   "memory for plane %d\n", plane);
> @@ -1256,8 +1258,8 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
> void *pb)
> 
>   /* Acquire each plane's memory */
>   mem_priv = call_ptr_memop(vb, attach_dmabuf,
> - q->alloc_ctx[plane], dbuf, planes[plane].length,
> - dma_dir);
> + q->alloc_ctx[plane] ? : &q->dev,
> + dbuf, planes[plane].length, dma_dir);
>   if (IS_ERR(mem_priv)) {
>   dprintk(1, "failed to attach dmabuf\n");
>   ret = PTR_ERR(mem_priv);
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index 8a0f55b..0f8b97b 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -397,6 +397,8 @@ struct vb2_buf_ops {
>   *   caller. For example, for V4L2, it should match
>   *   the V4L2_BUF_TYPE_* in include/uapi/linux/videodev2.h
>   * @io_modes:supported io methods (see vb2_io_modes enum)
> + * @dev: device to use for the default allocation context if the driver
> + *   doesn't fill in the @alloc_ctx array.
>   * @fileio_read_once:report EOF after reading the first 
> buffer
>   * @fileio_write_immediately:queue buffer after each write() call
>   * @allow_zero_bytesused:allow bytesused == 0 to be passed to the driver
> @@ -460,6 +462,7 @@ struct vb2_buf_ops {
>  struct vb2_queue {
>   unsigned inttype;
>   unsigned intio_modes;
> + struct device   *dev;
>   unsignedfileio_read_once:1;
>   unsignedfileio_write_immediately:1;
>   unsignedallow_zero_bytesused:1;

-- 
Regards,

Laurent Pinchart

--
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/

我的交友主页是

2016-04-22 Thread 我的交友主页是
你的老朋友邀你来Q群:343257759 抢红包 抢秒杀 抢vip 什么都要抢。太刺激了。不靠手气只拼手速


[PATCH] [media] au0828: fix double free in au0828_usb_probe()

2016-04-22 Thread Alexey Khoroshilov
In case of failure au0828_v4l2_device_register() deallocates dev
and returns error code to au0828_usb_probe(), which also
calls kfree(dev) on a failure path.

The patch removes duplicated code from au0828_v4l2_device_register().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/media/usb/au0828/au0828-video.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-video.c 
b/drivers/media/usb/au0828/au0828-video.c
index 32d7db96479c..7d0ec4cb248c 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -679,8 +679,6 @@ int au0828_v4l2_device_register(struct usb_interface 
*interface,
if (retval) {
pr_err("%s() v4l2_device_register failed\n",
   __func__);
-   mutex_unlock(&dev->lock);
-   kfree(dev);
return retval;
}
 
@@ -691,8 +689,6 @@ int au0828_v4l2_device_register(struct usb_interface 
*interface,
if (retval) {
pr_err("%s() v4l2_ctrl_handler_init failed\n",
   __func__);
-   mutex_unlock(&dev->lock);
-   kfree(dev);
return retval;
}
dev->v4l2_dev.ctrl_handler = &dev->v4l2_ctrl_hdl;
-- 
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 6/6] rcar-vin: failed start_streaming didn't call s_stream(0)

2016-04-22 Thread Niklas Söderlund
Hi Hans,

Acked-by: Niklas Söderlund 

On 2016-04-22 15:03:42 +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This can leave adv7180 in an inconsistent state
> 
> Signed-off-by: Hans Verkuil 
> Cc: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index 644ec9b..087c30c 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -1058,8 +1058,10 @@ static int rvin_start_streaming(struct vb2_queue *vq, 
> unsigned int count)
>   ret = rvin_capture_start(vin);
>  out:
>   /* Return all buffers if something went wrong */
> - if (ret)
> + if (ret) {
>   return_all_buffers(vin, VB2_BUF_STATE_QUEUED);
> + v4l2_subdev_call(sd, video, s_stream, 0);
> + }
>  
>   spin_unlock_irqrestore(&vin->qlock, flags);
>  
> -- 
> 2.8.0.rc3
> 

-- 
Regards,
Niklas Söderlund
--
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 3/6] rcar-vin: support the source change event and fix s_std

2016-04-22 Thread Niklas Söderlund
Hi Hans,

Great patch,

On 2016-04-22 15:03:39 +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> The patch adds support for the source change event and it fixes
> the s_std support: changing the standard will also change the
> resolution, and that was never updated.
> 
> Signed-off-by: Hans Verkuil 
> Cc: Niklas Söderlund 
> Cc: Ulrich Hecht 
> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 48 
> +++--
>  1 file changed, 46 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 8ac6149..49058ea 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -421,8 +421,25 @@ static int rvin_s_std(struct file *file, void *priv, 
> v4l2_std_id a)
>  {
>   struct rvin_dev *vin = video_drvdata(file);
>   struct v4l2_subdev *sd = vin_to_sd(vin);
> + struct v4l2_subdev_format fmt = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + };
> + struct v4l2_mbus_framefmt *mf = &fmt.format;
> + int ret = v4l2_subdev_call(sd, video, s_std, a);
> +
> + if (ret < 0)
> + return ret;
>  
> - return v4l2_subdev_call(sd, video, s_std, a);
> + /* Changing the standard will change the width/height */
> + ret = v4l2_subdev_call(sd, pad, get_fmt, NULL, &fmt);
> + if (ret) {
> + vin_err(vin, "Failed to get initial format\n");
> + return ret;
> + }
> +
> + vin->format.width = mf->width;
> + vin->format.height = mf->height;

I think you should reset the vin->crop and vin->compose v4l2_rect to 
match the new size here.

On this note I feel the documentation at 
https://linuxtv.org/downloads/v4l-dvb-apis/selection-api.html are a bit 
unclear. In the section 'Configuration of video capture' one can read:

"Each capture device has a default source rectangle, given by the 
V4L2_SEL_TGT_CROP_DEFAULT target. This rectangle shall over what the 
driver writer considers the complete picture. Drivers shall set the 
active crop rectangle to the default when the driver is first loaded, 
but not later."

For the driver to change this rectangle in s_std is that not in the 'but 
not later' category?

On the same note, should the crop and compose rectangles be reset if the 
user requests a resolution change with vidioc_s_fmt_vid_cap? 

> + return 0;
>  }
>  
>  static int rvin_g_std(struct file *file, void *priv, v4l2_std_id *a)
> @@ -433,6 +450,16 @@ static int rvin_g_std(struct file *file, void *priv, 
> v4l2_std_id *a)
>   return v4l2_subdev_call(sd, video, g_std, a);
>  }
>  
> +static int rvin_subscribe_event(struct v4l2_fh *fh,
> + const struct v4l2_event_subscription *sub)
> +{
> + switch (sub->type) {
> + case V4L2_EVENT_SOURCE_CHANGE:
> + return v4l2_event_subscribe(fh, sub, 4, NULL);
> + }
> + return v4l2_ctrl_subscribe_event(fh, sub);
> +}
> +
>  static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
>   .vidioc_querycap= rvin_querycap,
>   .vidioc_try_fmt_vid_cap = rvin_try_fmt_vid_cap,
> @@ -464,7 +491,7 @@ static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
>   .vidioc_streamoff   = vb2_ioctl_streamoff,
>  
>   .vidioc_log_status  = v4l2_ctrl_log_status,
> - .vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
> + .vidioc_subscribe_event = rvin_subscribe_event,
>   .vidioc_unsubscribe_event   = v4l2_event_unsubscribe,
>  };
>  
> @@ -623,6 +650,21 @@ void rvin_v4l2_remove(struct rvin_dev *vin)
>   video_unregister_device(&vin->vdev);
>  }
>  
> +static void rvin_notify(struct v4l2_subdev *sd,
> + unsigned int notification, void *arg)
> +{
> + struct rvin_dev *vin =
> + container_of(sd->v4l2_dev, struct rvin_dev, v4l2_dev);
> +
> + switch (notification) {
> + case V4L2_DEVICE_NOTIFY_EVENT:
> + v4l2_event_queue(&vin->vdev, arg);
> + break;
> + default:
> + break;
> + }
> +}
> +
>  int rvin_v4l2_probe(struct rvin_dev *vin)
>  {
>   struct v4l2_subdev_format fmt = {
> @@ -635,6 +677,8 @@ int rvin_v4l2_probe(struct rvin_dev *vin)
>  
>   v4l2_set_subdev_hostdata(sd, vin);
>  
> + vin->v4l2_dev.notify = rvin_notify;
> +
>   ret = v4l2_subdev_call(sd, video, g_tvnorms, &vin->vdev.tvnorms);
>   if (ret < 0 && ret != -ENOIOCTLCMD && ret != -ENODEV)
>   return ret;
> -- 
> 2.8.0.rc3
> 

-- 
Regards,
Niklas Söderlund
--
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: vb2: Fix regression on poll() for RW mode

2016-04-22 Thread Mauro Carvalho Chehab
Em Fri, 22 Apr 2016 18:45:41 +0200
Hans Verkuil  escreveu:

> On 04/22/2016 05:21 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 22 Apr 2016 16:56:00 +0200
> > Hans Verkuil  escreveu:
> >   
> >> On 04/22/2016 04:48 PM, Mauro Carvalho Chehab wrote:  
> >>> Em Fri, 22 Apr 2016 16:31:28 +0200
> >>> Hans Verkuil  escreveu:
> >>> 
>  On 04/22/2016 04:21 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 22 Apr 2016 14:37:07 +0200
> > Hans Verkuil  escreveu:
> >   
> >> On 04/22/2016 02:31 PM, Mauro Carvalho Chehab wrote:  
> >>> Em Fri, 22 Apr 2016 11:19:09 +0200
> >>> Hans Verkuil  escreveu:
> >>> 
>  Hi Ricardo,
> 
>  On 04/21/2016 11:15 AM, Ricardo Ribalda Delgado wrote:
> > When using a device is read/write mode, vb2 does not handle 
> > properly the
> > first select/poll operation. It allways return POLLERR.
> >
> > The reason for this is that when this code has been refactored, 
> > some of
> > the operations have changed their order, and now fileio emulator is 
> > not
> > started by poll, due to a previous check.
> >
> > Reported-by: Dimitrios Katsaros 
> > Cc: Junghak Sung 
> > Cc: sta...@vger.kernel.org
> > Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
> > Signed-off-by: Ricardo Ribalda Delgado 
> > ---
> >  drivers/media/v4l2-core/videobuf2-core.c | 8 
> >  drivers/media/v4l2-core/videobuf2-v4l2.c | 8 
> >  2 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index 5d016f496e0e..199c65dbe330 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -2298,6 +2298,14 @@ unsigned int vb2_core_poll(struct vb2_queue 
> > *q, struct file *file,
> > return 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 waiting_for_buffers to false.
> > +*/
> > +   if (q->waiting_for_buffers && (req_events & (POLLIN | 
> > POLLRDNORM)))
> > +   return POLLERR;  
> 
>  The problem I have with this is that this should be specific to 
>  V4L2. The only
>  reason we do this is that we had to stay backwards compatible with 
>  vb1.
> 
>  This is the reason this code was placed in videobuf2-v4l2.c. But you 
>  are correct
>  that this causes a regression, and I see no other choice but to put 
>  it in core.c.
> 
>  That said, I would still only honor this when called from v4l2, so I 
>  suggest that
>  a new flag 'check_waiting_for_buffers' is added that is only set in 
>  vb2_queue_init
>  in videobuf2-v4l2.c.
> 
>  So the test above becomes:
> 
>   if (q->check_waiting_for_buffers && q->waiting_for_buffers &&
>   (req_events & (POLLIN | POLLRDNORM)))
> 
>  It's not ideal, but at least this keeps this v4l2 specific.
> >>>
> >>> I don't like the above approach, for two reasons:
> >>>
> >>> 1) it is not obvious that this is V4L2 specific from the code;
> >>
> >> s/check_waiting_for_buffers/v4l2_needs_to_wait_for_buffers/  
> >
> > Better, but still hell of a hack. Maybe we could add a quirks
> > flag and add a flag like:
> > VB2_FLAG_ENABLE_POLLERR_IF_WAITING_BUFFERS_AND_NO_QBUF
> > (or some better naming, I'm not inspired today...)
> >
> > Of course, such quirk should be properly documented.  
> 
>  How about 'quirk_poll_must_check_waiting_for_buffers'? Something with 
>  'quirk' in the
>  name is a good idea.
> >>>
> >>> works for me, provided that we add the field as a flag. So it would be 
> >>> like:
> >>>
> >>> #define QUIRK_POLL_MUST_CHECK_WAITING_FOR_BUFFERS 0
> >>>
> >>>   if (test_bit(q->quirk, QUIRK_POLL_MUST_CHECK_WAITING_FOR_BUFFERS) &&
> >>>   q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
> >>
> >> Why should it be a flag? What is wrong with a bitfield?
> >>
> >> Just curious what the reasoning is for that. I don't see any obvious
> >> advantage of a flag over a bitfield.  
> > 
> > Huh? Flags are implemented as bitfields. See the above code: it is
> > using test_bit() for the new q->quirk flags/bitfield.  
> 
> I mean C bitfields like this:
> 
> unsignedfileio_read_on

Re: [PATCH] media: vb2: Fix regression on poll() for RW mode

2016-04-22 Thread Hans Verkuil
On 04/22/2016 05:21 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 22 Apr 2016 16:56:00 +0200
> Hans Verkuil  escreveu:
> 
>> On 04/22/2016 04:48 PM, Mauro Carvalho Chehab wrote:
>>> Em Fri, 22 Apr 2016 16:31:28 +0200
>>> Hans Verkuil  escreveu:
>>>   
 On 04/22/2016 04:21 PM, Mauro Carvalho Chehab wrote:  
> Em Fri, 22 Apr 2016 14:37:07 +0200
> Hans Verkuil  escreveu:
> 
>> On 04/22/2016 02:31 PM, Mauro Carvalho Chehab wrote:
>>> Em Fri, 22 Apr 2016 11:19:09 +0200
>>> Hans Verkuil  escreveu:
>>>   
 Hi Ricardo,

 On 04/21/2016 11:15 AM, Ricardo Ribalda Delgado wrote:  
> When using a device is read/write mode, vb2 does not handle properly 
> the
> first select/poll operation. It allways return POLLERR.
>
> The reason for this is that when this code has been refactored, some 
> of
> the operations have changed their order, and now fileio emulator is 
> not
> started by poll, due to a previous check.
>
> Reported-by: Dimitrios Katsaros 
> Cc: Junghak Sung 
> Cc: sta...@vger.kernel.org
> Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  drivers/media/v4l2-core/videobuf2-core.c | 8 
>  drivers/media/v4l2-core/videobuf2-v4l2.c | 8 
>  2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 5d016f496e0e..199c65dbe330 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -2298,6 +2298,14 @@ unsigned int vb2_core_poll(struct vb2_queue 
> *q, struct file *file,
>   return 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 waiting_for_buffers to false.
> +  */
> + if (q->waiting_for_buffers && (req_events & (POLLIN | 
> POLLRDNORM)))
> + return POLLERR;

 The problem I have with this is that this should be specific to V4L2. 
 The only
 reason we do this is that we had to stay backwards compatible with vb1.

 This is the reason this code was placed in videobuf2-v4l2.c. But you 
 are correct
 that this causes a regression, and I see no other choice but to put it 
 in core.c.

 That said, I would still only honor this when called from v4l2, so I 
 suggest that
 a new flag 'check_waiting_for_buffers' is added that is only set in 
 vb2_queue_init
 in videobuf2-v4l2.c.

 So the test above becomes:

if (q->check_waiting_for_buffers && q->waiting_for_buffers &&
(req_events & (POLLIN | POLLRDNORM)))

 It's not ideal, but at least this keeps this v4l2 specific.  
>>>
>>> I don't like the above approach, for two reasons:
>>>
>>> 1) it is not obvious that this is V4L2 specific from the code;  
>>
>> s/check_waiting_for_buffers/v4l2_needs_to_wait_for_buffers/
>
> Better, but still hell of a hack. Maybe we could add a quirks
> flag and add a flag like:
>   VB2_FLAG_ENABLE_POLLERR_IF_WAITING_BUFFERS_AND_NO_QBUF
> (or some better naming, I'm not inspired today...)
>
> Of course, such quirk should be properly documented.

 How about 'quirk_poll_must_check_waiting_for_buffers'? Something with 
 'quirk' in the
 name is a good idea.  
>>>
>>> works for me, provided that we add the field as a flag. So it would be like:
>>>
>>> #define QUIRK_POLL_MUST_CHECK_WAITING_FOR_BUFFERS 0
>>>
>>> if (test_bit(q->quirk, QUIRK_POLL_MUST_CHECK_WAITING_FOR_BUFFERS) &&
>>> q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))  
>>
>> Why should it be a flag? What is wrong with a bitfield?
>>
>> Just curious what the reasoning is for that. I don't see any obvious
>> advantage of a flag over a bitfield.
> 
> Huh? Flags are implemented as bitfields. See the above code: it is
> using test_bit() for the new q->quirk flags/bitfield.

I mean C bitfields like this:

unsignedfileio_read_once:1;
unsignedfileio_write_immediately:1;
unsignedallow_zero_bytesused:1;

This is already used in struct vb2_queue, so my proposal would be to add:

unsigned
quirk_poll_must_check_waiting_for_buffers:1;

Regards,

Hans
--

Re: [PATCH 0/8] Input: atmel_mxt_ts - output raw touch diagnostic data via V4L

2016-04-22 Thread Nick Dyer
On 22/04/2016 15:45, Mauro Carvalho Chehab wrote:
> Em Fri, 22 Apr 2016 10:26:37 +0200
> Hans Verkuil  escreveu:
>> On 04/21/2016 11:31 AM, Nick Dyer wrote:
>>> This is a series of patches to add diagnostic data support to the Atmel
>>> maXTouch driver. It's a rewrite of the previous implementation which output 
>>> via
>>> debugfs: it now uses a V4L2 device in a similar way to the sur40 driver.
>>>
>>> There are significant performance advantages to putting this code into the
>>> driver. The algorithm for retrieving the data has been fairly consistent 
>>> across
>>> a range of chips, with the exception of the mXT1386 series (see patch).
>>>
>>> We have a utility which can read the data and display it in a useful format:
>>> https://github.com/ndyer/heatmap/commits/heatmap-v4l
>>>
>>> These patches are also available from
>>> https://github.com/ndyer/linux/commits/diagnostic-v4l
>>>
>>> Any feedback appreciated.  
>>
>> FYI: we're working on a new buffer type for meta data:
>>
>> https://patchwork.linuxtv.org/patch/33938/
>> https://patchwork.linuxtv.org/patch/33939/
> 
> One of the things I missed on your patchset is the content of the
> new format you added (V4L2_PIX_FMT_YS16). You should be patching
> the V4L2 docbook too, in order to add it there.

OK, will do. I also see that I forgot Kconfig changes for CONFIG_VIDEO_V4L2
etc.

> That's said, if the output is really an image, I don't think it
> should be mapped via the new V4L2_BUF_TYPE_META_CAPTURE. This type of
> buffer is meant to be used on non-image metadata, like image statistics
> to feed auto whitebalance and other similar AAA algorithms.

The output is raw touch data - i.e. a rectangular grid of nodes each having
an integer value. I think it is an image in some senses, although perhaps
it's a matter of opinion!

You can see an example of a Atmel MXT capacitive touch device here (using
this patchset):
https://www.youtube.com/watch?v=Uj4T6fUCySw

There are touch devices which can deliver much higher resolution/framerate.
For example here's the data coming from a SUR40 which is an optical touch
sensor but uses V4L in a similar way:
https://www.youtube.com/watch?v=e-JNqTY_3b0

> It could still make sense to use the new device type (VFL_TYPE_META) for
> such drivers, as we don't want applications to identify those devices as
> if they are a webcam.

I agree it may be a little confusing if things like Skype start picking up
these devices. Could we #define V4L2_INPUT_TYPE_TOUCH_SENSOR to solve that
problem?
--
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 0/8] Input: atmel_mxt_ts - output raw touch diagnostic data via V4L

2016-04-22 Thread Mauro Carvalho Chehab
Em Fri, 22 Apr 2016 17:18:24 +0200
Hans Verkuil  escreveu:

> On 04/22/2016 05:07 PM, Nick Dyer wrote:
> > On 22/04/2016 15:45, Mauro Carvalho Chehab wrote:  
> >> Em Fri, 22 Apr 2016 10:26:37 +0200
> >> Hans Verkuil  escreveu:  
> >>> On 04/21/2016 11:31 AM, Nick Dyer wrote:  
>  This is a series of patches to add diagnostic data support to the Atmel
>  maXTouch driver. It's a rewrite of the previous implementation which 
>  output via
>  debugfs: it now uses a V4L2 device in a similar way to the sur40 driver.
> 
>  There are significant performance advantages to putting this code into 
>  the
>  driver. The algorithm for retrieving the data has been fairly consistent 
>  across
>  a range of chips, with the exception of the mXT1386 series (see patch).
> 
>  We have a utility which can read the data and display it in a useful 
>  format:
>   https://github.com/ndyer/heatmap/commits/heatmap-v4l
> 
>  These patches are also available from
>   https://github.com/ndyer/linux/commits/diagnostic-v4l
> 
>  Any feedback appreciated.
> >>>
> >>> FYI: we're working on a new buffer type for meta data:
> >>>
> >>> https://patchwork.linuxtv.org/patch/33938/
> >>> https://patchwork.linuxtv.org/patch/33939/  
> >>
> >> One of the things I missed on your patchset is the content of the
> >> new format you added (V4L2_PIX_FMT_YS16). You should be patching
> >> the V4L2 docbook too, in order to add it there.  
> > 
> > OK, will do. I also see that I forgot Kconfig changes for CONFIG_VIDEO_V4L2
> > etc.
> >   
> >> That's said, if the output is really an image, I don't think it
> >> should be mapped via the new V4L2_BUF_TYPE_META_CAPTURE. This type of
> >> buffer is meant to be used on non-image metadata, like image statistics
> >> to feed auto whitebalance and other similar AAA algorithms.  
> > 
> > The output is raw touch data - i.e. a rectangular grid of nodes each having
> > an integer value. I think it is an image in some senses, although perhaps
> > it's a matter of opinion!
> > 
> > You can see an example of a Atmel MXT capacitive touch device here (using
> > this patchset):
> > https://www.youtube.com/watch?v=Uj4T6fUCySw
> > 
> > There are touch devices which can deliver much higher resolution/framerate.
> > For example here's the data coming from a SUR40 which is an optical touch
> > sensor but uses V4L in a similar way:
> > https://www.youtube.com/watch?v=e-JNqTY_3b0
> >   
> >> It could still make sense to use the new device type (VFL_TYPE_META) for
> >> such drivers, as we don't want applications to identify those devices as
> >> if they are a webcam.  
> > 
> > I agree it may be a little confusing if things like Skype start picking up
> > these devices. Could we #define V4L2_INPUT_TYPE_TOUCH_SENSOR to solve that
> > problem?
> >   
> 
> That might be an idea. I have to admit that I didn't look at the patches in
> detail. It mentioned diagnostics, so I didn't realize that it is a image
> with a width and height, even though it is not a regular video input.
> 
> Adding a new input type won't prevent anyone from picking it up, since
> nobody tests that field :-)

Yeah, I agree.

> On the other hand, it would be a good place to tell the user that it
> is from a touch sensor.
> 
> Using the upcoming metadata feature wouldn't work since there is no width
> and height in the metadata format.
> 
> I wonder what others think about adding a new type value.

IMO, two things should be done here:

1) Add some caps flag to help userspace to identify what's there
   on those devices;

2) Make sure that udev/systemd won't be naming the devnodes as
   "/dev/video";


The latter one could be solved with either the new dev meta or
with another VFL_TYPE for input systems (like VFL_TYPE_TOUCH_SENSOR)
and use this code snippet:

diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
b/drivers/media/v4l2-core/v4l2-dev.c
index d8e5994cccf1..4d3e574eba49 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -887,6 +887,9 @@ int __video_register_device(struct video_device *vdev, int 
type, int nr,
/* Use device name 'swradio' because 'sdr' was already taken. */
name_base = "swradio";
break;
+   case VFL_TYPE_TOUCH_SENSOR:
+   name_base = "v4l-touch";
+   break;
default:
printk(KERN_ERR "%s called with unknown type: %d\n",
   __func__, type);


Such change would cause __video_register_device() to pass a different
name_base to:
dev_set_name(&vdev->dev, "%s%d", name_base, vdev->num);

This way, udev/systemd will use a different name (by default, 
/dev/v4l-touch0), and existing apps won't identify this as a
webcam.

Regards,
Mauro
--
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/ma

Re: [PATCH] media: vb2: Fix regression on poll() for RW mode

2016-04-22 Thread Mauro Carvalho Chehab
Em Fri, 22 Apr 2016 16:56:00 +0200
Hans Verkuil  escreveu:

> On 04/22/2016 04:48 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 22 Apr 2016 16:31:28 +0200
> > Hans Verkuil  escreveu:
> >   
> >> On 04/22/2016 04:21 PM, Mauro Carvalho Chehab wrote:  
> >>> Em Fri, 22 Apr 2016 14:37:07 +0200
> >>> Hans Verkuil  escreveu:
> >>> 
>  On 04/22/2016 02:31 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 22 Apr 2016 11:19:09 +0200
> > Hans Verkuil  escreveu:
> >   
> >> Hi Ricardo,
> >>
> >> On 04/21/2016 11:15 AM, Ricardo Ribalda Delgado wrote:  
> >>> When using a device is read/write mode, vb2 does not handle properly 
> >>> the
> >>> first select/poll operation. It allways return POLLERR.
> >>>
> >>> The reason for this is that when this code has been refactored, some 
> >>> of
> >>> the operations have changed their order, and now fileio emulator is 
> >>> not
> >>> started by poll, due to a previous check.
> >>>
> >>> Reported-by: Dimitrios Katsaros 
> >>> Cc: Junghak Sung 
> >>> Cc: sta...@vger.kernel.org
> >>> Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
> >>> Signed-off-by: Ricardo Ribalda Delgado 
> >>> ---
> >>>  drivers/media/v4l2-core/videobuf2-core.c | 8 
> >>>  drivers/media/v4l2-core/videobuf2-v4l2.c | 8 
> >>>  2 files changed, 8 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> >>> b/drivers/media/v4l2-core/videobuf2-core.c
> >>> index 5d016f496e0e..199c65dbe330 100644
> >>> --- a/drivers/media/v4l2-core/videobuf2-core.c
> >>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> >>> @@ -2298,6 +2298,14 @@ unsigned int vb2_core_poll(struct vb2_queue 
> >>> *q, struct file *file,
> >>>   return 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 waiting_for_buffers to false.
> >>> +  */
> >>> + if (q->waiting_for_buffers && (req_events & (POLLIN | 
> >>> POLLRDNORM)))
> >>> + return POLLERR;
> >>
> >> The problem I have with this is that this should be specific to V4L2. 
> >> The only
> >> reason we do this is that we had to stay backwards compatible with vb1.
> >>
> >> This is the reason this code was placed in videobuf2-v4l2.c. But you 
> >> are correct
> >> that this causes a regression, and I see no other choice but to put it 
> >> in core.c.
> >>
> >> That said, I would still only honor this when called from v4l2, so I 
> >> suggest that
> >> a new flag 'check_waiting_for_buffers' is added that is only set in 
> >> vb2_queue_init
> >> in videobuf2-v4l2.c.
> >>
> >> So the test above becomes:
> >>
> >>if (q->check_waiting_for_buffers && q->waiting_for_buffers &&
> >>(req_events & (POLLIN | POLLRDNORM)))
> >>
> >> It's not ideal, but at least this keeps this v4l2 specific.  
> >
> > I don't like the above approach, for two reasons:
> >
> > 1) it is not obvious that this is V4L2 specific from the code;  
> 
>  s/check_waiting_for_buffers/v4l2_needs_to_wait_for_buffers/
> >>>
> >>> Better, but still hell of a hack. Maybe we could add a quirks
> >>> flag and add a flag like:
> >>>   VB2_FLAG_ENABLE_POLLERR_IF_WAITING_BUFFERS_AND_NO_QBUF
> >>> (or some better naming, I'm not inspired today...)
> >>>
> >>> Of course, such quirk should be properly documented.
> >>
> >> How about 'quirk_poll_must_check_waiting_for_buffers'? Something with 
> >> 'quirk' in the
> >> name is a good idea.  
> > 
> > works for me, provided that we add the field as a flag. So it would be like:
> > 
> > #define QUIRK_POLL_MUST_CHECK_WAITING_FOR_BUFFERS 0
> > 
> > if (test_bit(q->quirk, QUIRK_POLL_MUST_CHECK_WAITING_FOR_BUFFERS) &&
> > q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))  
> 
> Why should it be a flag? What is wrong with a bitfield?
> 
> Just curious what the reasoning is for that. I don't see any obvious
> advantage of a flag over a bitfield.

Huh? Flags are implemented as bitfields. See the above code: it is
using test_bit() for the new q->quirk flags/bitfield.

Regards,
Mauro
--
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 0/8] Input: atmel_mxt_ts - output raw touch diagnostic data via V4L

2016-04-22 Thread Hans Verkuil
On 04/22/2016 05:07 PM, Nick Dyer wrote:
> On 22/04/2016 15:45, Mauro Carvalho Chehab wrote:
>> Em Fri, 22 Apr 2016 10:26:37 +0200
>> Hans Verkuil  escreveu:
>>> On 04/21/2016 11:31 AM, Nick Dyer wrote:
 This is a series of patches to add diagnostic data support to the Atmel
 maXTouch driver. It's a rewrite of the previous implementation which 
 output via
 debugfs: it now uses a V4L2 device in a similar way to the sur40 driver.

 There are significant performance advantages to putting this code into the
 driver. The algorithm for retrieving the data has been fairly consistent 
 across
 a range of chips, with the exception of the mXT1386 series (see patch).

 We have a utility which can read the data and display it in a useful 
 format:
https://github.com/ndyer/heatmap/commits/heatmap-v4l

 These patches are also available from
https://github.com/ndyer/linux/commits/diagnostic-v4l

 Any feedback appreciated.  
>>>
>>> FYI: we're working on a new buffer type for meta data:
>>>
>>> https://patchwork.linuxtv.org/patch/33938/
>>> https://patchwork.linuxtv.org/patch/33939/
>>
>> One of the things I missed on your patchset is the content of the
>> new format you added (V4L2_PIX_FMT_YS16). You should be patching
>> the V4L2 docbook too, in order to add it there.
> 
> OK, will do. I also see that I forgot Kconfig changes for CONFIG_VIDEO_V4L2
> etc.
> 
>> That's said, if the output is really an image, I don't think it
>> should be mapped via the new V4L2_BUF_TYPE_META_CAPTURE. This type of
>> buffer is meant to be used on non-image metadata, like image statistics
>> to feed auto whitebalance and other similar AAA algorithms.
> 
> The output is raw touch data - i.e. a rectangular grid of nodes each having
> an integer value. I think it is an image in some senses, although perhaps
> it's a matter of opinion!
> 
> You can see an example of a Atmel MXT capacitive touch device here (using
> this patchset):
> https://www.youtube.com/watch?v=Uj4T6fUCySw
> 
> There are touch devices which can deliver much higher resolution/framerate.
> For example here's the data coming from a SUR40 which is an optical touch
> sensor but uses V4L in a similar way:
> https://www.youtube.com/watch?v=e-JNqTY_3b0
> 
>> It could still make sense to use the new device type (VFL_TYPE_META) for
>> such drivers, as we don't want applications to identify those devices as
>> if they are a webcam.
> 
> I agree it may be a little confusing if things like Skype start picking up
> these devices. Could we #define V4L2_INPUT_TYPE_TOUCH_SENSOR to solve that
> problem?
> 

That might be an idea. I have to admit that I didn't look at the patches in
detail. It mentioned diagnostics, so I didn't realize that it is a image
with a width and height, even though it is not a regular video input.

Adding a new input type won't prevent anyone from picking it up, since
nobody tests that field :-)

On the other hand, it would be a good place to tell the user that it
is from a touch sensor.

Using the upcoming metadata feature wouldn't work since there is no width
and height in the metadata format.

I wonder what others think about adding a new type value.

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


Re: [PATCH] media: vb2: Fix regression on poll() for RW mode

2016-04-22 Thread Hans Verkuil
On 04/22/2016 04:48 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 22 Apr 2016 16:31:28 +0200
> Hans Verkuil  escreveu:
> 
>> On 04/22/2016 04:21 PM, Mauro Carvalho Chehab wrote:
>>> Em Fri, 22 Apr 2016 14:37:07 +0200
>>> Hans Verkuil  escreveu:
>>>   
 On 04/22/2016 02:31 PM, Mauro Carvalho Chehab wrote:  
> Em Fri, 22 Apr 2016 11:19:09 +0200
> Hans Verkuil  escreveu:
> 
>> Hi Ricardo,
>>
>> On 04/21/2016 11:15 AM, Ricardo Ribalda Delgado wrote:
>>> When using a device is read/write mode, vb2 does not handle properly the
>>> first select/poll operation. It allways return POLLERR.
>>>
>>> The reason for this is that when this code has been refactored, some of
>>> the operations have changed their order, and now fileio emulator is not
>>> started by poll, due to a previous check.
>>>
>>> Reported-by: Dimitrios Katsaros 
>>> Cc: Junghak Sung 
>>> Cc: sta...@vger.kernel.org
>>> Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
>>> Signed-off-by: Ricardo Ribalda Delgado 
>>> ---
>>>  drivers/media/v4l2-core/videobuf2-core.c | 8 
>>>  drivers/media/v4l2-core/videobuf2-v4l2.c | 8 
>>>  2 files changed, 8 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
>>> b/drivers/media/v4l2-core/videobuf2-core.c
>>> index 5d016f496e0e..199c65dbe330 100644
>>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>>> @@ -2298,6 +2298,14 @@ unsigned int vb2_core_poll(struct vb2_queue *q, 
>>> struct file *file,
>>> return 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 waiting_for_buffers to false.
>>> +*/
>>> +   if (q->waiting_for_buffers && (req_events & (POLLIN | 
>>> POLLRDNORM)))
>>> +   return POLLERR;  
>>
>> The problem I have with this is that this should be specific to V4L2. 
>> The only
>> reason we do this is that we had to stay backwards compatible with vb1.
>>
>> This is the reason this code was placed in videobuf2-v4l2.c. But you are 
>> correct
>> that this causes a regression, and I see no other choice but to put it 
>> in core.c.
>>
>> That said, I would still only honor this when called from v4l2, so I 
>> suggest that
>> a new flag 'check_waiting_for_buffers' is added that is only set in 
>> vb2_queue_init
>> in videobuf2-v4l2.c.
>>
>> So the test above becomes:
>>
>>  if (q->check_waiting_for_buffers && q->waiting_for_buffers &&
>>  (req_events & (POLLIN | POLLRDNORM)))
>>
>> It's not ideal, but at least this keeps this v4l2 specific.
>
> I don't like the above approach, for two reasons:
>
> 1) it is not obvious that this is V4L2 specific from the code;

 s/check_waiting_for_buffers/v4l2_needs_to_wait_for_buffers/  
>>>
>>> Better, but still hell of a hack. Maybe we could add a quirks
>>> flag and add a flag like:
>>> VB2_FLAG_ENABLE_POLLERR_IF_WAITING_BUFFERS_AND_NO_QBUF
>>> (or some better naming, I'm not inspired today...)
>>>
>>> Of course, such quirk should be properly documented.  
>>
>> How about 'quirk_poll_must_check_waiting_for_buffers'? Something with 
>> 'quirk' in the
>> name is a good idea.
> 
> works for me, provided that we add the field as a flag. So it would be like:
> 
> #define QUIRK_POLL_MUST_CHECK_WAITING_FOR_BUFFERS 0
> 
>   if (test_bit(q->quirk, QUIRK_POLL_MUST_CHECK_WAITING_FOR_BUFFERS) &&
>   q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))

Why should it be a flag? What is wrong with a bitfield?

Just curious what the reasoning is for that. I don't see any obvious
advantage of a flag over a bitfield.

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


Re: [PATCH] media: vb2: Fix regression on poll() for RW mode

2016-04-22 Thread Mauro Carvalho Chehab
Em Fri, 22 Apr 2016 16:31:28 +0200
Hans Verkuil  escreveu:

> On 04/22/2016 04:21 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 22 Apr 2016 14:37:07 +0200
> > Hans Verkuil  escreveu:
> >   
> >> On 04/22/2016 02:31 PM, Mauro Carvalho Chehab wrote:  
> >>> Em Fri, 22 Apr 2016 11:19:09 +0200
> >>> Hans Verkuil  escreveu:
> >>> 
>  Hi Ricardo,
> 
>  On 04/21/2016 11:15 AM, Ricardo Ribalda Delgado wrote:
> > When using a device is read/write mode, vb2 does not handle properly the
> > first select/poll operation. It allways return POLLERR.
> >
> > The reason for this is that when this code has been refactored, some of
> > the operations have changed their order, and now fileio emulator is not
> > started by poll, due to a previous check.
> >
> > Reported-by: Dimitrios Katsaros 
> > Cc: Junghak Sung 
> > Cc: sta...@vger.kernel.org
> > Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
> > Signed-off-by: Ricardo Ribalda Delgado 
> > ---
> >  drivers/media/v4l2-core/videobuf2-core.c | 8 
> >  drivers/media/v4l2-core/videobuf2-v4l2.c | 8 
> >  2 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index 5d016f496e0e..199c65dbe330 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -2298,6 +2298,14 @@ unsigned int vb2_core_poll(struct vb2_queue *q, 
> > struct file *file,
> > return 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 waiting_for_buffers to false.
> > +*/
> > +   if (q->waiting_for_buffers && (req_events & (POLLIN | 
> > POLLRDNORM)))
> > +   return POLLERR;  
> 
>  The problem I have with this is that this should be specific to V4L2. 
>  The only
>  reason we do this is that we had to stay backwards compatible with vb1.
> 
>  This is the reason this code was placed in videobuf2-v4l2.c. But you are 
>  correct
>  that this causes a regression, and I see no other choice but to put it 
>  in core.c.
> 
>  That said, I would still only honor this when called from v4l2, so I 
>  suggest that
>  a new flag 'check_waiting_for_buffers' is added that is only set in 
>  vb2_queue_init
>  in videobuf2-v4l2.c.
> 
>  So the test above becomes:
> 
>   if (q->check_waiting_for_buffers && q->waiting_for_buffers &&
>   (req_events & (POLLIN | POLLRDNORM)))
> 
>  It's not ideal, but at least this keeps this v4l2 specific.
> >>>
> >>> I don't like the above approach, for two reasons:
> >>>
> >>> 1) it is not obvious that this is V4L2 specific from the code;
> >>
> >> s/check_waiting_for_buffers/v4l2_needs_to_wait_for_buffers/  
> > 
> > Better, but still hell of a hack. Maybe we could add a quirks
> > flag and add a flag like:
> > VB2_FLAG_ENABLE_POLLERR_IF_WAITING_BUFFERS_AND_NO_QBUF
> > (or some better naming, I'm not inspired today...)
> > 
> > Of course, such quirk should be properly documented.  
> 
> How about 'quirk_poll_must_check_waiting_for_buffers'? Something with 'quirk' 
> in the
> name is a good idea.

works for me, provided that we add the field as a flag. So it would be like:

#define QUIRK_POLL_MUST_CHECK_WAITING_FOR_BUFFERS 0

if (test_bit(q->quirk, QUIRK_POLL_MUST_CHECK_WAITING_FOR_BUFFERS) &&
q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))

> 
> >   
> >>>
> >>> 2) we should not mess the core due to some V4L2 mess.
> >>
> >> Well, the only other alternative I see is to split vb2_core_poll() into two
> >> since the check has to happen in the middle. The v4l2 code would call 
> >> core_poll1(),
> >> then do the check and afterwards call core_poll2(). And that would really 
> >> be ugly.  
> > 
> > Actually, the first callback would be better called as
> > vb2_core_poll_check() - or something with similar name.
> > 
> > IMHO, this is the cleaner solution, although it adds an extra cost.  
> 
> I really don't like this. This has a much larger impact on vb2 core then 
> adding
> a simple quirk flag.
> 
> Regards,
> 
>   Hans


-- 
Thanks,
Mauro
--
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 0/8] Input: atmel_mxt_ts - output raw touch diagnostic data via V4L

2016-04-22 Thread Mauro Carvalho Chehab
Em Fri, 22 Apr 2016 10:26:37 +0200
Hans Verkuil  escreveu:

> Hi Nick,
> 
> On 04/21/2016 11:31 AM, Nick Dyer wrote:
> > This is a series of patches to add diagnostic data support to the Atmel
> > maXTouch driver. It's a rewrite of the previous implementation which output 
> > via
> > debugfs: it now uses a V4L2 device in a similar way to the sur40 driver.
> > 
> > There are significant performance advantages to putting this code into the
> > driver. The algorithm for retrieving the data has been fairly consistent 
> > across
> > a range of chips, with the exception of the mXT1386 series (see patch).
> > 
> > We have a utility which can read the data and display it in a useful format:
> > https://github.com/ndyer/heatmap/commits/heatmap-v4l
> > 
> > These patches are also available from
> > https://github.com/ndyer/linux/commits/diagnostic-v4l
> > 
> > Any feedback appreciated.  
> 
> FYI: we're working on a new buffer type for meta data:
> 
> https://patchwork.linuxtv.org/patch/33938/
> https://patchwork.linuxtv.org/patch/33939/

Nick,

One of the things I missed on your patchset is the content of the
new format you added (V4L2_PIX_FMT_YS16). You should be patching
the V4L2 docbook too, in order to add it there.

That's said, if the output is really an image, I don't think it
should be mapped via the new V4L2_BUF_TYPE_META_CAPTURE. This type of
buffer is meant to be used on non-image metadata, like image statistics
to feed auto whitebalance and other similar AAA algorithms.

It could still make sense to use the new device type (VFL_TYPE_META) for
such drivers, as we don't want applications to identify those devices as
if they are a webcam.

> 
> This would be an excellent fit for you. I expect that this new feature would 
> be
> merged soon (for 4.7 or 4.8 at the latest) since it looks all pretty good to 
> me.
> 
> So let's wait for this to be merged and then you can migrate to the new buffer
> type.
> 
> 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


-- 
Thanks,
Mauro
--
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/RFC 1/2] v4l: Add meta-data video device type

2016-04-22 Thread Mauro Carvalho Chehab
Em Fri, 22 Apr 2016 16:01:35 +0200
Hans Verkuil  escreveu:

> > + * %VFL_TYPE_META - Meta-data (including statistics)
> 
>  I would drop the '(including statistics)' part. It feels weird that
>  'statistics' are singled out, it makes the reader wonder what is so 
>  special
>  about it that it needs to be mentioned explicitly.
> >>>
> >>> Done.  
> > 
> > It actually makes sense to put statistics as an example of such
> > metadata, as this is the main(and currently only) usage for this
> > devnode.  
> 
> Then I would say 'like statistics' here. 

Fine for me. I would keep it like that.

> But I still don't like this to be
> honest. Heck, Nick Dyer posted a patch series for getting diagnostics 
> yesterday,
> which would be a good fit as well.

Nick patches are interesting. AFAIKT, input devices like touchscreen (and some
trackballs) actually produce a real 2D grey image. In the case of Nick's
patch, it seems that it is a new 16 bits per pixel grey image format:
+#define V4L2_PIX_FMT_YS16v4l2_fourcc('Y', 'S', '1', '6') /* signed 
16-bit Greyscale */

We need to ask him for mor info, how this is packaged, and what's the
difference from the previously supported formats:
 #define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16  Greyscale  
   */
 #define V4L2_PIX_FMT_Y16_BE  v4l2_fourcc_be('Y', '1', '6', ' ') /* 16  
Greyscale BE  */

IMO, if this is indeed a real image, it should not be using the
metadata buffer format, as this is not metadata, but an image stream.

An interesting question is: in such case, should it use a normal
/dev/video devnode or the new /dev/metadata devnode.

> 
> Anyway, it's not worth a long discussion :-)


-- 
Thanks,
Mauro
--
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: vb2: Fix regression on poll() for RW mode

2016-04-22 Thread Hans Verkuil
On 04/22/2016 04:21 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 22 Apr 2016 14:37:07 +0200
> Hans Verkuil  escreveu:
> 
>> On 04/22/2016 02:31 PM, Mauro Carvalho Chehab wrote:
>>> Em Fri, 22 Apr 2016 11:19:09 +0200
>>> Hans Verkuil  escreveu:
>>>   
 Hi Ricardo,

 On 04/21/2016 11:15 AM, Ricardo Ribalda Delgado wrote:  
> When using a device is read/write mode, vb2 does not handle properly the
> first select/poll operation. It allways return POLLERR.
>
> The reason for this is that when this code has been refactored, some of
> the operations have changed their order, and now fileio emulator is not
> started by poll, due to a previous check.
>
> Reported-by: Dimitrios Katsaros 
> Cc: Junghak Sung 
> Cc: sta...@vger.kernel.org
> Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  drivers/media/v4l2-core/videobuf2-core.c | 8 
>  drivers/media/v4l2-core/videobuf2-v4l2.c | 8 
>  2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 5d016f496e0e..199c65dbe330 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -2298,6 +2298,14 @@ unsigned int vb2_core_poll(struct vb2_queue *q, 
> struct file *file,
>   return 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 waiting_for_buffers to false.
> +  */
> + if (q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
> + return POLLERR;

 The problem I have with this is that this should be specific to V4L2. The 
 only
 reason we do this is that we had to stay backwards compatible with vb1.

 This is the reason this code was placed in videobuf2-v4l2.c. But you are 
 correct
 that this causes a regression, and I see no other choice but to put it in 
 core.c.

 That said, I would still only honor this when called from v4l2, so I 
 suggest that
 a new flag 'check_waiting_for_buffers' is added that is only set in 
 vb2_queue_init
 in videobuf2-v4l2.c.

 So the test above becomes:

if (q->check_waiting_for_buffers && q->waiting_for_buffers &&
(req_events & (POLLIN | POLLRDNORM)))

 It's not ideal, but at least this keeps this v4l2 specific.  
>>>
>>> I don't like the above approach, for two reasons:
>>>
>>> 1) it is not obvious that this is V4L2 specific from the code;  
>>
>> s/check_waiting_for_buffers/v4l2_needs_to_wait_for_buffers/
> 
> Better, but still hell of a hack. Maybe we could add a quirks
> flag and add a flag like:
>   VB2_FLAG_ENABLE_POLLERR_IF_WAITING_BUFFERS_AND_NO_QBUF
> (or some better naming, I'm not inspired today...)
> 
> Of course, such quirk should be properly documented.

How about 'quirk_poll_must_check_waiting_for_buffers'? Something with 'quirk' 
in the
name is a good idea.

> 
>>>
>>> 2) we should not mess the core due to some V4L2 mess.  
>>
>> Well, the only other alternative I see is to split vb2_core_poll() into two
>> since the check has to happen in the middle. The v4l2 code would call 
>> core_poll1(),
>> then do the check and afterwards call core_poll2(). And that would really be 
>> ugly.
> 
> Actually, the first callback would be better called as
> vb2_core_poll_check() - or something with similar name.
> 
> IMHO, this is the cleaner solution, although it adds an extra cost.

I really don't like this. This has a much larger impact on vb2 core then adding
a simple quirk flag.

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


Re: [PATCH] media: vb2: Fix regression on poll() for RW mode

2016-04-22 Thread Mauro Carvalho Chehab
Em Fri, 22 Apr 2016 14:37:07 +0200
Hans Verkuil  escreveu:

> On 04/22/2016 02:31 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 22 Apr 2016 11:19:09 +0200
> > Hans Verkuil  escreveu:
> >   
> >> Hi Ricardo,
> >>
> >> On 04/21/2016 11:15 AM, Ricardo Ribalda Delgado wrote:  
> >>> When using a device is read/write mode, vb2 does not handle properly the
> >>> first select/poll operation. It allways return POLLERR.
> >>>
> >>> The reason for this is that when this code has been refactored, some of
> >>> the operations have changed their order, and now fileio emulator is not
> >>> started by poll, due to a previous check.
> >>>
> >>> Reported-by: Dimitrios Katsaros 
> >>> Cc: Junghak Sung 
> >>> Cc: sta...@vger.kernel.org
> >>> Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
> >>> Signed-off-by: Ricardo Ribalda Delgado 
> >>> ---
> >>>  drivers/media/v4l2-core/videobuf2-core.c | 8 
> >>>  drivers/media/v4l2-core/videobuf2-v4l2.c | 8 
> >>>  2 files changed, 8 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> >>> b/drivers/media/v4l2-core/videobuf2-core.c
> >>> index 5d016f496e0e..199c65dbe330 100644
> >>> --- a/drivers/media/v4l2-core/videobuf2-core.c
> >>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> >>> @@ -2298,6 +2298,14 @@ unsigned int vb2_core_poll(struct vb2_queue *q, 
> >>> struct file *file,
> >>>   return 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 waiting_for_buffers to false.
> >>> +  */
> >>> + if (q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
> >>> + return POLLERR;
> >>
> >> The problem I have with this is that this should be specific to V4L2. The 
> >> only
> >> reason we do this is that we had to stay backwards compatible with vb1.
> >>
> >> This is the reason this code was placed in videobuf2-v4l2.c. But you are 
> >> correct
> >> that this causes a regression, and I see no other choice but to put it in 
> >> core.c.
> >>
> >> That said, I would still only honor this when called from v4l2, so I 
> >> suggest that
> >> a new flag 'check_waiting_for_buffers' is added that is only set in 
> >> vb2_queue_init
> >> in videobuf2-v4l2.c.
> >>
> >> So the test above becomes:
> >>
> >>if (q->check_waiting_for_buffers && q->waiting_for_buffers &&
> >>(req_events & (POLLIN | POLLRDNORM)))
> >>
> >> It's not ideal, but at least this keeps this v4l2 specific.  
> > 
> > I don't like the above approach, for two reasons:
> > 
> > 1) it is not obvious that this is V4L2 specific from the code;  
> 
> s/check_waiting_for_buffers/v4l2_needs_to_wait_for_buffers/

Better, but still hell of a hack. Maybe we could add a quirks
flag and add a flag like:
VB2_FLAG_ENABLE_POLLERR_IF_WAITING_BUFFERS_AND_NO_QBUF
(or some better naming, I'm not inspired today...)

Of course, such quirk should be properly documented.

> > 
> > 2) we should not mess the core due to some V4L2 mess.  
> 
> Well, the only other alternative I see is to split vb2_core_poll() into two
> since the check has to happen in the middle. The v4l2 code would call 
> core_poll1(),
> then do the check and afterwards call core_poll2(). And that would really be 
> ugly.

Actually, the first callback would be better called as
vb2_core_poll_check() - or something with similar name.

IMHO, this is the cleaner solution, although it adds an extra cost.


> I would probably NACK that.
> 
> Better ideas are welcome.
> 
> Regards,
> 
>   Hans


-- 
Thanks,
Mauro
--
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/6] adv7180: fix broken standards handling

2016-04-22 Thread Niklas Söderlund
Hi Hans,

Tested-by: Niklas Söderlund 

On 2016-04-22 15:03:37 +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> The adv7180 attempts to autodetect the standard. Unfortunately this
> is seriously broken.
> 
> This patch removes the autodetect completely. Only the querystd op
> will detect the standard. Since the design of the adv7180 requires
> that you switch to a special autodetect mode you cannot call querystd
> when you are streaming.
> 
> So the s_stream op has been added so we know whether we are streaming
> or not, and if we are, then querystd returns EBUSY.
> 
> After testing this with a signal generator is became obvious that
> a sleep is needed between changing the standard to autodetect and
> reading the status. So the autodetect can never have worked well.
> 
> The s_std call now just sets the new standard without any querying.
> 
> If the driver supports the interrupt, then when it detects a standard
> change it will signal that by sending the V4L2_EVENT_SOURCE_CHANGE
> event.
> 
> With these changes this driver now behaves like all other video
> receivers.
> 
> Signed-off-by: Hans Verkuil 
> Cc: Niklas Söderlund 
> Cc: Lars-Peter Clausen 
> Cc: Federico Vaga 
> ---
>  drivers/media/i2c/adv7180.c | 118 
> ++--
>  1 file changed, 80 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
> index 51a92b3..5a75a91 100644
> --- a/drivers/media/i2c/adv7180.c
> +++ b/drivers/media/i2c/adv7180.c
> @@ -26,8 +26,9 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -192,8 +193,8 @@ struct adv7180_state {
>   struct mutexmutex; /* mutual excl. when accessing chip */
>   int irq;
>   v4l2_std_id curr_norm;
> - boolautodetect;
>   boolpowered;
> + boolstreaming;
>   u8  input;
>  
>   struct i2c_client   *client;
> @@ -338,12 +339,26 @@ static int adv7180_querystd(struct v4l2_subdev *sd, 
> v4l2_std_id *std)
>   if (err)
>   return err;
>  
> - /* when we are interrupt driven we know the state */
> - if (!state->autodetect || state->irq > 0)
> - *std = state->curr_norm;
> - else
> - err = __adv7180_status(state, NULL, std);
> + if (state->streaming) {
> + err = -EBUSY;
> + goto unlock;
> + }
> +
> + err = adv7180_set_video_standard(state,
> + ADV7180_STD_AD_PAL_BG_NTSC_J_SECAM);
> + if (err)
> + goto unlock;
>  
> + msleep(100);
> + __adv7180_status(state, NULL, std);
> +
> + err = v4l2_std_to_adv7180(state->curr_norm);
> + if (err < 0)
> + goto unlock;
> +
> + err = adv7180_set_video_standard(state, err);
> +
> +unlock:
>   mutex_unlock(&state->mutex);
>   return err;
>  }
> @@ -387,23 +402,13 @@ static int adv7180_program_std(struct adv7180_state 
> *state)
>  {
>   int ret;
>  
> - if (state->autodetect) {
> - ret = adv7180_set_video_standard(state,
> - ADV7180_STD_AD_PAL_BG_NTSC_J_SECAM);
> - if (ret < 0)
> - return ret;
> -
> - __adv7180_status(state, NULL, &state->curr_norm);
> - } else {
> - ret = v4l2_std_to_adv7180(state->curr_norm);
> - if (ret < 0)
> - return ret;
> -
> - ret = adv7180_set_video_standard(state, ret);
> - if (ret < 0)
> - return ret;
> - }
> + ret = v4l2_std_to_adv7180(state->curr_norm);
> + if (ret < 0)
> + return ret;
>  
> + ret = adv7180_set_video_standard(state, ret);
> + if (ret < 0)
> + return ret;
>   return 0;
>  }
>  
> @@ -415,18 +420,12 @@ static int adv7180_s_std(struct v4l2_subdev *sd, 
> v4l2_std_id std)
>   if (ret)
>   return ret;
>  
> - /* all standards -> autodetect */
> - if (std == V4L2_STD_ALL) {
> - state->autodetect = true;
> - } else {
> - /* Make sure we can support this std */
> - ret = v4l2_std_to_adv7180(std);
> - if (ret < 0)
> - goto out;
> + /* Make sure we can support this std */
> + ret = v4l2_std_to_adv7180(std);
> + if (ret < 0)
> + goto out;
>  
> - state->curr_norm = std;
> - state->autodetect = false;
> - }
> + state->curr_norm = std;
>  
>   ret = adv7180_program_std(state);
>  out:
> @@ -747,6 +746,40 @@ static int adv7180_g_tvnorms(struct v4l2_subdev *sd, 
> v4l2_std_id *norm)
>   return 0;
>  }
>  
> +static int adv7180_s_stream(struct v4l2_subdev *sd, int enable)
> +{
> + struct adv7180_state *state = to_state(sd);
> + int ret;
> +
> + /* It's always 

Re: [PATCH v3 5/7] media: rcar-vin: add DV timings support

2016-04-22 Thread Hans Verkuil
On 04/14/2016 06:17 PM, Ulrich Hecht wrote:
> Adds ioctls DV_TIMINGS_CAP, ENUM_DV_TIMINGS, G_DV_TIMINGS, S_DV_TIMINGS,
> and QUERY_DV_TIMINGS.
> 
> Signed-off-by: Ulrich Hecht 
> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 69 
> +
>  1 file changed, 69 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index d8d5f3a..ba2ed4e 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -413,12 +413,17 @@ static int rvin_enum_input(struct file *file, void 
> *priv,
>  struct v4l2_input *i)
>  {
>   struct rvin_dev *vin = video_drvdata(file);
> + struct v4l2_subdev *sd = vin_to_sd(vin);
>  
>   if (i->index != 0)
>   return -EINVAL;
>  
>   i->type = V4L2_INPUT_TYPE_CAMERA;
>   i->std = vin->vdev.tvnorms;
> +
> + if (v4l2_subdev_has_op(sd, pad, dv_timings_cap))
> + i->capabilities = V4L2_IN_CAP_DV_TIMINGS;
> +
>   strlcpy(i->name, "Camera", sizeof(i->name));
>  
>   return 0;
> @@ -461,6 +466,64 @@ static int rvin_g_std(struct file *file, void *priv, 
> v4l2_std_id *a)
>   return v4l2_subdev_call(sd, video, g_std, a);
>  }
>  
> +static int rvin_enum_dv_timings(struct file *file, void *priv_fh,
> + struct v4l2_enum_dv_timings *timings)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> + struct v4l2_subdev *sd = vin_to_sd(vin);
> +
> + timings->pad = 0;
> + return v4l2_subdev_call(sd,
> + pad, enum_dv_timings, timings);
> +}
> +
> +static int rvin_s_dv_timings(struct file *file, void *priv_fh,
> + struct v4l2_dv_timings *timings)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> + struct v4l2_subdev *sd = vin_to_sd(vin);
> + int err;
> +
> + err = v4l2_subdev_call(sd,
> + video, s_dv_timings, timings);
> + if (!err) {
> + vin->sensor.width = timings->bt.width;
> + vin->sensor.height = timings->bt.height;

This updates the sensor w and h, but it should do the same with
vin->format.width and height.

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


Re: [PATCH/RFC 1/2] v4l: Add meta-data video device type

2016-04-22 Thread Hans Verkuil
On 04/22/2016 03:58 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 22 Apr 2016 09:46:04 +0200
> Hans Verkuil  escreveu:
> 
>> On 04/21/2016 09:15 PM, Laurent Pinchart wrote:
>>> Hi Hans,
>>>
>>> Thank you for the review.
>>>
>>> On Thursday 21 Apr 2016 08:39:59 Hans Verkuil wrote:  
 Hi Laurent,

 Thanks for the patch!

 Some, mostly small, comments follow:

 On 04/21/2016 02:40 AM, Laurent Pinchart wrote:  
> The meta-data video device is used to transfer meta-data between
> userspace and kernelspace through a V4L2 buffers queue. It comes with a
> new meta-data capture capability, buffer type and format description.
>
> Signed-off-by: Laurent Pinchart
> 
> ---
>
>  Documentation/DocBook/media/v4l/dev-meta.xml  | 100 +
>  Documentation/DocBook/media/v4l/v4l2.xml  |   1 +
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  19 +
>  drivers/media/v4l2-core/v4l2-dev.c|  21 +-
>  drivers/media/v4l2-core/v4l2-ioctl.c  |  39 ++
>  drivers/media/v4l2-core/videobuf2-v4l2.c  |   3 +
>  include/media/v4l2-dev.h  |   3 +-
>  include/media/v4l2-ioctl.h|   8 +++
>  include/uapi/linux/media.h|   2 +
>  include/uapi/linux/videodev2.h|  14 
>  10 files changed, 208 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/DocBook/media/v4l/dev-meta.xml
>
> diff --git a/Documentation/DocBook/media/v4l/dev-meta.xml
> b/Documentation/DocBook/media/v4l/dev-meta.xml new file mode 100644
> index ..ddc685186015
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/dev-meta.xml
> @@ -0,0 +1,100 @@
> +  Meta-Data Interface
> +
> +  
> +Experimental
> +This is an  experimental 
> +interface and may change in the future.
> +  
> +
> +  
> +Meta-data refers to any non-image data that supplements video frames with
> +additional information. This may include statistics computed over the
> image +or frame capture parameters supplied by the image source. This
> interface is +intended for transfer of meta-data to userspace and control
> of that operation. +  
> +
> +  
> +Meta-data devices are accessed through character device special files
> named +/dev/v4l-meta0 to
> /dev/v4l-meta255 +with major number 81 and
> dynamically allocated minor numbers 0 to 255. +  
> +
> +  
> +Querying Capabilities
> +
> +
> +Devices supporting the meta-data interface set the
> +V4L2_CAP_META_CAPTURE flag in the
> +capabilities field of &v4l2-capability;
> +returned by the &VIDIOC-QUERYCAP; ioctl. That flag means the device can
> capture +meta-data to memory.
> +
> +
> +At least one of the read/write, streaming or asynchronous I/O methods
> must  

 I think we can drop 'asynchronous I/O' since that's never been used. I
 assume this is copy-and-pasted and we should probably just remove any
 reference to async IO.  
>>>
>>> Agreed. I'll fix it.
>>>   
> +be supported.
> +
> +  
> +
> +  
> +Data Format Negotiation
> +
> +
> +The meta-data device uses the format ioctls
> to +select the capture format. The meta-data buffer content format is
> bound to that +selectable format. In addition to the basic
> +format ioctls, the &VIDIOC-ENUM-FMT; ioctl
> +must be supported as well.
> +
> +
> +
> +To use the format ioctls applications set
> the +type field of a &v4l2-format; to
> +V4L2_BUF_TYPE_META_CAPTURE and use the
> &v4l2-meta-format; +meta member of the
> fmt +union as needed per the desired
> operation.
> +Currently there are two fields, pixelformat
> and  

 Shouldn't that be metaformat? Since there are no pixels here? It was a bit
 dubious to call it pixelformat for SDR as well, but at least there you
 still have discrete samples which might be called pixels with some
 imagination. But certainly doesn't apply to meta data.  
>>>
>>> How about dataformat ? Or just format ?  
>>
>> Since the fourcc defines are called V4L2_META_FMT_ I think metaformat is a
>> good name. It's consistent with the other meta-related namings.
> 
> metaformat is OK.
> 
>>
>>>   
> +buffersize, of struct &v4l2-meta-format; that
> are +used. Content of the pixelformat is the
> V4L2 FourCC +code of the data format. The
> buffersize field is the +maximum buffer size
> in bytes required for data transfer, set by the driver in +order to
> inform applications.
> +
> +
> +
> +  struct v4l2_meta_format
> +  
> +&cs-str;
> +
> +  
> +__u32
> +pixelformat
> +  

Re: [PATCH/RFC 1/2] v4l: Add meta-data video device type

2016-04-22 Thread Mauro Carvalho Chehab
Em Fri, 22 Apr 2016 09:46:04 +0200
Hans Verkuil  escreveu:

> On 04/21/2016 09:15 PM, Laurent Pinchart wrote:
> > Hi Hans,
> > 
> > Thank you for the review.
> > 
> > On Thursday 21 Apr 2016 08:39:59 Hans Verkuil wrote:  
> >> Hi Laurent,
> >>
> >> Thanks for the patch!
> >>
> >> Some, mostly small, comments follow:
> >>
> >> On 04/21/2016 02:40 AM, Laurent Pinchart wrote:  
> >>> The meta-data video device is used to transfer meta-data between
> >>> userspace and kernelspace through a V4L2 buffers queue. It comes with a
> >>> new meta-data capture capability, buffer type and format description.
> >>>
> >>> Signed-off-by: Laurent Pinchart
> >>> 
> >>> ---
> >>>
> >>>  Documentation/DocBook/media/v4l/dev-meta.xml  | 100 +
> >>>  Documentation/DocBook/media/v4l/v4l2.xml  |   1 +
> >>>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  19 +
> >>>  drivers/media/v4l2-core/v4l2-dev.c|  21 +-
> >>>  drivers/media/v4l2-core/v4l2-ioctl.c  |  39 ++
> >>>  drivers/media/v4l2-core/videobuf2-v4l2.c  |   3 +
> >>>  include/media/v4l2-dev.h  |   3 +-
> >>>  include/media/v4l2-ioctl.h|   8 +++
> >>>  include/uapi/linux/media.h|   2 +
> >>>  include/uapi/linux/videodev2.h|  14 
> >>>  10 files changed, 208 insertions(+), 2 deletions(-)
> >>>  create mode 100644 Documentation/DocBook/media/v4l/dev-meta.xml
> >>>
> >>> diff --git a/Documentation/DocBook/media/v4l/dev-meta.xml
> >>> b/Documentation/DocBook/media/v4l/dev-meta.xml new file mode 100644
> >>> index ..ddc685186015
> >>> --- /dev/null
> >>> +++ b/Documentation/DocBook/media/v4l/dev-meta.xml
> >>> @@ -0,0 +1,100 @@
> >>> +  Meta-Data Interface
> >>> +
> >>> +  
> >>> +Experimental
> >>> +This is an  experimental 
> >>> +interface and may change in the future.
> >>> +  
> >>> +
> >>> +  
> >>> +Meta-data refers to any non-image data that supplements video frames with
> >>> +additional information. This may include statistics computed over the
> >>> image +or frame capture parameters supplied by the image source. This
> >>> interface is +intended for transfer of meta-data to userspace and control
> >>> of that operation. +  
> >>> +
> >>> +  
> >>> +Meta-data devices are accessed through character device special files
> >>> named +/dev/v4l-meta0 to
> >>> /dev/v4l-meta255 +with major number 81 and
> >>> dynamically allocated minor numbers 0 to 255. +  
> >>> +
> >>> +  
> >>> +Querying Capabilities
> >>> +
> >>> +
> >>> +Devices supporting the meta-data interface set the
> >>> +V4L2_CAP_META_CAPTURE flag in the
> >>> +capabilities field of &v4l2-capability;
> >>> +returned by the &VIDIOC-QUERYCAP; ioctl. That flag means the device can
> >>> capture +meta-data to memory.
> >>> +
> >>> +
> >>> +At least one of the read/write, streaming or asynchronous I/O methods
> >>> must  
> >>
> >> I think we can drop 'asynchronous I/O' since that's never been used. I
> >> assume this is copy-and-pasted and we should probably just remove any
> >> reference to async IO.  
> > 
> > Agreed. I'll fix it.
> >   
> >>> +be supported.
> >>> +
> >>> +  
> >>> +
> >>> +  
> >>> +Data Format Negotiation
> >>> +
> >>> +
> >>> +The meta-data device uses the format ioctls
> >>> to +select the capture format. The meta-data buffer content format is
> >>> bound to that +selectable format. In addition to the basic
> >>> +format ioctls, the &VIDIOC-ENUM-FMT; ioctl
> >>> +must be supported as well.
> >>> +
> >>> +
> >>> +
> >>> +To use the format ioctls applications set
> >>> the +type field of a &v4l2-format; to
> >>> +V4L2_BUF_TYPE_META_CAPTURE and use the
> >>> &v4l2-meta-format; +meta member of the
> >>> fmt +union as needed per the desired
> >>> operation.
> >>> +Currently there are two fields, pixelformat
> >>> and  
> >>
> >> Shouldn't that be metaformat? Since there are no pixels here? It was a bit
> >> dubious to call it pixelformat for SDR as well, but at least there you
> >> still have discrete samples which might be called pixels with some
> >> imagination. But certainly doesn't apply to meta data.  
> > 
> > How about dataformat ? Or just format ?  
> 
> Since the fourcc defines are called V4L2_META_FMT_ I think metaformat is a
> good name. It's consistent with the other meta-related namings.

metaformat is OK.

> 
> >   
> >>> +buffersize, of struct &v4l2-meta-format; that
> >>> are +used. Content of the pixelformat is the
> >>> V4L2 FourCC +code of the data format. The
> >>> buffersize field is the +maximum buffer size
> >>> in bytes required for data transfer, set by the driver in +order to
> >>> inform applications.
> >>> +
> >>> +
> >>> +
> >>> +  struct v4l2_meta_format
> >>> +  
> >>> +&cs-str;
> >>> +
> >>> +  
> >>> +__u32
> >>> +pixelformat
> >>> +
> >>> +The data format or type of compression, set by the

Re: [PATCH/RFC 1/2] v4l: Add meta-data video device type

2016-04-22 Thread Mauro Carvalho Chehab
Em Thu, 21 Apr 2016 03:40:26 +0300
Laurent Pinchart  escreveu:

> The meta-data video device is used to transfer meta-data between
> userspace and kernelspace through a V4L2 buffers queue. It comes with a
> new meta-data capture capability, buffer type and format description.

Thanks for the patch. I'm adding here some notes about a few things
that Hans and Sakari noticed. See below.

Regards,
Mauro

> 
> Signed-off-by: Laurent Pinchart 
> ---
>  Documentation/DocBook/media/v4l/dev-meta.xml  | 100 
> ++
>  Documentation/DocBook/media/v4l/v4l2.xml  |   1 +
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  19 +
>  drivers/media/v4l2-core/v4l2-dev.c|  21 +-
>  drivers/media/v4l2-core/v4l2-ioctl.c  |  39 ++
>  drivers/media/v4l2-core/videobuf2-v4l2.c  |   3 +
>  include/media/v4l2-dev.h  |   3 +-
>  include/media/v4l2-ioctl.h|   8 +++
>  include/uapi/linux/media.h|   2 +
>  include/uapi/linux/videodev2.h|  14 
>  10 files changed, 208 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/DocBook/media/v4l/dev-meta.xml
> 
> diff --git a/Documentation/DocBook/media/v4l/dev-meta.xml 
> b/Documentation/DocBook/media/v4l/dev-meta.xml
> new file mode 100644
> index ..ddc685186015
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/dev-meta.xml
> @@ -0,0 +1,100 @@
> +  Meta-Data Interface
> +
> +  
> +Experimental
> +This is an  experimental 
> +interface and may change in the future.
> +  

You know that, in practice, we may not be able to change it later, don't you?

> +
> +  
> +Meta-data refers to any non-image data that supplements video frames with

Please call it "Metadata" all over the patch.

> +additional information. This may include statistics computed over the image
> +or frame capture parameters supplied by the image source. This interface is
> +intended for transfer of meta-data to userspace and control of that 
> operation.
> +  
> +
> +  
> +Meta-data devices are accessed through character device special files named
> +/dev/v4l-meta0 to /dev/v4l-meta255
> +with major number 81 and dynamically allocated minor numbers 0 to 255.

I would suppress the range "0 to 255" here, and on other parts of the
document. Ok, there is a soft limit restricting the max number of V4L2
devices to 256, but this is something that may change any time someone
would need more.

> +  
> +
> +  
> +Querying Capabilities
> +
> +
> +Devices supporting the meta-data interface set the
> +V4L2_CAP_META_CAPTURE flag in the
> +capabilities field of &v4l2-capability;
> +returned by the &VIDIOC-QUERYCAP; ioctl. That flag means the device can 
> capture
> +meta-data to memory.
> +
> +
> +At least one of the read/write, streaming or asynchronous I/O methods must
> +be supported.
> +
> +  
> +
> +  
> +Data Format Negotiation
> +
> +
> +The meta-data device uses the format ioctls to
> +select the capture format. The meta-data buffer content format is bound to 
> that
> +selectable format. In addition to the basic
> +format ioctls, the &VIDIOC-ENUM-FMT; ioctl
> +must be supported as well.
> +
> +
> +
> +To use the format ioctls applications set the
> +type field of a &v4l2-format; to
> +V4L2_BUF_TYPE_META_CAPTURE and use the 
> &v4l2-meta-format;
> +meta member of the fmt
> +union as needed per the desired operation.
> +Currently there are two fields, pixelformat and
> +buffersize, of struct &v4l2-meta-format; that are
> +used. Content of the pixelformat is the V4L2 
> FourCC
> +code of the data format. The buffersize field is 
> the
> +maximum buffer size in bytes required for data transfer, set by the driver in
> +order to inform applications.
> +
> +
> +
> +  struct v4l2_meta_format
> +  
> +&cs-str;
> +
> +  
> +__u32
> +pixelformat
> +
> +The data format or type of compression, set by the application. This is a
> +little endian four character code.
> +V4L2 defines meta-data formats in .
> +   
> +  
> +  
> +__u32
> +buffersize
> +
> +Maximum size in bytes required for data. Value is set by the driver.
> +   
> +  
> +  
> +__u8
> +reserved[24]
> +This array is reserved for future extensions.
> +Drivers and applications must set it to zero.
> +  

Answering your discussions with Sakari about that, I'm OK on having a 
reserved field here, as this is what we're doing with the other members
of struct v4l2_format union.

> +
> +  
> +
> +
> +
> +A meta-data device may support read/write
> +and/or streaming (memory mapping
> +or user pointer) I/O.
> +
> +
> +  
> diff --git a/Documentation/DocBook/media/v4l/v4l2.xml 
> b/Documentation/DocBook/media/v4l/v4l2.xml
> index 42e626d6c936..5c83b5d342dd

Re: [PATCH v7 5/8] [media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver

2016-04-22 Thread Hans Verkuil
On 04/22/2016 06:25 AM, Tiffany Lin wrote:
> Add v4l2 layer encoder driver for MT8173
> 
> Signed-off-by: Tiffany Lin 
> 
> ---
>  drivers/media/platform/Kconfig |   16 +
>  drivers/media/platform/Makefile|2 +
>  drivers/media/platform/mtk-vcodec/Makefile |   14 +
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |  339 +
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1301 
> 
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h |   59 +
>  .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c |  467 +++
>  .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c  |  137 +++
>  .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.h  |   26 +
>  .../media/platform/mtk-vcodec/mtk_vcodec_intr.c|   56 +
>  .../media/platform/mtk-vcodec/mtk_vcodec_intr.h|   27 +
>  .../media/platform/mtk-vcodec/mtk_vcodec_util.c|   96 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_util.h|   87 ++
>  drivers/media/platform/mtk-vcodec/venc_drv_base.h  |   62 +
>  drivers/media/platform/mtk-vcodec/venc_drv_if.c|  107 ++
>  drivers/media/platform/mtk-vcodec/venc_drv_if.h|  165 +++
>  drivers/media/platform/mtk-vcodec/venc_ipi_msg.h   |  210 
>  17 files changed, 3171 insertions(+)
>  create mode 100644 drivers/media/platform/mtk-vcodec/Makefile
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_base.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h
> 
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c 
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> new file mode 100644
> index 000..b2b662c
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> @@ -0,0 +1,1301 @@
> +/* V4L2 specification suggests the driver corrects the format struct if any 
> of
> +  * the dimensions is unsupported
> +  */
> +static int vidioc_try_fmt(struct v4l2_format *f, struct mtk_video_fmt *fmt)
> +{
> + struct v4l2_pix_format_mplane *pix_fmt_mp = &f->fmt.pix_mp;
> + int i;
> +
> + pix_fmt_mp->field = V4L2_FIELD_NONE;
> +
> + if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> + pix_fmt_mp->num_planes = 1;
> + pix_fmt_mp->plane_fmt[0].bytesperline = 0;
> + } else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> + int tmp_w, tmp_h;
> +
> + pix_fmt_mp->height = clamp(pix_fmt_mp->height,
> + MTK_VENC_MIN_H,
> + MTK_VENC_MAX_H);
> + pix_fmt_mp->width = clamp(pix_fmt_mp->width,
> + MTK_VENC_MIN_W,
> + MTK_VENC_MAX_W);

Strange indentation. I see this in more places. Can you check this and fix
where needed?

> +
> + /* find next closer width align 16, heign align 32, size align
> +   * 64 rectangle
> +   */
> + tmp_w = pix_fmt_mp->width;
> + tmp_h = pix_fmt_mp->height;
> + v4l_bound_align_image(&pix_fmt_mp->width,
> + MTK_VENC_MIN_W,
> + MTK_VENC_MAX_W, 4,
> + &pix_fmt_mp->height,
> + MTK_VENC_MIN_H,
> + MTK_VENC_MAX_H, 5, 6);
> +

...

> +static int vidioc_try_fmt_vid_out_mplane(struct file *file, void *priv,
> +  struct v4l2_format *f)
> +{
> + struct mtk_video_fmt *fmt;
> +
> + fmt = mtk_venc_find_format(f);
> + if (!fmt) {
> + f->fmt.pix.pixelformat = mtk_video_formats[OUT_FMT_IDX].fourcc;
> + fmt = mtk_venc_find_format(f);
> + }
> + if (!f->fmt.pix_mp.colorspace)
> + f->fmt.pix_mp.colorspace = V4L2_COLORSPACE_REC709;
> + f->fmt.pix_mp.ycbcr_enc = V4L2_YCBCR_ENC_

Re: [PATCH 1/6] adv7180: fix broken standards handling

2016-04-22 Thread Federico Vaga
Acked-by: Federico Vaga 

On Friday, April 22, 2016 03:03:37 PM Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> The adv7180 attempts to autodetect the standard. Unfortunately this
> is seriously broken.
> 
> This patch removes the autodetect completely. Only the querystd op
> will detect the standard. Since the design of the adv7180 requires
> that you switch to a special autodetect mode you cannot call querystd
> when you are streaming.
> 
> So the s_stream op has been added so we know whether we are streaming
> or not, and if we are, then querystd returns EBUSY.
> 
> After testing this with a signal generator is became obvious that
> a sleep is needed between changing the standard to autodetect and
> reading the status. So the autodetect can never have worked well.
> 
> The s_std call now just sets the new standard without any querying.
> 
> If the driver supports the interrupt, then when it detects a standard
> change it will signal that by sending the V4L2_EVENT_SOURCE_CHANGE
> event.
> 
> With these changes this driver now behaves like all other video
> receivers.
> 
> Signed-off-by: Hans Verkuil 
> Cc: Niklas Söderlund 
> Cc: Lars-Peter Clausen 
> Cc: Federico Vaga 
> ---
>  drivers/media/i2c/adv7180.c | 118
> ++-- 1 file changed, 80
> insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
> index 51a92b3..5a75a91 100644
> --- a/drivers/media/i2c/adv7180.c
> +++ b/drivers/media/i2c/adv7180.c
> @@ -26,8 +26,9 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -192,8 +193,8 @@ struct adv7180_state {
>   struct mutexmutex; /* mutual excl. when accessing chip */
>   int irq;
>   v4l2_std_id curr_norm;
> - boolautodetect;
>   boolpowered;
> + boolstreaming;
>   u8  input;
> 
>   struct i2c_client   *client;
> @@ -338,12 +339,26 @@ static int adv7180_querystd(struct v4l2_subdev *sd,
> v4l2_std_id *std) if (err)
>   return err;
> 
> - /* when we are interrupt driven we know the state */
> - if (!state->autodetect || state->irq > 0)
> - *std = state->curr_norm;
> - else
> - err = __adv7180_status(state, NULL, std);
> + if (state->streaming) {
> + err = -EBUSY;
> + goto unlock;
> + }
> +
> + err = adv7180_set_video_standard(state,
> + ADV7180_STD_AD_PAL_BG_NTSC_J_SECAM);
> + if (err)
> + goto unlock;
> 
> + msleep(100);
> + __adv7180_status(state, NULL, std);
> +
> + err = v4l2_std_to_adv7180(state->curr_norm);
> + if (err < 0)
> + goto unlock;
> +
> + err = adv7180_set_video_standard(state, err);
> +
> +unlock:
>   mutex_unlock(&state->mutex);
>   return err;
>  }
> @@ -387,23 +402,13 @@ static int adv7180_program_std(struct adv7180_state
> *state) {
>   int ret;
> 
> - if (state->autodetect) {
> - ret = adv7180_set_video_standard(state,
> - ADV7180_STD_AD_PAL_BG_NTSC_J_SECAM);
> - if (ret < 0)
> - return ret;
> -
> - __adv7180_status(state, NULL, &state->curr_norm);
> - } else {
> - ret = v4l2_std_to_adv7180(state->curr_norm);
> - if (ret < 0)
> - return ret;
> -
> - ret = adv7180_set_video_standard(state, ret);
> - if (ret < 0)
> - return ret;
> - }
> + ret = v4l2_std_to_adv7180(state->curr_norm);
> + if (ret < 0)
> + return ret;
> 
> + ret = adv7180_set_video_standard(state, ret);
> + if (ret < 0)
> + return ret;
>   return 0;
>  }
> 
> @@ -415,18 +420,12 @@ static int adv7180_s_std(struct v4l2_subdev *sd,
> v4l2_std_id std) if (ret)
>   return ret;
> 
> - /* all standards -> autodetect */
> - if (std == V4L2_STD_ALL) {
> - state->autodetect = true;
> - } else {
> - /* Make sure we can support this std */
> - ret = v4l2_std_to_adv7180(std);
> - if (ret < 0)
> - goto out;
> + /* Make sure we can support this std */
> + ret = v4l2_std_to_adv7180(std);
> + if (ret < 0)
> + goto out;
> 
> - state->curr_norm = std;
> - state->autodetect = false;
> - }
> + state->curr_norm = std;
> 
>   ret = adv7180_program_std(state);
>  out:
> @@ -747,6 +746,40 @@ static int adv7180_g_tvnorms(struct v4l2_subdev *sd,
> v4l2_std_id *norm) return 0;
>  }
> 
> +static int adv7180_s_stream(struct v4l2_subdev *sd, int enable)
> +{
> + struct adv7180_state *state = to_state(sd);
> + int ret;
> +
> + /* It's always safe to stop streaming, no need to take the lock 

Re: [PATCH] media: fix media_open() to not release lock too soon

2016-04-22 Thread Mauro Carvalho Chehab
Em Wed, 20 Apr 2016 14:48:10 -0600
Shuah Khan  escreveu:

> media_open() releases media_devnode_lock before open is complete. Hold
> the lock to call mdev->fops->open and release at the end.

This patch looks scary on my eyes, as it has potential of causing
dead locks, if the code, depending on the code implemented at the
mdev->fops->open callback.

I suspect that the main reason for it to be like that is to call
mdev->fops-open() without any locks.

Right now, media_device_fops has an open that does nothing, but I'm not
sure if some driver change it to something else. On such case, we could
be taking media_devnode lock first, and then media_device on such open
callback, but, on other parts of the code, the code could be taking
media_device lock first, and than this one.

Did you check if such bad locks are not present in the code after
your changes at the platform drivers?

Regards,
Mauro

>
> Signed-off-by: Shuah Khan 
> ---
>  drivers/media/media-devnode.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/media-devnode.c b/drivers/media/media-devnode.c
> index 29409f4..0934789 100644
> --- a/drivers/media/media-devnode.c
> +++ b/drivers/media/media-devnode.c
> @@ -155,7 +155,7 @@ static long media_compat_ioctl(struct file *filp, 
> unsigned int cmd,
>  static int media_open(struct inode *inode, struct file *filp)
>  {
>   struct media_devnode *mdev;
> - int ret;
> + int ret = 0;
>  
>   /* Check if the media device is available. This needs to be done with
>* the media_devnode_lock held to prevent an open/unregister race:
> @@ -173,7 +173,6 @@ static int media_open(struct inode *inode, struct file 
> *filp)
>   }
>   /* and increase the device refcount */
>   get_device(&mdev->dev);
> - mutex_unlock(&media_devnode_lock);
>  
>   filp->private_data = mdev;
>  
> @@ -182,11 +181,12 @@ static int media_open(struct inode *inode, struct file 
> *filp)
>   if (ret) {
>   put_device(&mdev->dev);
>   filp->private_data = NULL;
> - return ret;
> + goto done;
>   }
>   }
> -
> - return 0;
> +done:
> + mutex_unlock(&media_devnode_lock);
> + return ret;
>  }
>  
>  /* Override for the release function */


-- 
Thanks,
Mauro
--
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/6] sta2x11_vip: fix s_std

2016-04-22 Thread Hans Verkuil
On 04/22/2016 03:15 PM, Federico Vaga wrote:
> Acked-by: Federico Vaga 
> 
> It sounds fine to me (even the ADV7180 patch). Unfortunately I do not have 
> the 
> hardware to test it.

Your Ack will have to suffice :-)

Can you Ack the adv7180 patch as well? Would be nice.

Regards,

Hans

> 
> On Friday, April 22, 2016 03:03:38 PM Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> The s_std ioctl was broken in this driver, partially due to the
>> changes to the adv7180 driver (this affected the handling of
>> V4L2_STD_ALL) and partially because the new standard was never
>> stored in vip->std.
>>
>> The handling of V4L2_STD_ALL has been rewritten to just call querystd
>> and the new standard is now stored correctly.
>>
>> Signed-off-by: Hans Verkuil 
>> Cc: Federico Vaga 
>> ---
>>  drivers/media/pci/sta2x11/sta2x11_vip.c | 26 ++
>>  1 file changed, 10 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/media/pci/sta2x11/sta2x11_vip.c
>> b/drivers/media/pci/sta2x11/sta2x11_vip.c index 753411c..c79623c 100644
>> --- a/drivers/media/pci/sta2x11/sta2x11_vip.c
>> +++ b/drivers/media/pci/sta2x11/sta2x11_vip.c
>> @@ -444,27 +444,21 @@ static int vidioc_querycap(struct file *file, void
>> *priv, static int vidioc_s_std(struct file *file, void *priv, v4l2_std_id
>> std) {
>>  struct sta2x11_vip *vip = video_drvdata(file);
>> -v4l2_std_id oldstd = vip->std, newstd;
>> +v4l2_std_id oldstd = vip->std;
>>  int status;
>>
>> -if (V4L2_STD_ALL == std) {
>> -v4l2_subdev_call(vip->decoder, video, s_std, std);
>> -ssleep(2);
>> -v4l2_subdev_call(vip->decoder, video, querystd, &newstd);
>> -v4l2_subdev_call(vip->decoder, video, g_input_status, &status);
>> -if (status & V4L2_IN_ST_NO_SIGNAL)
>> +/*
>> + * This is here for backwards compatibility only.
>> + * The use of V4L2_STD_ALL to trigger a querystd is non-standard.
>> + */
>> +if (std == V4L2_STD_ALL) {
>> +v4l2_subdev_call(vip->decoder, video, querystd, &std);
>> +if (std == V4L2_STD_UNKNOWN)
>>  return -EIO;
>> -std = vip->std = newstd;
>> -if (oldstd != std) {
>> -if (V4L2_STD_525_60 & std)
>> -vip->format = formats_60[0];
>> -else
>> -vip->format = formats_50[0];
>> -}
>> -return 0;
>>  }
>>
>> -if (oldstd != std) {
>> +if (vip->std != std) {
>> +vip->std = std;
>>  if (V4L2_STD_525_60 & std)
>>  vip->format = formats_60[0];
>>  else
> 

--
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/6] sta2x11_vip: fix s_std

2016-04-22 Thread Federico Vaga
Acked-by: Federico Vaga 

It sounds fine to me (even the ADV7180 patch). Unfortunately I do not have the 
hardware to test it.

On Friday, April 22, 2016 03:03:38 PM Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> The s_std ioctl was broken in this driver, partially due to the
> changes to the adv7180 driver (this affected the handling of
> V4L2_STD_ALL) and partially because the new standard was never
> stored in vip->std.
> 
> The handling of V4L2_STD_ALL has been rewritten to just call querystd
> and the new standard is now stored correctly.
> 
> Signed-off-by: Hans Verkuil 
> Cc: Federico Vaga 
> ---
>  drivers/media/pci/sta2x11/sta2x11_vip.c | 26 ++
>  1 file changed, 10 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/media/pci/sta2x11/sta2x11_vip.c
> b/drivers/media/pci/sta2x11/sta2x11_vip.c index 753411c..c79623c 100644
> --- a/drivers/media/pci/sta2x11/sta2x11_vip.c
> +++ b/drivers/media/pci/sta2x11/sta2x11_vip.c
> @@ -444,27 +444,21 @@ static int vidioc_querycap(struct file *file, void
> *priv, static int vidioc_s_std(struct file *file, void *priv, v4l2_std_id
> std) {
>   struct sta2x11_vip *vip = video_drvdata(file);
> - v4l2_std_id oldstd = vip->std, newstd;
> + v4l2_std_id oldstd = vip->std;
>   int status;
> 
> - if (V4L2_STD_ALL == std) {
> - v4l2_subdev_call(vip->decoder, video, s_std, std);
> - ssleep(2);
> - v4l2_subdev_call(vip->decoder, video, querystd, &newstd);
> - v4l2_subdev_call(vip->decoder, video, g_input_status, &status);
> - if (status & V4L2_IN_ST_NO_SIGNAL)
> + /*
> +  * This is here for backwards compatibility only.
> +  * The use of V4L2_STD_ALL to trigger a querystd is non-standard.
> +  */
> + if (std == V4L2_STD_ALL) {
> + v4l2_subdev_call(vip->decoder, video, querystd, &std);
> + if (std == V4L2_STD_UNKNOWN)
>   return -EIO;
> - std = vip->std = newstd;
> - if (oldstd != std) {
> - if (V4L2_STD_525_60 & std)
> - vip->format = formats_60[0];
> - else
> - vip->format = formats_50[0];
> - }
> - return 0;
>   }
> 
> - if (oldstd != std) {
> + if (vip->std != std) {
> + vip->std = std;
>   if (V4L2_STD_525_60 & std)
>   vip->format = formats_60[0];
>   else

-- 
Federico Vaga
--
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] VPU: mediatek: fix simple_open.cocci warnings

2016-04-22 Thread Julia Lawall
Remove an open coded simple_open() function
and replace file operations references to the function
with simple_open() instead.

Generated by: scripts/coccinelle/api/simple_open.cocci

CC: Andrew-CT Chen 
Signed-off-by: Fengguang Wu 
Signed-off-by: Julia Lawall 
---

I'm just passing this along.  Simple_open additionally has a check that
inode->i_private is not NULL, before doing the assignment.  I don't know
if that difference is important in this case.

base:   git://linuxtv.org/media_tree.git master

 mtk_vpu.c |7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

--- a/drivers/media/platform/mtk-vpu/mtk_vpu.c
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
@@ -599,11 +599,6 @@ static void vpu_init_ipi_handler(void *d
 }

 #ifdef CONFIG_DEBUG_FS
-static int vpu_debug_open(struct inode *inode, struct file *file)
-{
-   file->private_data = inode->i_private;
-   return 0;
-}

 static ssize_t vpu_debug_read(struct file *file, char __user *user_buf,
  size_t count, loff_t *ppos)
@@ -646,7 +641,7 @@ static ssize_t vpu_debug_read(struct fil
 }

 static const struct file_operations vpu_debug_fops = {
-   .open = vpu_debug_open,
+   .open = simple_open,
.read = vpu_debug_read,
 };
 #endif /* CONFIG_DEBUG_FS */
--
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] VPU: mediatek: fix platform_no_drv_owner.cocci warnings

2016-04-22 Thread Julia Lawall
Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: Andrew-CT Chen 
Signed-off-by: Fengguang Wu 
Signed-off-by: Julia Lawall 
---

base:   git://linuxtv.org/media_tree.git master

 mtk_vpu.c |1 -
 1 file changed, 1 deletion(-)

--- a/drivers/media/platform/mtk-vpu/mtk_vpu.c
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
@@ -939,7 +939,6 @@ static struct platform_driver mtk_vpu_dr
.remove = mtk_vpu_remove,
.driver = {
.name   = "mtk_vpu",
-   .owner  = THIS_MODULE,
.of_match_table = mtk_vpu_match,
},
 };
--
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 5/6] media/i2c/adv*: make controls inheritable instead of private

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

Marking these controls as private seemed a good idea at one time,
but in practice it makes no sense. So drop this.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/ad9389b.c | 8 
 drivers/media/i2c/adv7511.c | 6 --
 drivers/media/i2c/adv7604.c | 8 
 drivers/media/i2c/adv7842.c | 6 --
 4 files changed, 28 deletions(-)

diff --git a/drivers/media/i2c/ad9389b.c b/drivers/media/i2c/ad9389b.c
index 788967d..0462f46 100644
--- a/drivers/media/i2c/ad9389b.c
+++ b/drivers/media/i2c/ad9389b.c
@@ -1130,8 +1130,6 @@ static int ad9389b_probe(struct i2c_client *client, const 
struct i2c_device_id *
hdl = &state->hdl;
v4l2_ctrl_handler_init(hdl, 5);
 
-   /* private controls */
-
state->hdmi_mode_ctrl = v4l2_ctrl_new_std_menu(hdl, &ad9389b_ctrl_ops,
V4L2_CID_DV_TX_MODE, V4L2_DV_TX_MODE_HDMI,
0, V4L2_DV_TX_MODE_DVI_D);
@@ -1151,12 +1149,6 @@ static int ad9389b_probe(struct i2c_client *client, 
const struct i2c_device_id *
 
goto err_hdl;
}
-   state->hdmi_mode_ctrl->is_private = true;
-   state->hotplug_ctrl->is_private = true;
-   state->rx_sense_ctrl->is_private = true;
-   state->have_edid0_ctrl->is_private = true;
-   state->rgb_quantization_range_ctrl->is_private = true;
-
state->pad.flags = MEDIA_PAD_FL_SINK;
err = media_entity_pads_init(&sd->entity, 1, &state->pad);
if (err)
diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index bd822f0..39271c3 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -1502,12 +1502,6 @@ static int adv7511_probe(struct i2c_client *client, 
const struct i2c_device_id *
err = hdl->error;
goto err_hdl;
}
-   state->hdmi_mode_ctrl->is_private = true;
-   state->hotplug_ctrl->is_private = true;
-   state->rx_sense_ctrl->is_private = true;
-   state->have_edid0_ctrl->is_private = true;
-   state->rgb_quantization_range_ctrl->is_private = true;
-
state->pad.flags = MEDIA_PAD_FL_SINK;
err = media_entity_pads_init(&sd->entity, 1, &state->pad);
if (err)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 41a1bfc..beb2841 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -3141,7 +3141,6 @@ static int adv76xx_probe(struct i2c_client *client,
if (ctrl)
ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
 
-   /* private controls */
state->detect_tx_5v_ctrl = v4l2_ctrl_new_std(hdl, NULL,
V4L2_CID_DV_RX_POWER_PRESENT, 0,
(1 << state->info->num_dv_ports) - 1, 0, 0);
@@ -3164,13 +3163,6 @@ static int adv76xx_probe(struct i2c_client *client,
err = hdl->error;
goto err_hdl;
}
-   state->detect_tx_5v_ctrl->is_private = true;
-   state->rgb_quantization_range_ctrl->is_private = true;
-   if (adv76xx_has_afe(state))
-   state->analog_sampling_phase_ctrl->is_private = true;
-   state->free_run_color_manual_ctrl->is_private = true;
-   state->free_run_color_ctrl->is_private = true;
-
if (adv76xx_s_detect_tx_5v_ctrl(sd)) {
err = -ENODEV;
goto err_hdl;
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 7ccb85d..ecaacb0 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -3300,12 +3300,6 @@ static int adv7842_probe(struct i2c_client *client,
err = hdl->error;
goto err_hdl;
}
-   state->detect_tx_5v_ctrl->is_private = true;
-   state->rgb_quantization_range_ctrl->is_private = true;
-   state->analog_sampling_phase_ctrl->is_private = true;
-   state->free_run_color_ctrl_manual->is_private = true;
-   state->free_run_color_ctrl->is_private = true;
-
if (adv7842_s_detect_tx_5v_ctrl(sd)) {
err = -ENODEV;
goto err_hdl;
-- 
2.8.0.rc3

--
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 3/6] rcar-vin: support the source change event and fix s_std

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

The patch adds support for the source change event and it fixes
the s_std support: changing the standard will also change the
resolution, and that was never updated.

Signed-off-by: Hans Verkuil 
Cc: Niklas Söderlund 
Cc: Ulrich Hecht 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 48 +++--
 1 file changed, 46 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 8ac6149..49058ea 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -421,8 +421,25 @@ static int rvin_s_std(struct file *file, void *priv, 
v4l2_std_id a)
 {
struct rvin_dev *vin = video_drvdata(file);
struct v4l2_subdev *sd = vin_to_sd(vin);
+   struct v4l2_subdev_format fmt = {
+   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   };
+   struct v4l2_mbus_framefmt *mf = &fmt.format;
+   int ret = v4l2_subdev_call(sd, video, s_std, a);
+
+   if (ret < 0)
+   return ret;
 
-   return v4l2_subdev_call(sd, video, s_std, a);
+   /* Changing the standard will change the width/height */
+   ret = v4l2_subdev_call(sd, pad, get_fmt, NULL, &fmt);
+   if (ret) {
+   vin_err(vin, "Failed to get initial format\n");
+   return ret;
+   }
+
+   vin->format.width = mf->width;
+   vin->format.height = mf->height;
+   return 0;
 }
 
 static int rvin_g_std(struct file *file, void *priv, v4l2_std_id *a)
@@ -433,6 +450,16 @@ static int rvin_g_std(struct file *file, void *priv, 
v4l2_std_id *a)
return v4l2_subdev_call(sd, video, g_std, a);
 }
 
+static int rvin_subscribe_event(struct v4l2_fh *fh,
+   const struct v4l2_event_subscription *sub)
+{
+   switch (sub->type) {
+   case V4L2_EVENT_SOURCE_CHANGE:
+   return v4l2_event_subscribe(fh, sub, 4, NULL);
+   }
+   return v4l2_ctrl_subscribe_event(fh, sub);
+}
+
 static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
.vidioc_querycap= rvin_querycap,
.vidioc_try_fmt_vid_cap = rvin_try_fmt_vid_cap,
@@ -464,7 +491,7 @@ static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
.vidioc_streamoff   = vb2_ioctl_streamoff,
 
.vidioc_log_status  = v4l2_ctrl_log_status,
-   .vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
+   .vidioc_subscribe_event = rvin_subscribe_event,
.vidioc_unsubscribe_event   = v4l2_event_unsubscribe,
 };
 
@@ -623,6 +650,21 @@ void rvin_v4l2_remove(struct rvin_dev *vin)
video_unregister_device(&vin->vdev);
 }
 
+static void rvin_notify(struct v4l2_subdev *sd,
+   unsigned int notification, void *arg)
+{
+   struct rvin_dev *vin =
+   container_of(sd->v4l2_dev, struct rvin_dev, v4l2_dev);
+
+   switch (notification) {
+   case V4L2_DEVICE_NOTIFY_EVENT:
+   v4l2_event_queue(&vin->vdev, arg);
+   break;
+   default:
+   break;
+   }
+}
+
 int rvin_v4l2_probe(struct rvin_dev *vin)
 {
struct v4l2_subdev_format fmt = {
@@ -635,6 +677,8 @@ int rvin_v4l2_probe(struct rvin_dev *vin)
 
v4l2_set_subdev_hostdata(sd, vin);
 
+   vin->v4l2_dev.notify = rvin_notify;
+
ret = v4l2_subdev_call(sd, video, g_tvnorms, &vin->vdev.tvnorms);
if (ret < 0 && ret != -ENOIOCTLCMD && ret != -ENODEV)
return ret;
-- 
2.8.0.rc3

--
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/6] sta2x11_vip: fix s_std

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

The s_std ioctl was broken in this driver, partially due to the
changes to the adv7180 driver (this affected the handling of
V4L2_STD_ALL) and partially because the new standard was never
stored in vip->std.

The handling of V4L2_STD_ALL has been rewritten to just call querystd
and the new standard is now stored correctly.

Signed-off-by: Hans Verkuil 
Cc: Federico Vaga 
---
 drivers/media/pci/sta2x11/sta2x11_vip.c | 26 ++
 1 file changed, 10 insertions(+), 16 deletions(-)

diff --git a/drivers/media/pci/sta2x11/sta2x11_vip.c 
b/drivers/media/pci/sta2x11/sta2x11_vip.c
index 753411c..c79623c 100644
--- a/drivers/media/pci/sta2x11/sta2x11_vip.c
+++ b/drivers/media/pci/sta2x11/sta2x11_vip.c
@@ -444,27 +444,21 @@ static int vidioc_querycap(struct file *file, void *priv,
 static int vidioc_s_std(struct file *file, void *priv, v4l2_std_id std)
 {
struct sta2x11_vip *vip = video_drvdata(file);
-   v4l2_std_id oldstd = vip->std, newstd;
+   v4l2_std_id oldstd = vip->std;
int status;
 
-   if (V4L2_STD_ALL == std) {
-   v4l2_subdev_call(vip->decoder, video, s_std, std);
-   ssleep(2);
-   v4l2_subdev_call(vip->decoder, video, querystd, &newstd);
-   v4l2_subdev_call(vip->decoder, video, g_input_status, &status);
-   if (status & V4L2_IN_ST_NO_SIGNAL)
+   /*
+* This is here for backwards compatibility only.
+* The use of V4L2_STD_ALL to trigger a querystd is non-standard.
+*/
+   if (std == V4L2_STD_ALL) {
+   v4l2_subdev_call(vip->decoder, video, querystd, &std);
+   if (std == V4L2_STD_UNKNOWN)
return -EIO;
-   std = vip->std = newstd;
-   if (oldstd != std) {
-   if (V4L2_STD_525_60 & std)
-   vip->format = formats_60[0];
-   else
-   vip->format = formats_50[0];
-   }
-   return 0;
}
 
-   if (oldstd != std) {
+   if (vip->std != std) {
+   vip->std = std;
if (V4L2_STD_525_60 & std)
vip->format = formats_60[0];
else
-- 
2.8.0.rc3

--
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 4/6] tc358743: drop bogus comment

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

The control in question is not a private control, so drop that
comment. Copy-and-paste left-over.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/tc358743.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index 73e0cef..6cf6d06 100644
--- a/drivers/media/i2c/tc358743.c
+++ b/drivers/media/i2c/tc358743.c
@@ -1863,7 +1863,6 @@ static int tc358743_probe(struct i2c_client *client,
/* control handlers */
v4l2_ctrl_handler_init(&state->hdl, 3);
 
-   /* private controls */
state->detect_tx_5v_ctrl = v4l2_ctrl_new_std(&state->hdl, NULL,
V4L2_CID_DV_RX_POWER_PRESENT, 0, 1, 0, 0);
 
-- 
2.8.0.rc3

--
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/6] adv7180: fix broken standards handling

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

The adv7180 attempts to autodetect the standard. Unfortunately this
is seriously broken.

This patch removes the autodetect completely. Only the querystd op
will detect the standard. Since the design of the adv7180 requires
that you switch to a special autodetect mode you cannot call querystd
when you are streaming.

So the s_stream op has been added so we know whether we are streaming
or not, and if we are, then querystd returns EBUSY.

After testing this with a signal generator is became obvious that
a sleep is needed between changing the standard to autodetect and
reading the status. So the autodetect can never have worked well.

The s_std call now just sets the new standard without any querying.

If the driver supports the interrupt, then when it detects a standard
change it will signal that by sending the V4L2_EVENT_SOURCE_CHANGE
event.

With these changes this driver now behaves like all other video
receivers.

Signed-off-by: Hans Verkuil 
Cc: Niklas Söderlund 
Cc: Lars-Peter Clausen 
Cc: Federico Vaga 
---
 drivers/media/i2c/adv7180.c | 118 ++--
 1 file changed, 80 insertions(+), 38 deletions(-)

diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 51a92b3..5a75a91 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -26,8 +26,9 @@
 #include 
 #include 
 #include 
-#include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -192,8 +193,8 @@ struct adv7180_state {
struct mutexmutex; /* mutual excl. when accessing chip */
int irq;
v4l2_std_id curr_norm;
-   boolautodetect;
boolpowered;
+   boolstreaming;
u8  input;
 
struct i2c_client   *client;
@@ -338,12 +339,26 @@ static int adv7180_querystd(struct v4l2_subdev *sd, 
v4l2_std_id *std)
if (err)
return err;
 
-   /* when we are interrupt driven we know the state */
-   if (!state->autodetect || state->irq > 0)
-   *std = state->curr_norm;
-   else
-   err = __adv7180_status(state, NULL, std);
+   if (state->streaming) {
+   err = -EBUSY;
+   goto unlock;
+   }
+
+   err = adv7180_set_video_standard(state,
+   ADV7180_STD_AD_PAL_BG_NTSC_J_SECAM);
+   if (err)
+   goto unlock;
 
+   msleep(100);
+   __adv7180_status(state, NULL, std);
+
+   err = v4l2_std_to_adv7180(state->curr_norm);
+   if (err < 0)
+   goto unlock;
+
+   err = adv7180_set_video_standard(state, err);
+
+unlock:
mutex_unlock(&state->mutex);
return err;
 }
@@ -387,23 +402,13 @@ static int adv7180_program_std(struct adv7180_state 
*state)
 {
int ret;
 
-   if (state->autodetect) {
-   ret = adv7180_set_video_standard(state,
-   ADV7180_STD_AD_PAL_BG_NTSC_J_SECAM);
-   if (ret < 0)
-   return ret;
-
-   __adv7180_status(state, NULL, &state->curr_norm);
-   } else {
-   ret = v4l2_std_to_adv7180(state->curr_norm);
-   if (ret < 0)
-   return ret;
-
-   ret = adv7180_set_video_standard(state, ret);
-   if (ret < 0)
-   return ret;
-   }
+   ret = v4l2_std_to_adv7180(state->curr_norm);
+   if (ret < 0)
+   return ret;
 
+   ret = adv7180_set_video_standard(state, ret);
+   if (ret < 0)
+   return ret;
return 0;
 }
 
@@ -415,18 +420,12 @@ static int adv7180_s_std(struct v4l2_subdev *sd, 
v4l2_std_id std)
if (ret)
return ret;
 
-   /* all standards -> autodetect */
-   if (std == V4L2_STD_ALL) {
-   state->autodetect = true;
-   } else {
-   /* Make sure we can support this std */
-   ret = v4l2_std_to_adv7180(std);
-   if (ret < 0)
-   goto out;
+   /* Make sure we can support this std */
+   ret = v4l2_std_to_adv7180(std);
+   if (ret < 0)
+   goto out;
 
-   state->curr_norm = std;
-   state->autodetect = false;
-   }
+   state->curr_norm = std;
 
ret = adv7180_program_std(state);
 out:
@@ -747,6 +746,40 @@ static int adv7180_g_tvnorms(struct v4l2_subdev *sd, 
v4l2_std_id *norm)
return 0;
 }
 
+static int adv7180_s_stream(struct v4l2_subdev *sd, int enable)
+{
+   struct adv7180_state *state = to_state(sd);
+   int ret;
+
+   /* It's always safe to stop streaming, no need to take the lock */
+   if (!enable) {
+   state->streaming = enable;
+   return 0;
+   }
+
+   /* Must wait until querystd released the lock */
+   ret = mutex_lock_interruptible(&state-

[PATCH 0/6] Various rcar-vin and adv* fixes

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

While testing Niklas' new rcar-vin driver I found various problems
that is fixed in this patch series.

The main problem is the adv7180 driver which was simply broken when
it comes to detecting standards. This should now be fixed (at least
it works for me now).

As a result the sta2x11_vip driver needed to be changed as well.

The new rcar-vin driver driver didn't support the source change event.
While not relevant for the adv7180 driver (at least on the Koelsch
board the irq from that chip isn't hooked up), it certainly is needed
for the adv7612 driver. It doesn't hurt to add it here.

Niklas, just fold it in your patch.

The v4l2-compliance test complained about a missing V4L2_CID_DV_RX_POWER_PRESENT
control. This was because that control was marked private. The reality
is that that makes no sense and the control should just be inherited by
the rcar-vin driver. In practice making this private is just annoying.

The last patch is an rcar-vin bug fix. Niklas, just fold it in your
patch for the v8.

Niklas, Federico, can you both check the adv7180 changes?

Regards,

Hans

Hans Verkuil (6):
  adv7180: fix broken standards handling
  sta2x11_vip: fix s_std
  rcar-vin: support the source change event and fix s_std
  tc358743: drop bogus comment
  media/i2c/adv*: make controls inheritable instead of private
  rcar-vin: failed start_streaming didn't call s_stream(0)

 drivers/media/i2c/ad9389b.c |   8 --
 drivers/media/i2c/adv7180.c | 118 +++-
 drivers/media/i2c/adv7511.c |   6 --
 drivers/media/i2c/adv7604.c |   8 --
 drivers/media/i2c/adv7842.c |   6 --
 drivers/media/i2c/tc358743.c|   1 -
 drivers/media/pci/sta2x11/sta2x11_vip.c |  26 +++---
 drivers/media/platform/rcar-vin/rcar-dma.c  |   4 +-
 drivers/media/platform/rcar-vin/rcar-v4l2.c |  48 ++-
 9 files changed, 139 insertions(+), 86 deletions(-)

-- 
2.8.0.rc3

--
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 6/6] rcar-vin: failed start_streaming didn't call s_stream(0)

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

This can leave adv7180 in an inconsistent state

Signed-off-by: Hans Verkuil 
Cc: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 644ec9b..087c30c 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -1058,8 +1058,10 @@ static int rvin_start_streaming(struct vb2_queue *vq, 
unsigned int count)
ret = rvin_capture_start(vin);
 out:
/* Return all buffers if something went wrong */
-   if (ret)
+   if (ret) {
return_all_buffers(vin, VB2_BUF_STATE_QUEUED);
+   v4l2_subdev_call(sd, video, s_stream, 0);
+   }
 
spin_unlock_irqrestore(&vin->qlock, flags);
 
-- 
2.8.0.rc3

--
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: vb2: Fix regression on poll() for RW mode

2016-04-22 Thread Hans Verkuil
On 04/22/2016 02:31 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 22 Apr 2016 11:19:09 +0200
> Hans Verkuil  escreveu:
> 
>> Hi Ricardo,
>>
>> On 04/21/2016 11:15 AM, Ricardo Ribalda Delgado wrote:
>>> When using a device is read/write mode, vb2 does not handle properly the
>>> first select/poll operation. It allways return POLLERR.
>>>
>>> The reason for this is that when this code has been refactored, some of
>>> the operations have changed their order, and now fileio emulator is not
>>> started by poll, due to a previous check.
>>>
>>> Reported-by: Dimitrios Katsaros 
>>> Cc: Junghak Sung 
>>> Cc: sta...@vger.kernel.org
>>> Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
>>> Signed-off-by: Ricardo Ribalda Delgado 
>>> ---
>>>  drivers/media/v4l2-core/videobuf2-core.c | 8 
>>>  drivers/media/v4l2-core/videobuf2-v4l2.c | 8 
>>>  2 files changed, 8 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
>>> b/drivers/media/v4l2-core/videobuf2-core.c
>>> index 5d016f496e0e..199c65dbe330 100644
>>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>>> @@ -2298,6 +2298,14 @@ unsigned int vb2_core_poll(struct vb2_queue *q, 
>>> struct file *file,
>>> return 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 waiting_for_buffers to false.
>>> +*/
>>> +   if (q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
>>> +   return POLLERR;  
>>
>> The problem I have with this is that this should be specific to V4L2. The 
>> only
>> reason we do this is that we had to stay backwards compatible with vb1.
>>
>> This is the reason this code was placed in videobuf2-v4l2.c. But you are 
>> correct
>> that this causes a regression, and I see no other choice but to put it in 
>> core.c.
>>
>> That said, I would still only honor this when called from v4l2, so I suggest 
>> that
>> a new flag 'check_waiting_for_buffers' is added that is only set in 
>> vb2_queue_init
>> in videobuf2-v4l2.c.
>>
>> So the test above becomes:
>>
>>  if (q->check_waiting_for_buffers && q->waiting_for_buffers &&
>>  (req_events & (POLLIN | POLLRDNORM)))
>>
>> It's not ideal, but at least this keeps this v4l2 specific.
> 
> I don't like the above approach, for two reasons:
> 
> 1) it is not obvious that this is V4L2 specific from the code;

s/check_waiting_for_buffers/v4l2_needs_to_wait_for_buffers/

> 
> 2) we should not mess the core due to some V4L2 mess.

Well, the only other alternative I see is to split vb2_core_poll() into two
since the check has to happen in the middle. The v4l2 code would call 
core_poll1(),
then do the check and afterwards call core_poll2(). And that would really be 
ugly.
I would probably NACK that.

Better ideas are welcome.

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


Re: [PATCH v3 5/7] media: rcar-vin: add DV timings support

2016-04-22 Thread Hans Verkuil
New review of this code. Ignore the previous one.

On 04/14/2016 06:17 PM, Ulrich Hecht wrote:
> Adds ioctls DV_TIMINGS_CAP, ENUM_DV_TIMINGS, G_DV_TIMINGS, S_DV_TIMINGS,
> and QUERY_DV_TIMINGS.
> 
> Signed-off-by: Ulrich Hecht 
> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 69 
> +
>  1 file changed, 69 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index d8d5f3a..ba2ed4e 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -413,12 +413,17 @@ static int rvin_enum_input(struct file *file, void 
> *priv,
>  struct v4l2_input *i)
>  {
>   struct rvin_dev *vin = video_drvdata(file);
> + struct v4l2_subdev *sd = vin_to_sd(vin);
>  
>   if (i->index != 0)
>   return -EINVAL;
>  
>   i->type = V4L2_INPUT_TYPE_CAMERA;
>   i->std = vin->vdev.tvnorms;
> +
> + if (v4l2_subdev_has_op(sd, pad, dv_timings_cap))
> + i->capabilities = V4L2_IN_CAP_DV_TIMINGS;
> +
>   strlcpy(i->name, "Camera", sizeof(i->name));

I think it is better to use "HDMI" as the name.

>  
>   return 0;
> @@ -461,6 +466,64 @@ static int rvin_g_std(struct file *file, void *priv, 
> v4l2_std_id *a)
>   return v4l2_subdev_call(sd, video, g_std, a);
>  }
>  
> +static int rvin_enum_dv_timings(struct file *file, void *priv_fh,
> + struct v4l2_enum_dv_timings *timings)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> + struct v4l2_subdev *sd = vin_to_sd(vin);
> +
> + timings->pad = 0;

You should use vin->src_pad_idx here instead of 0.

> + return v4l2_subdev_call(sd,
> + pad, enum_dv_timings, timings);

The original pad value should be restored.

> +}
> +
> +static int rvin_s_dv_timings(struct file *file, void *priv_fh,
> + struct v4l2_dv_timings *timings)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> + struct v4l2_subdev *sd = vin_to_sd(vin);
> + int err;
> +
> + err = v4l2_subdev_call(sd,
> + video, s_dv_timings, timings);
> + if (!err) {
> + vin->sensor.width = timings->bt.width;
> + vin->sensor.height = timings->bt.height;
> + }
> + return err;
> +}
> +
> +static int rvin_g_dv_timings(struct file *file, void *priv_fh,
> + struct v4l2_dv_timings *timings)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> + struct v4l2_subdev *sd = vin_to_sd(vin);
> +
> + return v4l2_subdev_call(sd,
> + video, g_dv_timings, timings);
> +}
> +
> +static int rvin_query_dv_timings(struct file *file, void *priv_fh,
> + struct v4l2_dv_timings *timings)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> + struct v4l2_subdev *sd = vin_to_sd(vin);
> +
> + return v4l2_subdev_call(sd,
> + video, query_dv_timings, timings);
> +}
> +
> +static int rvin_dv_timings_cap(struct file *file, void *priv_fh,
> + struct v4l2_dv_timings_cap *cap)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> + struct v4l2_subdev *sd = vin_to_sd(vin);
> +
> + cap->pad = 0;
> + return v4l2_subdev_call(sd,
> + pad, dv_timings_cap, cap);

The comments for enum_dv_timings apply here as well.

> +}
> +
>  static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
>   .vidioc_querycap= rvin_querycap,
>   .vidioc_try_fmt_vid_cap = rvin_try_fmt_vid_cap,
> @@ -477,6 +540,12 @@ static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
>   .vidioc_g_input = rvin_g_input,
>   .vidioc_s_input = rvin_s_input,
>  
> + .vidioc_dv_timings_cap  = rvin_dv_timings_cap,
> + .vidioc_enum_dv_timings = rvin_enum_dv_timings,
> + .vidioc_g_dv_timings= rvin_g_dv_timings,
> + .vidioc_s_dv_timings= rvin_s_dv_timings,
> + .vidioc_query_dv_timings= rvin_query_dv_timings,
> +
>   .vidioc_querystd= rvin_querystd,
>   .vidioc_g_std   = rvin_g_std,
>   .vidioc_s_std   = rvin_s_std,
> 

You also need to support the SOURCE_CHANGE event, but I will post a patch for
that myself later.

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


Re: [PATCH] media: vb2: Fix regression on poll() for RW mode

2016-04-22 Thread Mauro Carvalho Chehab
Em Fri, 22 Apr 2016 11:19:09 +0200
Hans Verkuil  escreveu:

> Hi Ricardo,
> 
> On 04/21/2016 11:15 AM, Ricardo Ribalda Delgado wrote:
> > When using a device is read/write mode, vb2 does not handle properly the
> > first select/poll operation. It allways return POLLERR.
> > 
> > The reason for this is that when this code has been refactored, some of
> > the operations have changed their order, and now fileio emulator is not
> > started by poll, due to a previous check.
> > 
> > Reported-by: Dimitrios Katsaros 
> > Cc: Junghak Sung 
> > Cc: sta...@vger.kernel.org
> > Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
> > Signed-off-by: Ricardo Ribalda Delgado 
> > ---
> >  drivers/media/v4l2-core/videobuf2-core.c | 8 
> >  drivers/media/v4l2-core/videobuf2-v4l2.c | 8 
> >  2 files changed, 8 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index 5d016f496e0e..199c65dbe330 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -2298,6 +2298,14 @@ unsigned int vb2_core_poll(struct vb2_queue *q, 
> > struct file *file,
> > return 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 waiting_for_buffers to false.
> > +*/
> > +   if (q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
> > +   return POLLERR;  
> 
> The problem I have with this is that this should be specific to V4L2. The only
> reason we do this is that we had to stay backwards compatible with vb1.
> 
> This is the reason this code was placed in videobuf2-v4l2.c. But you are 
> correct
> that this causes a regression, and I see no other choice but to put it in 
> core.c.
> 
> That said, I would still only honor this when called from v4l2, so I suggest 
> that
> a new flag 'check_waiting_for_buffers' is added that is only set in 
> vb2_queue_init
> in videobuf2-v4l2.c.
> 
> So the test above becomes:
> 
>   if (q->check_waiting_for_buffers && q->waiting_for_buffers &&
>   (req_events & (POLLIN | POLLRDNORM)))
> 
> It's not ideal, but at least this keeps this v4l2 specific.

I don't like the above approach, for two reasons:

1) it is not obvious that this is V4L2 specific from the code;

2) we should not mess the core due to some V4L2 mess.


> 
> Regards,
> 
>   Hans
> 
> > +
> > +   /*
> >  * For output streams you can call write() as long as there are fewer
> >  * buffers queued than there are buffers available.
> >  */
> > diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> > b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > index 91f552124050..c9bad9ef2104 100644
> > --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> > +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > @@ -818,14 +818,6 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file 
> > *file, poll_table *wait)
> > poll_wait(file, &fh->wait, wait);
> > }
> >  
> > -   /*
> > -* 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 waiting_for_buffers to false.
> > -*/
> > -   if (q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
> > -   return POLLERR;
> > -
> > return res | vb2_core_poll(q, file, wait);
> >  }
> >  EXPORT_SYMBOL_GPL(vb2_poll);
> >   
> 


-- 
Thanks,
Mauro
--
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: vb2: Fix regression on poll() for RW mode

2016-04-22 Thread Mauro Carvalho Chehab
Em Thu, 21 Apr 2016 11:15:16 +0200
Ricardo Ribalda Delgado  escreveu:

> When using a device is read/write mode, vb2 does not handle properly the
> first select/poll operation. It allways return POLLERR.
> 
> The reason for this is that when this code has been refactored, some of
> the operations have changed their order, and now fileio emulator is not
> started by poll, due to a previous check.
> 
> Reported-by: Dimitrios Katsaros 
> Cc: Junghak Sung 
> Cc: sta...@vger.kernel.org
> Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  drivers/media/v4l2-core/videobuf2-core.c | 8 
>  drivers/media/v4l2-core/videobuf2-v4l2.c | 8 
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 5d016f496e0e..199c65dbe330 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -2298,6 +2298,14 @@ unsigned int vb2_core_poll(struct vb2_queue *q, struct 
> file *file,
>   return 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 waiting_for_buffers to false.
> +  */
> + if (q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
> + return POLLERR;
> +

No, we shouldn't do VB1 backward compatibility at the core, as this
is a special case that only applies for V4L2. The hole idea of splitting
the core and the v4l2-specific code is to allow VB2 to be used on other
places, like on DVB.

So, we need some other approach that would keep this specific to V4L2.

> + /*
>* For output streams you can call write() as long as there are fewer
>* buffers queued than there are buffers available.
>*/
> diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> b/drivers/media/v4l2-core/videobuf2-v4l2.c
> index 91f552124050..c9bad9ef2104 100644
> --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> @@ -818,14 +818,6 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file 
> *file, poll_table *wait)
>   poll_wait(file, &fh->wait, wait);
>   }
>  
> - /*
> -  * 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 waiting_for_buffers to false.
> -  */
> - if (q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
> - return POLLERR;
> -
>   return res | vb2_core_poll(q, file, wait);
>  }
>  EXPORT_SYMBOL_GPL(vb2_poll);


-- 
Thanks,
Mauro
--
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 v3 5/7] media: rcar-vin: add DV timings support

2016-04-22 Thread Hans Verkuil
On 04/20/2016 06:24 PM, Ulrich Hecht wrote:
> On Mon, Apr 18, 2016 at 12:04 PM, Hans Verkuil  wrote:
>> Hi Ulrich,
>>
>> This isn't right: this just overwrites the adv7180 input with an HDMI input.
>>
>> I assume the intention is to have support for both adv7180 and HDMI input and
>> to use VIDIOC_S_INPUT to select between the two.
> 
> I'm not quite sure what you mean.  The inputs are always hardwired to
> one specific decoder, no switching possible.

Never mind, I thought the composite and hdmi inputs where muxed to the same
rcar-vin instance, but each goes to the same instance.

I'll re-review the patch with that in mind.

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


Re: [PATCH v7 00/24] i2c mux cleanup and locking update

2016-04-22 Thread Peter Rosin
Wolfram Sang wrote:
> > The problem with waiting until 4.8 with the rest of the series is that it
> > will likely go stale, e.g. patch 22 ([media] rtl2832: change the i2c gate
> > to be mux-locked) touches a ton of register accesses in that driver since
> > it removes a regmap wrapper that is rendered obsolete. Expecting that
> > patch to work for 4.8 is overly optimistic, and while patching things up
> 
> Okay, that can be argued, I understand that. So, what about this
> suggestion: I pull in patches 1-15 today, and we schedule the rest of
> the patches for like next week or so. That still gives the first set of
> patches some time in linux-next for further exposure and testing whilst
> the whole series should arrive in 4.7.

That sounds really good, thanks!

> However, I need help with that. There are serious locking changes
> involved and ideally these patches are reviewed by multiple people,
> especially patches 16-19. I first want to say that the collaboration
> experience with this series was great so far, lots of testing and
> reporting back. Thanks for that already. Yet, if we want to have this in
> 4.7, this needs to be a group effort. So, if people interested could
> review even a little and report back this would be extremly helpful.

Yes please!

> > Third, should we deprecate the old i2c_add_mux_adapter, so that new
> > users do not crop up behind our backs in the transition? Or not bother?
> 
> Usually it is fine to change in-kernel-APIs when you take care that all
> current users are converted. But I am also fine with being nice and
> keeping the old call around for a few cycles. It is your call.

Ok, I'm a bit fed up with this series and will ignore it then.

> > Fourth, I forgot to change patch 8 (iio: imu: inv_mpu6050: convert to
> > use an explicit i2c mux core) to not change i2c_get_clientdata() ->
> > dev_get_drvdata() as requested by Jonathan Cameron. How should I handle
> > that?
> 
> I'll pull in the first patches this eveneing. You can choose to send me
> an incremental patch or resend patch 8. I am fine with both, but it
> should appear on the mailing list somehow.

I just sent a v8 of 08/24 (not sending a whole v8 for that though)

> > There are also some new Tested-by tags that I have added to my
> > local branch but have not pushed anywhere. I'm ready to push all that
> > to a new branch once you are ready to take it.
> 
> For the patches 1-15, I am ready when you are :)

Ok, I pushed out v8, see below. Pick what you want :-)

Cheers,
Peter

The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:

  Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)

are available in the git repository at:

  https://github.com/peda-r/i2c-mux.git mux-core-and-locking-8

for you to fetch changes up to b9a0ea3a309a3a4051c7c0cc54ade0eb5a877896:

  [media] rtl2832: regmap is aware of lockdep, drop local locking hack 
(2016-04-22 12:18:45 +0200)


Antti Palosaari (1):
  [media] si2168: change the i2c gate to be mux-locked

Peter Rosin (23):
  i2c-mux: add common data for every i2c-mux instance
  i2c: i2c-mux-gpio: convert to use an explicit i2c mux core
  i2c: i2c-mux-pinctrl: convert to use an explicit i2c mux core
  i2c: i2c-arb-gpio-challenge: convert to use an explicit i2c mux core
  i2c: i2c-mux-pca9541: convert to use an explicit i2c mux core
  i2c: i2c-mux-pca954x: convert to use an explicit i2c mux core
  i2c: i2c-mux-reg: convert to use an explicit i2c mux core
  iio: imu: inv_mpu6050: convert to use an explicit i2c mux core
  [media] m88ds3103: convert to use an explicit i2c mux core
  [media] rtl2830: convert to use an explicit i2c mux core
  [media] rtl2832: convert to use an explicit i2c mux core
  [media] si2168: convert to use an explicit i2c mux core
  [media] cx231xx: convert to use an explicit i2c mux core
  of/unittest: convert to use an explicit i2c mux core
  i2c-mux: drop old unused i2c-mux api
  i2c: allow adapter drivers to override the adapter locking
  i2c: muxes always lock the parent adapter
  i2c-mux: relax locking of the top i2c adapter during mux-locked muxing
  i2c-mux: document i2c muxes and elaborate on parent-/mux-locked muxes
  iio: imu: inv_mpu6050: change the i2c gate to be mux-locked
  [media] rtl2832: change the i2c gate to be mux-locked
  [media] rtl2832_sdr: get rid of empty regmap wrappers
  [media] rtl2832: regmap is aware of lockdep, drop local locking hack

 Documentation/i2c/i2c-topology   | 370 +++
 MAINTAINERS  |   1 +
 drivers/i2c/i2c-core.c   |  66 +++--
 drivers/i2c/i2c-mux.c| 297 -
 drivers/i2c/muxes/i2c-arb-gpio-challenge.c   |  47 ++--
 drivers/i2c/muxes/i2c-mux-gpio.c |  73 +++---
 drivers/i2c/muxes/i2c-mux-pca9541.c  |  58 ++

[PATCH v8 08/24] iio: imu: inv_mpu6050: convert to use an explicit i2c mux core

2016-04-22 Thread Peter Rosin
Allocate an explicit i2c mux core to handle parent and child adapters
etc. Update the select/deselect ops to be in terms of the i2c mux core
instead of the child adapter.

Acked-by: Jonathan Cameron 
Signed-off-by: Peter Rosin 
---
 drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c |  2 +-
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c |  1 -
 drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c  | 33 +++---
 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h  |  3 ++-
 4 files changed, 19 insertions(+), 20 deletions(-)

v8 compared to v7:
- Do not change i2c_get_clientdata() into dev_get_drvdata()

diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c 
b/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
index 2771106fd650..f62b8bd9ad7e 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
@@ -183,7 +183,7 @@ int inv_mpu_acpi_create_mux_client(struct i2c_client 
*client)
} else
return 0; /* no secondary addr, which is OK */
}
-   st->mux_client = i2c_new_device(st->mux_adapter, &info);
+   st->mux_client = i2c_new_device(st->muxc->adapter[0], &info);
if (!st->mux_client)
return -ENODEV;
}
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c 
b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
index d192953e9a38..0c2bded2b5b7 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include "inv_mpu_iio.h"
 
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c 
b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
index f581256d9d4c..3a078df84224 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include "inv_mpu_iio.h"
@@ -52,10 +51,9 @@ static int inv_mpu6050_write_reg_unlocked(struct i2c_client 
*client,
return 0;
 }
 
-static int inv_mpu6050_select_bypass(struct i2c_adapter *adap, void *mux_priv,
-u32 chan_id)
+static int inv_mpu6050_select_bypass(struct i2c_mux_core *muxc, u32 chan_id)
 {
-   struct i2c_client *client = mux_priv;
+   struct i2c_client *client = i2c_mux_priv(muxc);
struct iio_dev *indio_dev = dev_get_drvdata(&client->dev);
struct inv_mpu6050_state *st = iio_priv(indio_dev);
int ret = 0;
@@ -84,10 +82,9 @@ write_error:
return ret;
 }
 
-static int inv_mpu6050_deselect_bypass(struct i2c_adapter *adap,
-  void *mux_priv, u32 chan_id)
+static int inv_mpu6050_deselect_bypass(struct i2c_mux_core *muxc, u32 chan_id)
 {
-   struct i2c_client *client = mux_priv;
+   struct i2c_client *client = i2c_mux_priv(muxc);
struct iio_dev *indio_dev = dev_get_drvdata(&client->dev);
struct inv_mpu6050_state *st = iio_priv(indio_dev);
 
@@ -136,16 +133,18 @@ static int inv_mpu_probe(struct i2c_client *client,
return result;
 
st = iio_priv(dev_get_drvdata(&client->dev));
-   st->mux_adapter = i2c_add_mux_adapter(client->adapter,
- &client->dev,
- client,
- 0, 0, 0,
- inv_mpu6050_select_bypass,
- inv_mpu6050_deselect_bypass);
-   if (!st->mux_adapter) {
-   result = -ENODEV;
+   st->muxc = i2c_mux_alloc(client->adapter, &client->dev,
+1, 0, 0,
+inv_mpu6050_select_bypass,
+inv_mpu6050_deselect_bypass);
+   if (!st->muxc) {
+   result = -ENOMEM;
goto out_unreg_device;
}
+   st->muxc->priv = dev_get_drvdata(&client->dev);
+   result = i2c_mux_add_adapter(st->muxc, 0, 0, 0);
+   if (result)
+   goto out_unreg_device;
 
result = inv_mpu_acpi_create_mux_client(client);
if (result)
@@ -154,7 +153,7 @@ static int inv_mpu_probe(struct i2c_client *client,
return 0;
 
 out_del_mux:
-   i2c_del_mux_adapter(st->mux_adapter);
+   i2c_mux_del_adapters(st->muxc);
 out_unreg_device:
inv_mpu_core_remove(&client->dev);
return result;
@@ -166,7 +165,7 @@ static int inv_mpu_remove(struct i2c_client *client)
struct inv_mpu6050_state *st = iio_priv(indio_dev);
 
inv_mpu_acpi_delete_mux_client(client);
-   i2c_del_mux_adapter(st->mux_adapter);
+   i2c_mux_del_adapters(st->muxc);
 
return inv_mpu_core_remove(&client->dev);
 }
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h 
b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
index e302a49703bf..bb3cef6d7059 100644
--- a/d

Re: [PATCH v7 00/24] i2c mux cleanup and locking update

2016-04-22 Thread Wolfram Sang

> The problem with waiting until 4.8 with the rest of the series is that it
> will likely go stale, e.g. patch 22 ([media] rtl2832: change the i2c gate
> to be mux-locked) touches a ton of register accesses in that driver since
> it removes a regmap wrapper that is rendered obsolete. Expecting that
> patch to work for 4.8 is overly optimistic, and while patching things up

Okay, that can be argued, I understand that. So, what about this
suggestion: I pull in patches 1-15 today, and we schedule the rest of
the patches for like next week or so. That still gives the first set of
patches some time in linux-next for further exposure and testing whilst
the whole series should arrive in 4.7.

However, I need help with that. There are serious locking changes
involved and ideally these patches are reviewed by multiple people,
especially patches 16-19. I first want to say that the collaboration
experience with this series was great so far, lots of testing and
reporting back. Thanks for that already. Yet, if we want to have this in
4.7, this needs to be a group effort. So, if people interested could
review even a little and report back this would be extremly helpful.

> Third, should we deprecate the old i2c_add_mux_adapter, so that new
> users do not crop up behind our backs in the transition? Or not bother?

Usually it is fine to change in-kernel-APIs when you take care that all
current users are converted. But I am also fine with being nice and
keeping the old call around for a few cycles. It is your call.

> Fourth, I forgot to change patch 8 (iio: imu: inv_mpu6050: convert to
> use an explicit i2c mux core) to not change i2c_get_clientdata() ->
> dev_get_drvdata() as requested by Jonathan Cameron. How should I handle
> that?

I'll pull in the first patches this eveneing. You can choose to send me
an incremental patch or resend patch 8. I am fine with both, but it
should appear on the mailing list somehow.

> There are also some new Tested-by tags that I have added to my
> local branch but have not pushed anywhere. I'm ready to push all that
> to a new branch once you are ready to take it.

For the patches 1-15, I am ready when you are :)

Thanks,

   Wolfram



signature.asc
Description: PGP signature


[patch] [media] cx231xx: silence uninitialized variable warning

2016-04-22 Thread Dan Carpenter
We print an uninitialized "actlen" variable on the error path.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/media/usb/cx231xx/cx231xx-core.c 
b/drivers/media/usb/cx231xx/cx231xx-core.c
index f497888..6741fd0 100644
--- a/drivers/media/usb/cx231xx/cx231xx-core.c
+++ b/drivers/media/usb/cx231xx/cx231xx-core.c
@@ -752,7 +752,8 @@ EXPORT_SYMBOL_GPL(cx231xx_set_mode);
 int cx231xx_ep5_bulkout(struct cx231xx *dev, u8 *firmware, u16 size)
 {
int errCode = 0;
-   int actlen, ret = -ENOMEM;
+   int actlen = -1;
+   int ret = -ENOMEM;
u32 *buffer;
 
buffer = kzalloc(4096, GFP_KERNEL);
--
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: vb2: Fix regression on poll() for RW mode

2016-04-22 Thread Hans Verkuil
On 04/22/2016 11:47 AM, Ricardo Ribalda Delgado wrote:
> Thanks for your review!
> 
> I will fix it that way. Do you mind to wait until Monday for a patch?

No problem.

Hans

> 
> Regards
> 
> On 22 Apr 2016 11:19, "Hans Verkuil"  > wrote:
> 
> Hi Ricardo,
> 
> On 04/21/2016 11:15 AM, Ricardo Ribalda Delgado wrote:
> > When using a device is read/write mode, vb2 does not handle properly the
> > first select/poll operation. It allways return POLLERR.
> >
> > The reason for this is that when this code has been refactored, some of
> > the operations have changed their order, and now fileio emulator is not
> > started by poll, due to a previous check.
> >
> > Reported-by: Dimitrios Katsaros  >
> > Cc: Junghak Sung  >
> > Cc: sta...@vger.kernel.org 
> > Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
> > Signed-off-by: Ricardo Ribalda Delgado  >
> > ---
> >  drivers/media/v4l2-core/videobuf2-core.c | 8 
> >  drivers/media/v4l2-core/videobuf2-v4l2.c | 8 
> >  2 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> > index 5d016f496e0e..199c65dbe330 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -2298,6 +2298,14 @@ unsigned int vb2_core_poll(struct vb2_queue *q, 
> struct file *file,
> >   return 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 waiting_for_buffers to false.
> > +  */
> > + if (q->waiting_for_buffers && (req_events & (POLLIN | 
> POLLRDNORM)))
> > + return POLLERR;
> 
> The problem I have with this is that this should be specific to V4L2. The 
> only
> reason we do this is that we had to stay backwards compatible with vb1.
> 
> This is the reason this code was placed in videobuf2-v4l2.c. But you are 
> correct
> that this causes a regression, and I see no other choice but to put it in 
> core.c.
> 
> That said, I would still only honor this when called from v4l2, so I 
> suggest that
> a new flag 'check_waiting_for_buffers' is added that is only set in 
> vb2_queue_init
> in videobuf2-v4l2.c.
> 
> So the test above becomes:
> 
> if (q->check_waiting_for_buffers && q->waiting_for_buffers &&
> (req_events & (POLLIN | POLLRDNORM)))
> 
> It's not ideal, but at least this keeps this v4l2 specific.
> 
> Regards,
> 
> Hans
> 
> > +
> > + /*
> >* For output streams you can call write() as long as there are 
> fewer
> >* buffers queued than there are buffers available.
> >*/
> > diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > index 91f552124050..c9bad9ef2104 100644
> > --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> > +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > @@ -818,14 +818,6 @@ unsigned int vb2_poll(struct vb2_queue *q, struct 
> file *file, poll_table *wait)
> >   poll_wait(file, &fh->wait, wait);
> >   }
> >
> > - /*
> > -  * 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 waiting_for_buffers to false.
> > -  */
> > - if (q->waiting_for_buffers && (req_events & (POLLIN | 
> POLLRDNORM)))
> > - return POLLERR;
> > -
> >   return res | vb2_core_poll(q, file, wait);
> >  }
> >  EXPORT_SYMBOL_GPL(vb2_poll);
> >
> 

--
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 v7 4/8] dt-bindings: Add a binding for Mediatek Video Encoder

2016-04-22 Thread kbuild test robot
Hi,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.6-rc4 next-20160421]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Tiffany-Lin/Add-MT8173-Video-Encoder-Driver-and-VPU-Driver/20160422-123111
base:   git://linuxtv.org/media_tree.git master
config: i386-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> ERROR: "max_pfn" [drivers/media/platform/mtk-vpu/mtk-vpu.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH] media: vb2: Fix regression on poll() for RW mode

2016-04-22 Thread Hans Verkuil
Hi Ricardo,

On 04/21/2016 11:15 AM, Ricardo Ribalda Delgado wrote:
> When using a device is read/write mode, vb2 does not handle properly the
> first select/poll operation. It allways return POLLERR.
> 
> The reason for this is that when this code has been refactored, some of
> the operations have changed their order, and now fileio emulator is not
> started by poll, due to a previous check.
> 
> Reported-by: Dimitrios Katsaros 
> Cc: Junghak Sung 
> Cc: sta...@vger.kernel.org
> Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  drivers/media/v4l2-core/videobuf2-core.c | 8 
>  drivers/media/v4l2-core/videobuf2-v4l2.c | 8 
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 5d016f496e0e..199c65dbe330 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -2298,6 +2298,14 @@ unsigned int vb2_core_poll(struct vb2_queue *q, struct 
> file *file,
>   return 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 waiting_for_buffers to false.
> +  */
> + if (q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
> + return POLLERR;

The problem I have with this is that this should be specific to V4L2. The only
reason we do this is that we had to stay backwards compatible with vb1.

This is the reason this code was placed in videobuf2-v4l2.c. But you are correct
that this causes a regression, and I see no other choice but to put it in 
core.c.

That said, I would still only honor this when called from v4l2, so I suggest 
that
a new flag 'check_waiting_for_buffers' is added that is only set in 
vb2_queue_init
in videobuf2-v4l2.c.

So the test above becomes:

if (q->check_waiting_for_buffers && q->waiting_for_buffers &&
(req_events & (POLLIN | POLLRDNORM)))

It's not ideal, but at least this keeps this v4l2 specific.

Regards,

Hans

> +
> + /*
>* For output streams you can call write() as long as there are fewer
>* buffers queued than there are buffers available.
>*/
> diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> b/drivers/media/v4l2-core/videobuf2-v4l2.c
> index 91f552124050..c9bad9ef2104 100644
> --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> @@ -818,14 +818,6 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file 
> *file, poll_table *wait)
>   poll_wait(file, &fh->wait, wait);
>   }
>  
> - /*
> -  * 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 waiting_for_buffers to false.
> -  */
> - if (q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
> - return POLLERR;
> -
>   return res | vb2_core_poll(q, file, wait);
>  }
>  EXPORT_SYMBOL_GPL(vb2_poll);
> 

--
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] DocBook media: drop 'experimental' annotations

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

Drop the 'experimental' annotations. The only remaining part of the API
that is still marked 'experimental' are the debug ioctls/structs, and
that is intentional. Only the v4l2-dbg application should use those.

All others have been around for years, so it is time to drop the
'experimental' designation.

Signed-off-by: Hans Verkuil 
---
 Documentation/DocBook/media/v4l/compat.xml | 38 --
 Documentation/DocBook/media/v4l/controls.xml   | 31 --
 Documentation/DocBook/media/v4l/dev-sdr.xml|  6 
 Documentation/DocBook/media/v4l/dev-subdev.xml |  6 
 Documentation/DocBook/media/v4l/io.xml |  6 
 Documentation/DocBook/media/v4l/selection-api.xml  |  9 +
 Documentation/DocBook/media/v4l/subdev-formats.xml |  6 
 .../DocBook/media/v4l/vidioc-create-bufs.xml   |  6 
 .../DocBook/media/v4l/vidioc-dv-timings-cap.xml|  6 
 .../DocBook/media/v4l/vidioc-enum-dv-timings.xml   |  6 
 .../DocBook/media/v4l/vidioc-enum-freq-bands.xml   |  6 
 Documentation/DocBook/media/v4l/vidioc-expbuf.xml  |  6 
 .../DocBook/media/v4l/vidioc-g-selection.xml   |  6 
 .../DocBook/media/v4l/vidioc-prepare-buf.xml   |  6 
 .../DocBook/media/v4l/vidioc-query-dv-timings.xml  |  6 
 .../v4l/vidioc-subdev-enum-frame-interval.xml  |  6 
 .../media/v4l/vidioc-subdev-enum-frame-size.xml|  6 
 .../media/v4l/vidioc-subdev-enum-mbus-code.xml |  6 
 .../DocBook/media/v4l/vidioc-subdev-g-fmt.xml  |  6 
 .../media/v4l/vidioc-subdev-g-frame-interval.xml   |  6 
 .../media/v4l/vidioc-subdev-g-selection.xml|  6 
 21 files changed, 1 insertion(+), 185 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/compat.xml 
b/Documentation/DocBook/media/v4l/compat.xml
index 5399e89..82fa328 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2686,50 +2686,12 @@ and may change in the future.
 
   
 
- Video Output Overlay (OSD) Interface, .
-
-
  &VIDIOC-DBG-G-REGISTER; and &VIDIOC-DBG-S-REGISTER;
 ioctls.
 
 
  &VIDIOC-DBG-G-CHIP-INFO; ioctl.
 
-
- &VIDIOC-ENUM-DV-TIMINGS;, &VIDIOC-QUERY-DV-TIMINGS; and
- &VIDIOC-DV-TIMINGS-CAP; ioctls.
-
-
- Flash API. 
-
-
- &VIDIOC-CREATE-BUFS; and &VIDIOC-PREPARE-BUF; ioctls.
-
-
- Selection API. 
-
-
- Sub-device selection API: &VIDIOC-SUBDEV-G-SELECTION;
- and &VIDIOC-SUBDEV-S-SELECTION; ioctls.
-
-
- Support for frequency band enumeration: 
&VIDIOC-ENUM-FREQ-BANDS; ioctl.
-
-
- Vendor and device specific media bus pixel formats.
-   .
-
-
- Importing DMABUF file descriptors as a new IO method described
- in .
-
-
- Exporting DMABUF files using &VIDIOC-EXPBUF; ioctl.
-
-
- Software Defined Radio (SDR) Interface, .
-
   
 
 
diff --git a/Documentation/DocBook/media/v4l/controls.xml 
b/Documentation/DocBook/media/v4l/controls.xml
index 361040e..81efa88 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -4272,13 +4272,6 @@ manually or automatically if set to zero. Unit, range 
and step are driver-specif
 
   Flash Control Reference
 
-  
-   Experimental
-
-   This is an experimental
-interface and may change in the future.
-  
-
   
The V4L2 flash controls are intended to provide generic access
to flash controller devices. Flash controller devices are
@@ -4743,14 +4736,6 @@ interface and may change in the future.
 
   Image Source Control Reference
 
-  
-   Experimental
-
-   This is an experimental interface and may
-   change in the future.
-  
-
   
The Image Source control class is intended for low-level
control of image source devices such as image sensors. The
@@ -4862,14 +4847,6 @@ interface and may change in the future.
 
   Image Process Control Reference
 
-  
-   Experimental
-
-   This is an experimental interface and may
-   change in the future.
-  
-
   
The Image Process control class is intended for low-level control of
image processing functions. Unlike
@@ -4955,14 +4932,6 @@ interface and may change in the future.
 
   Digital Video Control Reference
 
-  
-   Experimental
-
-   This is an experimental interface and may
-   change in the future.
-  
-
   
The Digital Video control class is intended to control receivers
and transmitters for http://en.wikipedia.org/wiki/Vga";>VGA,
diff --git a/Documentation/DocBook/media/v4l/dev-sdr.xml 
b/Documentatio

[PATCH 0/2] Drop obsolete 'experimental' annotations

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

Both in videodev2.h and in the documentation there are a lot of features
marked 'experimental' that have been around for years. Remove these
annotations since it was pure laziness that we didn't do that before.

Regards,

Hans

Hans Verkuil (2):
  videodev2.h: remove 'experimental' annotations.
  DocBook media: drop 'experimental' annotations

 Documentation/DocBook/media/v4l/compat.xml | 38 --
 Documentation/DocBook/media/v4l/controls.xml   | 31 --
 Documentation/DocBook/media/v4l/dev-sdr.xml|  6 
 Documentation/DocBook/media/v4l/dev-subdev.xml |  6 
 Documentation/DocBook/media/v4l/io.xml |  6 
 Documentation/DocBook/media/v4l/selection-api.xml  |  9 +
 Documentation/DocBook/media/v4l/subdev-formats.xml |  6 
 .../DocBook/media/v4l/vidioc-create-bufs.xml   |  6 
 .../DocBook/media/v4l/vidioc-dv-timings-cap.xml|  6 
 .../DocBook/media/v4l/vidioc-enum-dv-timings.xml   |  6 
 .../DocBook/media/v4l/vidioc-enum-freq-bands.xml   |  6 
 Documentation/DocBook/media/v4l/vidioc-expbuf.xml  |  6 
 .../DocBook/media/v4l/vidioc-g-selection.xml   |  6 
 .../DocBook/media/v4l/vidioc-prepare-buf.xml   |  6 
 .../DocBook/media/v4l/vidioc-query-dv-timings.xml  |  6 
 .../v4l/vidioc-subdev-enum-frame-interval.xml  |  6 
 .../media/v4l/vidioc-subdev-enum-frame-size.xml|  6 
 .../media/v4l/vidioc-subdev-enum-mbus-code.xml |  6 
 .../DocBook/media/v4l/vidioc-subdev-g-fmt.xml  |  6 
 .../media/v4l/vidioc-subdev-g-frame-interval.xml   |  6 
 .../media/v4l/vidioc-subdev-g-selection.xml|  6 
 include/uapi/linux/videodev2.h | 38 ++
 22 files changed, 11 insertions(+), 213 deletions(-)

-- 
2.8.0.rc3

--
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] videodev2.h: remove 'experimental' annotations.

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

Most of what is marked as 'experimental' has been around for years. Time
to drop that annotation.

The only remaining 'experimental' bits of the API are the debug ioctls
and structs: these should remain experimental since the only application
that should use this is v4l2-dbg.

Signed-off-by: Hans Verkuil 
---
 include/uapi/linux/videodev2.h | 38 ++
 1 file changed, 10 insertions(+), 28 deletions(-)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index e895975..8f95191 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -138,10 +138,7 @@ enum v4l2_buf_type {
V4L2_BUF_TYPE_VBI_OUTPUT   = 5,
V4L2_BUF_TYPE_SLICED_VBI_CAPTURE   = 6,
V4L2_BUF_TYPE_SLICED_VBI_OUTPUT= 7,
-#if 1
-   /* Experimental */
V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
-#endif
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 9,
V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE  = 10,
V4L2_BUF_TYPE_SDR_CAPTURE  = 11,
@@ -657,8 +654,7 @@ struct v4l2_fmtdesc {
 #define V4L2_FMT_FLAG_COMPRESSED 0x0001
 #define V4L2_FMT_FLAG_EMULATED   0x0002
 
-#if 1
-   /* Experimental Frame Size and frame rate enumeration */
+   /* Frame Size and frame rate enumeration */
 /*
  * F R A M E   S I Z E   E N U M E R A T I O N
  */
@@ -724,7 +720,6 @@ struct v4l2_frmivalenum {
 
__u32   reserved[2];/* Reserved space for future 
use */
 };
-#endif
 
 /*
  * T I M E C O D E
@@ -1728,8 +1723,6 @@ struct v4l2_audioout {
 
 /*
  * M P E G   S E R V I C E S
- *
- * NOTE: EXPERIMENTAL API
  */
 #if 1
 #define V4L2_ENC_IDX_FRAME_I(0)
@@ -2259,46 +2252,35 @@ struct v4l2_create_buffers {
 #define VIDIOC_ENCODER_CMD  _IOWR('V', 77, struct v4l2_encoder_cmd)
 #define VIDIOC_TRY_ENCODER_CMD  _IOWR('V', 78, struct v4l2_encoder_cmd)
 
-/* Experimental, meant for debugging, testing and internal use.
-   Only implemented if CONFIG_VIDEO_ADV_DEBUG is defined.
-   You must be root to use these ioctls. Never use these in applications! */
+/*
+ * Experimental, meant for debugging, testing and internal use.
+ * Only implemented if CONFIG_VIDEO_ADV_DEBUG is defined.
+ * You must be root to use these ioctls. Never use these in applications!
+ */
 #defineVIDIOC_DBG_S_REGISTER_IOW('V', 79, struct v4l2_dbg_register)
 #defineVIDIOC_DBG_G_REGISTER   _IOWR('V', 80, struct v4l2_dbg_register)
 
 #define VIDIOC_S_HW_FREQ_SEEK   _IOW('V', 82, struct v4l2_hw_freq_seek)
-
 #defineVIDIOC_S_DV_TIMINGS _IOWR('V', 87, struct v4l2_dv_timings)
 #defineVIDIOC_G_DV_TIMINGS _IOWR('V', 88, struct v4l2_dv_timings)
 #defineVIDIOC_DQEVENT   _IOR('V', 89, struct v4l2_event)
 #defineVIDIOC_SUBSCRIBE_EVENT   _IOW('V', 90, struct 
v4l2_event_subscription)
 #defineVIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 91, struct 
v4l2_event_subscription)
-
-/* Experimental, the below two ioctls may change over the next couple of kernel
-   versions */
 #define VIDIOC_CREATE_BUFS _IOWR('V', 92, struct v4l2_create_buffers)
 #define VIDIOC_PREPARE_BUF _IOWR('V', 93, struct v4l2_buffer)
-
-/* Experimental selection API */
 #define VIDIOC_G_SELECTION _IOWR('V', 94, struct v4l2_selection)
 #define VIDIOC_S_SELECTION _IOWR('V', 95, struct v4l2_selection)
-
-/* Experimental, these two ioctls may change over the next couple of kernel
-   versions. */
 #define VIDIOC_DECODER_CMD _IOWR('V', 96, struct v4l2_decoder_cmd)
 #define VIDIOC_TRY_DECODER_CMD _IOWR('V', 97, struct v4l2_decoder_cmd)
-
-/* Experimental, these three ioctls may change over the next couple of kernel
-   versions. */
 #define VIDIOC_ENUM_DV_TIMINGS  _IOWR('V', 98, struct v4l2_enum_dv_timings)
 #define VIDIOC_QUERY_DV_TIMINGS  _IOR('V', 99, struct v4l2_dv_timings)
 #define VIDIOC_DV_TIMINGS_CAP   _IOWR('V', 100, struct v4l2_dv_timings_cap)
-
-/* Experimental, this ioctl may change over the next couple of kernel
-   versions. */
 #define VIDIOC_ENUM_FREQ_BANDS _IOWR('V', 101, struct v4l2_frequency_band)
 
-/* Experimental, meant for debugging, testing and internal use.
-   Never use these in applications! */
+/*
+ * Experimental, meant for debugging, testing and internal use.
+ * Never use this in applications!
+ */
 #define VIDIOC_DBG_G_CHIP_INFO  _IOWR('V', 102, struct v4l2_dbg_chip_info)
 
 #define VIDIOC_QUERY_EXT_CTRL  _IOWR('V', 103, struct v4l2_query_ext_ctrl)
-- 
2.8.0.rc3

--
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: [PATCHv3 06/12] media/platform: convert drivers to use the new vb2_queue dev field

2016-04-22 Thread Philipp Zabel
Am Freitag, den 22.04.2016, 10:38 +0200 schrieb Hans Verkuil:
> From: Hans Verkuil 
> 
> Stop using alloc_ctx and just fill in the device pointer.
> 
> Signed-off-by: Hans Verkuil 
> Cc: "Lad, Prabhakar" 
> Cc: Scott Jiang 
> Cc: Philipp Zabel 

coda-wise
Acked-by: Philipp Zabel 

> ---
>  drivers/media/platform/am437x/am437x-vpfe.c| 10 +-
>  drivers/media/platform/am437x/am437x-vpfe.h|  2 --
>  drivers/media/platform/blackfin/bfin_capture.c | 15 ++-
>  drivers/media/platform/coda/coda-common.c  | 16 ++--
>  drivers/media/platform/coda/coda.h |  1 -
>  drivers/media/platform/davinci/vpbe_display.c  | 12 +---
>  drivers/media/platform/davinci/vpif_capture.c  | 11 +--
>  drivers/media/platform/davinci/vpif_capture.h  |  2 --
>  drivers/media/platform/davinci/vpif_display.c  | 11 +--
>  drivers/media/platform/davinci/vpif_display.h  |  2 --
>  include/media/davinci/vpbe_display.h   |  2 --
>  11 files changed, 8 insertions(+), 76 deletions(-)
[...]
> diff --git a/drivers/media/platform/coda/coda-common.c 
> b/drivers/media/platform/coda/coda-common.c
> index 133ab9f..3d57c35 100644
> --- a/drivers/media/platform/coda/coda-common.c
> +++ b/drivers/media/platform/coda/coda-common.c
> @@ -1151,9 +1151,6 @@ static int coda_queue_setup(struct vb2_queue *vq,
>   *nplanes = 1;
>   sizes[0] = size;
>  
> - /* Set to vb2-dma-contig allocator context, ignored by vb2-vmalloc */
> - alloc_ctxs[0] = ctx->dev->alloc_ctx;
> -
>   v4l2_dbg(1, coda_debug, &ctx->dev->v4l2_dev,
>"get %d buffer(s) of size %d each.\n", *nbuffers, size);
>  
> @@ -1599,6 +1596,7 @@ static int coda_queue_init(struct coda_ctx *ctx, struct 
> vb2_queue *vq)
>* that videobuf2 will keep the value of bytesused intact.
>*/
>   vq->allow_zero_bytesused = 1;
> + vq->dev = &ctx->dev->plat_dev->dev;
>  
>   return vb2_queue_init(vq);
>  }
> @@ -2040,16 +2038,10 @@ static void coda_fw_callback(const struct firmware 
> *fw, void *context)
>   if (ret < 0)
>   goto put_pm;
>  
> - dev->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
> - if (IS_ERR(dev->alloc_ctx)) {
> - v4l2_err(&dev->v4l2_dev, "Failed to alloc vb2 context\n");
> - goto put_pm;
> - }
> -
>   dev->m2m_dev = v4l2_m2m_init(&coda_m2m_ops);
>   if (IS_ERR(dev->m2m_dev)) {
>   v4l2_err(&dev->v4l2_dev, "Failed to init mem2mem device\n");
> - goto rel_ctx;
> + goto put_pm;
>   }
>  
>   for (i = 0; i < dev->devtype->num_vdevs; i++) {
> @@ -2072,8 +2064,6 @@ rel_vfd:
>   while (--i >= 0)
>   video_unregister_device(&dev->vfd[i]);
>   v4l2_m2m_release(dev->m2m_dev);
> -rel_ctx:
> - vb2_dma_contig_cleanup_ctx(dev->alloc_ctx);
>  put_pm:
>   pm_runtime_put_sync(&pdev->dev);
>  }
> @@ -2324,8 +2314,6 @@ static int coda_remove(struct platform_device *pdev)
>   if (dev->m2m_dev)
>   v4l2_m2m_release(dev->m2m_dev);
>   pm_runtime_disable(&pdev->dev);
> - if (dev->alloc_ctx)
> - vb2_dma_contig_cleanup_ctx(dev->alloc_ctx);
>   v4l2_device_unregister(&dev->v4l2_dev);
>   destroy_workqueue(dev->workqueue);
>   if (dev->iram.vaddr)
> diff --git a/drivers/media/platform/coda/coda.h 
> b/drivers/media/platform/coda/coda.h
> index 8f2c71e..53f9666 100644
> --- a/drivers/media/platform/coda/coda.h
> +++ b/drivers/media/platform/coda/coda.h
> @@ -92,7 +92,6 @@ struct coda_dev {
>   struct mutexcoda_mutex;
>   struct workqueue_struct *workqueue;
>   struct v4l2_m2m_dev *m2m_dev;
> - struct vb2_alloc_ctx*alloc_ctx;
>   struct list_headinstances;
>   unsigned long   instance_mask;
>   struct dentry   *debugfs_root;
[...]

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


Re: [PATCHv3 01/12] vb2: add a dev field to use for the default allocation context

2016-04-22 Thread Philipp Zabel
Am Freitag, den 22.04.2016, 10:38 +0200 schrieb Hans Verkuil:
> From: Hans Verkuil 
> 
> The allocation context is nothing more than a per-plane device pointer
> to use when allocating buffers. So just provide a dev pointer in vb2_queue
> for that purpose and drivers can skip allocating/releasing/filling in
> the allocation context unless they require different per-plane device
> pointers as used by some Samsung SoCs.
> 
> Signed-off-by: Hans Verkuil 
> Cc: Laurent Pinchart 
> Cc: Sakari Ailus 
> Cc: Mauro Carvalho Chehab 
> Cc: Florian Echtler 
> Cc: Federico Vaga 
> Cc: "Lad, Prabhakar" 
> Cc: Scott Jiang 
> Cc: Philipp Zabel 
> Cc: Fabien Dessenne 
> Cc: Benoit Parrot 
> Cc: Mikhail Ulyanov 
> Cc: Guennadi Liakhovetski 
> Cc: Javier Martin 
> Cc: Jonathan Corbet 
> Cc: Ludovic Desroches 
> Cc: Sergei Shtylyov 
> Cc: Kyungmin Park 
> Cc: Sylwester Nawrocki 

Acked-by: Philipp Zabel 

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


[PATCHv3 04/12] media/pci: convert drivers to use the new vb2_queue dev field

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

Stop using alloc_ctx and just fill in the device pointer.

Signed-off-by: Hans Verkuil 
Cc: Federico Vaga 
Cc: Mauro Carvalho Chehab 
#
#total: 0 errors, 0 warnings, 16 lines checked
#
#Your patch has no obvious style problems and is ready for submission.
---
 drivers/media/pci/cobalt/cobalt-driver.c  |  9 -
 drivers/media/pci/cobalt/cobalt-driver.h  |  1 -
 drivers/media/pci/cobalt/cobalt-v4l2.c|  2 +-
 drivers/media/pci/cx23885/cx23885-417.c   |  1 -
 drivers/media/pci/cx23885/cx23885-core.c  | 10 +-
 drivers/media/pci/cx23885/cx23885-dvb.c   |  2 +-
 drivers/media/pci/cx23885/cx23885-vbi.c   |  1 -
 drivers/media/pci/cx23885/cx23885-video.c |  3 ++-
 drivers/media/pci/cx23885/cx23885.h   |  1 -
 drivers/media/pci/cx25821/cx25821-core.c  | 10 +-
 drivers/media/pci/cx25821/cx25821-video.c |  3 +--
 drivers/media/pci/cx25821/cx25821.h   |  1 -
 drivers/media/pci/cx88/cx88-blackbird.c   |  2 +-
 drivers/media/pci/cx88/cx88-dvb.c |  2 +-
 drivers/media/pci/cx88/cx88-mpeg.c| 10 +-
 drivers/media/pci/cx88/cx88-vbi.c |  1 -
 drivers/media/pci/cx88/cx88-video.c   | 11 ++-
 drivers/media/pci/cx88/cx88.h |  2 --
 drivers/media/pci/dt3155/dt3155.c | 13 ++---
 drivers/media/pci/dt3155/dt3155.h |  2 --
 drivers/media/pci/saa7134/saa7134-core.c  | 22 +++---
 drivers/media/pci/saa7134/saa7134-ts.c|  1 -
 drivers/media/pci/saa7134/saa7134-vbi.c   |  1 -
 drivers/media/pci/saa7134/saa7134-video.c |  3 ++-
 drivers/media/pci/saa7134/saa7134.h   |  1 -
 drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c| 11 +--
 drivers/media/pci/solo6x10/solo6x10-v4l2.c| 10 +-
 drivers/media/pci/solo6x10/solo6x10.h |  2 --
 drivers/media/pci/sta2x11/sta2x11_vip.c   | 18 ++
 drivers/media/pci/tw68/tw68-core.c| 15 +++
 drivers/media/pci/tw68/tw68-video.c   |  2 +-
 drivers/media/pci/tw68/tw68.h |  1 -
 drivers/staging/media/tw686x-kh/tw686x-kh-video.c | 10 +-
 drivers/staging/media/tw686x-kh/tw686x-kh.h   |  1 -
 34 files changed, 32 insertions(+), 153 deletions(-)

diff --git a/drivers/media/pci/cobalt/cobalt-driver.c 
b/drivers/media/pci/cobalt/cobalt-driver.c
index 8d6f04f..1aaa2b0 100644
--- a/drivers/media/pci/cobalt/cobalt-driver.c
+++ b/drivers/media/pci/cobalt/cobalt-driver.c
@@ -691,17 +691,10 @@ static int cobalt_probe(struct pci_dev *pci_dev,
cobalt->pci_dev = pci_dev;
cobalt->instance = i;
 
-   cobalt->alloc_ctx = vb2_dma_sg_init_ctx(&pci_dev->dev);
-   if (IS_ERR(cobalt->alloc_ctx)) {
-   kfree(cobalt);
-   return -ENOMEM;
-   }
-
retval = v4l2_device_register(&pci_dev->dev, &cobalt->v4l2_dev);
if (retval) {
pr_err("cobalt: v4l2_device_register of card %d failed\n",
cobalt->instance);
-   vb2_dma_sg_cleanup_ctx(cobalt->alloc_ctx);
kfree(cobalt);
return retval;
}
@@ -782,7 +775,6 @@ err:
cobalt_err("error %d on initialization\n", retval);
 
v4l2_device_unregister(&cobalt->v4l2_dev);
-   vb2_dma_sg_cleanup_ctx(cobalt->alloc_ctx);
kfree(cobalt);
return retval;
 }
@@ -818,7 +810,6 @@ static void cobalt_remove(struct pci_dev *pci_dev)
cobalt_info("removed cobalt card\n");
 
v4l2_device_unregister(v4l2_dev);
-   vb2_dma_sg_cleanup_ctx(cobalt->alloc_ctx);
kfree(cobalt);
 }
 
diff --git a/drivers/media/pci/cobalt/cobalt-driver.h 
b/drivers/media/pci/cobalt/cobalt-driver.h
index b2f08e4..ed00dc9 100644
--- a/drivers/media/pci/cobalt/cobalt-driver.h
+++ b/drivers/media/pci/cobalt/cobalt-driver.h
@@ -262,7 +262,6 @@ struct cobalt {
int instance;
struct pci_dev *pci_dev;
struct v4l2_device v4l2_dev;
-   void *alloc_ctx;
 
void __iomem *bar0, *bar1;
 
diff --git a/drivers/media/pci/cobalt/cobalt-v4l2.c 
b/drivers/media/pci/cobalt/cobalt-v4l2.c
index c0ba458..6c19cdf 100644
--- a/drivers/media/pci/cobalt/cobalt-v4l2.c
+++ b/drivers/media/pci/cobalt/cobalt-v4l2.c
@@ -54,7 +54,6 @@ static int cobalt_queue_setup(struct vb2_queue *q,
*num_buffers = 3;
if (*num_buffers > NR_BUFS)
*num_buffers = NR_BUFS;
-   alloc_ctxs[0] = s->cobalt->alloc_ctx;
if (*num_planes)
return sizes[0] < size ? -EINVAL : 0;
*num_planes = 1;
@@ -1224,6 +1223,7 @@ static int cobalt_node_register(struct cobalt *cobalt, 
int node)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 2;
q->lock = &s->lock

[PATCHv3 07/12] media/platform: convert drivers to use the new vb2_queue dev field

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

Stop using alloc_ctx and just fill in the device pointer.

Signed-off-by: Hans Verkuil 
Cc: Fabien Dessenne 
Cc: Benoit Parrot 
Cc: Laurent Pinchart 
#
#total: 0 errors, 0 warnings, 10 lines checked
#
#Your patch has no obvious style problems and is ready for submission.
---
 drivers/media/platform/sti/bdisp/bdisp-v4l2.c | 18 --
 drivers/media/platform/sti/bdisp/bdisp.h  |  2 --
 drivers/media/platform/ti-vpe/cal.c   | 15 +--
 drivers/media/platform/ti-vpe/vpe.c   | 20 
 drivers/media/platform/vsp1/vsp1_video.c  | 18 +++---
 drivers/media/platform/vsp1/vsp1_video.h  |  1 -
 drivers/media/platform/xilinx/xilinx-dma.c| 11 +--
 drivers/media/platform/xilinx/xilinx-dma.h|  2 --
 8 files changed, 13 insertions(+), 74 deletions(-)

diff --git a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c 
b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
index d12a419..b3e8b5a 100644
--- a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
+++ b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
@@ -439,7 +439,7 @@ static void bdisp_ctrls_delete(struct bdisp_ctx *ctx)
 
 static int bdisp_queue_setup(struct vb2_queue *vq,
 unsigned int *nb_buf, unsigned int *nb_planes,
-unsigned int sizes[], void *allocators[])
+unsigned int sizes[], void *alloc_ctxs[])
 {
struct bdisp_ctx *ctx = vb2_get_drv_priv(vq);
struct bdisp_frame *frame = ctx_get_frame(ctx, vq->type);
@@ -453,7 +453,6 @@ static int bdisp_queue_setup(struct vb2_queue *vq,
dev_err(ctx->bdisp_dev->dev, "Invalid format\n");
return -EINVAL;
}
-   allocators[0] = ctx->bdisp_dev->alloc_ctx;
 
if (*nb_planes)
return sizes[0] < frame->sizeimage ? -EINVAL : 0;
@@ -553,6 +552,7 @@ static int queue_init(void *priv,
src_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
src_vq->lock = &ctx->bdisp_dev->lock;
+   src_vq->dev = ctx->bdisp_dev->v4l2_dev.dev;
 
ret = vb2_queue_init(src_vq);
if (ret)
@@ -567,6 +567,7 @@ static int queue_init(void *priv,
dst_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
dst_vq->lock = &ctx->bdisp_dev->lock;
+   dst_vq->dev = ctx->bdisp_dev->v4l2_dev.dev;
 
return vb2_queue_init(dst_vq);
 }
@@ -1269,8 +1270,6 @@ static int bdisp_remove(struct platform_device *pdev)
 
bdisp_hw_free_filters(bdisp->dev);
 
-   vb2_dma_contig_cleanup_ctx(bdisp->alloc_ctx);
-
pm_runtime_disable(&pdev->dev);
 
bdisp_debugfs_remove(bdisp);
@@ -1371,18 +1370,11 @@ static int bdisp_probe(struct platform_device *pdev)
goto err_dbg;
}
 
-   /* Continuous memory allocator */
-   bdisp->alloc_ctx = vb2_dma_contig_init_ctx(dev);
-   if (IS_ERR(bdisp->alloc_ctx)) {
-   ret = PTR_ERR(bdisp->alloc_ctx);
-   goto err_pm;
-   }
-
/* Filters */
if (bdisp_hw_alloc_filters(bdisp->dev)) {
dev_err(bdisp->dev, "no memory for filters\n");
ret = -ENOMEM;
-   goto err_vb2_dma;
+   goto err_pm;
}
 
/* Register */
@@ -1401,8 +1393,6 @@ static int bdisp_probe(struct platform_device *pdev)
 
 err_filter:
bdisp_hw_free_filters(bdisp->dev);
-err_vb2_dma:
-   vb2_dma_contig_cleanup_ctx(bdisp->alloc_ctx);
 err_pm:
pm_runtime_put(dev);
 err_dbg:
diff --git a/drivers/media/platform/sti/bdisp/bdisp.h 
b/drivers/media/platform/sti/bdisp/bdisp.h
index 0cf9857..b3fbf99 100644
--- a/drivers/media/platform/sti/bdisp/bdisp.h
+++ b/drivers/media/platform/sti/bdisp/bdisp.h
@@ -175,7 +175,6 @@ struct bdisp_dbg {
  * @id: device index
  * @m2m:memory-to-memory V4L2 device information
  * @state:  flags used to synchronize m2m and capture mode operation
- * @alloc_ctx:  videobuf2 memory allocator context
  * @clock:  IP clock
  * @regs:   registers
  * @irq_queue:  interrupt handler waitqueue
@@ -193,7 +192,6 @@ struct bdisp_dev {
u16 id;
struct bdisp_m2m_device m2m;
unsigned long   state;
-   struct vb2_alloc_ctx*alloc_ctx;
struct clk  *clock;
void __iomem*regs;
wait_queue_head_t   irq_queue;
diff --git a/drivers/media/platform/ti-vpe/cal.c 
b/drivers/media/platform/ti-vpe/cal.c
index 82001e6..51ebf32 100644
--- a/drivers/media/platform/ti-vpe/cal.c
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -287,7 +287,6 @@ struct cal_ctx {
/* Several counters */
unsigned long   jiffies;
 
-   struct vb2_alloc_ctx*alloc_ctx;
struct cal_dmaqueue vidq;
 
/* Input Number */
@@ -12

[PATCHv3 11/12] media/platform: convert drivers to use the new vb2_queue dev field

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

Stop using alloc_ctx and just fill in the device pointer.

Signed-off-by: Hans Verkuil 
Cc: Kyungmin Park 
Cc: Sylwester Nawrocki 
---
 drivers/media/platform/exynos4-is/fimc-capture.c   |  7 ++-
 drivers/media/platform/exynos4-is/fimc-core.c  | 11 ---
 drivers/media/platform/exynos4-is/fimc-core.h  |  3 ---
 drivers/media/platform/exynos4-is/fimc-is.c| 13 +
 drivers/media/platform/exynos4-is/fimc-is.h|  2 --
 drivers/media/platform/exynos4-is/fimc-isp-video.c |  9 +++--
 drivers/media/platform/exynos4-is/fimc-isp.h   |  2 --
 drivers/media/platform/exynos4-is/fimc-lite.c  | 19 +++
 drivers/media/platform/exynos4-is/fimc-lite.h  |  2 --
 drivers/media/platform/exynos4-is/fimc-m2m.c   |  6 +++---
 drivers/media/platform/s5p-mfc/s5p_mfc.c   | 19 +--
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h|  2 --
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   | 10 --
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c   | 14 +-
 14 files changed, 22 insertions(+), 97 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c 
b/drivers/media/platform/exynos4-is/fimc-capture.c
index bf47d3b..512b254 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -354,11 +354,9 @@ static int queue_setup(struct vb2_queue *vq,
if (*num_planes) {
if (*num_planes != fmt->memplanes)
return -EINVAL;
-   for (i = 0; i < *num_planes; i++) {
+   for (i = 0; i < *num_planes; i++)
if (sizes[i] < (wh * fmt->depth[i]) / 8)
return -EINVAL;
-   allocators[i] = ctx->fimc_dev->alloc_ctx;
-   }
return 0;
}
 
@@ -371,8 +369,6 @@ static int queue_setup(struct vb2_queue *vq,
sizes[i] = frame->payload[i];
else
sizes[i] = max_t(u32, size, frame->payload[i]);
-
-   allocators[i] = ctx->fimc_dev->alloc_ctx;
}
 
return 0;
@@ -1779,6 +1775,7 @@ static int fimc_register_capture_device(struct fimc_dev 
*fimc,
q->buf_struct_size = sizeof(struct fimc_vid_buffer);
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->lock = &fimc->lock;
+   q->dev = &fimc->pdev->dev;
 
ret = vb2_queue_init(q);
if (ret)
diff --git a/drivers/media/platform/exynos4-is/fimc-core.c 
b/drivers/media/platform/exynos4-is/fimc-core.c
index b1c1cea..a767c76 100644
--- a/drivers/media/platform/exynos4-is/fimc-core.c
+++ b/drivers/media/platform/exynos4-is/fimc-core.c
@@ -1018,19 +1018,9 @@ static int fimc_probe(struct platform_device *pdev)
goto err_sd;
}
 
-   /* Initialize contiguous memory allocator */
-   fimc->alloc_ctx = vb2_dma_contig_init_ctx(dev);
-   if (IS_ERR(fimc->alloc_ctx)) {
-   ret = PTR_ERR(fimc->alloc_ctx);
-   goto err_gclk;
-   }
-
dev_dbg(dev, "FIMC.%d registered successfully\n", fimc->id);
return 0;
 
-err_gclk:
-   if (!pm_runtime_enabled(dev))
-   clk_disable(fimc->clock[CLK_GATE]);
 err_sd:
fimc_unregister_capture_subdev(fimc);
 err_sclk:
@@ -1123,7 +1113,6 @@ static int fimc_remove(struct platform_device *pdev)
pm_runtime_set_suspended(&pdev->dev);
 
fimc_unregister_capture_subdev(fimc);
-   vb2_dma_contig_cleanup_ctx(fimc->alloc_ctx);
 
clk_disable(fimc->clock[CLK_BUS]);
fimc_clk_put(fimc);
diff --git a/drivers/media/platform/exynos4-is/fimc-core.h 
b/drivers/media/platform/exynos4-is/fimc-core.h
index 6b74354..5615fef 100644
--- a/drivers/media/platform/exynos4-is/fimc-core.h
+++ b/drivers/media/platform/exynos4-is/fimc-core.h
@@ -307,7 +307,6 @@ struct fimc_m2m_device {
  */
 struct fimc_vid_cap {
struct fimc_ctx *ctx;
-   struct vb2_alloc_ctx*alloc_ctx;
struct v4l2_subdev  subdev;
struct exynos_video_entity  ve;
struct media_padvd_pad;
@@ -417,7 +416,6 @@ struct fimc_ctx;
  * @m2m:   memory-to-memory V4L2 device information
  * @vid_cap:   camera capture device information
  * @state: flags used to synchronize m2m and capture mode operation
- * @alloc_ctx: videobuf2 memory allocator context
  * @pipeline:  fimc video capture pipeline data structure
  */
 struct fimc_dev {
@@ -436,7 +434,6 @@ struct fimc_dev {
struct fimc_m2m_device  m2m;
struct fimc_vid_cap vid_cap;
unsigned long   state;
-   struct vb2_alloc_ctx*alloc_ctx;
 };
 
 /**
diff --git a/drivers/media/platform/exynos4-is/fimc-is.c 
b/drivers/media/platform/exynos4-is/fimc-is.c
index 979c388..4456c84 100644
--- a/drivers/me

[PATCHv3 10/12] media/platform: convert drivers to use the new vb2_queue dev field

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

Stop using alloc_ctx and just fill in the device pointer.

Signed-off-by: Hans Verkuil 
Cc: Kyungmin Park 
Cc: Sylwester Nawrocki 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 11 +--
 drivers/media/platform/exynos-gsc/gsc-core.h |  1 -
 drivers/media/platform/exynos-gsc/gsc-m2m.c  |  6 +++---
 drivers/media/platform/s3c-camif/camif-capture.c |  3 +--
 drivers/media/platform/s3c-camif/camif-core.c| 11 +--
 drivers/media/platform/s3c-camif/camif-core.h|  2 --
 drivers/media/platform/s5p-g2d/g2d.c | 14 +++---
 drivers/media/platform/s5p-g2d/g2d.h |  1 -
 drivers/media/platform/s5p-jpeg/jpeg-core.c  | 18 --
 drivers/media/platform/s5p-jpeg/jpeg-core.h  |  2 --
 drivers/media/platform/s5p-tv/mixer.h|  2 --
 drivers/media/platform/s5p-tv/mixer_video.c  | 16 ++--
 12 files changed, 15 insertions(+), 72 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index c595723..58a92a1 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1119,19 +1119,11 @@ static int gsc_probe(struct platform_device *pdev)
if (ret < 0)
goto err_m2m;
 
-   /* Initialize continious memory allocator */
-   gsc->alloc_ctx = vb2_dma_contig_init_ctx(dev);
-   if (IS_ERR(gsc->alloc_ctx)) {
-   ret = PTR_ERR(gsc->alloc_ctx);
-   goto err_pm;
-   }
-
dev_dbg(dev, "gsc-%d registered successfully\n", gsc->id);
 
pm_runtime_put(dev);
return 0;
-err_pm:
-   pm_runtime_put(dev);
+
 err_m2m:
gsc_unregister_m2m_device(gsc);
 err_v4l2:
@@ -1148,7 +1140,6 @@ static int gsc_remove(struct platform_device *pdev)
gsc_unregister_m2m_device(gsc);
v4l2_device_unregister(&gsc->v4l2_dev);
 
-   vb2_dma_contig_cleanup_ctx(gsc->alloc_ctx);
pm_runtime_disable(&pdev->dev);
gsc_clk_put(gsc);
 
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h 
b/drivers/media/platform/exynos-gsc/gsc-core.h
index ec4000c..5c48329 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.h
+++ b/drivers/media/platform/exynos-gsc/gsc-core.h
@@ -341,7 +341,6 @@ struct gsc_dev {
wait_queue_head_t   irq_queue;
struct gsc_m2m_device   m2m;
unsigned long   state;
-   struct vb2_alloc_ctx*alloc_ctx;
struct video_device vdev;
struct v4l2_device  v4l2_dev;
 };
diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c 
b/drivers/media/platform/exynos-gsc/gsc-m2m.c
index a600e32..622709c 100644
--- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
+++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
@@ -227,10 +227,8 @@ static int gsc_m2m_queue_setup(struct vb2_queue *vq,
return -EINVAL;
 
*num_planes = frame->fmt->num_planes;
-   for (i = 0; i < frame->fmt->num_planes; i++) {
+   for (i = 0; i < frame->fmt->num_planes; i++)
sizes[i] = frame->payload[i];
-   allocators[i] = ctx->gsc_dev->alloc_ctx;
-   }
return 0;
 }
 
@@ -591,6 +589,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq,
src_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
src_vq->lock = &ctx->gsc_dev->lock;
+   src_vq->dev = &ctx->gsc_dev->pdev->dev;
 
ret = vb2_queue_init(src_vq);
if (ret)
@@ -605,6 +604,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq,
dst_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
dst_vq->lock = &ctx->gsc_dev->lock;
+   dst_vq->dev = &ctx->gsc_dev->pdev->dev;
 
return vb2_queue_init(dst_vq);
 }
diff --git a/drivers/media/platform/s3c-camif/camif-capture.c 
b/drivers/media/platform/s3c-camif/camif-capture.c
index bd060ef..5eb5df1 100644
--- a/drivers/media/platform/s3c-camif/camif-capture.c
+++ b/drivers/media/platform/s3c-camif/camif-capture.c
@@ -440,7 +440,6 @@ static int queue_setup(struct vb2_queue *vq,
   unsigned int sizes[], void *allocators[])
 {
struct camif_vp *vp = vb2_get_drv_priv(vq);
-   struct camif_dev *camif = vp->camif;
struct camif_frame *frame = &vp->out_frame;
const struct camif_fmt *fmt = vp->out_fmt;
unsigned int size;
@@ -449,7 +448,6 @@ static int queue_setup(struct vb2_queue *vq,
return -EINVAL;
 
size = (frame->f_width * frame->f_height * fmt->depth) / 8;
-   allocators[0] = camif->alloc_ctx;
 
if (*num_planes)
return sizes[0] < size ? -EINVAL : 0;
@@ -1138,6 +1136,7 @@ int s3c_camif_register_video_node(struct camif_dev 
*camif, int idx)
q->drv_priv = vp;
 

[PATCHv3 09/12] media/.../soc-camera: convert drivers to use the new vb2_queue dev field

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

Stop using alloc_ctx and just fill in the device pointer.

Signed-off-by: Hans Verkuil 
Cc: Guennadi Liakhovetski 
Cc: Ludovic Desroches 
Cc: Sergei Shtylyov 
---
 drivers/media/platform/soc_camera/atmel-isi.c   | 13 +
 drivers/media/platform/soc_camera/rcar_vin.c| 12 +---
 .../media/platform/soc_camera/sh_mobile_ceu_camera.c| 15 ++-
 drivers/staging/media/mx2/mx2_camera.c  | 17 +++--
 drivers/staging/media/mx3/mx3_camera.c  | 16 ++--
 5 files changed, 9 insertions(+), 64 deletions(-)

diff --git a/drivers/media/platform/soc_camera/atmel-isi.c 
b/drivers/media/platform/soc_camera/atmel-isi.c
index ab2d9b9..899b93a 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -72,8 +72,6 @@ struct atmel_isi {
 
int sequence;
 
-   struct vb2_alloc_ctx*alloc_ctx;
-
/* Allocate descriptors for dma buffer use */
struct fbd  *p_fb_descriptors;
dma_addr_t  fb_descriptors_phys;
@@ -322,7 +320,6 @@ static int queue_setup(struct vb2_queue *vq,
 
*nplanes = 1;
sizes[0] = size;
-   alloc_ctxs[0] = isi->alloc_ctx;
 
isi->sequence = 0;
isi->active = NULL;
@@ -567,6 +564,7 @@ static int isi_camera_init_videobuf(struct vb2_queue *q,
q->mem_ops = &vb2_dma_contig_memops;
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->lock = &ici->host_lock;
+   q->dev = ici->v4l2_dev.dev;
 
return vb2_queue_init(q);
 }
@@ -963,7 +961,6 @@ static int atmel_isi_remove(struct platform_device *pdev)
struct atmel_isi, soc_host);
 
soc_camera_host_unregister(soc_host);
-   vb2_dma_contig_cleanup_ctx(isi->alloc_ctx);
dma_free_coherent(&pdev->dev,
sizeof(struct fbd) * MAX_BUFFER_NUM,
isi->p_fb_descriptors,
@@ -1067,12 +1064,6 @@ static int atmel_isi_probe(struct platform_device *pdev)
list_add(&isi->dma_desc[i].list, &isi->dma_desc_head);
}
 
-   isi->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
-   if (IS_ERR(isi->alloc_ctx)) {
-   ret = PTR_ERR(isi->alloc_ctx);
-   goto err_alloc_ctx;
-   }
-
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
isi->regs = devm_ioremap_resource(&pdev->dev, regs);
if (IS_ERR(isi->regs)) {
@@ -1119,8 +1110,6 @@ err_register_soc_camera_host:
pm_runtime_disable(&pdev->dev);
 err_req_irq:
 err_ioremap:
-   vb2_dma_contig_cleanup_ctx(isi->alloc_ctx);
-err_alloc_ctx:
dma_free_coherent(&pdev->dev,
sizeof(struct fbd) * MAX_BUFFER_NUM,
isi->p_fb_descriptors,
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
b/drivers/media/platform/soc_camera/rcar_vin.c
index 3f9c1b8..dadc5b3 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -484,7 +484,6 @@ struct rcar_vin_priv {
struct list_headcapture;
 #define MAX_BUFFER_NUM 3
struct vb2_v4l2_buffer  *queue_buf[MAX_BUFFER_NUM];
-   struct vb2_alloc_ctx*alloc_ctx;
enum v4l2_field field;
unsigned intpdata_flags;
unsigned intvb_count;
@@ -540,8 +539,6 @@ static int rcar_vin_videobuf_setup(struct vb2_queue *vq,
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
struct rcar_vin_priv *priv = ici->priv;
 
-   alloc_ctxs[0] = priv->alloc_ctx;
-
if (!vq->num_buffers)
priv->sequence = 0;
 
@@ -1816,6 +1813,7 @@ static int rcar_vin_init_videobuf2(struct vb2_queue *vq,
vq->buf_struct_size = sizeof(struct rcar_vin_buffer);
vq->timestamp_flags  = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
vq->lock = &ici->host_lock;
+   vq->dev = ici->v4l2_dev.dev;
 
return vb2_queue_init(vq);
 }
@@ -1912,10 +1910,6 @@ static int rcar_vin_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   priv->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
-   if (IS_ERR(priv->alloc_ctx))
-   return PTR_ERR(priv->alloc_ctx);
-
priv->ici.priv = priv;
priv->ici.v4l2_dev.dev = &pdev->dev;
priv->ici.drv_name = dev_name(&pdev->dev);
@@ -1946,7 +1940,6 @@ static int rcar_vin_probe(struct platform_device *pdev)
 
 cleanup:
pm_runtime_disable(&pdev->dev);
-   vb2_dma_contig_cleanup_ctx(priv->alloc_ctx);
 
return ret;
 }
@@ -1954,12 +1947,9 @@ cleanup:
 static int rcar_vin_remove(struct platform_device *pdev)
 {
struct soc_camera_host *soc_host = to_soc_camera_host(&pdev->dev);
-   struct

[PATCHv3 03/12] sur40: set q->dev instead of allocating a context

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

Stop using alloc_ctx and just fill in the device pointer.

Signed-off-by: Hans Verkuil 
Cc: Florian Echtler 
#
#total: 0 errors, 0 warnings, 304 lines checked
#
#Your patch has no obvious style problems and is ready for submission.
#
#total: 0 errors, 0 warnings, 8 lines checked
#
#Your patch has no obvious style problems and is ready for submission.
---
 drivers/input/touchscreen/sur40.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/input/touchscreen/sur40.c 
b/drivers/input/touchscreen/sur40.c
index 880c40b..cc4bd3e 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -151,7 +151,6 @@ struct sur40_state {
struct mutex lock;
 
struct vb2_queue queue;
-   struct vb2_alloc_ctx *alloc_ctx;
struct list_head buf_list;
spinlock_t qlock;
int sequence;
@@ -580,19 +579,13 @@ static int sur40_probe(struct usb_interface *interface,
sur40->queue = sur40_queue;
sur40->queue.drv_priv = sur40;
sur40->queue.lock = &sur40->lock;
+   sur40->queue.dev = sur40->dev;
 
/* initialize the queue */
error = vb2_queue_init(&sur40->queue);
if (error)
goto err_unreg_v4l2;
 
-   sur40->alloc_ctx = vb2_dma_sg_init_ctx(sur40->dev);
-   if (IS_ERR(sur40->alloc_ctx)) {
-   dev_err(sur40->dev, "Can't allocate buffer context");
-   error = PTR_ERR(sur40->alloc_ctx);
-   goto err_unreg_v4l2;
-   }
-
sur40->vdev = sur40_video_device;
sur40->vdev.v4l2_dev = &sur40->v4l2;
sur40->vdev.lock = &sur40->lock;
@@ -633,7 +626,6 @@ static void sur40_disconnect(struct usb_interface 
*interface)
 
video_unregister_device(&sur40->vdev);
v4l2_device_unregister(&sur40->v4l2);
-   vb2_dma_sg_cleanup_ctx(sur40->alloc_ctx);
 
input_unregister_polled_device(sur40->input);
input_free_polled_device(sur40->input);
@@ -655,11 +647,8 @@ static int sur40_queue_setup(struct vb2_queue *q,
   unsigned int *nbuffers, unsigned int *nplanes,
   unsigned int sizes[], void *alloc_ctxs[])
 {
-   struct sur40_state *sur40 = vb2_get_drv_priv(q);
-
if (q->num_buffers + *nbuffers < 3)
*nbuffers = 3 - q->num_buffers;
-   alloc_ctxs[0] = sur40->alloc_ctx;
 
if (*nplanes)
return sizes[0] < sur40_video_format.sizeimage ? -EINVAL : 0;
-- 
2.8.0.rc3

--
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


[PATCHv3 06/12] media/platform: convert drivers to use the new vb2_queue dev field

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

Stop using alloc_ctx and just fill in the device pointer.

Signed-off-by: Hans Verkuil 
Cc: "Lad, Prabhakar" 
Cc: Scott Jiang 
Cc: Philipp Zabel 
---
 drivers/media/platform/am437x/am437x-vpfe.c| 10 +-
 drivers/media/platform/am437x/am437x-vpfe.h|  2 --
 drivers/media/platform/blackfin/bfin_capture.c | 15 ++-
 drivers/media/platform/coda/coda-common.c  | 16 ++--
 drivers/media/platform/coda/coda.h |  1 -
 drivers/media/platform/davinci/vpbe_display.c  | 12 +---
 drivers/media/platform/davinci/vpif_capture.c  | 11 +--
 drivers/media/platform/davinci/vpif_capture.h  |  2 --
 drivers/media/platform/davinci/vpif_display.c  | 11 +--
 drivers/media/platform/davinci/vpif_display.h  |  2 --
 include/media/davinci/vpbe_display.h   |  2 --
 11 files changed, 8 insertions(+), 76 deletions(-)

diff --git a/drivers/media/platform/am437x/am437x-vpfe.c 
b/drivers/media/platform/am437x/am437x-vpfe.c
index e749eb7..d22b09d 100644
--- a/drivers/media/platform/am437x/am437x-vpfe.c
+++ b/drivers/media/platform/am437x/am437x-vpfe.c
@@ -1915,7 +1915,6 @@ static int vpfe_queue_setup(struct vb2_queue *vq,
 
if (vq->num_buffers + *nbuffers < 3)
*nbuffers = 3 - vq->num_buffers;
-   alloc_ctxs[0] = vpfe->alloc_ctx;
 
if (*nplanes) {
if (sizes[0] < size)
@@ -2364,13 +2363,6 @@ static int vpfe_probe_complete(struct vpfe_device *vpfe)
goto probe_out;
 
/* Initialize videobuf2 queue as per the buffer type */
-   vpfe->alloc_ctx = vb2_dma_contig_init_ctx(vpfe->pdev);
-   if (IS_ERR(vpfe->alloc_ctx)) {
-   vpfe_err(vpfe, "Failed to get the context\n");
-   err = PTR_ERR(vpfe->alloc_ctx);
-   goto probe_out;
-   }
-
q = &vpfe->buffer_queue;
q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
q->io_modes = VB2_MMAP | VB2_DMABUF | VB2_READ;
@@ -2381,11 +2373,11 @@ static int vpfe_probe_complete(struct vpfe_device *vpfe)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->lock = &vpfe->lock;
q->min_buffers_needed = 1;
+   q->dev = vpfe->pdev;
 
err = vb2_queue_init(q);
if (err) {
vpfe_err(vpfe, "vb2_queue_init() failed\n");
-   vb2_dma_contig_cleanup_ctx(vpfe->alloc_ctx);
goto probe_out;
}
 
diff --git a/drivers/media/platform/am437x/am437x-vpfe.h 
b/drivers/media/platform/am437x/am437x-vpfe.h
index 777bf97..17d7aa4 100644
--- a/drivers/media/platform/am437x/am437x-vpfe.h
+++ b/drivers/media/platform/am437x/am437x-vpfe.h
@@ -264,8 +264,6 @@ struct vpfe_device {
struct v4l2_rect crop;
/* Buffer queue used in video-buf */
struct vb2_queue buffer_queue;
-   /* Allocator-specific contexts for each plane */
-   struct vb2_alloc_ctx *alloc_ctx;
/* Queue of filled frames */
struct list_head dma_queue;
/* IRQ lock for DMA queue */
diff --git a/drivers/media/platform/blackfin/bfin_capture.c 
b/drivers/media/platform/blackfin/bfin_capture.c
index d0092da..1e244287 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -91,8 +91,6 @@ struct bcap_device {
struct bcap_buffer *cur_frm;
/* buffer queue used in videobuf2 */
struct vb2_queue buffer_queue;
-   /* allocator-specific contexts for each plane */
-   struct vb2_alloc_ctx *alloc_ctx;
/* queue of filled frames */
struct list_head dma_queue;
/* used in videobuf2 callback */
@@ -209,7 +207,6 @@ static int bcap_queue_setup(struct vb2_queue *vq,
 
if (vq->num_buffers + *nbuffers < 2)
*nbuffers = 2;
-   alloc_ctxs[0] = bcap_dev->alloc_ctx;
 
if (*nplanes)
return sizes[0] < bcap_dev->fmt.sizeimage ? -EINVAL : 0;
@@ -820,12 +817,6 @@ static int bcap_probe(struct platform_device *pdev)
}
bcap_dev->ppi->priv = bcap_dev;
 
-   bcap_dev->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
-   if (IS_ERR(bcap_dev->alloc_ctx)) {
-   ret = PTR_ERR(bcap_dev->alloc_ctx);
-   goto err_free_ppi;
-   }
-
vfd = &bcap_dev->video_dev;
/* initialize field of video device */
vfd->release= video_device_release_empty;
@@ -839,7 +830,7 @@ static int bcap_probe(struct platform_device *pdev)
if (ret) {
v4l2_err(pdev->dev.driver,
"Unable to register v4l2 device\n");
-   goto err_cleanup_ctx;
+   goto err_free_ppi;
}
v4l2_info(&bcap_dev->v4l2_dev, "v4l2 device registered\n");
 
@@ -863,6 +854,7 @@ static int bcap_probe(struct platform_device *pdev)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->lock = &bcap_dev->mutex;
q->min_buffers_needed = 1;
+   q->

[PATCHv3 12/12] vb2: replace void *alloc_ctxs by struct device *alloc_devs

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

Make this a proper typed array. Drop the old allocate context code since
that is no longer used.

Note that the memops functions now get a struct device pointer instead of
the struct device ** that was there initially (actually a void pointer to
a struct containing only a struct device pointer).

This code is now a lot cleaner.

Signed-off-by: Hans Verkuil 
Cc: Laurent Pinchart 
Cc: Sakari Ailus 
Cc: Mauro Carvalho Chehab 
---
 Documentation/video4linux/v4l2-pci-skeleton.c  |  2 +-
 drivers/input/touchscreen/sur40.c  |  2 +-
 drivers/media/dvb-frontends/rtl2832_sdr.c  |  2 +-
 drivers/media/pci/cobalt/cobalt-v4l2.c |  2 +-
 drivers/media/pci/cx23885/cx23885-417.c|  2 +-
 drivers/media/pci/cx23885/cx23885-dvb.c|  2 +-
 drivers/media/pci/cx23885/cx23885-vbi.c|  2 +-
 drivers/media/pci/cx23885/cx23885-video.c  |  2 +-
 drivers/media/pci/cx25821/cx25821-video.c  |  2 +-
 drivers/media/pci/cx88/cx88-blackbird.c|  2 +-
 drivers/media/pci/cx88/cx88-dvb.c  |  2 +-
 drivers/media/pci/cx88/cx88-vbi.c  |  2 +-
 drivers/media/pci/cx88/cx88-video.c|  2 +-
 drivers/media/pci/dt3155/dt3155.c  |  2 +-
 drivers/media/pci/netup_unidvb/netup_unidvb_core.c |  2 +-
 drivers/media/pci/saa7134/saa7134-ts.c |  2 +-
 drivers/media/pci/saa7134/saa7134-vbi.c|  2 +-
 drivers/media/pci/saa7134/saa7134-video.c  |  2 +-
 drivers/media/pci/saa7134/saa7134.h|  2 +-
 drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c |  2 +-
 drivers/media/pci/solo6x10/solo6x10-v4l2.c |  2 +-
 drivers/media/pci/sta2x11/sta2x11_vip.c|  2 +-
 drivers/media/pci/tw68/tw68-video.c|  2 +-
 drivers/media/pci/tw686x/tw686x-video.c|  2 +-
 drivers/media/platform/am437x/am437x-vpfe.c|  4 +-
 drivers/media/platform/blackfin/bfin_capture.c |  2 +-
 drivers/media/platform/coda/coda-common.c  |  2 +-
 drivers/media/platform/davinci/vpbe_display.c  |  2 +-
 drivers/media/platform/davinci/vpif_capture.c  |  4 +-
 drivers/media/platform/davinci/vpif_display.c  |  4 +-
 drivers/media/platform/exynos-gsc/gsc-core.h   |  1 -
 drivers/media/platform/exynos-gsc/gsc-m2m.c|  2 +-
 drivers/media/platform/exynos4-is/fimc-capture.c   |  2 +-
 drivers/media/platform/exynos4-is/fimc-isp-video.c |  2 +-
 drivers/media/platform/exynos4-is/fimc-lite.c  |  2 +-
 drivers/media/platform/exynos4-is/fimc-m2m.c   |  2 +-
 drivers/media/platform/m2m-deinterlace.c   |  2 +-
 drivers/media/platform/marvell-ccic/mcam-core.c|  2 +-
 drivers/media/platform/mx2_emmaprp.c   |  2 +-
 drivers/media/platform/omap3isp/ispvideo.c |  2 +-
 drivers/media/platform/rcar_jpu.c  |  2 +-
 drivers/media/platform/s3c-camif/camif-capture.c   |  2 +-
 drivers/media/platform/s5p-g2d/g2d.c   |  2 +-
 drivers/media/platform/s5p-jpeg/jpeg-core.c|  2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   | 10 ++---
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c   | 12 +++---
 drivers/media/platform/s5p-tv/mixer_video.c|  2 +-
 drivers/media/platform/sh_veu.c|  2 +-
 drivers/media/platform/sh_vou.c|  2 +-
 drivers/media/platform/soc_camera/atmel-isi.c  |  2 +-
 drivers/media/platform/soc_camera/rcar_vin.c   |  2 +-
 .../platform/soc_camera/sh_mobile_ceu_camera.c |  2 +-
 drivers/media/platform/sti/bdisp/bdisp-v4l2.c  |  2 +-
 drivers/media/platform/ti-vpe/cal.c|  2 +-
 drivers/media/platform/ti-vpe/vpe.c|  2 +-
 drivers/media/platform/vim2m.c |  7 +---
 drivers/media/platform/vivid/vivid-sdr-cap.c   |  2 +-
 drivers/media/platform/vivid/vivid-vbi-cap.c   |  2 +-
 drivers/media/platform/vivid/vivid-vbi-out.c   |  2 +-
 drivers/media/platform/vivid/vivid-vid-cap.c   |  7 +---
 drivers/media/platform/vivid/vivid-vid-out.c   |  7 +---
 drivers/media/platform/vsp1/vsp1_video.c   |  4 +-
 drivers/media/platform/xilinx/xilinx-dma.c |  2 +-
 drivers/media/usb/airspy/airspy.c  |  2 +-
 drivers/media/usb/au0828/au0828-vbi.c  |  2 +-
 drivers/media/usb/au0828/au0828-video.c|  2 +-
 drivers/media/usb/em28xx/em28xx-vbi.c  |  2 +-
 drivers/media/usb/em28xx/em28xx-video.c|  2 +-
 drivers/media/usb/go7007/go7007-v4l2.c |  2 +-
 drivers/media/usb/hackrf/hackrf.c  |  2 +-
 drivers/media/usb/msi2500/msi2500.c|  2 +-
 drivers/media/usb/pwc/pwc-if.c |  2 +-
 drivers/media/usb/s2255/s2255drv.c |  2 +-
 drivers/media/usb/stk1160/stk1160-v4l.c|  2 +-
 drivers/media/usb/usbtv/usbtv-video.c  |  2 +-
 drivers/media/usb/uvc/uvc_queue.c 

[PATCHv3 08/12] media/platform: convert drivers to use the new vb2_queue dev field

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

Stop using alloc_ctx and just fill in the device pointer.

Signed-off-by: Hans Verkuil 
Cc: Laurent Pinchart 
Cc: Mikhail Ulyanov 
Cc: Guennadi Liakhovetski 
Cc: Javier Martin 
Cc: Jonathan Corbet 
---
 drivers/media/platform/m2m-deinterlace.c| 15 ++-
 drivers/media/platform/marvell-ccic/mcam-core.c | 24 +---
 drivers/media/platform/marvell-ccic/mcam-core.h |  2 --
 drivers/media/platform/mx2_emmaprp.c| 17 +++--
 drivers/media/platform/omap3isp/ispvideo.c  | 12 ++--
 drivers/media/platform/omap3isp/ispvideo.h  |  1 -
 drivers/media/platform/rcar_jpu.c   | 22 --
 drivers/media/platform/sh_veu.c | 17 +++--
 drivers/media/platform/sh_vou.c | 14 ++
 9 files changed, 17 insertions(+), 107 deletions(-)

diff --git a/drivers/media/platform/m2m-deinterlace.c 
b/drivers/media/platform/m2m-deinterlace.c
index 7383818..15110ea 100644
--- a/drivers/media/platform/m2m-deinterlace.c
+++ b/drivers/media/platform/m2m-deinterlace.c
@@ -136,7 +136,6 @@ struct deinterlace_dev {
struct dma_chan *dma_chan;
 
struct v4l2_m2m_dev *m2m_dev;
-   struct vb2_alloc_ctx*alloc_ctx;
 };
 
 struct deinterlace_ctx {
@@ -820,8 +819,6 @@ static int deinterlace_queue_setup(struct vb2_queue *vq,
*nbuffers = count;
sizes[0] = size;
 
-   alloc_ctxs[0] = ctx->dev->alloc_ctx;
-
dprintk(ctx->dev, "get %d buffer(s) of size %d each.\n", count, size);
 
return 0;
@@ -874,6 +871,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq,
src_vq->ops = &deinterlace_qops;
src_vq->mem_ops = &vb2_dma_contig_memops;
src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
+   src_vq->dev = ctx->dev->v4l2_dev.dev;
q_data[V4L2_M2M_SRC].fmt = &formats[0];
q_data[V4L2_M2M_SRC].width = 640;
q_data[V4L2_M2M_SRC].height = 480;
@@ -891,6 +889,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq,
dst_vq->ops = &deinterlace_qops;
dst_vq->mem_ops = &vb2_dma_contig_memops;
dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
+   dst_vq->dev = ctx->dev->v4l2_dev.dev;
q_data[V4L2_M2M_DST].fmt = &formats[0];
q_data[V4L2_M2M_DST].width = 640;
q_data[V4L2_M2M_DST].height = 480;
@@ -1046,13 +1045,6 @@ static int deinterlace_probe(struct platform_device 
*pdev)
 
platform_set_drvdata(pdev, pcdev);
 
-   pcdev->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
-   if (IS_ERR(pcdev->alloc_ctx)) {
-   v4l2_err(&pcdev->v4l2_dev, "Failed to alloc vb2 context\n");
-   ret = PTR_ERR(pcdev->alloc_ctx);
-   goto err_ctx;
-   }
-
pcdev->m2m_dev = v4l2_m2m_init(&m2m_ops);
if (IS_ERR(pcdev->m2m_dev)) {
v4l2_err(&pcdev->v4l2_dev, "Failed to init mem2mem device\n");
@@ -1064,8 +1056,6 @@ static int deinterlace_probe(struct platform_device *pdev)
 
 err_m2m:
video_unregister_device(&pcdev->vfd);
-err_ctx:
-   vb2_dma_contig_cleanup_ctx(pcdev->alloc_ctx);
 unreg_dev:
v4l2_device_unregister(&pcdev->v4l2_dev);
 rel_dma:
@@ -1082,7 +1072,6 @@ static int deinterlace_remove(struct platform_device 
*pdev)
v4l2_m2m_release(pcdev->m2m_dev);
video_unregister_device(&pcdev->vfd);
v4l2_device_unregister(&pcdev->v4l2_dev);
-   vb2_dma_contig_cleanup_ctx(pcdev->alloc_ctx);
dma_release_channel(pcdev->dma_chan);
 
return 0;
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c 
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 9b878de..8a1f12d 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -1059,10 +1059,6 @@ static int mcam_vb_queue_setup(struct vb2_queue *vq,
 
if (*nbufs < minbufs)
*nbufs = minbufs;
-   if (cam->buffer_mode == B_DMA_contig)
-   alloc_ctxs[0] = cam->vb_alloc_ctx;
-   else if (cam->buffer_mode == B_DMA_sg)
-   alloc_ctxs[0] = cam->vb_alloc_ctx_sg;
 
if (*num_planes)
return sizes[0] < size ? -EINVAL : 0;
@@ -1271,6 +1267,7 @@ static int mcam_setup_vb2(struct mcam_camera *cam)
vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
vq->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
vq->buf_struct_size = sizeof(struct mcam_vb_buffer);
+   vq->dev = cam->dev;
INIT_LIST_HEAD(&cam->buffers);
switch (cam->buffer_mode) {
case B_DMA_contig:
@@ -1279,9 +1276,6 @@ static int mcam_setup_vb2(struct mcam_camera *cam)
vq->mem_ops = &vb2_dma_contig_memops;
cam->dma_setup = mcam_ctlr_dma_contig;
cam->frame_complete = mcam_dma_contig_done;
-   cam->vb_alloc_ctx = vb2_dma_contig_init_ctx(cam->dev);

[PATCHv3 05/12] staging/media: convert drivers to use the new vb2_queue dev field

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

Stop using alloc_ctx and just fill in the device pointer.

Signed-off-by: Hans Verkuil 
Cc: "Lad, Prabhakar" 
Cc: Laurent Pinchart 
---
 drivers/staging/media/davinci_vpfe/vpfe_video.c | 10 +-
 drivers/staging/media/davinci_vpfe/vpfe_video.h |  2 --
 drivers/staging/media/omap4iss/iss_video.c  | 10 +-
 drivers/staging/media/omap4iss/iss_video.h  |  1 -
 4 files changed, 2 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c 
b/drivers/staging/media/davinci_vpfe/vpfe_video.c
index ea3ddec..77e66e7 100644
--- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
+++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
@@ -542,7 +542,6 @@ static int vpfe_release(struct file *file)
video->io_usrs = 0;
/* Free buffers allocated */
vb2_queue_release(&video->buffer_queue);
-   vb2_dma_contig_cleanup_ctx(video->alloc_ctx);
}
/* Decrement device users counter */
video->usrs--;
@@ -1115,7 +1114,6 @@ vpfe_buffer_queue_setup(struct vb2_queue *vq,
 
*nplanes = 1;
sizes[0] = size;
-   alloc_ctxs[0] = video->alloc_ctx;
v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev,
 "nbuffers=%d, size=%lu\n", *nbuffers, size);
return 0;
@@ -1350,12 +1348,6 @@ static int vpfe_reqbufs(struct file *file, void *priv,
video->memory = req_buf->memory;
 
/* Initialize videobuf2 queue as per the buffer type */
-   video->alloc_ctx = vb2_dma_contig_init_ctx(vpfe_dev->pdev);
-   if (IS_ERR(video->alloc_ctx)) {
-   v4l2_err(&vpfe_dev->v4l2_dev, "Failed to get the context\n");
-   return PTR_ERR(video->alloc_ctx);
-   }
-
q = &video->buffer_queue;
q->type = req_buf->type;
q->io_modes = VB2_MMAP | VB2_USERPTR;
@@ -1365,11 +1357,11 @@ static int vpfe_reqbufs(struct file *file, void *priv,
q->mem_ops = &vb2_dma_contig_memops;
q->buf_struct_size = sizeof(struct vpfe_cap_buffer);
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
+   q->dev = vpfe_dev->pdev;
 
ret = vb2_queue_init(q);
if (ret) {
v4l2_err(&vpfe_dev->v4l2_dev, "vb2_queue_init() failed\n");
-   vb2_dma_contig_cleanup_ctx(vpfe_dev->pdev);
return ret;
}
 
diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.h 
b/drivers/staging/media/davinci_vpfe/vpfe_video.h
index 653334d..aaec440 100644
--- a/drivers/staging/media/davinci_vpfe/vpfe_video.h
+++ b/drivers/staging/media/davinci_vpfe/vpfe_video.h
@@ -123,8 +123,6 @@ struct vpfe_video_device {
/* Used to store pixel format */
struct v4l2_format  fmt;
struct vb2_queuebuffer_queue;
-   /* allocator-specific contexts for each plane */
-   struct vb2_alloc_ctx *alloc_ctx;
/* Queue of filled frames */
struct list_headdma_queue;
spinlock_t  irqlock;
diff --git a/drivers/staging/media/omap4iss/iss_video.c 
b/drivers/staging/media/omap4iss/iss_video.c
index cf8da23..3c077e3 100644
--- a/drivers/staging/media/omap4iss/iss_video.c
+++ b/drivers/staging/media/omap4iss/iss_video.c
@@ -310,8 +310,6 @@ static int iss_video_queue_setup(struct vb2_queue *vq,
if (sizes[0] == 0)
return -EINVAL;
 
-   alloc_ctxs[0] = video->alloc_ctx;
-
*count = min(*count, video->capture_mem / PAGE_ALIGN(sizes[0]));
 
return 0;
@@ -1017,13 +1015,6 @@ static int iss_video_open(struct file *file)
goto done;
}
 
-   video->alloc_ctx = vb2_dma_contig_init_ctx(video->iss->dev);
-   if (IS_ERR(video->alloc_ctx)) {
-   ret = PTR_ERR(video->alloc_ctx);
-   omap4iss_put(video->iss);
-   goto done;
-   }
-
q = &handle->queue;
 
q->type = video->type;
@@ -1033,6 +1024,7 @@ static int iss_video_open(struct file *file)
q->mem_ops = &vb2_dma_contig_memops;
q->buf_struct_size = sizeof(struct iss_buffer);
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
+   q->dev = video->iss->dev;
 
ret = vb2_queue_init(q);
if (ret) {
diff --git a/drivers/staging/media/omap4iss/iss_video.h 
b/drivers/staging/media/omap4iss/iss_video.h
index c8bd295..d7e05d0 100644
--- a/drivers/staging/media/omap4iss/iss_video.h
+++ b/drivers/staging/media/omap4iss/iss_video.h
@@ -170,7 +170,6 @@ struct iss_video {
spinlock_t qlock;   /* protects dmaqueue and error */
struct list_head dmaqueue;
enum iss_video_dmaqueue_flags dmaqueue_flags;
-   struct vb2_alloc_ctx *alloc_ctx;
 
const struct iss_video_operations *ops;
 };
-- 
2.8.0.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More ma

[PATCHv3 01/12] vb2: add a dev field to use for the default allocation context

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

The allocation context is nothing more than a per-plane device pointer
to use when allocating buffers. So just provide a dev pointer in vb2_queue
for that purpose and drivers can skip allocating/releasing/filling in
the allocation context unless they require different per-plane device
pointers as used by some Samsung SoCs.

Signed-off-by: Hans Verkuil 
Cc: Laurent Pinchart 
Cc: Sakari Ailus 
Cc: Mauro Carvalho Chehab 
Cc: Florian Echtler 
Cc: Federico Vaga 
Cc: "Lad, Prabhakar" 
Cc: Scott Jiang 
Cc: Philipp Zabel 
Cc: Fabien Dessenne 
Cc: Benoit Parrot 
Cc: Mikhail Ulyanov 
Cc: Guennadi Liakhovetski 
Cc: Javier Martin 
Cc: Jonathan Corbet 
Cc: Ludovic Desroches 
Cc: Sergei Shtylyov 
Cc: Kyungmin Park 
Cc: Sylwester Nawrocki 
---
 drivers/media/v4l2-core/videobuf2-core.c | 16 +---
 include/media/videobuf2-core.h   |  3 +++
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 5d016f4..88b5e48 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -206,8 +206,9 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
for (plane = 0; plane < vb->num_planes; ++plane) {
unsigned long size = PAGE_ALIGN(vb->planes[plane].length);
 
-   mem_priv = call_ptr_memop(vb, alloc, q->alloc_ctx[plane],
- size, dma_dir, q->gfp_flags);
+   mem_priv = call_ptr_memop(vb, alloc,
+   q->alloc_ctx[plane] ? : &q->dev,
+   size, dma_dir, q->gfp_flags);
if (IS_ERR_OR_NULL(mem_priv))
goto free;
 
@@ -1131,9 +1132,10 @@ static int __qbuf_userptr(struct vb2_buffer *vb, const 
void *pb)
vb->planes[plane].data_offset = 0;
 
/* Acquire each plane's memory */
-   mem_priv = call_ptr_memop(vb, get_userptr, q->alloc_ctx[plane],
- planes[plane].m.userptr,
- planes[plane].length, dma_dir);
+   mem_priv = call_ptr_memop(vb, get_userptr,
+   q->alloc_ctx[plane] ? : &q->dev,
+   planes[plane].m.userptr,
+   planes[plane].length, dma_dir);
if (IS_ERR_OR_NULL(mem_priv)) {
dprintk(1, "failed acquiring userspace "
"memory for plane %d\n", plane);
@@ -1256,8 +1258,8 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const 
void *pb)
 
/* Acquire each plane's memory */
mem_priv = call_ptr_memop(vb, attach_dmabuf,
-   q->alloc_ctx[plane], dbuf, planes[plane].length,
-   dma_dir);
+   q->alloc_ctx[plane] ? : &q->dev,
+   dbuf, planes[plane].length, dma_dir);
if (IS_ERR(mem_priv)) {
dprintk(1, "failed to attach dmabuf\n");
ret = PTR_ERR(mem_priv);
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 8a0f55b..0f8b97b 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -397,6 +397,8 @@ struct vb2_buf_ops {
  * caller. For example, for V4L2, it should match
  * the V4L2_BUF_TYPE_* in include/uapi/linux/videodev2.h
  * @io_modes:  supported io methods (see vb2_io_modes enum)
+ * @dev:   device to use for the default allocation context if the driver
+ * doesn't fill in the @alloc_ctx array.
  * @fileio_read_once:  report EOF after reading the first buffer
  * @fileio_write_immediately:  queue buffer after each write() call
  * @allow_zero_bytesused:  allow bytesused == 0 to be passed to the driver
@@ -460,6 +462,7 @@ struct vb2_buf_ops {
 struct vb2_queue {
unsigned inttype;
unsigned intio_modes;
+   struct device   *dev;
unsignedfileio_read_once:1;
unsignedfileio_write_immediately:1;
unsignedallow_zero_bytesused:1;
-- 
2.8.0.rc3

--
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


[PATCHv3 02/12] v4l2-pci-skeleton: set q->dev instead of allocating a context

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

Stop using alloc_ctx as that is now no longer needed.

Signed-off-by: Hans Verkuil 
---
 Documentation/video4linux/v4l2-pci-skeleton.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/Documentation/video4linux/v4l2-pci-skeleton.c 
b/Documentation/video4linux/v4l2-pci-skeleton.c
index a55cf94..5f91d76 100644
--- a/Documentation/video4linux/v4l2-pci-skeleton.c
+++ b/Documentation/video4linux/v4l2-pci-skeleton.c
@@ -56,7 +56,6 @@ MODULE_LICENSE("GPL v2");
  * @format: current pix format
  * @input: current video input (0 = SDTV, 1 = HDTV)
  * @queue: vb2 video capture queue
- * @alloc_ctx: vb2 contiguous DMA context
  * @qlock: spinlock controlling access to buf_list and sequence
  * @buf_list: list of buffers queued for DMA
  * @sequence: frame sequence counter
@@ -73,7 +72,6 @@ struct skeleton {
unsigned input;
 
struct vb2_queue queue;
-   struct vb2_alloc_ctx *alloc_ctx;
 
spinlock_t qlock;
struct list_head buf_list;
@@ -182,7 +180,6 @@ static int queue_setup(struct vb2_queue *vq,
 
if (vq->num_buffers + *nbuffers < 3)
*nbuffers = 3 - vq->num_buffers;
-   alloc_ctxs[0] = skel->alloc_ctx;
 
if (*nplanes)
return sizes[0] < skel->format.sizeimage ? -EINVAL : 0;
@@ -820,6 +817,7 @@ static int skeleton_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
q = &skel->queue;
q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
q->io_modes = VB2_MMAP | VB2_DMABUF | VB2_READ;
+   q->dev = &pdev->dev;
q->drv_priv = skel;
q->buf_struct_size = sizeof(struct skel_buffer);
q->ops = &skel_qops;
@@ -850,12 +848,6 @@ static int skeleton_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
if (ret)
goto free_hdl;
 
-   skel->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
-   if (IS_ERR(skel->alloc_ctx)) {
-   dev_err(&pdev->dev, "Can't allocate buffer context");
-   ret = PTR_ERR(skel->alloc_ctx);
-   goto free_hdl;
-   }
INIT_LIST_HEAD(&skel->buf_list);
spin_lock_init(&skel->qlock);
 
@@ -885,13 +877,11 @@ static int skeleton_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
 
ret = video_register_device(vdev, VFL_TYPE_GRABBER, -1);
if (ret)
-   goto free_ctx;
+   goto free_hdl;
 
dev_info(&pdev->dev, "V4L2 PCI Skeleton Driver loaded\n");
return 0;
 
-free_ctx:
-   vb2_dma_contig_cleanup_ctx(skel->alloc_ctx);
 free_hdl:
v4l2_ctrl_handler_free(&skel->ctrl_handler);
v4l2_device_unregister(&skel->v4l2_dev);
@@ -907,7 +897,6 @@ static void skeleton_remove(struct pci_dev *pdev)
 
video_unregister_device(&skel->vdev);
v4l2_ctrl_handler_free(&skel->ctrl_handler);
-   vb2_dma_contig_cleanup_ctx(skel->alloc_ctx);
v4l2_device_unregister(&skel->v4l2_dev);
pci_disable_device(skel->pdev);
 }
-- 
2.8.0.rc3

--
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


[PATCHv3 00/12] vb2: replace allocation context by device pointer

2016-04-22 Thread Hans Verkuil
From: Hans Verkuil 

The opaque allocation context that allocators use and drivers have to fill
in is really nothing more than a device pointer wrapped in an kmalloc()ed
struct.

This patch series adds a new 'struct device *dev' field that contains the
default device pointer to use if the driver doesn't set alloc_ctxs. This
simplifies many drivers since there are only two Samsung drivers that need
different devices for different planes. All others use the same device for
everything.

So instead of having to allocate a context (and free it, which not all
drivers did) you just set a dev pointer once.

The last patch removes the allocation context code altogether and replaces
it with proper struct device pointers instead of the untyped void pointer.

Note: one idea I toyed with was to have an array of devs instead of a
single dev field in vb2_queue, but that was actually awkward to use.

A single dev turned out to be much easier to use.

If there are no comments, then I intend to post a pull request on
Monday.

Regards,

Hans

Changes since v2:
- rebased against latest linuxtv master and converted the tw686x
  drivers.

Changes since v1:
- rebased against latest linuxtv master
- add dma_attrs field to vb2_queue to specify non-standard DMA attributes
  for both dma-contig. This feature was added to v4.6.

Hans Verkuil (12):
  vb2: add a dev field to use for the default allocation context
  v4l2-pci-skeleton: set q->dev instead of allocating a context
  sur40: set q->dev instead of allocating a context
  media/pci: convert drivers to use the new vb2_queue dev field
  staging/media: convert drivers to use the new vb2_queue dev field
  media/platform: convert drivers to use the new vb2_queue dev field
  media/platform: convert drivers to use the new vb2_queue dev field
  media/platform: convert drivers to use the new vb2_queue dev field
  media/.../soc-camera: convert drivers to use the new vb2_queue dev
field
  media/platform: convert drivers to use the new vb2_queue dev field
  media/platform: convert drivers to use the new vb2_queue dev field
  vb2: replace void *alloc_ctxs by struct device *alloc_devs

 Documentation/video4linux/v4l2-pci-skeleton.c  | 17 ++--
 drivers/input/touchscreen/sur40.c  | 15 +--
 drivers/media/dvb-frontends/rtl2832_sdr.c  |  2 +-
 drivers/media/pci/cobalt/cobalt-driver.c   |  9 
 drivers/media/pci/cobalt/cobalt-driver.h   |  1 -
 drivers/media/pci/cobalt/cobalt-v4l2.c |  4 +-
 drivers/media/pci/cx23885/cx23885-417.c|  3 +-
 drivers/media/pci/cx23885/cx23885-core.c   | 10 +
 drivers/media/pci/cx23885/cx23885-dvb.c|  4 +-
 drivers/media/pci/cx23885/cx23885-vbi.c|  3 +-
 drivers/media/pci/cx23885/cx23885-video.c  |  5 ++-
 drivers/media/pci/cx23885/cx23885.h|  1 -
 drivers/media/pci/cx25821/cx25821-core.c   | 10 +
 drivers/media/pci/cx25821/cx25821-video.c  |  5 +--
 drivers/media/pci/cx25821/cx25821.h|  1 -
 drivers/media/pci/cx88/cx88-blackbird.c|  4 +-
 drivers/media/pci/cx88/cx88-dvb.c  |  4 +-
 drivers/media/pci/cx88/cx88-mpeg.c | 10 +
 drivers/media/pci/cx88/cx88-vbi.c  |  3 +-
 drivers/media/pci/cx88/cx88-video.c| 13 ++
 drivers/media/pci/cx88/cx88.h  |  2 -
 drivers/media/pci/dt3155/dt3155.c  | 15 ++-
 drivers/media/pci/dt3155/dt3155.h  |  2 -
 drivers/media/pci/netup_unidvb/netup_unidvb_core.c |  2 +-
 drivers/media/pci/saa7134/saa7134-core.c   | 22 --
 drivers/media/pci/saa7134/saa7134-ts.c |  3 +-
 drivers/media/pci/saa7134/saa7134-vbi.c|  3 +-
 drivers/media/pci/saa7134/saa7134-video.c  |  5 ++-
 drivers/media/pci/saa7134/saa7134.h|  3 +-
 drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 13 +-
 drivers/media/pci/solo6x10/solo6x10-v4l2.c | 12 +-
 drivers/media/pci/solo6x10/solo6x10.h  |  2 -
 drivers/media/pci/sta2x11/sta2x11_vip.c| 20 ++---
 drivers/media/pci/tw68/tw68-core.c | 15 ++-
 drivers/media/pci/tw68/tw68-video.c|  4 +-
 drivers/media/pci/tw68/tw68.h  |  1 -
 drivers/media/pci/tw686x/tw686x-video.c|  2 +-
 drivers/media/platform/am437x/am437x-vpfe.c| 14 ++-
 drivers/media/platform/am437x/am437x-vpfe.h|  2 -
 drivers/media/platform/blackfin/bfin_capture.c | 17 ++--
 drivers/media/platform/coda/coda-common.c  | 18 ++--
 drivers/media/platform/coda/coda.h |  1 -
 drivers/media/platform/davinci/vpbe_display.c  | 14 +--
 drivers/media/platform/davinci/vpif_capture.c  | 15 ++-
 drivers/media/platform/davinci/vpif_capture.h  |  2 -
 drivers/media/platform/davinci/vpif_display.c  | 15 ++-
 drive

Re: [RFC] Streaming I/O: proposal to expose MMAP/USERPTR/DMABUF capabilities with QUERYCAP

2016-04-22 Thread Hans Verkuil
On 04/22/2016 10:23 AM, Jean-Michel Hautbois wrote:
> Hi Hans,
> 
> 2016-04-22 10:08 GMT+02:00 Hans Verkuil :
>> Hi all,
>>
>> I have always been unhappy with the fact that it is so hard to tell whether
>> the USERPTR and/or DMABUF modes are available with Streaming I/O. QUERYCAP
>> only tells you if Streaming I/O is available, but not in which flavors.
>>
>> So I propose the following:
>>
>> #define V4L2_CAP_STREAMING_MMAP V4L2_CAP_STREAMING
>> #define V4L2_CAP_STREAMING_USERPTR 0x0800
>> #define V4L2_CAP_STREAMING_DMABUF  0x1000
>>
>> All drivers that currently support CAP_STREAMING also support MMAP. For 
>> userptr
>> and dmabuf support we add new caps. These can be set by the core if the 
>> driver
>> uses vb2 since the core can query the io_modes field of vb2_queue.
> 
> So, you want to make it mandatory for future drivers that they support
> MMAP. Fine with me.
> BTW, dmabuf is still marked as experimental, what would make it part
> of the API for good ?

Just laziness on our part. I think I should go through the docs and update these
things. Most things marked experimental can probably drop that designation.

> 
>> For the drivers that do not yet support vb2 we can add it manually.
>>
>> I was considering making it a requirement that the MMAP streaming mode is
>> always present, but I don't know if that works once we get drivers that 
>> operate
>> on secure memory. So I won't do that for now.
> 
> By using "#define V4L2_CAP_STREAMING_MMAP V4L2_CAP_STREAMING" you make
> it mandatory... You would need a separate bit to indicate MMAP
> otherwise...

No: all *current* drivers marked CAP_STREAMING support MMAP. But future devices
that might not support MMAP would not set this cap.

So it is possible that in the future you'd get a driver that has just 
STREAMING_DMABUF
set. Which is something I can imagine for drivers operating on secure memory.

Regards,

Hans

> 
>> Since we are looking at device caps anyway: can we just drop 
>> V4L2_CAP_ASYNCIO?
>> It's never been implemented, nor is it likely in the future. And we don't 
>> have
>> all that many bits left before we need to use one of the reserved fields for
>> additional capabilities.
>>
>> 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
> 

--
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] drm: rcar-du: Add Z-order support for VSP planes

2016-04-22 Thread Daniel Vetter
On Fri, Apr 22, 2016 at 12:00:39AM +0300, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Thursday 21 Apr 2016 18:10:25 Daniel Vetter wrote:
> > On Thu, Apr 21, 2016 at 04:14:12AM +0300, Laurent Pinchart wrote:
> > > Make the Z-order of VSP planes configurable through the zpos property,
> > > exactly as for the native DU planes.
> > > 
> > > Signed-off-by: Laurent Pinchart
> > > 
> > > ---
> > > 
> > >  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 16 
> > >  drivers/gpu/drm/rcar-du/rcar_du_vsp.h |  2 ++
> > >  2 files changed, 14 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > > b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index de7ef041182b..62e9619eaea4
> > > 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > > @@ -180,8 +180,9 @@ static void rcar_du_vsp_plane_setup(struct
> > > rcar_du_vsp_plane *plane)> 
> > >   WARN_ON(!pixelformat);
> > > 
> > > - vsp1_du_atomic_update(plane->vsp->vsp, plane->index, pixelformat,
> > > -   fb->pitches[0], paddr, &src, &dst);
> > > + vsp1_du_atomic_update_zpos(plane->vsp->vsp, plane->index, pixelformat,
> > > +fb->pitches[0], paddr, &src, &dst,
> > > +state->zpos);
> > > 
> > >  }
> > >  
> > >  static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
> > > 
> > > @@ -220,8 +221,8 @@ static void rcar_du_vsp_plane_atomic_update(struct
> > > drm_plane *plane,> 
> > >   if (plane->state->crtc)
> > >   
> > >   rcar_du_vsp_plane_setup(rplane);
> > >   
> > >   else
> > > 
> > > - vsp1_du_atomic_update(rplane->vsp->vsp, rplane->index, 0, 0, 0,
> > > -   NULL, NULL);
> > > + vsp1_du_atomic_update_zpos(rplane->vsp->vsp, rplane->index,
> > > +0, 0, 0, NULL, NULL, 0);
> > > 
> > >  }
> > >  
> > >  static const struct drm_plane_helper_funcs rcar_du_vsp_plane_helper_funcs
> > >  = {> 
> > > @@ -269,6 +270,7 @@ static void rcar_du_vsp_plane_reset(struct drm_plane
> > > *plane)> 
> > >   return;
> > >   
> > >   state->alpha = 255;
> > > 
> > > + state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
> > > 
> > >   plane->state = &state->state;
> > >   plane->state->plane = plane;
> > > 
> > > @@ -283,6 +285,8 @@ static int
> > > rcar_du_vsp_plane_atomic_set_property(struct drm_plane *plane,> 
> > >   if (property == rcdu->props.alpha)
> > >   
> > >   rstate->alpha = val;
> > > 
> > > + else if (property == rcdu->props.zpos)
> > > + rstate->zpos = val;
> > > 
> > >   else
> > >   
> > >   return -EINVAL;
> > > 
> > > @@ -299,6 +303,8 @@ static int
> > > rcar_du_vsp_plane_atomic_get_property(struct drm_plane *plane,> 
> > >   if (property == rcdu->props.alpha)
> > >   
> > >   *val = rstate->alpha;
> > > 
> > > + else if (property == rcdu->props.zpos)
> > > + *val = rstate->zpos;
> > > 
> > >   else
> > >   
> > >   return -EINVAL;
> > > 
> > > @@ -378,6 +384,8 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp)
> > > 
> > >   drm_object_attach_property(&plane->plane.base,
> > >   
> > >  rcdu->props.alpha, 255);
> > > 
> > > + drm_object_attach_property(&plane->plane.base,
> > > +rcdu->props.zpos, 1);
> > > 
> > >   }
> > >   
> > >   return 0;
> > > 
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> > > b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h index df3bf3805c69..510dcc9c6816
> > > 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> > > @@ -44,6 +44,7 @@ static inline struct rcar_du_vsp_plane
> > > *to_rcar_vsp_plane(struct drm_plane *p)> 
> > >   * @state: base DRM plane state
> > >   * @format: information about the pixel format used by the plane
> > >   * @alpha: value of the plane alpha property
> > > 
> > > + * @zpos: value of the plane zpos property
> > > 
> > >   */
> > >  
> > >  struct rcar_du_vsp_plane_state {
> > >  
> > >   struct drm_plane_state state;
> > > 
> > > @@ -51,6 +52,7 @@ struct rcar_du_vsp_plane_state {
> > > 
> > >   const struct rcar_du_format_info *format;
> > >   
> > >   unsigned int alpha;
> > > 
> > > + unsigned int zpos;
> > 
> > There's lots of effort by various people to create a generic zpos/blending
> > set of properties. Care to jump onto that effort and making it finally
> > happen for real? I kinda don't want to have a propliferation of slightly
> > diffferent zpos/blending props across all the drivers ...
> 
> OK, I'll try to. Would you mind if we got these patches merged first for 
> v4.7, 
> and then switched to a generic property for v4.8 ? The reason is that this 
> series depends on a large patch series queued in the linux-media tree for 
> v4.7, and it would be easier to handle the dependency by merging these two 
> patches in linux-me

Re: [PATCH 0/8] Input: atmel_mxt_ts - output raw touch diagnostic data via V4L

2016-04-22 Thread Hans Verkuil
Hi Nick,

On 04/21/2016 11:31 AM, Nick Dyer wrote:
> This is a series of patches to add diagnostic data support to the Atmel
> maXTouch driver. It's a rewrite of the previous implementation which output 
> via
> debugfs: it now uses a V4L2 device in a similar way to the sur40 driver.
> 
> There are significant performance advantages to putting this code into the
> driver. The algorithm for retrieving the data has been fairly consistent 
> across
> a range of chips, with the exception of the mXT1386 series (see patch).
> 
> We have a utility which can read the data and display it in a useful format:
>   https://github.com/ndyer/heatmap/commits/heatmap-v4l
> 
> These patches are also available from
>   https://github.com/ndyer/linux/commits/diagnostic-v4l
> 
> Any feedback appreciated.

FYI: we're working on a new buffer type for meta data:

https://patchwork.linuxtv.org/patch/33938/
https://patchwork.linuxtv.org/patch/33939/

This would be an excellent fit for you. I expect that this new feature would be
merged soon (for 4.7 or 4.8 at the latest) since it looks all pretty good to me.

So let's wait for this to be merged and then you can migrate to the new buffer
type.

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


Re: libdvbv5 licencing

2016-04-22 Thread Russel Winder
On Tue, 2016-04-19 at 16:36 -0300, Mauro Carvalho Chehab wrote:
> […]
> License changed.

Thank you, this is great news.

GStreamer dvbsrc rewrite now on the starting blocks: lots of code
"replication" deletion first thing on the agenda.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part


Re: [RFC] Streaming I/O: proposal to expose MMAP/USERPTR/DMABUF capabilities with QUERYCAP

2016-04-22 Thread Jean-Michel Hautbois
Hi Hans,

2016-04-22 10:08 GMT+02:00 Hans Verkuil :
> Hi all,
>
> I have always been unhappy with the fact that it is so hard to tell whether
> the USERPTR and/or DMABUF modes are available with Streaming I/O. QUERYCAP
> only tells you if Streaming I/O is available, but not in which flavors.
>
> So I propose the following:
>
> #define V4L2_CAP_STREAMING_MMAP V4L2_CAP_STREAMING
> #define V4L2_CAP_STREAMING_USERPTR 0x0800
> #define V4L2_CAP_STREAMING_DMABUF  0x1000
>
> All drivers that currently support CAP_STREAMING also support MMAP. For 
> userptr
> and dmabuf support we add new caps. These can be set by the core if the driver
> uses vb2 since the core can query the io_modes field of vb2_queue.

So, you want to make it mandatory for future drivers that they support
MMAP. Fine with me.
BTW, dmabuf is still marked as experimental, what would make it part
of the API for good ?

> For the drivers that do not yet support vb2 we can add it manually.
>
> I was considering making it a requirement that the MMAP streaming mode is
> always present, but I don't know if that works once we get drivers that 
> operate
> on secure memory. So I won't do that for now.

By using "#define V4L2_CAP_STREAMING_MMAP V4L2_CAP_STREAMING" you make
it mandatory... You would need a separate bit to indicate MMAP
otherwise...

> Since we are looking at device caps anyway: can we just drop V4L2_CAP_ASYNCIO?
> It's never been implemented, nor is it likely in the future. And we don't have
> all that many bits left before we need to use one of the reserved fields for
> additional capabilities.
>
> 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


[RFC] Streaming I/O: proposal to expose MMAP/USERPTR/DMABUF capabilities with QUERYCAP

2016-04-22 Thread Hans Verkuil
Hi all,

I have always been unhappy with the fact that it is so hard to tell whether
the USERPTR and/or DMABUF modes are available with Streaming I/O. QUERYCAP
only tells you if Streaming I/O is available, but not in which flavors.

So I propose the following:

#define V4L2_CAP_STREAMING_MMAP V4L2_CAP_STREAMING
#define V4L2_CAP_STREAMING_USERPTR 0x0800
#define V4L2_CAP_STREAMING_DMABUF  0x1000

All drivers that currently support CAP_STREAMING also support MMAP. For userptr
and dmabuf support we add new caps. These can be set by the core if the driver
uses vb2 since the core can query the io_modes field of vb2_queue.

For the drivers that do not yet support vb2 we can add it manually.

I was considering making it a requirement that the MMAP streaming mode is
always present, but I don't know if that works once we get drivers that operate
on secure memory. So I won't do that for now.

Since we are looking at device caps anyway: can we just drop V4L2_CAP_ASYNCIO?
It's never been implemented, nor is it likely in the future. And we don't have
all that many bits left before we need to use one of the reserved fields for
additional capabilities.

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


Re: [PATCH v7 7/8] [media] vcodec: mediatek: Add Mediatek H264 Video Encoder Driver

2016-04-22 Thread kbuild test robot
Hi,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.6-rc4 next-20160421]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Tiffany-Lin/Add-MT8173-Video-Encoder-Driver-and-VPU-Driver/20160422-123111
base:   git://linuxtv.org/media_tree.git master
config: i386-allyesconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c: In function 
'h264_enc_alloc_work_buf':
>> drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c:299:35: warning: 
>> format '%lx' expects argument of type 'long unsigned int', but argument 7 
>> has type 'size_t {aka unsigned int}' [-Wformat=]

vim +299 drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c

   283   * This RC_CODE is pre-allocated by VPU and 
saved in VPU
   284   * addr. So we need use memcpy to copy RC_CODE 
from VPU
   285   * addr into IO virtual addr in 'iova' field 
for reg
   286   * setting in VPU side.
   287   */
   288  if (i == VENC_H264_VPU_WORK_BUF_RC_CODE) {
   289  void *tmp_va;
   290  
   291  tmp_va = 
vpu_mapping_dm_addr(inst->vpu_inst.dev,
   292   
wb[i].vpua);
   293  memcpy(inst->work_bufs[i].va, tmp_va,
   294 wb[i].size);
   295  }
   296  }
   297  wb[i].iova = inst->work_bufs[i].dma_addr;
   298  
 > 299  mtk_vcodec_debug(inst,
   300   "work_buf[%d] va=0x%p iova=0x%p 
size=0x%lx",
   301   i, inst->work_bufs[i].va,
   302   (void *)inst->work_bufs[i].dma_addr,
   303   inst->work_bufs[i].size);
   304  }
   305  
   306  /* the pps_buf is used by AP side only */
   307  inst->pps_buf.size = 128;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH v7 00/24] i2c mux cleanup and locking update

2016-04-22 Thread Peter Rosin
Hi Wolfram,

Wolfram Sang wrote:
> This was the diff of v6:
> 
> >  32 files changed, 1277 insertions(+), 915 deletions(-)
> 
> This is v7:
> 
> >  32 files changed, 1225 insertions(+), 916 deletions(-)
> 
> So, we gained a little overall. And while the individual drivers have a
> few lines more now, I still think it is more readable.
> 
> So, thanks for doing that!

Most, if not all, of these ~50 lines gained in v7 come from removing
i2c_mux_reserve_adapters and realloc. I.e., I think we might even have
lost a few lines with the i2c_mux_one_adapter removal, but not that many.
If the doc patch is taken out of the equation, we gain new functionality,
fix a bug and lose lines of code. Feels good!
However, this is not why I'm writing this message...

> I'll give people some time for testing. I'll have a further look, too.
> Hopefully, I can pick up patches 1-14 by the end of the week.

The reason for this message is that I just realized a couple of things.

First, you have suggested to merge patches 1-14 about now, and I assumed
that implied merging with Linus for 4.6, but on rereading I realize that
you have consistently targeted 4.7. I must be sloppy, and that had escaped
me. Is it really necessary to be that cautious? Maybe I'm overly confident,
but is 1-14 really such a big deal that it has to float in next for a whole
cycle?

The problem with waiting until 4.8 with the rest of the series is that it
will likely go stale, e.g. patch 22 ([media] rtl2832: change the i2c gate
to be mux-locked) touches a ton of register accesses in that driver since
it removes a regmap wrapper that is rendered obsolete. Expecting that
patch to work for 4.8 is overly optimistic, and while patching things up
is (probably) easy, it also renders any previous testing suspect.

That said, maybe I'm just impatient and reckless?

Second, should we not add 15-24 to the next branch now as well to get
testing going asap, even if we do not intend to merge it just yet or even
in that exact form? Or is that abusing the next branch?

Third, should we deprecate the old i2c_add_mux_adapter, so that new
users do not crop up behind our backs in the transition? Or not bother?

Fourth, I forgot to change patch 8 (iio: imu: inv_mpu6050: convert to
use an explicit i2c mux core) to not change i2c_get_clientdata() ->
dev_get_drvdata() as requested by Jonathan Cameron. How should I handle
that? There are also some new Tested-by tags that I have added to my
local branch but have not pushed anywhere. I'm ready to push all that
to a new branch once you are ready to take it.

Cheers,
Peter
--
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 v7 6/8] [media] vcodec: mediatek: Add Mediatek VP8 Video Encoder Driver

2016-04-22 Thread kbuild test robot
Hi,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.6-rc4 next-20160421]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Tiffany-Lin/Add-MT8173-Video-Encoder-Driver-and-VPU-Driver/20160422-123111
base:   git://linuxtv.org/media_tree.git master
config: i386-allyesconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c: In function 
'vp8_enc_alloc_work_buf':
>> drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:214:35: warning: format 
>> '%lx' expects argument of type 'long unsigned int', but argument 7 has type 
>> 'size_t {aka unsigned int}' [-Wformat=]
   drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c: In function 
'vp8_enc_compose_one_frame':
>> drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:279:10: warning: format 
>> '%ld' expects argument of type 'long int', but argument 4 has type 'size_t 
>> {aka unsigned int}' [-Wformat=]
  mtk_vcodec_err(inst, "bitstream buf size is too small(%ld)",
 ^

vim +214 drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c

   208  tmp_va = vpu_mapping_dm_addr(inst->vpu_inst.dev,
   209   wb[i].vpua);
   210  memcpy(inst->work_bufs[i].va, tmp_va, 
wb[i].size);
   211  }
   212  wb[i].iova = inst->work_bufs[i].dma_addr;
   213  
 > 214  mtk_vcodec_debug(inst,
   215   "work_bufs[%d] 
va=0x%p,iova=0x%p,size=0x%lx",
   216   i, inst->work_bufs[i].va,
   217   (void *)inst->work_bufs[i].dma_addr,
   218   inst->work_bufs[i].size);
   219  }
   220  
   221  mtk_vcodec_debug_leave(inst);
   222  
   223  return ret;
   224  
   225  err_alloc:
   226  vp8_enc_free_work_buf(inst);
   227  
   228  return ret;
   229  }
   230  
   231  static unsigned int vp8_enc_wait_venc_done(struct venc_vp8_inst *inst)
   232  {
   233  unsigned int irq_status = 0;
   234  struct mtk_vcodec_ctx *ctx = (struct mtk_vcodec_ctx *)inst->ctx;
   235  
   236  if (!mtk_vcodec_wait_for_done_ctx(ctx, MTK_INST_IRQ_RECEIVED,
   237WAIT_INTR_TIMEOUT_MS)) {
   238  irq_status = ctx->irq_status;
   239  mtk_vcodec_debug(inst, "isr return %x", irq_status);
   240  }
   241  return irq_status;
   242  }
   243  
   244  /*
   245   * Compose ac_tag, bitstream header and bitstream payload into
   246   * one bitstream buffer.
   247   */
   248  static int vp8_enc_compose_one_frame(struct venc_vp8_inst *inst,
   249   struct mtk_vcodec_mem *bs_buf,
   250   unsigned int *bs_size)
   251  {
   252  unsigned int not_key;
   253  u32 bs_frm_size;
   254  u32 bs_hdr_len;
   255  unsigned int ac_tag_size;
   256  u8 ac_tag[MAX_AC_TAG_SIZE];
   257  
   258  bs_frm_size = vp8_enc_read_reg(inst, VENC_BITSTREAM_FRAME_SIZE);
   259  bs_hdr_len = vp8_enc_read_reg(inst, VENC_BITSTREAM_HEADER_LEN);
   260  
   261  /* if a frame is key frame, not_key is 0 */
   262  not_key = !inst->vpu_inst.is_key_frm;
   263  *(u32 *)ac_tag = __cpu_to_le32((bs_hdr_len << 5) | 0x10 | 
not_key);
   264  /* key frame */
   265  if (not_key == 0) {
   266  ac_tag_size = MAX_AC_TAG_SIZE;
   267  ac_tag[3] = 0x9d;
   268  ac_tag[4] = 0x01;
   269  ac_tag[5] = 0x2a;
   270  ac_tag[6] = inst->vsi->config.pic_w;
   271  ac_tag[7] = inst->vsi->config.pic_w >> 8;
   272  ac_tag[8] = inst->vsi->config.pic_h;
   273  ac_tag[9] = inst->vsi->config.pic_h >> 8;
   274  } else {
   275  ac_tag_size = 3;
   276  }
   277  
   278  if (bs_buf->size < bs_hdr_len + bs_frm_size + ac_tag_size) {
 > 279  mtk_vcodec_err(inst, "bitstream buf size is too 
 > small(%ld)",
   280 bs_buf->size);
   281  return -EINVAL;
   282  }

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH/RFC 1/2] v4l: Add meta-data video device type

2016-04-22 Thread Hans Verkuil
On 04/21/2016 09:15 PM, Laurent Pinchart wrote:
> Hi Hans,
> 
> Thank you for the review.
> 
> On Thursday 21 Apr 2016 08:39:59 Hans Verkuil wrote:
>> Hi Laurent,
>>
>> Thanks for the patch!
>>
>> Some, mostly small, comments follow:
>>
>> On 04/21/2016 02:40 AM, Laurent Pinchart wrote:
>>> The meta-data video device is used to transfer meta-data between
>>> userspace and kernelspace through a V4L2 buffers queue. It comes with a
>>> new meta-data capture capability, buffer type and format description.
>>>
>>> Signed-off-by: Laurent Pinchart
>>> 
>>> ---
>>>
>>>  Documentation/DocBook/media/v4l/dev-meta.xml  | 100 +
>>>  Documentation/DocBook/media/v4l/v4l2.xml  |   1 +
>>>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  19 +
>>>  drivers/media/v4l2-core/v4l2-dev.c|  21 +-
>>>  drivers/media/v4l2-core/v4l2-ioctl.c  |  39 ++
>>>  drivers/media/v4l2-core/videobuf2-v4l2.c  |   3 +
>>>  include/media/v4l2-dev.h  |   3 +-
>>>  include/media/v4l2-ioctl.h|   8 +++
>>>  include/uapi/linux/media.h|   2 +
>>>  include/uapi/linux/videodev2.h|  14 
>>>  10 files changed, 208 insertions(+), 2 deletions(-)
>>>  create mode 100644 Documentation/DocBook/media/v4l/dev-meta.xml
>>>
>>> diff --git a/Documentation/DocBook/media/v4l/dev-meta.xml
>>> b/Documentation/DocBook/media/v4l/dev-meta.xml new file mode 100644
>>> index ..ddc685186015
>>> --- /dev/null
>>> +++ b/Documentation/DocBook/media/v4l/dev-meta.xml
>>> @@ -0,0 +1,100 @@
>>> +  Meta-Data Interface
>>> +
>>> +  
>>> +Experimental
>>> +This is an  experimental 
>>> +interface and may change in the future.
>>> +  
>>> +
>>> +  
>>> +Meta-data refers to any non-image data that supplements video frames with
>>> +additional information. This may include statistics computed over the
>>> image +or frame capture parameters supplied by the image source. This
>>> interface is +intended for transfer of meta-data to userspace and control
>>> of that operation. +  
>>> +
>>> +  
>>> +Meta-data devices are accessed through character device special files
>>> named +/dev/v4l-meta0 to
>>> /dev/v4l-meta255 +with major number 81 and
>>> dynamically allocated minor numbers 0 to 255. +  
>>> +
>>> +  
>>> +Querying Capabilities
>>> +
>>> +
>>> +Devices supporting the meta-data interface set the
>>> +V4L2_CAP_META_CAPTURE flag in the
>>> +capabilities field of &v4l2-capability;
>>> +returned by the &VIDIOC-QUERYCAP; ioctl. That flag means the device can
>>> capture +meta-data to memory.
>>> +
>>> +
>>> +At least one of the read/write, streaming or asynchronous I/O methods
>>> must
>>
>> I think we can drop 'asynchronous I/O' since that's never been used. I
>> assume this is copy-and-pasted and we should probably just remove any
>> reference to async IO.
> 
> Agreed. I'll fix it.
> 
>>> +be supported.
>>> +
>>> +  
>>> +
>>> +  
>>> +Data Format Negotiation
>>> +
>>> +
>>> +The meta-data device uses the format ioctls
>>> to +select the capture format. The meta-data buffer content format is
>>> bound to that +selectable format. In addition to the basic
>>> +format ioctls, the &VIDIOC-ENUM-FMT; ioctl
>>> +must be supported as well.
>>> +
>>> +
>>> +
>>> +To use the format ioctls applications set
>>> the +type field of a &v4l2-format; to
>>> +V4L2_BUF_TYPE_META_CAPTURE and use the
>>> &v4l2-meta-format; +meta member of the
>>> fmt +union as needed per the desired
>>> operation.
>>> +Currently there are two fields, pixelformat
>>> and
>>
>> Shouldn't that be metaformat? Since there are no pixels here? It was a bit
>> dubious to call it pixelformat for SDR as well, but at least there you
>> still have discrete samples which might be called pixels with some
>> imagination. But certainly doesn't apply to meta data.
> 
> How about dataformat ? Or just format ?

Since the fourcc defines are called V4L2_META_FMT_ I think metaformat is a
good name. It's consistent with the other meta-related namings.

> 
>>> +buffersize, of struct &v4l2-meta-format; that
>>> are +used. Content of the pixelformat is the
>>> V4L2 FourCC +code of the data format. The
>>> buffersize field is the +maximum buffer size
>>> in bytes required for data transfer, set by the driver in +order to
>>> inform applications.
>>> +
>>> +
>>> +
>>> +  struct v4l2_meta_format
>>> +  
>>> +&cs-str;
>>> +
>>> +  
>>> +__u32
>>> +pixelformat
>>> +
>>> +The data format or type of compression, set by the application. This is a
>>> +little endian four character code.
>>> +V4L2 defines meta-data formats in .
>>> +   
>>> +  
>>> +  
>>> +__u32
>>> +buffersize
>>> +
>>> +Maximum size in bytes required for data. Value is set by the driver.
>>> +   
>>> +  
>>> +  
>>> +__u8

Re: [PATCH v7 5/8] [media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver

2016-04-22 Thread kbuild test robot
Hi,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.6-rc4 next-20160421]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Tiffany-Lin/Add-MT8173-Video-Encoder-Driver-and-VPU-Driver/20160422-123111
base:   git://linuxtv.org/media_tree.git master
config: i386-allyesconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c: In function 
'mtk_venc_encode_header':
>> drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c:896:43: warning: format 
>> '%lx' expects argument of type 'long unsigned int', but argument 9 has type 
>> 'size_t {aka unsigned int}' [-Wformat=]
   drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c: In function 
'mtk_venc_worker':
   drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c:1046:43: warning: format 
'%lx' expects argument of type 'long unsigned int', but argument 7 has type 
'size_t {aka unsigned int}' [-Wformat=]
   drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c:1046:43: warning: format 
'%lx' expects argument of type 'long unsigned int', but argument 10 has type 
'size_t {aka unsigned int}' [-Wformat=]
   drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c:1046:43: warning: format 
'%lx' expects argument of type 'long unsigned int', but argument 13 has type 
'size_t {aka unsigned int}' [-Wformat=]

vim +896 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c

   880  struct mtk_vcodec_ctx *ctx = priv;
   881  int ret;
   882  struct vb2_buffer *dst_buf;
   883  struct mtk_vcodec_mem bs_buf;
   884  struct venc_done_result enc_result;
   885  
   886  dst_buf = v4l2_m2m_dst_buf_remove(ctx->m2m_ctx);
   887  if (!dst_buf) {
   888  mtk_v4l2_debug(1, "No dst buffer");
   889  return -EINVAL;
   890  }
   891  
   892  bs_buf.va = vb2_plane_vaddr(dst_buf, 0);
   893  bs_buf.dma_addr = vb2_dma_contig_plane_dma_addr(dst_buf, 0);
   894  bs_buf.size = (size_t)dst_buf->planes[0].length;
   895  
 > 896  mtk_v4l2_debug(1,
   897  "[%d] buf idx=%d va=0x%p dma_addr=0x%llx 
size=0x%lx",
   898  ctx->idx,
   899  dst_buf->index, bs_buf.va,
   900  (u64)bs_buf.dma_addr,
   901  bs_buf.size);
   902  
   903  ret = venc_if_encode(ctx,
   904  VENC_START_OPT_ENCODE_SEQUENCE_HEADER,

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


[PATCH for v4.6] v4l2-dv-timings.h: fix polarity for 4k formats

2016-04-22 Thread Hans Verkuil
The VSync polarity was negative instead of positive for the 4k CEA formats.
I probably copy-and-pasted these from the DMT 4k format, which does have a
negative VSync polarity.

Signed-off-by: Hans Verkuil 
Reported-by: Martin Bugge 
---
diff --git a/include/uapi/linux/v4l2-dv-timings.h 
b/include/uapi/linux/v4l2-dv-timings.h
index c039f1d..086168e 100644
--- a/include/uapi/linux/v4l2-dv-timings.h
+++ b/include/uapi/linux/v4l2-dv-timings.h
@@ -183,7 +183,8 @@

 #define V4L2_DV_BT_CEA_3840X2160P24 { \
.type = V4L2_DV_BT_656_1120, \
-   V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+   V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
+   V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 1276, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
@@ -191,14 +192,16 @@

 #define V4L2_DV_BT_CEA_3840X2160P25 { \
.type = V4L2_DV_BT_656_1120, \
-   V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+   V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
+   V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 1056, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_IS_CE_VIDEO) \
 }

 #define V4L2_DV_BT_CEA_3840X2160P30 { \
.type = V4L2_DV_BT_656_1120, \
-   V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+   V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
+   V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 176, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
@@ -206,14 +209,16 @@

 #define V4L2_DV_BT_CEA_3840X2160P50 { \
.type = V4L2_DV_BT_656_1120, \
-   V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+   V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
+   V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
59400, 1056, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_IS_CE_VIDEO) \
 }

 #define V4L2_DV_BT_CEA_3840X2160P60 { \
.type = V4L2_DV_BT_656_1120, \
-   V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+   V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
+   V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
59400, 176, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
@@ -221,7 +226,8 @@

 #define V4L2_DV_BT_CEA_4096X2160P24 { \
.type = V4L2_DV_BT_656_1120, \
-   V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+   V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
+   V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 1020, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
@@ -229,14 +235,16 @@

 #define V4L2_DV_BT_CEA_4096X2160P25 { \
.type = V4L2_DV_BT_656_1120, \
-   V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+   V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
+   V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 968, 88, 128, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_IS_CE_VIDEO) \
 }

 #define V4L2_DV_BT_CEA_4096X2160P30 { \
.type = V4L2_DV_BT_656_1120, \
-   V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+   V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
+   V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 88, 88, 128, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
@@ -244,14 +252,16 @@

 #define V4L2_DV_BT_CEA_4096X2160P50 { \
.type = V4L2_DV_BT_656_1120, \
-   V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+   V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
+   V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
59400, 968, 88, 128, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_IS_CE_VIDEO) \
 }

 #define V4L2_DV_BT_CEA_4096X2160P60 { \
.type = V4L2_DV_BT_656_1120, \
-   V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+   V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
+   V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
59400, 88, 88, 128, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
--
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