cron job: media_tree daily build: ERRORS

[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 Aug 19 05:00:16 CEST 2017
media-tree git hash:ec0c3ec497cabbf3bfa03a9eb5edcc252190a4e0
media_build git hash:   e0d45ffd87934f5d53f6977c009f07d5aed6
v4l-utils git hash: 5a67da05fded64b5f678033c16196799e134c62c
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.11.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-blackfin-bf561: OK
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: WARNINGS
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.12.67-i686: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: WARNINGS
linux-4.9.26-i686: WARNINGS
linux-4.10.14-i686: WARNINGS
linux-4.11-i686: WARNINGS
linux-4.12.1-i686: WARNINGS
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK

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/index.html

[PATCH 1/2] v4l: Add support for V4L2_BUF_TYPE_META_OUTPUT

[Sakari Ailus]

The V4L2_BUF_TYPE_META_OUTPUT mirrors the V4L2_BUF_TYPE_META_CAPTURE with
the exception that it is an OUTPUT type. The use case for this is to pass
buffers to the device that are not image data but metadata. The formats,
just as the metadata capture formats, are typically device specific and
highly structured.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  2 ++
 drivers/media/v4l2-core/v4l2-ioctl.c  | 25 +
 drivers/media/v4l2-core/videobuf2-v4l2.c  |  1 +
 include/media/v4l2-ioctl.h| 17 +
 include/uapi/linux/videodev2.h|  2 ++
 5 files changed, 47 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index af8b4c5..1ea99a7 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -235,6 +235,7 @@ static int __get_v4l2_format32(struct v4l2_format *kp, 
struct v4l2_format32 __us
case V4L2_BUF_TYPE_SDR_OUTPUT:
return get_v4l2_sdr_format(>fmt.sdr, >fmt.sdr);
case V4L2_BUF_TYPE_META_CAPTURE:
+   case V4L2_BUF_TYPE_META_OUTPUT:
return get_v4l2_meta_format(>fmt.meta, >fmt.meta);
default:
pr_info("compat_ioctl32: unexpected VIDIOC_FMT type %d\n",
@@ -284,6 +285,7 @@ static int __put_v4l2_format32(struct v4l2_format *kp, 
struct v4l2_format32 __us
case V4L2_BUF_TYPE_SDR_OUTPUT:
return put_v4l2_sdr_format(>fmt.sdr, >fmt.sdr);
case V4L2_BUF_TYPE_META_CAPTURE:
+   case V4L2_BUF_TYPE_META_OUTPUT:
return put_v4l2_meta_format(>fmt.meta, >fmt.meta);
default:
pr_info("compat_ioctl32: unexpected VIDIOC_FMT type %d\n",
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index cab63bb..df9f046 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -157,6 +157,7 @@ const char *v4l2_type_names[] = {
[V4L2_BUF_TYPE_SDR_CAPTURE]= "sdr-cap",
[V4L2_BUF_TYPE_SDR_OUTPUT] = "sdr-out",
[V4L2_BUF_TYPE_META_CAPTURE]   = "meta-cap",
+   [V4L2_BUF_TYPE_META_OUTPUT]= "meta-out",
 };
 EXPORT_SYMBOL(v4l2_type_names);
 
@@ -329,6 +330,7 @@ static void v4l_print_format(const void *arg, bool 
write_only)
(sdr->pixelformat >> 24) & 0xff);
break;
case V4L2_BUF_TYPE_META_CAPTURE:
+   case V4L2_BUF_TYPE_META_OUTPUT:
meta = >fmt.meta;
pr_cont(", dataformat=%c%c%c%c, buffersize=%u\n",
(meta->dataformat >>  0) & 0xff,
@@ -959,6 +961,10 @@ static int check_fmt(struct file *file, enum v4l2_buf_type 
type)
if (is_vid && is_rx && ops->vidioc_g_fmt_meta_cap)
return 0;
break;
+   case V4L2_BUF_TYPE_META_OUTPUT:
+   if (is_vid && is_tx && ops->vidioc_g_fmt_meta_out)
+   return 0;
+   break;
default:
break;
}
@@ -1353,6 +1359,11 @@ static int v4l_enum_fmt(const struct v4l2_ioctl_ops *ops,
break;
ret = ops->vidioc_enum_fmt_meta_cap(file, fh, arg);
break;
+   case V4L2_BUF_TYPE_META_OUTPUT:
+   if (unlikely(!is_tx || !is_vid || 
!ops->vidioc_enum_fmt_meta_out))
+   break;
+   ret = ops->vidioc_enum_fmt_meta_out(file, fh, arg);
+   break;
}
if (ret == 0)
v4l_fill_fmtdesc(p);
@@ -1456,6 +1467,10 @@ static int v4l_g_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!is_rx || !is_vid || !ops->vidioc_g_fmt_meta_cap))
break;
return ops->vidioc_g_fmt_meta_cap(file, fh, arg);
+   case V4L2_BUF_TYPE_META_OUTPUT:
+   if (unlikely(!is_tx || !is_vid || !ops->vidioc_g_fmt_meta_out))
+   break;
+   return ops->vidioc_g_fmt_meta_out(file, fh, arg);
}
return -EINVAL;
 }
@@ -1566,6 +1581,11 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
break;
CLEAR_AFTER_FIELD(p, fmt.meta);
return ops->vidioc_s_fmt_meta_cap(file, fh, arg);
+   case V4L2_BUF_TYPE_META_OUTPUT:
+   if (unlikely(!is_tx || !is_vid || !ops->vidioc_s_fmt_meta_out))
+   break;
+   CLEAR_AFTER_FIELD(p, fmt.meta);
+   return ops->vidioc_s_fmt_meta_out(file, fh, arg);
}
return -EINVAL;
 }
@@ -1656,6 +1676,11 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
break;
CLEAR_AFTER_FIELD(p, fmt.meta);
return 

[PATCH 2/2] docs-rst: v4l: Document V4L2_BUF_TYPE_META_OUTPUT interface

[Sakari Ailus]

Document the interface for metadata output, including
V4L2_BUF_TYPE_META_OUTPUT buffer type and V4L2_CAP_META_OUTPUT capability
bits.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/buffer.rst  |  3 +++
 Documentation/media/uapi/v4l/dev-meta.rst| 33 ++--
 Documentation/media/uapi/v4l/vidioc-querycap.rst |  3 +++
 Documentation/media/videodev2.h.rst.exceptions   |  2 ++
 4 files changed, 28 insertions(+), 13 deletions(-)

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index ae6ee73..33b932e 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -452,6 +452,9 @@ enum v4l2_buf_type
 * - ``V4L2_BUF_TYPE_META_CAPTURE``
   - 13
   - Buffer for metadata capture, see :ref:`metadata`.
+* - ``V4L2_BUF_TYPE_META_OUTPUT``
+  - 14
+  - Buffer for metadata output, see :ref:`metadata`.
 
 
 
diff --git a/Documentation/media/uapi/v4l/dev-meta.rst 
b/Documentation/media/uapi/v4l/dev-meta.rst
index 62518ad..a1e54bc 100644
--- a/Documentation/media/uapi/v4l/dev-meta.rst
+++ b/Documentation/media/uapi/v4l/dev-meta.rst
@@ -7,21 +7,27 @@ Metadata Interface
 **
 
 Metadata 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 metadata to userspace and control of that operation.
+additional information. This may include statistics computed over the image,
+frame capture parameters supplied by the image source or device specific
+parameters for specifying how the device processes images. This interface is
+intended for transfer of metadata between the userspace and the hardware and
+control of that operation.
 
-The metadata interface is implemented on video capture device nodes. The device
-can be dedicated to metadata or can implement both video and metadata capture
-as specified in its reported capabilities.
+The metadata interface is implemented on video device nodes. The device can be
+dedicated to metadata or can support both video and metadata as specified in 
its
+reported capabilities.
 
 Querying Capabilities
 =
 
-Device nodes supporting the metadata interface set the 
``V4L2_CAP_META_CAPTURE``
-flag in the ``device_caps`` field of the
+Device nodes supporting the metadata capture interface set the
+``V4L2_CAP_META_CAPTURE`` flag in the ``device_caps`` field of the
 :c:type:`v4l2_capability` structure returned by the :c:func:`VIDIOC_QUERYCAP`
-ioctl. That flag means the device can capture metadata to memory.
+ioctl. That flag means the device can capture metadata to memory. Similarly,
+device nodes supporting metadata output interface set the
+``V4L2_CAP_META_OUTPUT`` flag in the ``device_caps`` field of
+:c:type:`v4l2_capability` structure. That flag means the device can read
+metadata from memory.
 
 At least one of the read/write or streaming I/O methods must be supported.
 
@@ -35,10 +41,11 @@ to the basic :ref:`format` ioctls, the 
:c:func:`VIDIOC_ENUM_FMT` ioctl must be
 supported as well.
 
 To use the :ref:`format` ioctls applications set the ``type`` field of the
-:c:type:`v4l2_format` structure to ``V4L2_BUF_TYPE_META_CAPTURE`` and use the
-:c:type:`v4l2_meta_format` ``meta`` member of the ``fmt`` union as needed per
-the desired operation. Both drivers and applications must set the remainder of
-the :c:type:`v4l2_format` structure to 0.
+:c:type:`v4l2_format` structure to ``V4L2_BUF_TYPE_META_CAPTURE`` or to
+``V4L2_BUF_TYPE_META_OUTPUT`` and use the :c:type:`v4l2_meta_format` ``meta``
+member of the ``fmt`` union as needed per the desired operation. Both drivers
+and applications must set the remainder of the :c:type:`v4l2_format` structure
+to 0.
 
 .. _v4l2-meta-format:
 
diff --git a/Documentation/media/uapi/v4l/vidioc-querycap.rst 
b/Documentation/media/uapi/v4l/vidioc-querycap.rst
index 12e0d9a..36bf879 100644
--- a/Documentation/media/uapi/v4l/vidioc-querycap.rst
+++ b/Documentation/media/uapi/v4l/vidioc-querycap.rst
@@ -249,6 +249,9 @@ specification the ioctl returns an ``EINVAL`` error code.
 * - ``V4L2_CAP_STREAMING``
   - 0x0400
   - The device supports the :ref:`streaming ` I/O method.
+* - ``V4L2_CAP_META_OUTPUT``
+  - 0x0800
+  - The device supports the :ref:`metadata` output interface.
 * - ``V4L2_CAP_TOUCH``
   - 0x1000
   - This is a touch device.
diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index a5cb0a8..32172db 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -28,6 +28,7 @@ replace symbol V4L2_FIELD_TOP :c:type:`v4l2_field`
 
 # Documented enum 

[PATCH 0/2] Add V4L2_BUF_TYPE_META_OUTPUT buffer type

[Sakari Ailus]

Hi folks,

Here's a non-RFC version of the META_OUTPUT buffer type patches.

The V4L2_BUF_TYPE_META_OUTPUT buffer type complements the metadata buffer
types support for OUTPUT buffers, capture being already supported. This is
intended for similar cases than V4L2_BUF_TYPE_META_CAPTURE but for output
buffers, e.g. device parameters that may be complex and highly
hierarchical data structure. Statistics are a current use case for
metadata capture buffers.

Yong: could you take these to your IPU3 ImgU patchset, please? As that
would be the first user, the patches would be merged with the driver
itself.

since RFC:

- Fix make htmldocs build.

- Fix CAPTURE -> OUTPUT in buffer.rst.

- Added " for specifying how the device processes images" in the
  documentation.

Sakari Ailus (2):
  v4l: Add support for V4L2_BUF_TYPE_META_OUTPUT
  docs-rst: v4l: Document V4L2_BUF_TYPE_META_OUTPUT interface

 Documentation/media/uapi/v4l/buffer.rst  |  3 +++
 Documentation/media/uapi/v4l/dev-meta.rst| 33 ++--
 Documentation/media/uapi/v4l/vidioc-querycap.rst |  3 +++
 Documentation/media/videodev2.h.rst.exceptions   |  2 ++
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c|  2 ++
 drivers/media/v4l2-core/v4l2-ioctl.c | 25 ++
 drivers/media/v4l2-core/videobuf2-v4l2.c |  1 +
 include/media/v4l2-ioctl.h   | 17 
 include/uapi/linux/videodev2.h   |  2 ++
 9 files changed, 75 insertions(+), 13 deletions(-)

-- 
2.7.4

Re: [PATCH 1/2] doc: media/v4l-drivers/qcom_camss: Add abbreviations explanation

[Sakari Ailus]

On Fri, Aug 18, 2017 at 11:16:33AM +0300, Todor Tomov wrote:
> Add explanations for VFE's PIX and RDI interfaces.
> 
> Signed-off-by: Todor Tomov 

For both:

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

[PATCH v2] venus: fix copy/paste error in return_buf_error

[Gustavo A. R. Silva]

Call function v4l2_m2m_dst_buf_remove_by_buf() instead of
v4l2_m2m_src_buf_remove_by_buf()

Addresses-Coverity-ID: 1415317
Cc: Stanimir Varbanov 
Cc: Hans Verkuil 
Signed-off-by: Gustavo A. R. Silva 
---
Changes in v2:
 Stanimir Varbanov confirmed this is a bug. The correct fix is to call
 function v4l2_m2m_dst_buf_remove_by_buf instead of function
 v4l2_m2m_src_buf_remove_by_buf in the _else_ branch.

 drivers/media/platform/qcom/venus/helpers.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index 5f4434c..2d61879 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -243,7 +243,7 @@ static void return_buf_error(struct venus_inst *inst,
if (vbuf->vb2_buf.type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
v4l2_m2m_src_buf_remove_by_buf(m2m_ctx, vbuf);
else
-   v4l2_m2m_src_buf_remove_by_buf(m2m_ctx, vbuf);
+   v4l2_m2m_dst_buf_remove_by_buf(m2m_ctx, vbuf);
 
v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_ERROR);
 }
-- 
2.5.0

Re: [PATCH] media: venus: fix duplicated code for different branches

[Gustavo A. R. Silva]

Hi Stanimir,

On 08/18/2017 02:52 AM, Stanimir Varbanov wrote:

Hi Gustavo,

On 08/18/2017 02:12 AM, Gustavo A. R. Silva wrote:

Refactor code in order to avoid identical code for different branches.

This issue was detected with the help of Coccinelle.

Addresses-Coverity-ID: 1415317
Signed-off-by: Gustavo A. R. Silva 
---
This code was reported by Coverity and it was tested by compilation only.
Please, verify if this is an actual bug.


Yes looks like copy/paste error, and yes it is a bug.



Thank you for reviewing it.



 drivers/media/platform/qcom/venus/helpers.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index 5f4434c..8a5c467 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -240,11 +240,7 @@ static void return_buf_error(struct venus_inst *inst,
 {
struct v4l2_m2m_ctx *m2m_ctx = inst->m2m_ctx;

-   if (vbuf->vb2_buf.type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
-   v4l2_m2m_src_buf_remove_by_buf(m2m_ctx, vbuf);
-   else
-   v4l2_m2m_src_buf_remove_by_buf(m2m_ctx, vbuf);


the correct fix must replace the second v4l2_m2m_src_* with v4l2_m2m_dst_*.



I'll send a patch to fix this bug shortly


-
+   v4l2_m2m_src_buf_remove_by_buf(m2m_ctx, vbuf);
v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_ERROR);
 }






Thanks!
--
Gustavo A. R. Silva

[PATCH 0/2] drivers: make i2c_algorithm const

[Bhumika Goyal]

Make these const.

Bhumika Goyal (2):
  i2c: busses: make i2c_algorithm const
  [media] usb: make i2c_algorithm const

 drivers/i2c/busses/i2c-pnx.c | 2 +-
 drivers/i2c/busses/i2c-puv3.c| 2 +-
 drivers/media/usb/au0828/au0828-i2c.c| 2 +-
 drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

-- 
1.9.1

[PATCH 1/2] i2c: busses: make i2c_algorithm const

[Bhumika Goyal]

Make these const as they are only stored in the algo field of
i2c_adapter structure, which is const.

Signed-off-by: Bhumika Goyal 
---
 drivers/i2c/busses/i2c-pnx.c  | 2 +-
 drivers/i2c/busses/i2c-puv3.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-pnx.c b/drivers/i2c/busses/i2c-pnx.c
index fd5f9d2..42d6b3a 100644
--- a/drivers/i2c/busses/i2c-pnx.c
+++ b/drivers/i2c/busses/i2c-pnx.c
@@ -590,7 +590,7 @@ static u32 i2c_pnx_func(struct i2c_adapter *adapter)
return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
 }
 
-static struct i2c_algorithm pnx_algorithm = {
+static const struct i2c_algorithm pnx_algorithm = {
.master_xfer = i2c_pnx_xfer,
.functionality = i2c_pnx_func,
 };
diff --git a/drivers/i2c/busses/i2c-puv3.c b/drivers/i2c/busses/i2c-puv3.c
index 0c8b157..287088b 100644
--- a/drivers/i2c/busses/i2c-puv3.c
+++ b/drivers/i2c/busses/i2c-puv3.c
@@ -175,7 +175,7 @@ static u32 puv3_i2c_func(struct i2c_adapter *adapter)
return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
 }
 
-static struct i2c_algorithm puv3_i2c_algorithm = {
+static const struct i2c_algorithm puv3_i2c_algorithm = {
.master_xfer= puv3_i2c_xfer,
.functionality  = puv3_i2c_func,
 };
-- 
1.9.1

[PATCH 2/2] [media] usb: make i2c_algorithm const

[Bhumika Goyal]

Make these const as they are only used in a copy operation or
are stored in the algo field of i2c_adapter structure, which is const.

Signed-off-by: Bhumika Goyal 
---
 drivers/media/usb/au0828/au0828-i2c.c| 2 +-
 drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-i2c.c 
b/drivers/media/usb/au0828/au0828-i2c.c
index 42b352b..a028e36 100644
--- a/drivers/media/usb/au0828/au0828-i2c.c
+++ b/drivers/media/usb/au0828/au0828-i2c.c
@@ -329,7 +329,7 @@ static u32 au0828_functionality(struct i2c_adapter *adap)
return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C;
 }
 
-static struct i2c_algorithm au0828_i2c_algo_template = {
+static const struct i2c_algorithm au0828_i2c_algo_template = {
.master_xfer= i2c_xfer,
.functionality  = au0828_functionality,
 };
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c 
b/drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c
index 20a52b7..cfa8fbe 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c
@@ -514,7 +514,7 @@ static u32 pvr2_i2c_functionality(struct i2c_adapter *adap)
return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C;
 }
 
-static struct i2c_algorithm pvr2_i2c_algo_template = {
+static const struct i2c_algorithm pvr2_i2c_algo_template = {
.master_xfer   = pvr2_i2c_xfer,
.functionality = pvr2_i2c_functionality,
 };
-- 
1.9.1

Re: [PATCH 1/7] media: vb2: add bidirectional flag in vb2_queue

[Stanimir Varbanov]

Hi Hans,

On 08/18/2017 05:30 PM, Hans Verkuil wrote:
> On 08/18/17 16:16, Stanimir Varbanov wrote:
>> This change is intended to give to the v4l2 drivers a choice to
>> change the default behavior of the v4l2-core DMA mapping direction
>> from DMA_TO/FROM_DEVICE (depending on the buffer type CAPTURE or
>> OUTPUT) to DMA_BIDIRECTIONAL during queue_init time.
>>
>> Initially the issue with DMA mapping direction has been found in
>> Venus encoder driver where the hardware (firmware side) adds few
>> lines padding on bottom of the image buffer, and the consequence
>> is triggering of IOMMU protection faults.
>>
>> This will help supporting venus encoder (and probably other drivers
>> in the future) which wants to map output type of buffers as
>> read/write.
>>
>> Signed-off-by: Stanimir Varbanov 
>> ---
>>  drivers/media/v4l2-core/videobuf2-core.c | 17 -
>>  include/media/videobuf2-core.h   | 13 +
>>  2 files changed, 21 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
>> b/drivers/media/v4l2-core/videobuf2-core.c
>> index 0924594989b4..cb115ba6a1d2 100644
>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>> @@ -194,8 +194,6 @@ static void __enqueue_in_driver(struct vb2_buffer *vb);
>>  static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
>>  {
>>  struct vb2_queue *q = vb->vb2_queue;
>> -enum dma_data_direction dma_dir =
>> -q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
>>  void *mem_priv;
>>  int plane;
>>  int ret = -ENOMEM;
>> @@ -209,7 +207,7 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
>>  
>>  mem_priv = call_ptr_memop(vb, alloc,
>>  q->alloc_devs[plane] ? : q->dev,
>> -q->dma_attrs, size, dma_dir, q->gfp_flags);
>> +q->dma_attrs, size, q->dma_dir, q->gfp_flags);
>>  if (IS_ERR_OR_NULL(mem_priv)) {
>>  if (mem_priv)
>>  ret = PTR_ERR(mem_priv);
>> @@ -978,8 +976,6 @@ static int __prepare_userptr(struct vb2_buffer *vb, 
>> const void *pb)
>>  void *mem_priv;
>>  unsigned int plane;
>>  int ret = 0;
>> -enum dma_data_direction dma_dir =
>> -q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
>>  bool reacquired = vb->planes[0].mem_priv == NULL;
>>  
>>  memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
>> @@ -1030,7 +1026,7 @@ static int __prepare_userptr(struct vb2_buffer *vb, 
>> const void *pb)
>>  mem_priv = call_ptr_memop(vb, get_userptr,
>>  q->alloc_devs[plane] ? : q->dev,
>>  planes[plane].m.userptr,
>> -planes[plane].length, dma_dir);
>> +planes[plane].length, q->dma_dir);
>>  if (IS_ERR(mem_priv)) {
>>  dprintk(1, "failed acquiring userspace memory for plane 
>> %d\n",
>>  plane);
>> @@ -1096,8 +1092,6 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, 
>> const void *pb)
>>  void *mem_priv;
>>  unsigned int plane;
>>  int ret = 0;
>> -enum dma_data_direction dma_dir =
>> -q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
>>  bool reacquired = vb->planes[0].mem_priv == NULL;
>>  
>>  memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
>> @@ -1156,7 +1150,7 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, 
>> const void *pb)
>>  /* Acquire each plane's memory */
>>  mem_priv = call_ptr_memop(vb, attach_dmabuf,
>>  q->alloc_devs[plane] ? : q->dev,
>> -dbuf, planes[plane].length, dma_dir);
>> +dbuf, planes[plane].length, q->dma_dir);
>>  if (IS_ERR(mem_priv)) {
>>  dprintk(1, "failed to attach dmabuf\n");
>>  ret = PTR_ERR(mem_priv);
>> @@ -2003,6 +1997,11 @@ int vb2_core_queue_init(struct vb2_queue *q)
>>  if (q->buf_struct_size == 0)
>>  q->buf_struct_size = sizeof(struct vb2_buffer);
>>  
>> +if (q->bidirectional)
>> +q->dma_dir = DMA_BIDIRECTIONAL;
>> +else
>> +q->dma_dir = q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
>> +
>>  return 0;
>>  }
>>  EXPORT_SYMBOL_GPL(vb2_core_queue_init);
>> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
>> index cb97c224be73..ede09fff1de8 100644
>> --- a/include/media/videobuf2-core.h
>> +++ b/include/media/videobuf2-core.h
>> @@ -427,6 +427,17 @@ struct vb2_buf_ops {
>>   * @dev:device to use for the default allocation context if the driver
>>   *  doesn't fill in the @alloc_devs array.
>>   * @dma_attrs:  DMA attributes to use for the DMA.
>> + * @dma_dir:DMA mapping direction.
> 

Re: [PATCH 1/7] media: vb2: add bidirectional flag in vb2_queue

[Hans Verkuil]

On 08/18/17 16:16, Stanimir Varbanov wrote:
> This change is intended to give to the v4l2 drivers a choice to
> change the default behavior of the v4l2-core DMA mapping direction
> from DMA_TO/FROM_DEVICE (depending on the buffer type CAPTURE or
> OUTPUT) to DMA_BIDIRECTIONAL during queue_init time.
> 
> Initially the issue with DMA mapping direction has been found in
> Venus encoder driver where the hardware (firmware side) adds few
> lines padding on bottom of the image buffer, and the consequence
> is triggering of IOMMU protection faults.
> 
> This will help supporting venus encoder (and probably other drivers
> in the future) which wants to map output type of buffers as
> read/write.
> 
> Signed-off-by: Stanimir Varbanov 
> ---
>  drivers/media/v4l2-core/videobuf2-core.c | 17 -
>  include/media/videobuf2-core.h   | 13 +
>  2 files changed, 21 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 0924594989b4..cb115ba6a1d2 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -194,8 +194,6 @@ static void __enqueue_in_driver(struct vb2_buffer *vb);
>  static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
>  {
>   struct vb2_queue *q = vb->vb2_queue;
> - enum dma_data_direction dma_dir =
> - q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
>   void *mem_priv;
>   int plane;
>   int ret = -ENOMEM;
> @@ -209,7 +207,7 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
>  
>   mem_priv = call_ptr_memop(vb, alloc,
>   q->alloc_devs[plane] ? : q->dev,
> - q->dma_attrs, size, dma_dir, q->gfp_flags);
> + q->dma_attrs, size, q->dma_dir, q->gfp_flags);
>   if (IS_ERR_OR_NULL(mem_priv)) {
>   if (mem_priv)
>   ret = PTR_ERR(mem_priv);
> @@ -978,8 +976,6 @@ static int __prepare_userptr(struct vb2_buffer *vb, const 
> void *pb)
>   void *mem_priv;
>   unsigned int plane;
>   int ret = 0;
> - enum dma_data_direction dma_dir =
> - q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
>   bool reacquired = vb->planes[0].mem_priv == NULL;
>  
>   memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
> @@ -1030,7 +1026,7 @@ static int __prepare_userptr(struct vb2_buffer *vb, 
> const void *pb)
>   mem_priv = call_ptr_memop(vb, get_userptr,
>   q->alloc_devs[plane] ? : q->dev,
>   planes[plane].m.userptr,
> - planes[plane].length, dma_dir);
> + planes[plane].length, q->dma_dir);
>   if (IS_ERR(mem_priv)) {
>   dprintk(1, "failed acquiring userspace memory for plane 
> %d\n",
>   plane);
> @@ -1096,8 +1092,6 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, 
> const void *pb)
>   void *mem_priv;
>   unsigned int plane;
>   int ret = 0;
> - enum dma_data_direction dma_dir =
> - q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
>   bool reacquired = vb->planes[0].mem_priv == NULL;
>  
>   memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
> @@ -1156,7 +1150,7 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, 
> const void *pb)
>   /* Acquire each plane's memory */
>   mem_priv = call_ptr_memop(vb, attach_dmabuf,
>   q->alloc_devs[plane] ? : q->dev,
> - dbuf, planes[plane].length, dma_dir);
> + dbuf, planes[plane].length, q->dma_dir);
>   if (IS_ERR(mem_priv)) {
>   dprintk(1, "failed to attach dmabuf\n");
>   ret = PTR_ERR(mem_priv);
> @@ -2003,6 +1997,11 @@ int vb2_core_queue_init(struct vb2_queue *q)
>   if (q->buf_struct_size == 0)
>   q->buf_struct_size = sizeof(struct vb2_buffer);
>  
> + if (q->bidirectional)
> + q->dma_dir = DMA_BIDIRECTIONAL;
> + else
> + q->dma_dir = q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
> +
>   return 0;
>  }
>  EXPORT_SYMBOL_GPL(vb2_core_queue_init);
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index cb97c224be73..ede09fff1de8 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -427,6 +427,17 @@ struct vb2_buf_ops {
>   * @dev: device to use for the default allocation context if the driver
>   *   doesn't fill in the @alloc_devs array.
>   * @dma_attrs:   DMA attributes to use for the DMA.
> + * @dma_dir: DMA mapping direction.

This one should be moved to the 'Private elements' section. This is set and used
by the vb2 core, drivers won't 

[PATCH 0/7] Venus updates

[Stanimir Varbanov]

Hello,

Patch 1/7 has been sent already as an RFC but in this patchset
it can be found as a regular patch. The RFC version can be found
at [1] and also to prove its need look at [2]. Patch 2/7 fixes
Venus encoder issue with help of 1/7.

The other patches 3/7 to 7/7 can be treated as updates for
v4.14. For more info look in the patch descriptions.

Comments are welcome!

regards,
Stan

[1] https://lkml.org/lkml/2017/8/14/104
[2] https://patchwork.kernel.org/patch/9394145/

Stanimir Varbanov (7):
  media: vb2: add bidirectional flag in vb2_queue
  media: venus: venc: set correct resolution on compressed stream
  media: venus: mark venc and vdec PM functions as __maybe_unused
  media: venus: fill missing video_device name
  media: venus: add helper to check supported codecs
  media: venus: use helper function to check supported codecs
  media: venus: venc: drop VP9 codec support

 drivers/media/platform/qcom/venus/helpers.c | 49 +
 drivers/media/platform/qcom/venus/helpers.h |  1 +
 drivers/media/platform/qcom/venus/vdec.c| 31 +++---
 drivers/media/platform/qcom/venus/venc.c| 47 +++
 drivers/media/v4l2-core/videobuf2-core.c| 17 +-
 include/media/videobuf2-core.h  | 13 
 6 files changed, 118 insertions(+), 40 deletions(-)

-- 
2.11.0

[PATCH 1/7] media: vb2: add bidirectional flag in vb2_queue

[Stanimir Varbanov]

This change is intended to give to the v4l2 drivers a choice to
change the default behavior of the v4l2-core DMA mapping direction
from DMA_TO/FROM_DEVICE (depending on the buffer type CAPTURE or
OUTPUT) to DMA_BIDIRECTIONAL during queue_init time.

Initially the issue with DMA mapping direction has been found in
Venus encoder driver where the hardware (firmware side) adds few
lines padding on bottom of the image buffer, and the consequence
is triggering of IOMMU protection faults.

This will help supporting venus encoder (and probably other drivers
in the future) which wants to map output type of buffers as
read/write.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/v4l2-core/videobuf2-core.c | 17 -
 include/media/videobuf2-core.h   | 13 +
 2 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 0924594989b4..cb115ba6a1d2 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -194,8 +194,6 @@ static void __enqueue_in_driver(struct vb2_buffer *vb);
 static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
 {
struct vb2_queue *q = vb->vb2_queue;
-   enum dma_data_direction dma_dir =
-   q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
void *mem_priv;
int plane;
int ret = -ENOMEM;
@@ -209,7 +207,7 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
 
mem_priv = call_ptr_memop(vb, alloc,
q->alloc_devs[plane] ? : q->dev,
-   q->dma_attrs, size, dma_dir, q->gfp_flags);
+   q->dma_attrs, size, q->dma_dir, q->gfp_flags);
if (IS_ERR_OR_NULL(mem_priv)) {
if (mem_priv)
ret = PTR_ERR(mem_priv);
@@ -978,8 +976,6 @@ static int __prepare_userptr(struct vb2_buffer *vb, const 
void *pb)
void *mem_priv;
unsigned int plane;
int ret = 0;
-   enum dma_data_direction dma_dir =
-   q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
bool reacquired = vb->planes[0].mem_priv == NULL;
 
memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
@@ -1030,7 +1026,7 @@ static int __prepare_userptr(struct vb2_buffer *vb, const 
void *pb)
mem_priv = call_ptr_memop(vb, get_userptr,
q->alloc_devs[plane] ? : q->dev,
planes[plane].m.userptr,
-   planes[plane].length, dma_dir);
+   planes[plane].length, q->dma_dir);
if (IS_ERR(mem_priv)) {
dprintk(1, "failed acquiring userspace memory for plane 
%d\n",
plane);
@@ -1096,8 +1092,6 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, const 
void *pb)
void *mem_priv;
unsigned int plane;
int ret = 0;
-   enum dma_data_direction dma_dir =
-   q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
bool reacquired = vb->planes[0].mem_priv == NULL;
 
memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
@@ -1156,7 +1150,7 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, const 
void *pb)
/* Acquire each plane's memory */
mem_priv = call_ptr_memop(vb, attach_dmabuf,
q->alloc_devs[plane] ? : q->dev,
-   dbuf, planes[plane].length, dma_dir);
+   dbuf, planes[plane].length, q->dma_dir);
if (IS_ERR(mem_priv)) {
dprintk(1, "failed to attach dmabuf\n");
ret = PTR_ERR(mem_priv);
@@ -2003,6 +1997,11 @@ int vb2_core_queue_init(struct vb2_queue *q)
if (q->buf_struct_size == 0)
q->buf_struct_size = sizeof(struct vb2_buffer);
 
+   if (q->bidirectional)
+   q->dma_dir = DMA_BIDIRECTIONAL;
+   else
+   q->dma_dir = q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
+
return 0;
 }
 EXPORT_SYMBOL_GPL(vb2_core_queue_init);
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index cb97c224be73..ede09fff1de8 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -427,6 +427,17 @@ struct vb2_buf_ops {
  * @dev:   device to use for the default allocation context if the driver
  * doesn't fill in the @alloc_devs array.
  * @dma_attrs: DMA attributes to use for the DMA.
+ * @dma_dir:   DMA mapping direction.
+ * @bidirectional: when this flag is set the DMA direction for the buffers of
+ * this queue will be overridden with DMA_BIDIRECTIONAL direction.
+ * This is useful in cases where the hardware (firmware) writes to
+ * a buffer 

[PATCH 4/7] media: venus: fill missing video_device name

[Stanimir Varbanov]

This fills missing (forgotten) video device name with
appropriate string so that udev can distinguishes between
decoder and encoder devices.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/vdec.c | 1 +
 drivers/media/platform/qcom/venus/venc.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index 44d4848e878a..32a1feb2fe6a 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -1069,6 +1069,7 @@ static int vdec_probe(struct platform_device *pdev)
if (!vdev)
return -ENOMEM;
 
+   strlcpy(vdev->name, "qcom-venus-decoder", sizeof(vdev->name));
vdev->release = video_device_release;
vdev->fops = _fops;
vdev->ioctl_ops = _ioctl_ops;
diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index 4bffadd67238..bcb50d39f88a 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -1192,6 +1192,7 @@ static int venc_probe(struct platform_device *pdev)
if (!vdev)
return -ENOMEM;
 
+   strlcpy(vdev->name, "qcom-venus-encoder", sizeof(vdev->name));
vdev->release = video_device_release;
vdev->fops = _fops;
vdev->ioctl_ops = _ioctl_ops;
-- 
2.11.0

[PATCH 2/7] media: venus: venc: set correct resolution on compressed stream

[Stanimir Varbanov]

This change the alignment restriction for output type of buffers
only, also set corect input resolution and fill bidirectional
vb2 queue flag in order to map output type buffers read/write.
The last is needed by encoder firmware to add padding at the
bottom of output (input buffers).

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/venc.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index 39748e7a08e4..01af1ac89edf 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -289,7 +289,7 @@ venc_try_fmt_common(struct venus_inst *inst, struct 
v4l2_format *f)
pixmp->height = clamp(pixmp->height, inst->cap_height.min,
  inst->cap_height.max);
 
-   if (inst->core->res->hfi_version == HFI_VERSION_1XX)
+   if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
pixmp->height = ALIGN(pixmp->height, 32);
 
pixmp->width = ALIGN(pixmp->width, 2);
@@ -747,8 +747,8 @@ static int venc_init_session(struct venus_inst *inst)
if (ret)
return ret;
 
-   ret = venus_helper_set_input_resolution(inst, inst->out_width,
-   inst->out_height);
+   ret = venus_helper_set_input_resolution(inst, inst->width,
+   inst->height);
if (ret)
goto deinit;
 
@@ -1010,6 +1010,8 @@ static int m2m_queue_init(void *priv, struct vb2_queue 
*src_vq,
src_vq->allow_zero_bytesused = 1;
src_vq->min_buffers_needed = 1;
src_vq->dev = inst->core->dev;
+   if (inst->core->res->hfi_version == HFI_VERSION_1XX)
+   src_vq->bidirectional = 1;
ret = vb2_queue_init(src_vq);
if (ret)
return ret;
-- 
2.11.0

[PATCH 3/7] media: venus: mark venc and vdec PM functions as __maybe_unused

[Stanimir Varbanov]

Without PM support gcc could warns about unused functions, thus
mark runtime_suspend/resume as __maybe_unused.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/vdec.c | 6 ++
 drivers/media/platform/qcom/venus/venc.c | 6 ++
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index eb0c1c51cfef..44d4848e878a 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -1103,8 +1103,7 @@ static int vdec_remove(struct platform_device *pdev)
return 0;
 }
 
-#ifdef CONFIG_PM
-static int vdec_runtime_suspend(struct device *dev)
+static __maybe_unused int vdec_runtime_suspend(struct device *dev)
 {
struct venus_core *core = dev_get_drvdata(dev);
 
@@ -1118,7 +1117,7 @@ static int vdec_runtime_suspend(struct device *dev)
return 0;
 }
 
-static int vdec_runtime_resume(struct device *dev)
+static __maybe_unused int vdec_runtime_resume(struct device *dev)
 {
struct venus_core *core = dev_get_drvdata(dev);
int ret;
@@ -1132,7 +1131,6 @@ static int vdec_runtime_resume(struct device *dev)
 
return ret;
 }
-#endif
 
 static const struct dev_pm_ops vdec_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index 01af1ac89edf..4bffadd67238 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -1226,8 +1226,7 @@ static int venc_remove(struct platform_device *pdev)
return 0;
 }
 
-#ifdef CONFIG_PM
-static int venc_runtime_suspend(struct device *dev)
+static __maybe_unused int venc_runtime_suspend(struct device *dev)
 {
struct venus_core *core = dev_get_drvdata(dev);
 
@@ -1241,7 +1240,7 @@ static int venc_runtime_suspend(struct device *dev)
return 0;
 }
 
-static int venc_runtime_resume(struct device *dev)
+static __maybe_unused int venc_runtime_resume(struct device *dev)
 {
struct venus_core *core = dev_get_drvdata(dev);
int ret;
@@ -1255,7 +1254,6 @@ static int venc_runtime_resume(struct device *dev)
 
return ret;
 }
-#endif
 
 static const struct dev_pm_ops venc_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
-- 
2.11.0

[PATCH 5/7] media: venus: add helper to check supported codecs

[Stanimir Varbanov]

Adds a helper function to runtime check supported encoder and
decoder codecs depending on venus version and platform.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/helpers.c | 49 +
 drivers/media/platform/qcom/venus/helpers.h |  1 +
 2 files changed, 50 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index 5f4434c0a8f1..b52410deeb4c 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -34,6 +34,55 @@ struct intbuf {
unsigned long attrs;
 };
 
+bool venus_helper_check_codec(struct venus_inst *inst, u32 v4l2_pixfmt)
+{
+   struct venus_core *core = inst->core;
+   u32 session_type = inst->session_type;
+   u32 codec;
+
+   switch (v4l2_pixfmt) {
+   case V4L2_PIX_FMT_H264:
+   codec = HFI_VIDEO_CODEC_H264;
+   break;
+   case V4L2_PIX_FMT_H263:
+   codec = HFI_VIDEO_CODEC_H263;
+   break;
+   case V4L2_PIX_FMT_MPEG1:
+   codec = HFI_VIDEO_CODEC_MPEG1;
+   break;
+   case V4L2_PIX_FMT_MPEG2:
+   codec = HFI_VIDEO_CODEC_MPEG2;
+   break;
+   case V4L2_PIX_FMT_MPEG4:
+   codec = HFI_VIDEO_CODEC_MPEG4;
+   break;
+   case V4L2_PIX_FMT_VC1_ANNEX_G:
+   case V4L2_PIX_FMT_VC1_ANNEX_L:
+   codec = HFI_VIDEO_CODEC_VC1;
+   break;
+   case V4L2_PIX_FMT_VP8:
+   codec = HFI_VIDEO_CODEC_VP8;
+   break;
+   case V4L2_PIX_FMT_VP9:
+   codec = HFI_VIDEO_CODEC_VP9;
+   break;
+   case V4L2_PIX_FMT_XVID:
+   codec = HFI_VIDEO_CODEC_DIVX;
+   break;
+   default:
+   return false;
+   }
+
+   if (session_type == VIDC_SESSION_TYPE_ENC && core->enc_codecs & codec)
+   return true;
+
+   if (session_type == VIDC_SESSION_TYPE_DEC && core->dec_codecs & codec)
+   return true;
+
+   return false;
+}
+EXPORT_SYMBOL_GPL(venus_helper_check_codec);
+
 static int intbufs_set_buffer(struct venus_inst *inst, u32 type)
 {
struct venus_core *core = inst->core;
diff --git a/drivers/media/platform/qcom/venus/helpers.h 
b/drivers/media/platform/qcom/venus/helpers.h
index 6a061b417a93..971392be5df5 100644
--- a/drivers/media/platform/qcom/venus/helpers.h
+++ b/drivers/media/platform/qcom/venus/helpers.h
@@ -19,6 +19,7 @@
 
 struct venus_inst;
 
+bool venus_helper_check_codec(struct venus_inst *inst, u32 v4l2_pixfmt);
 struct vb2_v4l2_buffer *venus_helper_find_buf(struct venus_inst *inst,
  unsigned int type, u32 idx);
 void venus_helper_buffers_done(struct venus_inst *inst,
-- 
2.11.0

[PATCH 6/7] media: venus: use helper function to check supported codecs

[Stanimir Varbanov]

Use the helper function in decoder and encoder find_format
to runtime check supported codecs.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/vdec.c | 24 +---
 drivers/media/platform/qcom/venus/venc.c | 28 +++-
 2 files changed, 36 insertions(+), 16 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index 32a1feb2fe6a..da611a5eb670 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -102,7 +102,8 @@ static const struct venus_format vdec_formats[] = {
},
 };
 
-static const struct venus_format *find_format(u32 pixfmt, u32 type)
+static const struct venus_format *
+find_format(struct venus_inst *inst, u32 pixfmt, u32 type)
 {
const struct venus_format *fmt = vdec_formats;
unsigned int size = ARRAY_SIZE(vdec_formats);
@@ -116,11 +117,15 @@ static const struct venus_format *find_format(u32 pixfmt, 
u32 type)
if (i == size || fmt[i].type != type)
return NULL;
 
+   if (type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE &&
+   !venus_helper_check_codec(inst, fmt[i].pixfmt))
+   return NULL;
+
return [i];
 }
 
 static const struct venus_format *
-find_format_by_index(unsigned int index, u32 type)
+find_format_by_index(struct venus_inst *inst, unsigned int index, u32 type)
 {
const struct venus_format *fmt = vdec_formats;
unsigned int size = ARRAY_SIZE(vdec_formats);
@@ -140,6 +145,10 @@ find_format_by_index(unsigned int index, u32 type)
if (i == size)
return NULL;
 
+   if (type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE &&
+   !venus_helper_check_codec(inst, fmt[i].pixfmt))
+   return NULL;
+
return [i];
 }
 
@@ -154,7 +163,7 @@ vdec_try_fmt_common(struct venus_inst *inst, struct 
v4l2_format *f)
memset(pfmt[0].reserved, 0, sizeof(pfmt[0].reserved));
memset(pixmp->reserved, 0, sizeof(pixmp->reserved));
 
-   fmt = find_format(pixmp->pixelformat, f->type);
+   fmt = find_format(inst, pixmp->pixelformat, f->type);
if (!fmt) {
if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
pixmp->pixelformat = V4L2_PIX_FMT_NV12;
@@ -162,7 +171,7 @@ vdec_try_fmt_common(struct venus_inst *inst, struct 
v4l2_format *f)
pixmp->pixelformat = V4L2_PIX_FMT_H264;
else
return NULL;
-   fmt = find_format(pixmp->pixelformat, f->type);
+   fmt = find_format(inst, pixmp->pixelformat, f->type);
pixmp->width = 1280;
pixmp->height = 720;
}
@@ -364,11 +373,12 @@ vdec_querycap(struct file *file, void *fh, struct 
v4l2_capability *cap)
 
 static int vdec_enum_fmt(struct file *file, void *fh, struct v4l2_fmtdesc *f)
 {
+   struct venus_inst *inst = to_inst(file);
const struct venus_format *fmt;
 
memset(f->reserved, 0, sizeof(f->reserved));
 
-   fmt = find_format_by_index(f->index, f->type);
+   fmt = find_format_by_index(inst, f->index, f->type);
if (!fmt)
return -EINVAL;
 
@@ -417,10 +427,10 @@ static int vdec_enum_framesizes(struct file *file, void 
*fh,
struct venus_inst *inst = to_inst(file);
const struct venus_format *fmt;
 
-   fmt = find_format(fsize->pixel_format,
+   fmt = find_format(inst, fsize->pixel_format,
  V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE);
if (!fmt) {
-   fmt = find_format(fsize->pixel_format,
+   fmt = find_format(inst, fsize->pixel_format,
  V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE);
if (!fmt)
return -EINVAL;
diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index bcb50d39f88a..9f459024aa07 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -91,7 +91,8 @@ static const struct venus_format venc_formats[] = {
},
 };
 
-static const struct venus_format *find_format(u32 pixfmt, u32 type)
+static const struct venus_format *
+find_format(struct venus_inst *inst, u32 pixfmt, u32 type)
 {
const struct venus_format *fmt = venc_formats;
unsigned int size = ARRAY_SIZE(venc_formats);
@@ -105,11 +106,15 @@ static const struct venus_format *find_format(u32 pixfmt, 
u32 type)
if (i == size || fmt[i].type != type)
return NULL;
 
+   if (type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE &&
+   !venus_helper_check_codec(inst, fmt[i].pixfmt))
+   return NULL;
+
return [i];
 }
 
 static const struct venus_format *
-find_format_by_index(unsigned int index, u32 type)
+find_format_by_index(struct venus_inst *inst, unsigned int index, u32 type)
 

[PATCH 7/7] media: venus: venc: drop VP9 codec support

[Stanimir Varbanov]

No one of the supported Venus version has implemented VP9 codec
for enconding, so drop it from the list of codecs.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/venc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index 9f459024aa07..6f123a387cf9 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -84,10 +84,6 @@ static const struct venus_format venc_formats[] = {
.pixfmt = V4L2_PIX_FMT_VP8,
.num_planes = 1,
.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
-   }, {
-   .pixfmt = V4L2_PIX_FMT_VP9,
-   .num_planes = 1,
-   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
},
 };
 
-- 
2.11.0

Re: [PATCH v3 0/3] Unified fwnode endpoint parser

[Sakari Ailus]

On Fri, Aug 18, 2017 at 02:23:14PM +0300, Sakari Ailus wrote:
> Hi folks,
> 
> We have a large influx of new, unmerged, drivers that are now parsing
> fwnode endpoints and each one of them is doing this a little bit
> differently. The needs are still exactly the same for the graph data
> structure is device independent. This is still a non-trivial task and the
> majority of the driver implementations are buggy, just buggy in different
> ways.
> 
> Facilitate parsing endpoints by adding a convenience function for parsing
> the endpoints, and make the omap3isp driver use it as an example.
> 
> I plan to include the first patch to a pull request soonish, the second
> could go in with the first user.

And now that a new patch has been added in front of the set, this means
that 1 and 2 could IMO go in soonish whereas the third would go in later.

> 
> since v2:
> 
> - Rebase on CCP2 support patches.
> 
> - Prepend a patch cleaning up omap3isp driver a little.
> 
> since v1:
> 
> - The first patch has been merged (it was a bugfix).
> 
> - In anticipation that the parsing can take place over several iterations,
>   take the existing number of async sub-devices into account when
>   re-allocating an array of async sub-devices.
> 
> - Rework the first patch to better anticipate parsing single endpoint at a
>   time by a driver.
> 
> - Add a second patch that adds a function for parsing endpoints one at a
>   time based on port and endpoint numbers.
> 
> Sakari Ailus (3):
>   omap3isp: Drop redundant isp->subdevs field and ISP_MAX_SUBDEVS
>   v4l: fwnode: Support generic parsing of graph endpoints in a device
>   v4l: fwnode: Support generic parsing of graph endpoints in a single
> port
> 
>  drivers/media/platform/omap3isp/isp.c | 116 +++---
>  drivers/media/platform/omap3isp/isp.h |   3 -
>  drivers/media/v4l2-core/v4l2-fwnode.c | 176 
> ++
>  include/media/v4l2-async.h|   4 +-
>  include/media/v4l2-fwnode.h   |  16 
>  5 files changed, 231 insertions(+), 84 deletions(-)
> 
> -- 
> 2.11.0
> 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH 1/4] v4l: async: fix unbind error in v4l2_async_notifier_unregister()

[Sakari Ailus]

On Fri, Aug 18, 2017 at 03:42:07PM +0200, Niklas Söderlund wrote:
> Hi,
> 
> On 2017-08-18 14:15:26 +0300, Laurent Pinchart wrote:
> > Hi Sakari,
> > 
> > On Tuesday 15 Aug 2017 19:16:14 Sakari Ailus wrote:
> > > On Mon, Jul 31, 2017 at 12:31:55AM +0200, Niklas Söderlund wrote:
> > > > The call to v4l2_async_cleanup() will set sd->asd to NULL so passing it
> > > > to notifier->unbind() have no effect and leaves the notifier confused.
> > > > Call the unbind() callback prior to cleaning up the subdevice to avoid
> > > > this.
> > > > 
> > > > Signed-off-by: Niklas Söderlund 
> > > 
> > > This is a bugfix and worthy without any other patches and so should be
> > > applied separately.
> > > 
> > > I think it'd be safer to store sd->asd locally and call the notifier 
> > > unbind
> > > with that. Now you're making changes to the order in which things work, 
> > > and
> > > that's not necessary to achieve the objective of passing the async subdev
> > > pointer to the notifier.
> > 
> > But on the other hand I think the unbind notification should be called 
> > before 
> > the subdevice gets unbound, the same way the bound notification is called 
> > after it gets bound. One of the purposes of the unbind notification is to 
> > allow drivers to prepare for subdev about to be unbound, and they can't 
> > prepare if the unbind happened already.
> 
> I'm not opposed to move in the direction suggested by Sakari but I agree 
> with Laurent here. It makes more sens that the unbind callback is called 
> before the actual unbind happens. At the same time I agree that it dose 
> change the behavior, but I think it's for the better.

I agree with Laurent's reasoning. Feel free to add my ack.

> 
> > 
> > > With that changed,
> > > 
> > > Acked-by: Sakari Ailus 
> > > 
> > > > ---
> > > > 
> > > >  drivers/media/v4l2-core/v4l2-async.c | 6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/media/v4l2-core/v4l2-async.c
> > > > b/drivers/media/v4l2-core/v4l2-async.c index
> > > > 851f128eba2219ad..0acf288d7227ba97 100644
> > > > --- a/drivers/media/v4l2-core/v4l2-async.c
> > > > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > > > @@ -226,14 +226,14 @@ void v4l2_async_notifier_unregister(struct
> > > > v4l2_async_notifier *notifier)> 
> > > > d = get_device(sd->dev);
> > > > 
> > > > +   if (notifier->unbind)
> > > > +   notifier->unbind(notifier, sd, sd->asd);
> > > > +
> > > > 
> > > > v4l2_async_cleanup(sd);
> > > > 
> > > > /* If we handled USB devices, we'd have to lock the 
> > > > parent too 
> > */
> > > > device_release_driver(d);
> > > > 
> > > > -   if (notifier->unbind)
> > > > -   notifier->unbind(notifier, sd, sd->asd);
> > > > -
> > > > 
> > > > /*
> > > > 
> > > >  * Store device at the device cache, in order to call
> > > >  * put_device() on the final step
> > 
> > -- 
> > Regards,
> > 
> > Laurent Pinchart
> > 
> 
> -- 
> Regards,
> Niklas Söderlund

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH 4/4] v4l: async: add comment about re-probing to v4l2_async_notifier_unregister()

[Niklas Söderlund]

Hi Sakari and Laurent,

Thanks for your feedback.

On 2017-08-18 14:20:08 +0300, Laurent Pinchart wrote:
> Hello,
> 
> On Tuesday 15 Aug 2017 19:09:33 Sakari Ailus wrote:
> > On Mon, Jul 31, 2017 at 12:31:58AM +0200, Niklas Söderlund wrote:
> > > The re-probing of subdevices when unregistering a notifier is tricky to
> > > understand, and implemented somewhat as a hack. Add a comment trying to
> > > explain why the re-probing is needed in the first place and why existing
> > > helper functions can't be used in this situation.
> > > 
> > > Signed-off-by: Niklas Söderlund 
> > > ---
> > > 
> > >  drivers/media/v4l2-core/v4l2-async.c | 17 +
> > >  1 file changed, 17 insertions(+)
> > > 
> > > diff --git a/drivers/media/v4l2-core/v4l2-async.c
> > > b/drivers/media/v4l2-core/v4l2-async.c index
> > > d91ff0a33fd3eaff..a3c5a1f6d4d2ab03 100644
> > > --- a/drivers/media/v4l2-core/v4l2-async.c
> > > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > > @@ -234,6 +234,23 @@ void v4l2_async_notifier_unregister(struct
> > > v4l2_async_notifier *notifier)> 
> > >   mutex_unlock(_lock);
> > > 
> > > + /*
> > > +  * Try to re-probe the subdevices which where part of the notifier.
> > > +  * This is done so subdevices which where part of the notifier will
> > > +  * be re-probed to a pristine state and put back on the global
> > > +  * list of subdevices so they can once more be found and associated
> > > +  * with a new notifier.
> > 
> > Instead of tweaking the code trying to handle unhandleable error conditions
> > in notifier unregistration and adding lengthy stories on why this is done
> > the way it is, could we simply get rid of the driver re-probing?
> > 
> > I can't see why drivers shouldn't simply cope with the current interfaces
> > without re-probing to which I've never seen any reasoned cause. When a
> > sub-device driver is unbound, simply return the sub-device node to the list
> > of async sub-devices.
> 
> I agree, this is a hack that we should get rid of. Reprobing has been there 
> from the very beginning, it's now 4 years and a half old, let's allow it to 
> retire :-)

I would also be happy to see this code go away :-)

> 
> > Or can someone come up with a valid reason why the re-probing code should
> > stay? :-)

Hans kindly dug out the original reason talking about why this code was 
added in the first place at

http://lkml.iu.edu/hypermail/linux/kernel/1210.2/00713.html

I would also like record here what Laurent stated about this after 
reading the above on #v4l 

13:53  pinchartl : what could happen is this
13:53  pinchartl : the master could export resources used by the subdev
13:53  pinchartl : the omap3 isp driver, for instance, is a clock source
13:54  pinchartl : and the clock can be used by sensors
13:54  pinchartl : so if you remove the omap3 isp, the clock won't be 
   there anymore
13:54  pinchartl : and that's bad for the subdev


I don't claim I fully understand all the consequences of removing this 
reprobing now. But maybe it's safer to lave the current behavior in for 
now until the full problem is understood and move forward whit these 
patches since at least they document the behavior and removes another 
funky bit when trying to handle the situation where the memory 
allocation fails? What do you guys think?

> > 
> > > +  *
> > > +  * One might be tempted to use device_reprobe() to handle the re-
> > > +  * probing. Unfortunately this is not possible since some video
> > > +  * device drivers call v4l2_async_notifier_unregister() from
> > > +  * there remove function leading to a dead lock situation on
> > > +  * device_lock(dev->parent). This lock is held when video device
> > > +  * drivers remove function is called and device_reprobe() also
> > > +  * tries to take the same lock, so using it here could lead to a
> > > +  * dead lock situation.
> > > +  */
> > > +
> > >   for (i = 0; i < count; i++) {
> > >   
> > >   /* If we handled USB devices, we'd have to lock the parent too 
> */
> > >   device_release_driver(dev[i]);
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH 1/4] v4l: async: fix unbind error in v4l2_async_notifier_unregister()

[Niklas Söderlund]

Hi,

On 2017-08-18 14:15:26 +0300, Laurent Pinchart wrote:
> Hi Sakari,
> 
> On Tuesday 15 Aug 2017 19:16:14 Sakari Ailus wrote:
> > On Mon, Jul 31, 2017 at 12:31:55AM +0200, Niklas Söderlund wrote:
> > > The call to v4l2_async_cleanup() will set sd->asd to NULL so passing it
> > > to notifier->unbind() have no effect and leaves the notifier confused.
> > > Call the unbind() callback prior to cleaning up the subdevice to avoid
> > > this.
> > > 
> > > Signed-off-by: Niklas Söderlund 
> > 
> > This is a bugfix and worthy without any other patches and so should be
> > applied separately.
> > 
> > I think it'd be safer to store sd->asd locally and call the notifier unbind
> > with that. Now you're making changes to the order in which things work, and
> > that's not necessary to achieve the objective of passing the async subdev
> > pointer to the notifier.
> 
> But on the other hand I think the unbind notification should be called before 
> the subdevice gets unbound, the same way the bound notification is called 
> after it gets bound. One of the purposes of the unbind notification is to 
> allow drivers to prepare for subdev about to be unbound, and they can't 
> prepare if the unbind happened already.

I'm not opposed to move in the direction suggested by Sakari but I agree 
with Laurent here. It makes more sens that the unbind callback is called 
before the actual unbind happens. At the same time I agree that it dose 
change the behavior, but I think it's for the better.

> 
> > With that changed,
> > 
> > Acked-by: Sakari Ailus 
> > 
> > > ---
> > > 
> > >  drivers/media/v4l2-core/v4l2-async.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/media/v4l2-core/v4l2-async.c
> > > b/drivers/media/v4l2-core/v4l2-async.c index
> > > 851f128eba2219ad..0acf288d7227ba97 100644
> > > --- a/drivers/media/v4l2-core/v4l2-async.c
> > > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > > @@ -226,14 +226,14 @@ void v4l2_async_notifier_unregister(struct
> > > v4l2_async_notifier *notifier)> 
> > >   d = get_device(sd->dev);
> > > 
> > > + if (notifier->unbind)
> > > + notifier->unbind(notifier, sd, sd->asd);
> > > +
> > > 
> > >   v4l2_async_cleanup(sd);
> > >   
> > >   /* If we handled USB devices, we'd have to lock the parent too 
> */
> > >   device_release_driver(d);
> > > 
> > > - if (notifier->unbind)
> > > - notifier->unbind(notifier, sd, sd->asd);
> > > -
> > > 
> > >   /*
> > >   
> > >* Store device at the device cache, in order to call
> > >* put_device() on the final step
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Regards,
Niklas Söderlund

[GIT PULL FOR v4.14] vsp1: partition algorithm improvements

[Hans Verkuil]

Note from Laurent: the series merges cleanly with Dave's drm-next branch
(git://people.freedesktop.org/~airlied/linux) that contains a large series of
VSP patches. There should thus be no merge conflict (at least none that git
won't solve automatically) when merging upstream.

Regards,

Hans

The following changes since commit ec0c3ec497cabbf3bfa03a9eb5edcc252190a4e0:

  media: ddbridge: split code into multiple files (2017-08-09 12:17:01 -0400)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git vsp1

for you to fetch changes up to 8ced9b7523eb503a3271bbfbc41451455fea7d0c:

  v4l: vsp1: Allow entities to participate in the partition algorithm 
(2017-08-18 15:05:26 +0200)


Kieran Bingham (7):
  v4l: vsp1: Release buffers in start_streaming error path
  v4l: vsp1: Move vsp1_video_pipeline_setup_partitions() function
  v4l: vsp1: Calculate partition sizes at stream start
  v4l: vsp1: Remove redundant context variables
  v4l: vsp1: Move partition rectangles to struct and operate directly
  v4l: vsp1: Provide UDS register updates
  v4l: vsp1: Allow entities to participate in the partition algorithm

 drivers/media/platform/vsp1/vsp1_entity.h |   7 +++
 drivers/media/platform/vsp1/vsp1_pipe.c   |  22 
 drivers/media/platform/vsp1/vsp1_pipe.h   |  46 +++--
 drivers/media/platform/vsp1/vsp1_regs.h   |  14 ++
 drivers/media/platform/vsp1/vsp1_rpf.c|  27 +-
 drivers/media/platform/vsp1/vsp1_sru.c|  26 ++
 drivers/media/platform/vsp1/vsp1_uds.c|  57 ++---
 drivers/media/platform/vsp1/vsp1_video.c  | 182 
+-
 drivers/media/platform/vsp1/vsp1_wpf.c|  24 ++---
 9 files changed, 289 insertions(+), 116 deletions(-)

[PATCH 1/1] dt: bindings: Add a binding for flash devices associated to a sensor

[Sakari Ailus]

Camera flash drivers (and LEDs) are separate from the sensor devices in
DT. In order to make an association between the two, provide the
association information to the software.

Signed-off-by: Sakari Ailus 
---
Hi Rob and Jacek, others,

I know I've submitted previous versions of this patch that I have changed
since getting your acks... that's bad. I realised there will be problems
due to the vague referencing in the old version.

Instead of referring to the flash LED controller itself, the references are
now suggested to be made to the LEDs explicitly.

While most of the time all LEDs are associated to the same camera sensor,
there's nothing that suggests that this will always be the case. This will
work rather nicely with this change to the V4L2 flash class:



An alternative to this could be to refer to the LEDs using the LED
controller node and integer arguments. That would require e.g. #led-cells
property to tell how many arguments there are. The actual LEDs also have
device nodes already so I thought using them would probably be a good idea
so we continue to have a single way to refer to LEDs.

Let me know your thoughts / if you're ok with the patch.

 Documentation/devicetree/bindings/media/video-interfaces.txt | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
b/Documentation/devicetree/bindings/media/video-interfaces.txt
index 852041a7480c..fee73cf2a714 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.txt
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -67,6 +67,14 @@ are required in a relevant parent node:
identifier, should be 1.
  - #size-cells: should be zero.
 
+
+Optional properties
+---
+
+- flash: An array of phandles referring to the flash LED, a sub-node
+  of the LED driver device node.
+
+
 Optional endpoint properties
 
 
-- 
2.11.0

Re: [PATCH v2 0/3] Add ZTE zx-irdec remote control driver

[Shawn Guo]

On Sun, Jul 30, 2017 at 09:23:10PM +0800, Shawn Guo wrote:
> From: Shawn Guo 
> 
> The series adds dt-bindings and remote control driver for IRDEC block
> found on ZTE ZX family SoCs.
> 
> Changes for v2:
>  - Add one patch to move generic NEC scancode composing and protocol
>type detection code from ir_nec_decode() into an inline shared
>function, which can be reused by zx-irdec driver.
> 
> Shawn Guo (3):
>   rc: ir-nec-decoder: move scancode composing code into a shared
> function
>   dt-bindings: add bindings document for zx-irdec
>   rc: add zx-irdec remote control driver

Hi Sean,

We are getting close to 4.14 merge window.  Can we get this into -next
for a bit exposure, if you are fine with the patches?

Shawn

[PATCH] [em28xx] add config for em28xx-based board by MAGIX

[panic]

Hi,

the patch below adds the entries to the config arrays for a capture-only
board distributed by MAGIX [0]. The hardware itself (EM2860, SAA7113,
EMP202) is already supported.
This patch lacks the configuration for the GPIO pin, because I had/have
no time yet to figure out how it works. Video and audio work fine for me
in mplayer/mencoder.
The patch works against Linux 4.9.0 from Debian stretch/stable.

This is my first kernel submission, so tell me if you need more info or
if something should be changed. Thanks!

Cheers,
panic

[0] contains not much info, but for the record:
http://www.magix.com/gb/rescue-your-videotapes/
---
 drivers/media/usb/em28xx/em28xx-cards.c | 20 
 drivers/media/usb/em28xx/em28xx.h   |  1 +
 2 files changed, 21 insertions(+)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c b/drivers/media/usb/em28xx/em28xx-cards.c
index e397f54..96afb46 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -2389,6 +2389,24 @@ struct em28xx_board em28xx_boards[] = {
 		.ir_codes  = RC_MAP_HAUPPAUGE,
 		.leds  = hauppauge_dualhd_leds,
 	},
+	/*
+	 * 1b80:e349 MAGIX "Rescue your Videotapes!"
+	 * Empia EM2860, Philips SAA7113, Empia EMP202, No Tuner
+	 */
+	[EM2860_BOARD_MAGIX] = {
+		.name = "MAGIX",
+		.tuner_type   = TUNER_ABSENT,
+		.decoder  = EM28XX_SAA711X,
+		.input= { {
+			.type = EM28XX_VMUX_COMPOSITE,
+			.vmux = SAA7115_COMPOSITE0,
+			.amux = EM28XX_AMUX_AUX,
+		}, {
+			.type = EM28XX_VMUX_SVIDEO,
+			.vmux = SAA7115_SVIDEO3,
+			.amux = EM28XX_AMUX_AUX,
+		} },
+	},
 };
 EXPORT_SYMBOL_GPL(em28xx_boards);
 
@@ -2582,6 +2600,8 @@ struct usb_device_id em28xx_id_table[] = {
 			.driver_info = EM28178_BOARD_TERRATEC_T2_STICK_HD },
 	{ USB_DEVICE(0x3275, 0x0085),
 			.driver_info = EM28178_BOARD_PLEX_PX_BCUD },
+	{ USB_DEVICE(0x1b80, 0xe349),
+			.driver_info = EM2860_BOARD_MAGIX },
 	{ },
 };
 MODULE_DEVICE_TABLE(usb, em28xx_id_table);
diff --git a/drivers/media/usb/em28xx/em28xx.h b/drivers/media/usb/em28xx/em28xx.h
index d148463..0da7f6a 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -147,6 +147,7 @@
 #define EM2884_BOARD_ELGATO_EYETV_HYBRID_2008 97
 #define EM28178_BOARD_PLEX_PX_BCUD98
 #define EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB  99
+#define EM2860_BOARD_MAGIX100
 
 /* Limits minimum and default number of buffers */
 #define EM28XX_MIN_BUF 4
-- 
2.11.0

[PATCH v3 2/3] v4l: fwnode: Support generic parsing of graph endpoints in a device

[Sakari Ailus]

The current practice is that drivers iterate over their endpoints and
parse each endpoint separately. This is very similar in a number of
drivers, implement a generic function for the job. Driver specific matters
can be taken into account in the driver specific callback.

Convert the omap3isp as an example.

Signed-off-by: Sakari Ailus 
---
 drivers/media/platform/omap3isp/isp.c | 116 ++-
 drivers/media/v4l2-core/v4l2-fwnode.c | 125 ++
 include/media/v4l2-async.h|   4 +-
 include/media/v4l2-fwnode.h   |   9 +++
 4 files changed, 173 insertions(+), 81 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index c3014c82d64d..3ed213b82eaa 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2011,44 +2011,41 @@ enum isp_of_phy {
ISP_OF_PHY_CSIPHY2,
 };
 
-static int isp_fwnode_parse(struct device *dev, struct fwnode_handle *fwnode,
-   struct isp_async_subdev *isd)
+static int isp_fwnode_parse(struct device *dev,
+   struct v4l2_fwnode_endpoint *vep,
+   struct v4l2_async_subdev *asd)
 {
+   struct isp_async_subdev *isd =
+   container_of(asd, struct isp_async_subdev, asd);
struct isp_bus_cfg *buscfg = >bus;
-   struct v4l2_fwnode_endpoint vep;
-   unsigned int i;
-   int ret;
bool csi1 = false;
-
-   ret = v4l2_fwnode_endpoint_parse(fwnode, );
-   if (ret)
-   return ret;
+   unsigned int i;
 
dev_dbg(dev, "parsing endpoint %s, interface %u\n",
-   to_of_node(fwnode)->full_name, vep.base.port);
+   to_of_node(vep->base.local_fwnode)->full_name, vep->base.port);
 
-   switch (vep.base.port) {
+   switch (vep->base.port) {
case ISP_OF_PHY_PARALLEL:
buscfg->interface = ISP_INTERFACE_PARALLEL;
buscfg->bus.parallel.data_lane_shift =
-   vep.bus.parallel.data_shift;
+   vep->bus.parallel.data_shift;
buscfg->bus.parallel.clk_pol =
-   !!(vep.bus.parallel.flags
+   !!(vep->bus.parallel.flags
   & V4L2_MBUS_PCLK_SAMPLE_FALLING);
buscfg->bus.parallel.hs_pol =
-   !!(vep.bus.parallel.flags & V4L2_MBUS_VSYNC_ACTIVE_LOW);
+   !!(vep->bus.parallel.flags & 
V4L2_MBUS_VSYNC_ACTIVE_LOW);
buscfg->bus.parallel.vs_pol =
-   !!(vep.bus.parallel.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW);
+   !!(vep->bus.parallel.flags & 
V4L2_MBUS_HSYNC_ACTIVE_LOW);
buscfg->bus.parallel.fld_pol =
-   !!(vep.bus.parallel.flags & V4L2_MBUS_FIELD_EVEN_LOW);
+   !!(vep->bus.parallel.flags & V4L2_MBUS_FIELD_EVEN_LOW);
buscfg->bus.parallel.data_pol =
-   !!(vep.bus.parallel.flags & V4L2_MBUS_DATA_ACTIVE_LOW);
-   buscfg->bus.parallel.bt656 = vep.bus_type == V4L2_MBUS_BT656;
+   !!(vep->bus.parallel.flags & V4L2_MBUS_DATA_ACTIVE_LOW);
+   buscfg->bus.parallel.bt656 = vep->bus_type == V4L2_MBUS_BT656;
break;
 
case ISP_OF_PHY_CSIPHY1:
case ISP_OF_PHY_CSIPHY2:
-   switch (vep.bus_type) {
+   switch (vep->bus_type) {
case V4L2_MBUS_CCP2:
case V4L2_MBUS_CSI1:
dev_dbg(dev, "CSI-1/CCP-2 configuration\n");
@@ -2060,11 +2057,11 @@ static int isp_fwnode_parse(struct device *dev, struct 
fwnode_handle *fwnode,
break;
default:
dev_err(dev, "unsupported bus type %u\n",
-   vep.bus_type);
+   vep->bus_type);
return -EINVAL;
}
 
-   switch (vep.base.port) {
+   switch (vep->base.port) {
case ISP_OF_PHY_CSIPHY1:
if (csi1)
buscfg->interface = ISP_INTERFACE_CCP2B_PHY1;
@@ -2080,47 +2077,47 @@ static int isp_fwnode_parse(struct device *dev, struct 
fwnode_handle *fwnode,
}
if (csi1) {
buscfg->bus.ccp2.lanecfg.clk.pos =
-   vep.bus.mipi_csi1.clock_lane;
+   vep->bus.mipi_csi1.clock_lane;
buscfg->bus.ccp2.lanecfg.clk.pol =
-   vep.bus.mipi_csi1.lane_polarity[0];
+   vep->bus.mipi_csi1.lane_polarity[0];
dev_dbg(dev, "clock lane polarity %u, pos %u\n",
buscfg->bus.ccp2.lanecfg.clk.pol,
   

[PATCH v3 0/3] Unified fwnode endpoint parser

[Sakari Ailus]

Hi folks,

We have a large influx of new, unmerged, drivers that are now parsing
fwnode endpoints and each one of them is doing this a little bit
differently. The needs are still exactly the same for the graph data
structure is device independent. This is still a non-trivial task and the
majority of the driver implementations are buggy, just buggy in different
ways.

Facilitate parsing endpoints by adding a convenience function for parsing
the endpoints, and make the omap3isp driver use it as an example.

I plan to include the first patch to a pull request soonish, the second
could go in with the first user.

since v2:

- Rebase on CCP2 support patches.

- Prepend a patch cleaning up omap3isp driver a little.

since v1:

- The first patch has been merged (it was a bugfix).

- In anticipation that the parsing can take place over several iterations,
  take the existing number of async sub-devices into account when
  re-allocating an array of async sub-devices.

- Rework the first patch to better anticipate parsing single endpoint at a
  time by a driver.

- Add a second patch that adds a function for parsing endpoints one at a
  time based on port and endpoint numbers.

Sakari Ailus (3):
  omap3isp: Drop redundant isp->subdevs field and ISP_MAX_SUBDEVS
  v4l: fwnode: Support generic parsing of graph endpoints in a device
  v4l: fwnode: Support generic parsing of graph endpoints in a single
port

 drivers/media/platform/omap3isp/isp.c | 116 +++---
 drivers/media/platform/omap3isp/isp.h |   3 -
 drivers/media/v4l2-core/v4l2-fwnode.c | 176 ++
 include/media/v4l2-async.h|   4 +-
 include/media/v4l2-fwnode.h   |  16 
 5 files changed, 231 insertions(+), 84 deletions(-)

-- 
2.11.0

[PATCH v3 3/3] v4l: fwnode: Support generic parsing of graph endpoints in a single port

[Sakari Ailus]

This is the preferred way to parse the endpoints.

Signed-off-by: Sakari Ailus 
---
 drivers/media/v4l2-core/v4l2-fwnode.c | 51 +++
 include/media/v4l2-fwnode.h   |  7 +
 2 files changed, 58 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
b/drivers/media/v4l2-core/v4l2-fwnode.c
index cb0fc4b4e3bf..961bcdf22d9a 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -508,6 +508,57 @@ int v4l2_fwnode_endpoints_parse(
 }
 EXPORT_SYMBOL_GPL(v4l2_fwnode_endpoints_parse);
 
+/**
+ * v4l2_fwnode_endpoint_parse - Parse V4L2 fwnode endpoints in a port node
+ * @dev: local struct device
+ * @notifier: async notifier related to @dev
+ * @port: port number
+ * @endpoint: endpoint number
+ * @asd_struct_size: size of the driver's async sub-device struct, including
+ *  sizeof(struct v4l2_async_subdev)
+ * @parse_single: driver's callback function called on each V4L2 fwnode 
endpoint
+ *
+ * Parse all V4L2 fwnode endpoints related to a given port. This is
+ * the preferred interface over v4l2_fwnode_endpoints_parse() and
+ * should be used by new drivers.
+ */
+int v4l2_fwnode_endpoint_parse_port(
+   struct device *dev, struct v4l2_async_notifier *notifier,
+   unsigned int port, unsigned int endpoint, size_t asd_struct_size,
+   int (*parse_single)(struct device *dev,
+   struct v4l2_fwnode_endpoint *vep,
+   struct v4l2_async_subdev *asd))
+{
+   struct fwnode_handle *fwnode;
+   struct v4l2_async_subdev *asd;
+   int ret;
+
+   fwnode = fwnode_graph_get_remote_node(dev_fwnode(dev), port, endpoint);
+   if (!fwnode)
+   return -ENOENT;
+
+   asd = devm_kzalloc(dev, asd_struct_size, GFP_KERNEL);
+   if (!asd)
+   return -ENOMEM;
+
+   ret = notifier_realloc(dev, notifier, notifier->num_subdevs + 1);
+   if (ret)
+   goto out_free;
+
+   ret = __v4l2_fwnode_endpoint_parse(dev, notifier, fwnode, asd,
+  parse_single);
+   if (ret)
+   goto out_free;
+
+   return 0;
+
+out_free:
+   devm_kfree(dev, asd);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(v4l2_fwnode_endpoint_parse_port);
+
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Sakari Ailus ");
 MODULE_AUTHOR("Sylwester Nawrocki ");
diff --git a/include/media/v4l2-fwnode.h b/include/media/v4l2-fwnode.h
index c75a768d4ef7..5adf28e7b070 100644
--- a/include/media/v4l2-fwnode.h
+++ b/include/media/v4l2-fwnode.h
@@ -131,4 +131,11 @@ int v4l2_fwnode_endpoints_parse(
struct v4l2_fwnode_endpoint *vep,
struct v4l2_async_subdev *asd));
 
+int v4l2_fwnode_endpoint_parse_port(
+   struct device *dev, struct v4l2_async_notifier *notifier,
+   unsigned int port, unsigned int endpoint, size_t asd_struct_size,
+   int (*parse_single)(struct device *dev,
+   struct v4l2_fwnode_endpoint *vep,
+   struct v4l2_async_subdev *asd));
+
 #endif /* _V4L2_FWNODE_H */
-- 
2.11.0

[PATCH v3 1/3] omap3isp: Drop redundant isp->subdevs field and ISP_MAX_SUBDEVS

[Sakari Ailus]

struct omap3isp.subdevs field and ISP_MAX_SUBDEVS macro are both unused.
Remove them.

Signed-off-by: Sakari Ailus 
---
 drivers/media/platform/omap3isp/isp.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isp.h 
b/drivers/media/platform/omap3isp/isp.h
index e528df6efc09..848cd96b67ca 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -220,9 +220,6 @@ struct isp_device {
 
unsigned int sbl_resources;
unsigned int subclk_resources;
-
-#define ISP_MAX_SUBDEVS8
-   struct v4l2_subdev *subdevs[ISP_MAX_SUBDEVS];
 };
 
 struct isp_async_subdev {
-- 
2.11.0

Re: [PATCH 4/4] v4l: async: add comment about re-probing to v4l2_async_notifier_unregister()

[Laurent Pinchart]

Hello,

On Tuesday 15 Aug 2017 19:09:33 Sakari Ailus wrote:
> On Mon, Jul 31, 2017 at 12:31:58AM +0200, Niklas Söderlund wrote:
> > The re-probing of subdevices when unregistering a notifier is tricky to
> > understand, and implemented somewhat as a hack. Add a comment trying to
> > explain why the re-probing is needed in the first place and why existing
> > helper functions can't be used in this situation.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> > 
> >  drivers/media/v4l2-core/v4l2-async.c | 17 +
> >  1 file changed, 17 insertions(+)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-async.c
> > b/drivers/media/v4l2-core/v4l2-async.c index
> > d91ff0a33fd3eaff..a3c5a1f6d4d2ab03 100644
> > --- a/drivers/media/v4l2-core/v4l2-async.c
> > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > @@ -234,6 +234,23 @@ void v4l2_async_notifier_unregister(struct
> > v4l2_async_notifier *notifier)> 
> > mutex_unlock(_lock);
> > 
> > +   /*
> > +* Try to re-probe the subdevices which where part of the notifier.
> > +* This is done so subdevices which where part of the notifier will
> > +* be re-probed to a pristine state and put back on the global
> > +* list of subdevices so they can once more be found and associated
> > +* with a new notifier.
> 
> Instead of tweaking the code trying to handle unhandleable error conditions
> in notifier unregistration and adding lengthy stories on why this is done
> the way it is, could we simply get rid of the driver re-probing?
> 
> I can't see why drivers shouldn't simply cope with the current interfaces
> without re-probing to which I've never seen any reasoned cause. When a
> sub-device driver is unbound, simply return the sub-device node to the list
> of async sub-devices.

I agree, this is a hack that we should get rid of. Reprobing has been there 
from the very beginning, it's now 4 years and a half old, let's allow it to 
retire :-)

> Or can someone come up with a valid reason why the re-probing code should
> stay? :-)
> 
> > +*
> > +* One might be tempted to use device_reprobe() to handle the re-
> > +* probing. Unfortunately this is not possible since some video
> > +* device drivers call v4l2_async_notifier_unregister() from
> > +* there remove function leading to a dead lock situation on
> > +* device_lock(dev->parent). This lock is held when video device
> > +* drivers remove function is called and device_reprobe() also
> > +* tries to take the same lock, so using it here could lead to a
> > +* dead lock situation.
> > +*/
> > +
> > for (i = 0; i < count; i++) {
> > 
> > /* If we handled USB devices, we'd have to lock the parent too 
*/
> > device_release_driver(dev[i]);

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/4] v4l: async: fix unbind error in v4l2_async_notifier_unregister()

[Laurent Pinchart]

Hi Sakari,

On Tuesday 15 Aug 2017 19:16:14 Sakari Ailus wrote:
> On Mon, Jul 31, 2017 at 12:31:55AM +0200, Niklas Söderlund wrote:
> > The call to v4l2_async_cleanup() will set sd->asd to NULL so passing it
> > to notifier->unbind() have no effect and leaves the notifier confused.
> > Call the unbind() callback prior to cleaning up the subdevice to avoid
> > this.
> > 
> > Signed-off-by: Niklas Söderlund 
> 
> This is a bugfix and worthy without any other patches and so should be
> applied separately.
> 
> I think it'd be safer to store sd->asd locally and call the notifier unbind
> with that. Now you're making changes to the order in which things work, and
> that's not necessary to achieve the objective of passing the async subdev
> pointer to the notifier.

But on the other hand I think the unbind notification should be called before 
the subdevice gets unbound, the same way the bound notification is called 
after it gets bound. One of the purposes of the unbind notification is to 
allow drivers to prepare for subdev about to be unbound, and they can't 
prepare if the unbind happened already.

> With that changed,
> 
> Acked-by: Sakari Ailus 
> 
> > ---
> > 
> >  drivers/media/v4l2-core/v4l2-async.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-async.c
> > b/drivers/media/v4l2-core/v4l2-async.c index
> > 851f128eba2219ad..0acf288d7227ba97 100644
> > --- a/drivers/media/v4l2-core/v4l2-async.c
> > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > @@ -226,14 +226,14 @@ void v4l2_async_notifier_unregister(struct
> > v4l2_async_notifier *notifier)> 
> > d = get_device(sd->dev);
> > 
> > +   if (notifier->unbind)
> > +   notifier->unbind(notifier, sd, sd->asd);
> > +
> > 
> > v4l2_async_cleanup(sd);
> > 
> > /* If we handled USB devices, we'd have to lock the parent too 
*/
> > device_release_driver(d);
> > 
> > -   if (notifier->unbind)
> > -   notifier->unbind(notifier, sd, sd->asd);
> > -
> > 
> > /*
> > 
> >  * Store device at the device cache, in order to call
> >  * put_device() on the final step

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/4] v4l: async: fix unbind error in v4l2_async_notifier_unregister()

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday 31 Jul 2017 00:31:55 Niklas Söderlund wrote:
> The call to v4l2_async_cleanup() will set sd->asd to NULL so passing it
> to notifier->unbind() have no effect and leaves the notifier confused.
> Call the unbind() callback prior to cleaning up the subdevice to avoid
> this.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/v4l2-core/v4l2-async.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c
> b/drivers/media/v4l2-core/v4l2-async.c index
> 851f128eba2219ad..0acf288d7227ba97 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -226,14 +226,14 @@ void v4l2_async_notifier_unregister(struct
> v4l2_async_notifier *notifier)
> 
>   d = get_device(sd->dev);
> 
> + if (notifier->unbind)
> + notifier->unbind(notifier, sd, sd->asd);
> +
>   v4l2_async_cleanup(sd);
> 
>   /* If we handled USB devices, we'd have to lock the parent too 
*/
>   device_release_driver(d);
> 
> - if (notifier->unbind)
> - notifier->unbind(notifier, sd, sd->asd);
> -
>   /*
>* Store device at the device cache, in order to call
>* put_device() on the final step

-- 
Regards,

Laurent Pinchart

[GIT PULL for v4l-utils] rc fixes

[Sean Young]

Hi Mauro,

These are just fixes to ir-keytable and ir-ctl. Please let me know if you
have any ideas for improving them.

Thanks,

Sean

 
The following changes since commit 16c3764b636d647a8b41bc34d34722678220a9ff:

  cec-ctl: refactor: split the monitor code off into its own function 
(2017-08-01 09:04:51 +0200)

are available in the git repository at:

  git://linuxtv.org/syoung/v4l-utils.git rc-fixes

for you to fetch changes up to e7ce5d47962a2d1d41cd0d48f8c4d35c316e0bf5:

  ir-keytable: "ir-keytable -s rc1" should only describe rc1, not all 
(2017-08-18 10:15:56 +0100)


Sean Young (7):
  ir-keytable: do not fail at the first transmit-only device
  ir-ctl: "ir-ctl -S rc6_mce:0x800f0410" does not work on 32-bit
  ir-ctl: lirc resolution is in microseconds
  ir-ctl: report LIRCCODE drivers even if we don't supported them
  ir-keytable: null deref if kernel compiled without CONFIG_INPUT_EVDEV
  ir-keytable: ensure udev rule fires on rc input device
  ir-keytable: "ir-keytable -s rc1" should only describe rc1, not all

 utils/ir-ctl/ir-ctl.c|  8 ++--
 utils/keytable/70-infrared.rules |  2 +-
 utils/keytable/keytable.c| 19 ++-
 3 files changed, 17 insertions(+), 12 deletions(-)

Re: [PATCHv2 0/9] omapdrm: hdmi4: add CEC support

[Hans Verkuil]

On 08/18/17 11:02, Tomi Valkeinen wrote:
> Hi Hans,
> 
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
> On 11/08/17 13:57, Tomi Valkeinen wrote:
> 
>> I'm doing some testing with this series on my panda. One issue I see is
>> that when I unload the display modules, I get:
>>
>> [   75.180206] platform 58006000.encoder: enabled after unload, idling
>> [   75.187896] platform 58001000.dispc: enabled after unload, idling
>> [   75.198242] platform 5800.dss: enabled after unload, idling
> 
> This one is caused by hdmi_cec_adap_enable() never getting called with
> enable=false when unloading the modules. Should that be called
> explicitly in hdmi4_cec_uninit, or is the CEC framework supposed to call it?

Nicely found!

The cec_delete_adapter() function calls __cec_s_phys_addr(CEC_PHYS_ADDR_INVALID)
which would normally call adap_enable(false), except when the device node was
already unregistered, in which case it just returns immediately.

The patch below should fix this. Let me know if it works, and I'll post a proper
patch and get that in for 4.14 (and possible backported as well, I'll have to
look at that).

Regards,

Hans

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index bf45977b2823..61dffe165565 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -1390,7 +1390,9 @@ static void cec_claim_log_addrs(struct cec_adapter *adap, 
bool block)
  */
 void __cec_s_phys_addr(struct cec_adapter *adap, u16 phys_addr, bool block)
 {
-   if (phys_addr == adap->phys_addr || adap->devnode.unregistered)
+   if (phys_addr == adap->phys_addr)
+   return;
+   if (phys_addr != CEC_PHYS_ADDR_INVALID && adap->devnode.unregistered)
return;

dprintk(1, "new physical address %x.%x.%x.%x\n",

Re: [PATCH] uvcvideo: Apply flags from device to actual properties

[Edgar Thier]

Use flags the device exposes for UVC controls.
This allows the device to define which property flags are set.

Since some cameras offer auto-adjustments for properties (e.g. auto-gain),
the values of other properties (e.g. gain) can change in the camera.
Examining the flags ensures that the driver is aware of such properties.

Signed-off-by: Edgar Thier 
---
 drivers/media/usb/uvc/uvc_ctrl.c | 58 +++-
 1 file changed, 40 insertions(+), 18 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index c2ee6e3..6922c0cb 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -1629,6 +1629,9 @@ static void uvc_ctrl_fixup_xu_info(struct uvc_device *dev,
}
 }

+static int uvc_ctrl_get_flags(struct uvc_device *dev, const struct uvc_control 
*ctrl,
+   const struct uvc_control_info *info);
+
 /*
  * Query control information (size and flags) for XU controls.
  */
@@ -1659,24 +1662,7 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device *dev,

info->size = le16_to_cpup((__le16 *)data);

-   /* Query the control information (GET_INFO) */
-   ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl->entity->id, dev->intfnum,
-info->selector, data, 1);
-   if (ret < 0) {
-   uvc_trace(UVC_TRACE_CONTROL,
- "GET_INFO failed on control %pUl/%u (%d).\n",
- info->entity, info->selector, ret);
-   goto done;
-   }
-
-   info->flags = UVC_CTRL_FLAG_GET_MIN | UVC_CTRL_FLAG_GET_MAX
-   | UVC_CTRL_FLAG_GET_RES | UVC_CTRL_FLAG_GET_DEF
-   | (data[0] & UVC_CONTROL_CAP_GET ?
-  UVC_CTRL_FLAG_GET_CUR : 0)
-   | (data[0] & UVC_CONTROL_CAP_SET ?
-  UVC_CTRL_FLAG_SET_CUR : 0)
-   | (data[0] & UVC_CONTROL_CAP_AUTOUPDATE ?
-  UVC_CTRL_FLAG_AUTO_UPDATE : 0);
+   info->flags = uvc_ctrl_get_flags(dev, ctrl, info);

uvc_ctrl_fixup_xu_info(dev, ctrl, info);

@@ -1884,6 +1870,40 @@ int uvc_ctrl_restore_values(struct uvc_device *dev)
  */

 /*
+ * Retrieve flags for a given control
+ */
+static int uvc_ctrl_get_flags(struct uvc_device *dev, const struct uvc_control 
*ctrl,
+   const struct uvc_control_info *info)
+{
+   u8 *data;
+   int ret = 0;
+   int flags = 0;
+
+   data = kmalloc(2, GFP_KERNEL);
+   if (data == NULL)
+   return -ENOMEM;
+
+   ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl->entity->id, dev->intfnum,
+info->selector, data, 1);
+   if (ret < 0) {
+   uvc_trace(UVC_TRACE_CONTROL,
+ "GET_INFO failed on control %pUl/%u (%d).\n",
+ info->entity, info->selector, ret);
+   } else {
+   flags = UVC_CTRL_FLAG_GET_MIN | UVC_CTRL_FLAG_GET_MAX
+   | UVC_CTRL_FLAG_GET_RES | UVC_CTRL_FLAG_GET_DEF
+   | (data[0] & UVC_CONTROL_CAP_GET ?
+  UVC_CTRL_FLAG_GET_CUR : 0)
+   | (data[0] & UVC_CONTROL_CAP_SET ?
+  UVC_CTRL_FLAG_SET_CUR : 0)
+   | (data[0] & UVC_CONTROL_CAP_AUTOUPDATE ?
+  UVC_CTRL_FLAG_AUTO_UPDATE : 0);
+   }
+   kfree(data);
+   return flags;
+}
+
+/*
  * Add control information to a given control.
  */
 static int uvc_ctrl_add_info(struct uvc_device *dev, struct uvc_control *ctrl,
@@ -1902,6 +1922,8 @@ static int uvc_ctrl_add_info(struct uvc_device *dev, 
struct uvc_control *ctrl,
goto done;
}

+   ctrl->info.flags = uvc_ctrl_get_flags(dev, ctrl, info);
+
ctrl->initialized = 1;

uvc_trace(UVC_TRACE_CONTROL, "Added control %pUl/%u to device %s "
-- 
2.7.4

[GIT PULL for 4.14] More sensor driver patches

[Sakari Ailus]

Hi Mauro,

Here are more sensor driver patches for 4.14.

Please pull.


The following changes since commit ec0c3ec497cabbf3bfa03a9eb5edcc252190a4e0:

  media: ddbridge: split code into multiple files (2017-08-09 12:17:01 -0400)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git for-4.14-4

for you to fetch changes up to 0a1405339595edaaf165988b313683b1c1c90fdb:

  media: ov13858: Limit vblank to permissible range (2017-08-18 11:42:04 +0300)


Chiranjeevi Rapolu (3):
  media: ov5670: Fix incorrect frame timing reported to user
  media: ov5670: Limit vblank to permissible range
  media: ov13858: Limit vblank to permissible range

Julia Lawall (2):
  v4l: mt9t001: constify video_subdev structures
  media: mt9m111: constify video_subdev structures

Sakari Ailus (1):
  et8ek8: Decrease stack usage

 drivers/media/i2c/et8ek8/et8ek8_driver.c | 26 ++
 drivers/media/i2c/mt9m111.c  |  6 +--
 drivers/media/i2c/mt9t001.c  |  8 +--
 drivers/media/i2c/ov13858.c  | 35 -
 drivers/media/i2c/ov5670.c   | 85 ++--
 5 files changed, 96 insertions(+), 64 deletions(-)

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH 3/3] Documentation: subdev-formats: Add Xilinx YCbCr to Vendor specific area

[Laurent Pinchart]

Hi Rohit,

Thank you for the patch.

On Wednesday 09 Aug 2017 11:27:54 Rohit Athavale wrote:
> This commit adds the custom Xilinx IP specific 8-bit YCbCr 4:2:0
> to the custom formats area in the subdev-formats documentation.
> 
> Signed-off-by: Rohit Athavale 
> ---
>  Documentation/media/uapi/v4l/subdev-formats.rst | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst
> b/Documentation/media/uapi/v4l/subdev-formats.rst index 8e73bb0..141a837
> 100644
> --- a/Documentation/media/uapi/v4l/subdev-formats.rst
> +++ b/Documentation/media/uapi/v4l/subdev-formats.rst
> @@ -7483,3 +7483,8 @@ formats.
>- 0x5001
>- Interleaved raw UYVY and JPEG image format with embedded meta-data
>   used by Samsung S3C73MX camera sensors.
> +* .. _MEDIA_BUS_FMT_XLNX8_VUY420_1X24:
> +
> +  - MEDIA_BUS_FMT_XLNX8_VUY420_1X24
> +  - 0x5002
> +  - Xilinx IP specific 8-bit color depth YCbCr 4:2:0 used by Xilinx
> Video IP.

You need to document this format in more details, with a table explaining how 
bits are transferred on the bus, the same way the standard YUV formats are 
documented.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/3] uapi: media-bus-format: Add Xilinx specific YCbCr 4:2:0 media bus format

[Laurent Pinchart]

Hi Rohit,

Thank you for the patch.

On Wednesday 09 Aug 2017 11:27:52 Rohit Athavale wrote:
> This commit adds Xilinx Video IP specific 8-bit color depth YCbCr 4:2:0
> to the media bus format uapi.
> 
> Signed-off-by: Rohit Athavale 
> ---
>  include/uapi/linux/media-bus-format.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/media-bus-format.h
> b/include/uapi/linux/media-bus-format.h index ef6fb30..6f65607 100644
> --- a/include/uapi/linux/media-bus-format.h
> +++ b/include/uapi/linux/media-bus-format.h
> @@ -143,10 +143,12 @@
>  /* JPEG compressed formats - next is 0x4002 */
>  #define MEDIA_BUS_FMT_JPEG_1X8   0x4001
> 
> -/* Vendor specific formats - next is 0x5002 */
> +/* Vendor specific formats - next is 0x5003 */
> 
>  /* S5C73M3 sensor specific interleaved UYVY and JPEG */
>  #define MEDIA_BUS_FMT_S5C_UYVY_JPEG_1X8  0x5001
> +/* Xilinx IP Specific 8-bit YCbCr 4:2:0 */
> +#define MEDIA_BUS_FMT_XLNX8_VUY420_1X24  0x5002

Is this really a Xilinx-specific format ? I think it would make sense to 
define it as a standard YUV format.

>  /* HSV - next is 0x6002 */
>  #define MEDIA_BUS_FMT_AHSV_1X32  0x6001

-- 
Regards,

Laurent Pinchart

Re: [PATCH 2/3] media: xilinx-vip: Add 8-bit YCbCr 4:2:0 to formats table

[Laurent Pinchart]

Hi Rohit,

Thank you for the patch.

On Wednesday 09 Aug 2017 11:27:53 Rohit Athavale wrote:
> Add Xilinx YCbCr 4:2:0 to xvip formats table. This commit
> will allow driver to setup media pad codes to YUV 420
> via DT properties.
> 
> Signed-off-by: Rohit Athavale 
> ---
>  drivers/media/platform/xilinx/xilinx-vip.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/media/platform/xilinx/xilinx-vip.c
> b/drivers/media/platform/xilinx/xilinx-vip.c index 3112591..37b80bf 100644
> --- a/drivers/media/platform/xilinx/xilinx-vip.c
> +++ b/drivers/media/platform/xilinx/xilinx-vip.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

I'm pretty sure the file is included indirectly already, so this isn't 
strictly needed, but it shouldn't hurt either.

>  #include 
>  #include 
> 
> @@ -27,6 +28,8 @@
>   */
> 
>  static const struct xvip_video_format xvip_video_formats[] = {
> + { XVIP_VF_YUV_420, 8, NULL, MEDIA_BUS_FMT_XLNX8_VUY420_1X24,
> +   2, V4L2_PIX_FMT_NV12, "4:2:0, semi-planar, YUYV" },

You're mapping XVIP_VF_YUV_420 to V4L2_PIX_FMT_NV12 which has an average bpp 
of 1.5 bytes per pixel, but you're setting bpp to 2. How does that work ? You 
obviously can't express a 1.5 bpp currently in the driver, so we might need to 
extend the xvip_video_format structure with additional fields (for instance 
turning bytes per pixel into bits per pixel, but we might need per-plane 
information too).

On a side note, how does this work with VDMA ? The latest VDMA version I 
checked (v6.2, a while ago) didn't seem to support planar formats. Has it 
changed in more recent versions ? Doesn't it require changes in the xilinx-vip 
driver ?

>   { XVIP_VF_YUV_422, 8, NULL, MEDIA_BUS_FMT_UYVY8_1X16,
> 2, V4L2_PIX_FMT_YUYV, "4:2:2, packed, YUYV" },
>   { XVIP_VF_YUV_444, 8, NULL, MEDIA_BUS_FMT_VUY8_1X24,

-- 
Regards,

Laurent Pinchart

Re: [PATCHv2 0/9] omapdrm: hdmi4: add CEC support

[Tomi Valkeinen]

Hi Hans,


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 11/08/17 13:57, Tomi Valkeinen wrote:

> I'm doing some testing with this series on my panda. One issue I see is
> that when I unload the display modules, I get:
> 
> [   75.180206] platform 58006000.encoder: enabled after unload, idling
> [   75.187896] platform 58001000.dispc: enabled after unload, idling
> [   75.198242] platform 5800.dss: enabled after unload, idling

This one is caused by hdmi_cec_adap_enable() never getting called with
enable=false when unloading the modules. Should that be called
explicitly in hdmi4_cec_uninit, or is the CEC framework supposed to call it?

 Tomi

Re: [PATCH 1/1] et8ek8: Decrease stack usage

[Sakari Ailus]

On Thu, Aug 17, 2017 at 11:38:43PM +0200, Pavel Machek wrote:
> On Wed 2017-08-16 10:33:45, Sakari Ailus wrote:
> > The et8ek8 driver combines I²C register writes to a single array that it
> > passes to i2c_transfer(). The maximum number of writes is 48 at once,
> > decrease it to 8 and make more transfers if needed, thus avoiding a
> > warning on stack usage.
> > 
> > Signed-off-by: Sakari Ailus 
> > ---
> > Pavel: this is just compile tested. Could you test it on N900, please?
> 
> (More than 1 et8ek8 device makes static bad idea).
> 
> Acked-by: Pavel Machek 
> Tested-by: Pavel Machek 

Thanks!

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

[PATCH 1/2] doc: media/v4l-drivers/qcom_camss: Add abbreviations explanation

[Todor Tomov]

Add explanations for VFE's PIX and RDI interfaces.

Signed-off-by: Todor Tomov 
---
 Documentation/media/v4l-drivers/qcom_camss.rst | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/Documentation/media/v4l-drivers/qcom_camss.rst 
b/Documentation/media/v4l-drivers/qcom_camss.rst
index 7ef632a..9e66b7b 100644
--- a/Documentation/media/v4l-drivers/qcom_camss.rst
+++ b/Documentation/media/v4l-drivers/qcom_camss.rst
@@ -34,11 +34,12 @@ driver consists of:
 - ISPIF (ISP Interface) module. Handles the routing of the data streams from
   the CSIDs to the inputs of the VFE;
 - VFE (Video Front End) module. Contains a pipeline of image processing 
hardware
-  blocks. The VFE has different input interfaces. The PIX input interface feeds
-  the input data to the image processing pipeline. The image processing 
pipeline
-  contains also a scale and crop module at the end. Three RDI input interfaces
-  bypass the image processing pipeline. The VFE also contains the AXI bus
-  interface which writes the output data to memory.
+  blocks. The VFE has different input interfaces. The PIX (Pixel) input
+  interface feeds the input data to the image processing pipeline. The image
+  processing pipeline contains also a scale and crop module at the end. Three
+  RDI (Raw Dump Interface) input interfaces bypass the image processing
+  pipeline. The VFE also contains the AXI bus interface which writes the output
+  data to memory.
 
 
 Supported functionality
-- 
2.7.4

[PATCH 2/2] media: camss: Add abbreviations explanation

[Todor Tomov]

Add abbreviations explanation at the top header blocks in source files.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss-8x16/camss-csid.c  | 2 +-
 drivers/media/platform/qcom/camss-8x16/camss-csid.h  | 2 +-
 drivers/media/platform/qcom/camss-8x16/camss-ispif.c | 2 +-
 drivers/media/platform/qcom/camss-8x16/camss-ispif.h | 2 +-
 drivers/media/platform/qcom/camss-8x16/camss-vfe.c   | 2 +-
 drivers/media/platform/qcom/camss-8x16/camss-vfe.h   | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/qcom/camss-8x16/camss-csid.c 
b/drivers/media/platform/qcom/camss-8x16/camss-csid.c
index 792c14a..64df828 100644
--- a/drivers/media/platform/qcom/camss-8x16/camss-csid.c
+++ b/drivers/media/platform/qcom/camss-8x16/camss-csid.c
@@ -1,7 +1,7 @@
 /*
  * camss-csid.c
  *
- * Qualcomm MSM Camera Subsystem - CSID Module
+ * Qualcomm MSM Camera Subsystem - CSID (CSI Decoder) Module
  *
  * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
  * Copyright (C) 2015-2017 Linaro Ltd.
diff --git a/drivers/media/platform/qcom/camss-8x16/camss-csid.h 
b/drivers/media/platform/qcom/camss-8x16/camss-csid.h
index 4df7018..8682d30 100644
--- a/drivers/media/platform/qcom/camss-8x16/camss-csid.h
+++ b/drivers/media/platform/qcom/camss-8x16/camss-csid.h
@@ -1,7 +1,7 @@
 /*
  * camss-csid.h
  *
- * Qualcomm MSM Camera Subsystem - CSID Module
+ * Qualcomm MSM Camera Subsystem - CSID (CSI Decoder) Module
  *
  * Copyright (c) 2011-2014, The Linux Foundation. All rights reserved.
  * Copyright (C) 2015-2017 Linaro Ltd.
diff --git a/drivers/media/platform/qcom/camss-8x16/camss-ispif.c 
b/drivers/media/platform/qcom/camss-8x16/camss-ispif.c
index 54d1946..24da529 100644
--- a/drivers/media/platform/qcom/camss-8x16/camss-ispif.c
+++ b/drivers/media/platform/qcom/camss-8x16/camss-ispif.c
@@ -1,7 +1,7 @@
 /*
  * camss-ispif.c
  *
- * Qualcomm MSM Camera Subsystem - ISPIF Module
+ * Qualcomm MSM Camera Subsystem - ISPIF (ISP Interface) Module
  *
  * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
  * Copyright (C) 2015-2017 Linaro Ltd.
diff --git a/drivers/media/platform/qcom/camss-8x16/camss-ispif.h 
b/drivers/media/platform/qcom/camss-8x16/camss-ispif.h
index 6659020..f668306 100644
--- a/drivers/media/platform/qcom/camss-8x16/camss-ispif.h
+++ b/drivers/media/platform/qcom/camss-8x16/camss-ispif.h
@@ -1,7 +1,7 @@
 /*
  * camss-ispif.h
  *
- * Qualcomm MSM Camera Subsystem - ISPIF Module
+ * Qualcomm MSM Camera Subsystem - ISPIF (ISP Interface) Module
  *
  * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
  * Copyright (C) 2015-2017 Linaro Ltd.
diff --git a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c 
b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
index 1c86b10..94d635e 100644
--- a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
@@ -1,7 +1,7 @@
 /*
  * camss-vfe.c
  *
- * Qualcomm MSM Camera Subsystem - VFE Module
+ * Qualcomm MSM Camera Subsystem - VFE (Video Front End) Module
  *
  * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
  * Copyright (C) 2015-2017 Linaro Ltd.
diff --git a/drivers/media/platform/qcom/camss-8x16/camss-vfe.h 
b/drivers/media/platform/qcom/camss-8x16/camss-vfe.h
index 88c29d0..53d5b66 100644
--- a/drivers/media/platform/qcom/camss-8x16/camss-vfe.h
+++ b/drivers/media/platform/qcom/camss-8x16/camss-vfe.h
@@ -1,7 +1,7 @@
 /*
  * camss-vfe.h
  *
- * Qualcomm MSM Camera Subsystem - VFE Module
+ * Qualcomm MSM Camera Subsystem - VFE (Video Front End) Module
  *
  * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
  * Copyright (C) 2015-2017 Linaro Ltd.
-- 
2.7.4

Re: [PATCH v4 04/21] doc: media/v4l-drivers: Add Qualcomm Camera Subsystem driver document

[Todor Tomov]

Hi Hans,

On 18.08.2017 10:45, Hans Verkuil wrote:
> Hi Todor,
> 
> A few small comments below:
> 
> On 08/08/2017 03:30 PM, Todor Tomov wrote:
>> Add a document to describe Qualcomm Camera Subsystem driver.
>>
>> Signed-off-by: Todor Tomov 
>> ---
>>  Documentation/media/v4l-drivers/qcom_camss.rst | 124 
>> +
>>  1 file changed, 124 insertions(+)
>>  create mode 100644 Documentation/media/v4l-drivers/qcom_camss.rst
>>
>> diff --git a/Documentation/media/v4l-drivers/qcom_camss.rst 
>> b/Documentation/media/v4l-drivers/qcom_camss.rst
>> new file mode 100644
>> index 000..4707ea7
>> --- /dev/null
>> +++ b/Documentation/media/v4l-drivers/qcom_camss.rst
>> @@ -0,0 +1,124 @@
>> +.. include:: 
>> +
>> +Qualcomm Camera Subsystem driver
>> +
>> +
>> +Introduction
>> +
>> +
>> +This file documents the Qualcomm Camera Subsystem driver located under
>> +drivers/media/platform/qcom/camss-8x16.
>> +
>> +The current version of the driver supports the Camera Subsystem found on
>> +Qualcomm MSM8916 and APQ8016 processors.
>> +
>> +The driver implements V4L2, Media controller and V4L2 subdev interfaces.
>> +Camera sensor using V4L2 subdev interface in the kernel is supported.
>> +
>> +The driver is implemented using as a reference the Qualcomm Camera Subsystem
>> +driver for Android as found in Code Aurora [#f1]_.
>> +
>> +
>> +Qualcomm Camera Subsystem hardware
>> +--
>> +
>> +The Camera Subsystem hardware found on 8x16 processors and supported by the
>> +driver consists of:
>> +
>> +- 2 CSIPHY modules. They handle the Physical layer of the CSI2 receivers.
>> +  A separate camera sensor can be connected to each of the CSIPHY module;
>> +- 2 CSID (CSI Decoder) modules. They handle the Protocol and Application 
>> layer
>> +  of the CSI2 receivers. A CSID can decode data stream from any of the 
>> CSIPHY.
>> +  Each CSID also contains a TG (Test Generator) block which can generate
>> +  artificial input data for test purposes;
>> +- ISPIF (ISP Interface) module. Handles the routing of the data streams from
>> +  the CSIDs to the inputs of the VFE;
>> +- VFE (Video Front End) module. Contains a pipeline of image processing 
>> hardware
>> +  blocks. The VFE has different input interfaces. The PIX input interface 
>> feeds
>> +  the input data to the image processing pipeline. Three RDI input 
>> interfaces
>> +  bypass the image processing pipeline. The VFE also contains the AXI bus
>> +  interface which writes the output data to memory.
> 
> Can you explain what PIX and RDI stand for?
> 
> I would also think it is a good idea to add a comment at the top of the 
> various
> subdev sources that say a bit more than just "CSID Module".
> 
> A simple "CSID (CSI Decoder) Module" is enough. Just so the reader knows what
> it is all about.
> 
> Otherwise I don't have any more comments about this series.
> 
> I don't need a v5 for this, if you can just post one patch for this 
> documentation
> and one patch improving the source comments as described above, then that's
> fine with me.

Thank you for the review again.
I'll post two additional patches to add explanations of the abbreviations.

> 
> Regards,
> 
>   Hans
> 
>> +
>> +
>> +Supported functionality
>> +---
>> +
>> +The current version of the driver supports:
>> +
>> +- input from camera sensor via CSIPHY;
>> +- generation of test input data by the TG in CSID;
>> +- raw dump of the input data to memory. RDI interface of VFE is supported.
>> +  PIX interface (ISP processing, statistics engines, resize/crop, format
>> +  conversion) is not supported in the current version;
>> +- concurrent and independent usage of two data inputs - could be camera 
>> sensors
>> +  and/or TG.
>> +
>> +
>> +Driver Architecture and Design
>> +--
>> +
>> +The driver implements the V4L2 subdev interface. With the goal to model the
>> +hardware links between the modules and to expose a clean, logical and usable
>> +interface, the driver is split into V4L2 sub-devices as follows:
>> +
>> +- 2 CSIPHY sub-devices - each CSIPHY is represented by a single sub-device;
>> +- 2 CSID sub-devices - each CSID is represented by a single sub-device;
>> +- 2 ISPIF sub-devices - ISPIF is represented by a number of sub-devices 
>> equal
>> +  to the number of CSID sub-devices;
>> +- 3 VFE sub-devices - VFE is represented by a number of sub-devices equal to
>> +  the number of RDI input interfaces.
>> +
>> +The considerations to split the driver in this particular way are as 
>> follows:
>> +
>> +- representing CSIPHY and CSID modules by a separate sub-device for each 
>> module
>> +  allows to model the hardware links between these modules;
>> +- representing VFE by a separate sub-devices for each RDI input interface 
>> allows
>> +  to use the three RDI interfaces concurently and independently as this is
>> +  supported by the 

Re: [PATCH] media: venus: fix duplicated code for different branches

[Stanimir Varbanov]

Hi Gustavo,

On 08/18/2017 02:12 AM, Gustavo A. R. Silva wrote:
> Refactor code in order to avoid identical code for different branches.
> 
> This issue was detected with the help of Coccinelle.
> 
> Addresses-Coverity-ID: 1415317
> Signed-off-by: Gustavo A. R. Silva 
> ---
> This code was reported by Coverity and it was tested by compilation only.
> Please, verify if this is an actual bug.

Yes looks like copy/paste error, and yes it is a bug.

> 
>  drivers/media/platform/qcom/venus/helpers.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/venus/helpers.c 
> b/drivers/media/platform/qcom/venus/helpers.c
> index 5f4434c..8a5c467 100644
> --- a/drivers/media/platform/qcom/venus/helpers.c
> +++ b/drivers/media/platform/qcom/venus/helpers.c
> @@ -240,11 +240,7 @@ static void return_buf_error(struct venus_inst *inst,
>  {
>   struct v4l2_m2m_ctx *m2m_ctx = inst->m2m_ctx;
>  
> - if (vbuf->vb2_buf.type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
> - v4l2_m2m_src_buf_remove_by_buf(m2m_ctx, vbuf);
> - else
> - v4l2_m2m_src_buf_remove_by_buf(m2m_ctx, vbuf);

the correct fix must replace the second v4l2_m2m_src_* with v4l2_m2m_dst_*.

> -
> + v4l2_m2m_src_buf_remove_by_buf(m2m_ctx, vbuf);
>   v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_ERROR);
>  }
>  
> 

-- 
regards,
Stan

Re: [PATCH v4 04/21] doc: media/v4l-drivers: Add Qualcomm Camera Subsystem driver document

[Hans Verkuil]

Hi Todor,

A few small comments below:

On 08/08/2017 03:30 PM, Todor Tomov wrote:
> Add a document to describe Qualcomm Camera Subsystem driver.
> 
> Signed-off-by: Todor Tomov 
> ---
>  Documentation/media/v4l-drivers/qcom_camss.rst | 124 
> +
>  1 file changed, 124 insertions(+)
>  create mode 100644 Documentation/media/v4l-drivers/qcom_camss.rst
> 
> diff --git a/Documentation/media/v4l-drivers/qcom_camss.rst 
> b/Documentation/media/v4l-drivers/qcom_camss.rst
> new file mode 100644
> index 000..4707ea7
> --- /dev/null
> +++ b/Documentation/media/v4l-drivers/qcom_camss.rst
> @@ -0,0 +1,124 @@
> +.. include:: 
> +
> +Qualcomm Camera Subsystem driver
> +
> +
> +Introduction
> +
> +
> +This file documents the Qualcomm Camera Subsystem driver located under
> +drivers/media/platform/qcom/camss-8x16.
> +
> +The current version of the driver supports the Camera Subsystem found on
> +Qualcomm MSM8916 and APQ8016 processors.
> +
> +The driver implements V4L2, Media controller and V4L2 subdev interfaces.
> +Camera sensor using V4L2 subdev interface in the kernel is supported.
> +
> +The driver is implemented using as a reference the Qualcomm Camera Subsystem
> +driver for Android as found in Code Aurora [#f1]_.
> +
> +
> +Qualcomm Camera Subsystem hardware
> +--
> +
> +The Camera Subsystem hardware found on 8x16 processors and supported by the
> +driver consists of:
> +
> +- 2 CSIPHY modules. They handle the Physical layer of the CSI2 receivers.
> +  A separate camera sensor can be connected to each of the CSIPHY module;
> +- 2 CSID (CSI Decoder) modules. They handle the Protocol and Application 
> layer
> +  of the CSI2 receivers. A CSID can decode data stream from any of the 
> CSIPHY.
> +  Each CSID also contains a TG (Test Generator) block which can generate
> +  artificial input data for test purposes;
> +- ISPIF (ISP Interface) module. Handles the routing of the data streams from
> +  the CSIDs to the inputs of the VFE;
> +- VFE (Video Front End) module. Contains a pipeline of image processing 
> hardware
> +  blocks. The VFE has different input interfaces. The PIX input interface 
> feeds
> +  the input data to the image processing pipeline. Three RDI input interfaces
> +  bypass the image processing pipeline. The VFE also contains the AXI bus
> +  interface which writes the output data to memory.

Can you explain what PIX and RDI stand for?

I would also think it is a good idea to add a comment at the top of the various
subdev sources that say a bit more than just "CSID Module".

A simple "CSID (CSI Decoder) Module" is enough. Just so the reader knows what
it is all about.

Otherwise I don't have any more comments about this series.

I don't need a v5 for this, if you can just post one patch for this 
documentation
and one patch improving the source comments as described above, then that's
fine with me.

Regards,

Hans

> +
> +
> +Supported functionality
> +---
> +
> +The current version of the driver supports:
> +
> +- input from camera sensor via CSIPHY;
> +- generation of test input data by the TG in CSID;
> +- raw dump of the input data to memory. RDI interface of VFE is supported.
> +  PIX interface (ISP processing, statistics engines, resize/crop, format
> +  conversion) is not supported in the current version;
> +- concurrent and independent usage of two data inputs - could be camera 
> sensors
> +  and/or TG.
> +
> +
> +Driver Architecture and Design
> +--
> +
> +The driver implements the V4L2 subdev interface. With the goal to model the
> +hardware links between the modules and to expose a clean, logical and usable
> +interface, the driver is split into V4L2 sub-devices as follows:
> +
> +- 2 CSIPHY sub-devices - each CSIPHY is represented by a single sub-device;
> +- 2 CSID sub-devices - each CSID is represented by a single sub-device;
> +- 2 ISPIF sub-devices - ISPIF is represented by a number of sub-devices equal
> +  to the number of CSID sub-devices;
> +- 3 VFE sub-devices - VFE is represented by a number of sub-devices equal to
> +  the number of RDI input interfaces.
> +
> +The considerations to split the driver in this particular way are as follows:
> +
> +- representing CSIPHY and CSID modules by a separate sub-device for each 
> module
> +  allows to model the hardware links between these modules;
> +- representing VFE by a separate sub-devices for each RDI input interface 
> allows
> +  to use the three RDI interfaces concurently and independently as this is
> +  supported by the hardware;
> +- representing ISPIF by a number of sub-devices equal to the number of CSID
> +  sub-devices allows to create linear media controller pipelines when using 
> two
> +  cameras simultaneously. This avoids branches in the pipelines which 
> otherwise
> +  will require a) userspace and b) media framework (e.g. power 

Re: [PATCH] [media] mx2_emmaprp: Check for platform_get_irq() error

[Philipp Zabel]

Hi Fabio,

On Thu, 2017-08-17 at 18:12 -0300, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> platform_get_irq() may fail, so we should better check its return
> value and propagate it in the case of error.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  drivers/media/platform/mx2_emmaprp.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/media/platform/mx2_emmaprp.c
> b/drivers/media/platform/mx2_emmaprp.c
> index 03e47e0..f90eaa0 100644
> --- a/drivers/media/platform/mx2_emmaprp.c
> +++ b/drivers/media/platform/mx2_emmaprp.c
> @@ -942,6 +942,8 @@ static int emmaprp_probe(struct platform_device
> *pdev)
>   platform_set_drvdata(pdev, pcdev);
>  
>   irq = platform_get_irq(pdev, 0);
> + if (irq < 0)
> + return irq;
>   ret = devm_request_irq(>dev, irq, emmaprp_irq, 0,
>      dev_name(>dev), pcdev);
>   if (ret)

For IORESOURCE_MEM + devm_ioremap_resource pairs this seems to be a
pattern in the kernel, though.
Does devm_request_irq reliably return an error when irq is negative? If
so, this check would be redundant.

regards
Philipp

Re: [PATCH] [media] coda/imx-vdoa: Check for platform_get_resource() error

[Philipp Zabel]

Hi Fabio,

On Wed, 2017-08-16 at 21:14 -0300, Fabio Estevam wrote:
> > From: Fabio Estevam 
> 
> platform_get_resource() may fail and in this case a NULL dereference
> will occur.
> 
> Prevent this from happening by returning an error on
> platform_get_resource() failure. 
> 
> Fixes: b0444f18e0b18abce ("[media] coda: add i.MX6 VDOA driver")
> > Signed-off-by: Fabio Estevam 
> ---
>  drivers/media/platform/coda/imx-vdoa.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/media/platform/coda/imx-vdoa.c 
> b/drivers/media/platform/coda/imx-vdoa.c
> index df9b716..8eb3e0c 100644
> --- a/drivers/media/platform/coda/imx-vdoa.c
> +++ b/drivers/media/platform/coda/imx-vdoa.c
> @@ -314,6 +314,8 @@ static int vdoa_probe(struct platform_device *pdev)
> >     return PTR_ERR(vdoa->regs);
>  
> >     res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> > +   if (!res)
> > +   return -EINVAL;
> >     vdoa->irq = devm_request_threaded_irq(>dev, res->start, NULL,
> >     vdoa_irq_handler, IRQF_ONESHOT,
> >     "vdoa", vdoa);

Thank you for the fix! I think it would be better to replace
platform_get_resource with platform_get_irq. Either way,

Acked-by: Philipp Zabel 

regards
Philipp

[GIT PULL FOR v4.14] Various fixes/improvements

[Hans Verkuil]

Lots of constify stuff, some random other fixes.

The following changes since commit ec0c3ec497cabbf3bfa03a9eb5edcc252190a4e0:

  media: ddbridge: split code into multiple files (2017-08-09 12:17:01 -0400)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.14i

for you to fetch changes up to 6b1672790166600515ff497a3e2733d0b2787815:

  usb: rainshadow-cec: constify serio_device_id (2017-08-18 09:13:43 +0200)


Arvind Yadav (5):
  coda: constify platform_device_id
  davinci: constify platform_device_id
  radio: constify pnp_device_id
  usb: pulse8-cec: constify serio_device_id
  usb: rainshadow-cec: constify serio_device_id

Bhumika Goyal (6):
  tuners: make tda18271_std_map const
  staging: bcm2835-audio: make snd_pcm_hardware const
  cx88: make snd_kcontrol_new const
  solo6x10: make snd_kcontrol_new const
  cx18: Fix incompatible type for argument error
  ivtv: Fix incompatible type for argument error

Fabio Estevam (1):
  coda/imx-vdoa: Check for platform_get_resource() error

Pan Bian (1):
  media: mtk-mdp: use IS_ERR to check return value of of_clk_get

Rob Herring (1):
  media: Convert to using %pOF instead of full_name

 drivers/media/i2c/s5c73m3/s5c73m3-core.c  |  3 +--
 drivers/media/i2c/s5k5baf.c   |  7 +++---
 drivers/media/pci/cx18/cx18-alsa-mixer.c  |  2 +-
 drivers/media/pci/cx88/cx88-alsa.c|  2 +-
 drivers/media/pci/ivtv/ivtv-alsa-mixer.c  |  2 +-
 drivers/media/pci/solo6x10/solo6x10-g723.c|  2 +-
 drivers/media/platform/am437x/am437x-vpfe.c   |  4 ++--
 drivers/media/platform/atmel/atmel-isc.c  |  4 ++--
 drivers/media/platform/coda/coda-common.c |  2 +-
 drivers/media/platform/coda/imx-vdoa.c|  2 ++
 drivers/media/platform/davinci/vpbe_osd.c |  2 +-
 drivers/media/platform/davinci/vpbe_venc.c|  2 +-
 drivers/media/platform/davinci/vpif_capture.c | 16 ++---
 drivers/media/platform/exynos4-is/fimc-is.c   |  8 +++
 drivers/media/platform/exynos4-is/fimc-lite.c |  3 +--
 drivers/media/platform/exynos4-is/media-dev.c |  8 +++
 drivers/media/platform/exynos4-is/mipi-csis.c |  4 ++--
 drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 10 -
 drivers/media/platform/mtk-mdp/mtk_mdp_core.c |  8 +++
 drivers/media/platform/omap3isp/isp.c |  8 +++
 drivers/media/platform/pxa_camera.c   |  2 +-
 drivers/media/platform/rcar-vin/rcar-core.c   |  4 ++--
 drivers/media/platform/soc_camera/soc_camera.c|  6 ++---
 drivers/media/platform/xilinx/xilinx-vipp.c   | 52 
+--
 drivers/media/radio/radio-cadet.c |  2 +-
 drivers/media/radio/radio-gemtek.c|  2 +-
 drivers/media/radio/radio-sf16fmr2.c  |  2 +-
 drivers/media/tuners/tda18271-maps.c  |  4 ++--
 drivers/media/usb/pulse8-cec/pulse8-cec.c |  2 +-
 drivers/media/usb/rainshadow-cec/rainshadow-cec.c |  2 +-
 drivers/media/v4l2-core/v4l2-clk.c|  3 +--
 drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c |  4 ++--
 include/media/v4l2-clk.h  |  4 ++--
 33 files changed, 90 insertions(+), 98 deletions(-)

[PATCH v1] [media] uvcvideo: mark buffer error where overflow

[Baoyou Xie]

Some cameras post inaccurate frame where next frame data overlap
it. this results in screen flicker, and it need to be prevented.

So this patch marks the buffer error to discard the frame where
buffer overflow.

Signed-off-by: Baoyou Xie 
---
 drivers/media/usb/uvc/uvc_video.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/usb/uvc/uvc_video.c 
b/drivers/media/usb/uvc/uvc_video.c
index fb86d6a..81a3530 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1077,6 +1077,7 @@ static void uvc_video_decode_data(struct uvc_streaming 
*stream,
/* Complete the current frame if the buffer size was exceeded. */
if (len > maxlen) {
uvc_trace(UVC_TRACE_FRAME, "Frame complete (overflow).\n");
+   buf->error = 1;
buf->state = UVC_BUF_STATE_READY;
}
 }
-- 
2.7.4

Re: [PATCH] media: venus: fix duplicated code for different branches

[Hans Verkuil]

Stanimir, please review this! I suspect that this is the wrong fix and
that the first v4l2_m2m_src_buf_remove_by_buf should be
v4l2_m2m_dst_buf_remove_by_buf instead.

Regards,

Hans

On 08/18/2017 01:12 AM, Gustavo A. R. Silva wrote:
> Refactor code in order to avoid identical code for different branches.
> 
> This issue was detected with the help of Coccinelle.
> 
> Addresses-Coverity-ID: 1415317
> Signed-off-by: Gustavo A. R. Silva 
> ---
> This code was reported by Coverity and it was tested by compilation only.
> Please, verify if this is an actual bug.
> 
>  drivers/media/platform/qcom/venus/helpers.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/venus/helpers.c 
> b/drivers/media/platform/qcom/venus/helpers.c
> index 5f4434c..8a5c467 100644
> --- a/drivers/media/platform/qcom/venus/helpers.c
> +++ b/drivers/media/platform/qcom/venus/helpers.c
> @@ -240,11 +240,7 @@ static void return_buf_error(struct venus_inst *inst,
>  {
>   struct v4l2_m2m_ctx *m2m_ctx = inst->m2m_ctx;
>  
> - if (vbuf->vb2_buf.type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
> - v4l2_m2m_src_buf_remove_by_buf(m2m_ctx, vbuf);
> - else
> - v4l2_m2m_src_buf_remove_by_buf(m2m_ctx, vbuf);
> -
> + v4l2_m2m_src_buf_remove_by_buf(m2m_ctx, vbuf);
>   v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_ERROR);
>  }
>  
>