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:   Wed Jun  7 05:00:17 CEST 2017
media-tree git hash:6fb05e0dd32e566facb96ea61a48c7488daa5ac3
media_build git hash:   0d8b3274e29b597780719e7ce1b3b460241a5395
v4l-utils git hash: ef074cf5500b7dd62e6eb3527ec47a914c7189ca
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

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

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

[PATCH v2 0/3] [media] add IPU3 CIO2 CSI2 driver

[Yong Zhi]

This patch adds the driver for the CIO2 device found in some the Skylake
and Kaby Kake SoCs. The CIO2 consists of four D-PHY receivers.

The CIO2 driver exposes V4L2, V4L2 sub-device and Media controller
interfaces to the user space.

===
= history =
===
version 2:
- remove all explicit DMA flush operations
- change dma_free_noncoherent() to dma_free_coherent()
- remove cio2_hw_mipi_lanes()
- replace v4l2_g_ext_ctrls() with v4l2_ctrl_g_ctrl()
  in cio2_csi2_calc_timing().
- use ffs() to iterate the port_status in cio2_irq()
- add static inline file_to_cio2_queue() function
- comment dma_wmb(), cio2_rx_timing() and few other places
- use ktime_get_ns() for vb2_buf.timestamp in cio2_buffer_done()
- use of SET_RUNTIME_PM_OPS() macro for cio2_pm_ops
- use BIT() macro for bit difinitions
- remove un-used macros such as CIO2_QUEUE_WIDTH() in ipu3-cio2.h
- move the MODULE_AUTHOR() to the end of the file
- change file path to drivers/media/pci/intel/ipu3

version 1:
- Initial submission
Yong Zhi (3):
  [media] videodev2.h, v4l2-ioctl: add IPU3 raw10 color format
  [media] doc-rst: add IPU3 raw10 bayer pixel format definitions
  [media] intel-ipu3: cio2: Add new MIPI-CSI2 driver

 Documentation/media/uapi/v4l/pixfmt-rgb.rst|1 +
 .../media/uapi/v4l/pixfmt-srggb10-ipu3.rst |   62 +
 drivers/media/pci/Kconfig  |2 +
 drivers/media/pci/Makefile |3 +-
 drivers/media/pci/intel/Makefile   |5 +
 drivers/media/pci/intel/ipu3/Kconfig   |   17 +
 drivers/media/pci/intel/ipu3/Makefile  |1 +
 drivers/media/pci/intel/ipu3/ipu3-cio2.c   | 1788 
 drivers/media/pci/intel/ipu3/ipu3-cio2.h   |  424 +
 drivers/media/v4l2-core/v4l2-ioctl.c   |4 +
 include/uapi/linux/videodev2.h |5 +
 11 files changed, 2311 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst
 create mode 100644 drivers/media/pci/intel/Makefile
 create mode 100644 drivers/media/pci/intel/ipu3/Kconfig
 create mode 100644 drivers/media/pci/intel/ipu3/Makefile
 create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.c
 create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.h

-- 
2.7.4

[PATCH v2 2/3] [media] doc-rst: add IPU3 raw10 bayer pixel format definitions

[Yong Zhi]

The formats added by this patch are:

V4L2_PIX_FMT_IPU3_SBGGR10
V4L2_PIX_FMT_IPU3_SGBRG10
V4L2_PIX_FMT_IPU3_SGRBG10
V4L2_PIX_FMT_IPU3_SRGGB10

Signed-off-by: Yong Zhi 
---
 Documentation/media/uapi/v4l/pixfmt-rgb.rst|  1 +
 .../media/uapi/v4l/pixfmt-srggb10-ipu3.rst | 62 ++
 2 files changed, 63 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst

diff --git a/Documentation/media/uapi/v4l/pixfmt-rgb.rst 
b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
index b0f3513..6900d5c 100644
--- a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
@@ -16,5 +16,6 @@ RGB Formats
 pixfmt-srggb10p
 pixfmt-srggb10alaw8
 pixfmt-srggb10dpcm8
+pixfmt-srggb10-ipu3
 pixfmt-srggb12
 pixfmt-srggb16
diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst 
b/Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst
new file mode 100644
index 000..618e24a
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst
@@ -0,0 +1,62 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2_PIX_FMT_IPU3_SBGGR10:
+.. _V4L2_PIX_FMT_IPU3_SGBRG10:
+.. _V4L2_PIX_FMT_IPU3_SGRBG10:
+.. _V4L2_PIX_FMT_IPU3_SRGGB10:
+
+**
+V4L2_PIX_FMT_IPU3_SBGGR10 ('ip3b'), V4L2_PIX_FMT_IPU3_SGBRG10 ('ip3g'), 
V4L2_PIX_FMT_IPU3_SGRBG10 ('ip3G'), V4L2_PIX_FMT_IPU3_SRGGB10 ('ip3r')
+**
+
+10-bit Bayer formats
+
+Description
+===
+
+These four pixel formats are used by Intel IPU3 driver, they are raw
+sRGB / Bayer formats with 10 bits per sample with every 25 pixels packed
+to 32 bytes leaving 6 most significant bits padding in the last byte.
+The format is little endian.
+
+In other respects this format is similar to :ref:`V4L2-PIX-FMT-SRGGB10`.
+
+**Byte Order.**
+Each cell is one byte.
+
+.. raw:: latex
+
+\newline\newline\begin{adjustbox}{width=\columnwidth}
+
+.. tabularcolumns:: |p{1.3cm}|p{1.0cm}|p{10.9cm}|p{10.9cm}|p{10.9cm}|p{1.0cm}|
+
+.. flat-table::
+
+* - start + 0:
+  - B\ :sub:`00low`
+  - G\ :sub:`01low` \ (bits 7--2) B\ :sub:`00high`\ (bits 1--0)
+  - B\ :sub:`02low` \ (bits 7--4) G\ :sub:`01high`\ (bits 3--0)
+  - G\ :sub:`03low` \ (bits 7--6) B\ :sub:`02high`\ (bits 5--0)
+  - G\ :sub:`03high`
+* - start + 5:
+  - G\ :sub:`10low`
+  - R\ :sub:`11low` \ (bits 7--2) G\ :sub:`10high`\ (bits 1--0)
+  - G\ :sub:`12low` \ (bits 7--4) R\ :sub:`11high`\ (bits 3--0)
+  - R\ :sub:`13low` \ (bits 7--6) G\ :sub:`12high`\ (bits 5--0)
+  - R\ :sub:`13high`
+* - start + 10:
+  - B\ :sub:`20low`
+  - G\ :sub:`21low` \ (bits 7--2) B\ :sub:`20high`\ (bits 1--0)
+  - B\ :sub:`22low` \ (bits 7--4) G\ :sub:`21high`\ (bits 3--0)
+  - G\ :sub:`23low` \ (bits 7--6) B\ :sub:`22high`\ (bits 5--0)
+  - G\ :sub:`23high`
+* - start + 15:
+  - G\ :sub:`30low`
+  - R\ :sub:`31low` \ (bits 7--2) G\ :sub:`30high`\ (bits 1--0)
+  - G\ :sub:`32low` \ (bits 7--4) R\ :sub:`31high`\ (bits 3--0)
+  - R\ :sub:`33low` \ (bits 7--6) G\ :sub:`32high`\ (bits 5--0)
+  - R\ :sub:`33high`
+
+.. raw:: latex
+
+\end{adjustbox}\newline\newline
-- 
2.7.4

[PATCH v2 1/3] [media] videodev2.h, v4l2-ioctl: add IPU3 raw10 color format

[Yong Zhi]

Add IPU3 specific formats:

V4L2_PIX_FMT_IPU3_SBGGR10
V4L2_PIX_FMT_IPU3_SGBRG10
V4L2_PIX_FMT_IPU3_SGRBG10
V4L2_PIX_FMT_IPU3_SRGGB10

Signed-off-by: Yong Zhi 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 4 
 include/uapi/linux/videodev2.h   | 5 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index e5a2187..fb1387f 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1202,6 +1202,10 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_SGBRG10P: descr = "10-bit Bayer GBGB/RGRG 
Packed"; break;
case V4L2_PIX_FMT_SGRBG10P: descr = "10-bit Bayer GRGR/BGBG 
Packed"; break;
case V4L2_PIX_FMT_SRGGB10P: descr = "10-bit Bayer RGRG/GBGB 
Packed"; break;
+   case V4L2_PIX_FMT_IPU3_SBGGR10: descr = "10-bit bayer BGGR IPU3 
Packed"; break;
+   case V4L2_PIX_FMT_IPU3_SGBRG10: descr = "10-bit bayer GBRG IPU3 
Packed"; break;
+   case V4L2_PIX_FMT_IPU3_SGRBG10: descr = "10-bit bayer GRBG IPU3 
Packed"; break;
+   case V4L2_PIX_FMT_IPU3_SRGGB10: descr = "10-bit bayer RGGB IPU3 
Packed"; break;
case V4L2_PIX_FMT_SBGGR10ALAW8: descr = "8-bit Bayer BGBG/GRGR 
(A-law)"; break;
case V4L2_PIX_FMT_SGBRG10ALAW8: descr = "8-bit Bayer GBGB/RGRG 
(A-law)"; break;
case V4L2_PIX_FMT_SGRBG10ALAW8: descr = "8-bit Bayer GRGR/BGBG 
(A-law)"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 2b8feb8..7bfa6ad 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -663,6 +663,11 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_MT21Cv4l2_fourcc('M', 'T', '2', '1') /* Mediatek 
compressed block mode  */
 #define V4L2_PIX_FMT_INZI v4l2_fourcc('I', 'N', 'Z', 'I') /* Intel Planar 
Greyscale 10-bit and Depth 16-bit */
 
+#define V4L2_PIX_FMT_IPU3_SBGGR10  v4l2_fourcc('i', 'p', '3', 'b') /* IPU3 
packed 10-bit BGGR bayer */
+#define V4L2_PIX_FMT_IPU3_SGBRG10  v4l2_fourcc('i', 'p', '3', 'g') /* IPU3 
packed 10-bit GBRG bayer */
+#define V4L2_PIX_FMT_IPU3_SGRBG10  v4l2_fourcc('i', 'p', '3', 'G') /* IPU3 
packed 10-bit GRBG bayer */
+#define V4L2_PIX_FMT_IPU3_SRGGB10  v4l2_fourcc('i', 'p', '3', 'r') /* IPU3 
packed 10-bit RGGB bayer */
+
 /* SDR formats - used only for Software Defined Radio devices */
 #define V4L2_SDR_FMT_CU8  v4l2_fourcc('C', 'U', '0', '8') /* IQ u8 */
 #define V4L2_SDR_FMT_CU16LE   v4l2_fourcc('C', 'U', '1', '6') /* IQ u16le 
*/
-- 
2.7.4

[PATCH v2 3/3] [media] intel-ipu3: cio2: Add new MIPI-CSI2 driver

[Yong Zhi]

This patch adds CIO2 CSI-2 device driver for
Intel's IPU3 camera sub-system support.

Signed-off-by: Yong Zhi 
---
 drivers/media/pci/Kconfig|2 +
 drivers/media/pci/Makefile   |3 +-
 drivers/media/pci/intel/Makefile |5 +
 drivers/media/pci/intel/ipu3/Kconfig |   17 +
 drivers/media/pci/intel/ipu3/Makefile|1 +
 drivers/media/pci/intel/ipu3/ipu3-cio2.c | 1788 ++
 drivers/media/pci/intel/ipu3/ipu3-cio2.h |  424 +++
 7 files changed, 2239 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/pci/intel/Makefile
 create mode 100644 drivers/media/pci/intel/ipu3/Kconfig
 create mode 100644 drivers/media/pci/intel/ipu3/Makefile
 create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.c
 create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.h

diff --git a/drivers/media/pci/Kconfig b/drivers/media/pci/Kconfig
index da28e68..5932e22 100644
--- a/drivers/media/pci/Kconfig
+++ b/drivers/media/pci/Kconfig
@@ -54,5 +54,7 @@ source "drivers/media/pci/smipcie/Kconfig"
 source "drivers/media/pci/netup_unidvb/Kconfig"
 endif
 
+source "drivers/media/pci/intel/ipu3/Kconfig"
+
 endif #MEDIA_PCI_SUPPORT
 endif #PCI
diff --git a/drivers/media/pci/Makefile b/drivers/media/pci/Makefile
index a7e8af0..d8f9843 100644
--- a/drivers/media/pci/Makefile
+++ b/drivers/media/pci/Makefile
@@ -13,7 +13,8 @@ obj-y+=   ttpci/  \
ddbridge/   \
saa7146/\
smipcie/\
-   netup_unidvb/
+   netup_unidvb/   \
+   intel/
 
 obj-$(CONFIG_VIDEO_IVTV) += ivtv/
 obj-$(CONFIG_VIDEO_ZORAN) += zoran/
diff --git a/drivers/media/pci/intel/Makefile b/drivers/media/pci/intel/Makefile
new file mode 100644
index 000..745c8b2
--- /dev/null
+++ b/drivers/media/pci/intel/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the IPU3 cio2 and ImGU drivers
+#
+
+obj-y  += ipu3/
diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
b/drivers/media/pci/intel/ipu3/Kconfig
new file mode 100644
index 000..2a895d6
--- /dev/null
+++ b/drivers/media/pci/intel/ipu3/Kconfig
@@ -0,0 +1,17 @@
+config VIDEO_IPU3_CIO2
+   tristate "Intel ipu3-cio2 driver"
+   depends on VIDEO_V4L2 && PCI
+   depends on MEDIA_CONTROLLER
+   depends on HAS_DMA
+   depends on ACPI
+   select V4L2_FWNODE
+   select VIDEOBUF2_DMA_SG
+
+   ---help---
+   This is the Intel IPU3 CIO2 CSI-2 receiver unit, found in Intel
+   Skylake and Kaby Lake SoCs and used for capturing images and
+   video from a camera sensor.
+
+   Say Y or M here if you have a Skylake/Kaby Lake SoC with MIPI CSI-2
+   connected camera.
+   The module will be called ipu3-cio2.
diff --git a/drivers/media/pci/intel/ipu3/Makefile 
b/drivers/media/pci/intel/ipu3/Makefile
new file mode 100644
index 000..20186e3
--- /dev/null
+++ b/drivers/media/pci/intel/ipu3/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c 
b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
new file mode 100644
index 000..69c47fc
--- /dev/null
+++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
@@ -0,0 +1,1788 @@
+/*
+ * Copyright (c) 2017 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Based partially on Intel IPU4 driver written by
+ *  Sakari Ailus 
+ *  Samu Onkalo 
+ *  Jouni Högander 
+ *  Jouni Ukkonen 
+ *  Antti Laakso 
+ * et al.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ipu3-cio2.h"
+
+/*
+ * These are raw formats used in Intel's third generation of
+ * Image Processing Unit known as IPU3.
+ * 10bit raw bayer packed, 32 bytes for every 25 pixels,
+ * last LSB 6 bits unused.
+ */
+static const u32 cio2_csi2_fmts[] = {
+   V4L2_PIX_FMT_IPU3_SRGGB10,
+   V4L2_PIX_FMT_IPU3_SGBRG10,
+   V4L2_PIX_FMT_IPU3_SGRBG10,
+   V4L2_PIX_FMT_IPU3_SBGGR10,
+};
+
+static inline u32 cio2_bytesperline(const unsigned int width)
+{
+   /*
+* 64 bytes for every 50 pixels, the line length
+* in bytes is multiple of 64 (line end alignment).
+*/
+   return DIV_ROUND_UP(width, 50) * 64;
+}
+
+/ FBPT operations /
+
+static void cio2_fbpt_exit_dummy(struct cio2_device *cio2)
+{
+   

Re: [PATCH] [media] imx: switch from V4L2 OF to V4L2 fwnode API

[Steve Longerbeam]

Hi Philipp,

v4l2_fwnode patch has been merged to mediatree, so I've applied this
to my imx-media-staging-md-v16 branch, thanks for the patch!

However before I can submit version 8 of the patchset, the video-mux
driver also needs conversion. Can you submit a version 8 of your
video-mux patchset (your last was v7) containing the switch to
v4l2-fwnode, and I will incorporate into the imx-media v8 patchset.

Thanks!
Steve


On 05/04/2017 06:37 AM, Philipp Zabel wrote:

Switch from the v4l2_of_ APIs to the v4l2_fwnode_ APIs so this driver
can work if the patch "v4l: Switch from V4L2 OF not V4L2 fwnode API"
is applied before it. Tested against
https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-acpi-merge

Signed-off-by: Philipp Zabel 
---
  drivers/staging/media/imx/imx-media-capture.c |  2 +-
  drivers/staging/media/imx/imx-media-csi.c | 10 +-
  drivers/staging/media/imx/imx-media-dev.c | 19 ++-
  drivers/staging/media/imx/imx-media-fim.c |  1 -
  drivers/staging/media/imx/imx-media-of.c  |  6 --
  drivers/staging/media/imx/imx-media.h |  4 ++--
  drivers/staging/media/imx/imx6-mipi-csi2.c|  9 +
  7 files changed, 27 insertions(+), 24 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-capture.c 
b/drivers/staging/media/imx/imx-media-capture.c
index 8b28dbc21566c..ddab4c249da25 100644
--- a/drivers/staging/media/imx/imx-media-capture.c
+++ b/drivers/staging/media/imx/imx-media-capture.c
@@ -21,8 +21,8 @@
  #include 
  #include 
  #include 
+#include 
  #include 
-#include 
  #include 
  #include 
  #include 
diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 447c597111852..fdf90dc7d212e 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -17,8 +17,8 @@
  #include 
  #include 
  #include 
+#include 
  #include 
-#include 
  #include 
  #include 
  #include 
@@ -307,7 +307,7 @@ static void csi_idmac_unsetup_vb2_buf(struct csi_priv *priv,
  static int csi_idmac_setup_channel(struct csi_priv *priv)
  {
struct imx_media_video_dev *vdev = priv->vdev;
-   struct v4l2_of_endpoint *sensor_ep;
+   struct v4l2_fwnode_endpoint *sensor_ep;
struct v4l2_mbus_framefmt *infmt;
struct ipu_image image;
u32 passthrough_bits;
@@ -557,7 +557,7 @@ static int csi_setup(struct csi_priv *priv)
  {
struct v4l2_mbus_framefmt *infmt, *outfmt;
struct v4l2_mbus_config sensor_mbus_cfg;
-   struct v4l2_of_endpoint *sensor_ep;
+   struct v4l2_fwnode_endpoint *sensor_ep;
struct v4l2_mbus_framefmt if_fmt;
const struct csi_skip_desc *skip;
  
@@ -957,7 +957,7 @@ static int csi_link_validate(struct v4l2_subdev *sd,

  {
struct csi_priv *priv = v4l2_get_subdevdata(sd);
const struct imx_media_pixfmt *incc;
-   struct v4l2_of_endpoint *sensor_ep;
+   struct v4l2_fwnode_endpoint *sensor_ep;
struct imx_media_subdev *sensor;
bool is_csi2;
int ret;
@@ -1066,7 +1066,7 @@ static void csi_try_crop(struct csi_priv *priv,
 struct v4l2_mbus_framefmt *infmt,
 struct imx_media_subdev *sensor)
  {
-   struct v4l2_of_endpoint *sensor_ep;
+   struct v4l2_fwnode_endpoint *sensor_ep;
  
  	sensor_ep = >sensor_ep;
  
diff --git a/drivers/staging/media/imx/imx-media-dev.c b/drivers/staging/media/imx/imx-media-dev.c

index d149d2f222f10..488c4d24783d9 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -40,14 +40,15 @@ imx_media_find_async_subdev(struct imx_media_dev *imxmd,
struct device_node *np,
const char *devname)
  {
+   struct fwnode_handle *fwnode = np ? of_fwnode_handle(np) : NULL;
struct imx_media_subdev *imxsd;
int i;
  
  	for (i = 0; i < imxmd->subdev_notifier.num_subdevs; i++) {

imxsd = >subdev[i];
switch (imxsd->asd.match_type) {
-   case V4L2_ASYNC_MATCH_OF:
-   if (np && imxsd->asd.match.of.node == np)
+   case V4L2_ASYNC_MATCH_FWNODE:
+   if (fwnode && imxsd->asd.match.fwnode.fwnode == fwnode)
return imxsd;
break;
case V4L2_ASYNC_MATCH_DEVNAME:
@@ -65,8 +66,8 @@ imx_media_find_async_subdev(struct imx_media_dev *imxmd,
  
  /*

   * Adds a subdev to the async subdev list. If np is non-NULL, adds
- * the async as a V4L2_ASYNC_MATCH_OF match type, otherwise as a
- * V4L2_ASYNC_MATCH_DEVNAME match type using the dev_name of the
+ * the async as a V4L2_ASYNC_MATCH_FWNODE match type, otherwise as
+ * a V4L2_ASYNC_MATCH_DEVNAME match type using the dev_name of the
   * given platform_device. This is called during driver load when
   * forming the async subdev list.
   */

Re: [PATCH 0/4] [media] davinci: vpif_capture: raw camera support

[Kevin Hilman]

On Tue, Jun 6, 2017 at 1:34 PM, Hans Verkuil  wrote:
> Hi Kevin,
>
> On 02/06/17 23:34, Kevin Hilman wrote:
>> This series fixes/updates the support for raw camera input to the VPIF.
>>
>> Tested on da850-evm boards using the add-on UI board.  Tested with
>> both composite video input (on-board tvp514x) and raw camera input
>> using the camera board from On-Semi based on the aptina,mt9v032
>> sensor[1], as this was the only camera board with the right connector
>> for the da850-evm UI board.
>>
>> Verified that composite video capture is still working well after these
>> updates.
>
> Can you rebase this patch series against the latest media master branch?
>
> Mauro merged a lot of patches, in particular the one switching v4l2_of_ to
> v4l2_fwnode_. And that conflicts with patches 2 and 4.

Rebased and resent as v2.

Kevin

[PATCH v2 4/4] [media] davinci: vpif: adaptions for DT support

[Kevin Hilman]

The davinci VPIF is a single hardware block, but the existing driver
is broken up into a common library (vpif.c), output (vpif_display.c) and
intput (vpif_capture.c).

When migrating to DT, to better model the hardware, and because
registers, interrupts, etc. are all common,it was decided to
have a single VPIF hardware node[1].

Because davinci uses legacy, non-DT boot on several SoCs still, the
platform_drivers need to remain.  But they are also needed in DT boot.
Since there are no DT nodes for the display/capture parts in DT
boot (there is a single node for the parent/common device) we need to
create platform_devices somewhere to instansiate the platform_drivers.

When VPIF display/capture are needed for a DT boot, the VPIF node
will have endpoints defined for its subdevs.  Therefore, vpif_probe()
checks for the presence of endpoints, and if detected manually creates
the platform_devices for the display and capture platform_drivers.

[1] Documentation/devicetree/bindings/media/ti,da850-vpif.txt

Signed-off-by: Kevin Hilman 
---
 drivers/media/platform/davinci/vpif.c | 49 ++-
 1 file changed, 48 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/davinci/vpif.c 
b/drivers/media/platform/davinci/vpif.c
index 1b02a6363f77..502917abcb13 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "vpif.h"
 
@@ -423,7 +424,9 @@ EXPORT_SYMBOL(vpif_channel_getfid);
 
 static int vpif_probe(struct platform_device *pdev)
 {
-   static struct resource  *res;
+   static struct resource  *res, *res_irq;
+   struct platform_device *pdev_capture, *pdev_display;
+   struct device_node *endpoint = NULL;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
vpif_base = devm_ioremap_resource(>dev, res);
@@ -435,6 +438,50 @@ static int vpif_probe(struct platform_device *pdev)
 
spin_lock_init(_lock);
dev_info(>dev, "vpif probe success\n");
+
+   /*
+* If VPIF Node has endpoints, assume "new" DT support,
+* where capture and display drivers don't have DT nodes
+* so their devices need to be registered manually here
+* for their legacy platform_drivers to work.
+*/
+   endpoint = of_graph_get_next_endpoint(pdev->dev.of_node,
+ endpoint);
+   if (!endpoint) 
+   return 0;
+
+   /*
+* For DT platforms, manually create platform_devices for
+* capture/display drivers.
+*/
+   res_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+   if (!res_irq) {
+   dev_warn(>dev, "Missing IRQ resource.\n");
+   return -EINVAL;
+   }
+
+   pdev_capture = devm_kzalloc(>dev, sizeof(*pdev_capture),
+   GFP_KERNEL);
+   pdev_capture->name = "vpif_capture";
+   pdev_capture->id = -1;
+   pdev_capture->resource = res_irq;
+   pdev_capture->num_resources = 1;
+   pdev_capture->dev.dma_mask = pdev->dev.dma_mask;
+   pdev_capture->dev.coherent_dma_mask = pdev->dev.coherent_dma_mask;
+   pdev_capture->dev.parent = >dev;
+   platform_device_register(pdev_capture);
+
+   pdev_display = devm_kzalloc(>dev, sizeof(*pdev_display),
+   GFP_KERNEL);
+   pdev_display->name = "vpif_display";
+   pdev_display->id = -1;
+   pdev_display->resource = res_irq;
+   pdev_display->num_resources = 1;
+   pdev_display->dev.dma_mask = pdev->dev.dma_mask;
+   pdev_display->dev.coherent_dma_mask = pdev->dev.coherent_dma_mask;
+   pdev_display->dev.parent = >dev;
+   platform_device_register(pdev_display);
+
return 0;
 }
 
-- 
2.9.3

[PATCH v2 3/4] [media] davinci: vpif_capture: cleanup raw camera support

[Kevin Hilman]

The current driver has a handful of hard-coded assumptions based on its
primary use for capture of video signals.  Cleanup those assumptions,
and also query the subdev for format information and use that if
available.

Tested with 10-bit raw bayer input (SGRBG10) using the aptina,mt9v032
sensor, and also tested that composite video input still works from
ti,tvp514x decoder.  Both tests done on the da850-evm board with the
add-on UI board.

NOTE: Will need further testing for other sensors with different bus
formats.

Signed-off-by: Kevin Hilman 
---
 drivers/media/platform/davinci/vpif_capture.c | 82 ++-
 1 file changed, 80 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/davinci/vpif_capture.c 
b/drivers/media/platform/davinci/vpif_capture.c
index b9d927d1e5a8..67624dbf1272 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -24,6 +24,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#include 
 
 #include "vpif.h"
 #include "vpif_capture.h"
@@ -387,7 +390,8 @@ static irqreturn_t vpif_channel_isr(int irq, void *dev_id)
common = >common[i];
/* skip If streaming is not started in this channel */
/* Check the field format */
-   if (1 == ch->vpifparams.std_info.frm_fmt) {
+   if (1 == ch->vpifparams.std_info.frm_fmt ||
+   common->fmt.fmt.pix.field == V4L2_FIELD_NONE) {
/* Progressive mode */
spin_lock(>irqlock);
if (list_empty(>dma_queue)) {
@@ -468,9 +472,38 @@ static int vpif_update_std_info(struct channel_obj *ch)
struct vpif_channel_config_params *std_info = >std_info;
struct video_obj *vid_ch = >video;
int index;
+   struct v4l2_pix_format *pixfmt = >fmt.fmt.pix;
 
vpif_dbg(2, debug, "vpif_update_std_info\n");
 
+   /*
+* if called after try_fmt or g_fmt, there will already be a size
+* so use that by default.
+*/
+   if (pixfmt->width && pixfmt->height) {
+   if (pixfmt->field == V4L2_FIELD_ANY ||
+   pixfmt->field == V4L2_FIELD_NONE)
+   pixfmt->field = V4L2_FIELD_NONE;
+   
+   vpifparams->iface.if_type = VPIF_IF_BT656;
+   if (pixfmt->pixelformat == V4L2_PIX_FMT_SGRBG10 ||
+   pixfmt->pixelformat == V4L2_PIX_FMT_SBGGR8)
+   vpifparams->iface.if_type = VPIF_IF_RAW_BAYER;
+
+   if (pixfmt->pixelformat == V4L2_PIX_FMT_SGRBG10)
+   vpifparams->params.data_sz = 1; /* 10 bits/pixel.  */
+
+   /* 
+* For raw formats from camera sensors, we don't need 
+* the std_info from table lookup, so nothing else to do here.
+*/
+   if (vpifparams->iface.if_type == VPIF_IF_RAW_BAYER) {
+   memset(std_info, 0, sizeof(struct 
vpif_channel_config_params));
+   vpifparams->std_info.capture_format = 1; /* CCD/raw 
mode */
+   return 0;
+   }
+   }
+
for (index = 0; index < vpif_ch_params_count; index++) {
config = _ch_params[index];
if (config->hd_sd == 0) {
@@ -939,6 +972,7 @@ static int vpif_try_fmt_vid_cap(struct file *file, void 
*priv,
struct v4l2_pix_format *pixfmt = >fmt.pix;
struct common_obj *common = &(ch->common[VPIF_VIDEO_INDEX]);
 
+   common->fmt = *fmt;
vpif_update_std_info(ch);
 
pixfmt->field = common->fmt.fmt.pix.field;
@@ -947,8 +981,17 @@ static int vpif_try_fmt_vid_cap(struct file *file, void 
*priv,
pixfmt->width = common->fmt.fmt.pix.width;
pixfmt->height = common->fmt.fmt.pix.height;
pixfmt->sizeimage = pixfmt->bytesperline * pixfmt->height * 2;
+   if (pixfmt->pixelformat == V4L2_PIX_FMT_SGRBG10) {
+   pixfmt->bytesperline = common->fmt.fmt.pix.width * 2;
+   pixfmt->sizeimage = pixfmt->bytesperline * pixfmt->height;
+   }
pixfmt->priv = 0;
 
+   dev_dbg(vpif_dev, "%s: %d x %d; pitch=%d pixelformat=0x%08x, field=%d, 
size=%d\n", __func__,
+   pixfmt->width, pixfmt->height,
+   pixfmt->bytesperline, pixfmt->pixelformat,
+   pixfmt->field, pixfmt->sizeimage);
+
return 0;
 }
 
@@ -965,13 +1008,47 @@ static int vpif_g_fmt_vid_cap(struct file *file, void 
*priv,
struct video_device *vdev = video_devdata(file);
struct channel_obj *ch = video_get_drvdata(vdev);
struct common_obj *common = >common[VPIF_VIDEO_INDEX];
+   struct v4l2_pix_format *pix_fmt = >fmt.pix;
+   struct v4l2_subdev_format format = {
+   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   };
+   struct v4l2_mbus_framefmt *mbus_fmt = 
+   int ret;
 
/* Check 

[PATCH v2 0/4] [media] davinci: vpif_capture: raw camera support

[Kevin Hilman]

Same as v1, just rebased onto master branch of media tree, as
requested by Hans.

This series fixes/updates the support for raw camera input to the VPIF.

Tested on da850-evm boards using the add-on UI board.  Tested with
both composite video input (on-board tvp514x) and raw camera input
using the camera board from On-Semi based on the aptina,mt9v032
sensor[1], as this was the only camera board with the right connector
for the da850-evm UI board.

Verified that composite video capture is still working well after these
updates.

[1] 
http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeyMT9V032C12STCH-GEVB

Kevin Hilman (4):
  [media] davinci: vpif_capture: drop compliance hack
  [media] davinci: vpif_capture: get subdevs from DT when available
  [media] davinci: vpif_capture: cleanup raw camera support
  [media] davinci: vpif: adaptions for DT support

 drivers/media/platform/davinci/vpif.c |  49 +-
 drivers/media/platform/davinci/vpif_capture.c | 223 +++---
 drivers/media/platform/davinci/vpif_display.c |   5 +
 include/media/davinci/vpif_types.h|   9 +-
 4 files changed, 262 insertions(+), 24 deletions(-)

-- 
2.9.3

[PATCH v2 2/4] [media] davinci: vpif_capture: get subdevs from DT when available

[Kevin Hilman]

Enable  getting of subdevs from DT ports and endpoints.

The _get_pdata() function was larely inspired by (i.e. stolen from)
am437x-vpfe.c

Signed-off-by: Kevin Hilman 
---
 drivers/media/platform/davinci/vpif_capture.c | 126 +-
 drivers/media/platform/davinci/vpif_display.c |   5 +
 include/media/davinci/vpif_types.h|   9 +-
 3 files changed, 134 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/davinci/vpif_capture.c 
b/drivers/media/platform/davinci/vpif_capture.c
index fc5c7622660c..b9d927d1e5a8 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -22,6 +22,8 @@
 #include 
 
 #include 
+#include 
+#include 
 
 #include "vpif.h"
 #include "vpif_capture.h"
@@ -655,7 +657,7 @@ static int vpif_input_to_subdev(
/* loop through the sub device list to get the sub device info */
for (i = 0; i < vpif_cfg->subdev_count; i++) {
subdev_info = _cfg->subdev_info[i];
-   if (!strcmp(subdev_info->name, subdev_name))
+   if (subdev_info && !strcmp(subdev_info->name, subdev_name))
return i;
}
return -1;
@@ -1308,6 +1310,21 @@ static int vpif_async_bound(struct v4l2_async_notifier 
*notifier,
 {
int i;
 
+   for (i = 0; i < vpif_obj.config->asd_sizes[0]; i++) {
+   struct v4l2_async_subdev *_asd = vpif_obj.config->asd[i];
+   const struct device_node *node = _asd->match.of.node;
+
+   if (node == subdev->of_node) {
+   vpif_obj.sd[i] = subdev;
+   vpif_obj.config->chan_config->inputs[i].subdev_name =
+   (char *)subdev->of_node->full_name;
+   vpif_dbg(2, debug,
+"%s: setting input %d subdev_name = %s\n",
+__func__, i, subdev->of_node->full_name);
+   return 0;
+   }
+   }
+
for (i = 0; i < vpif_obj.config->subdev_count; i++)
if (!strcmp(vpif_obj.config->subdev_info[i].name,
subdev->name)) {
@@ -1403,6 +1420,105 @@ static int vpif_async_complete(struct 
v4l2_async_notifier *notifier)
return vpif_probe_complete();
 }
 
+static struct vpif_capture_config *
+vpif_capture_get_pdata(struct platform_device *pdev)
+{
+   struct device_node *endpoint = NULL;
+   struct v4l2_of_endpoint bus_cfg;
+   struct vpif_capture_config *pdata;
+   struct vpif_subdev_info *sdinfo;
+   struct vpif_capture_chan_config *chan;
+   unsigned int i;
+
+   /*
+* DT boot: OF node from parent device contains
+* video ports & endpoints data.
+*/
+   if (pdev->dev.parent && pdev->dev.parent->of_node)
+   pdev->dev.of_node = pdev->dev.parent->of_node;
+   if (!IS_ENABLED(CONFIG_OF) || !pdev->dev.of_node)
+   return pdev->dev.platform_data;
+
+   pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return NULL;
+   pdata->subdev_info =
+   devm_kzalloc(>dev, sizeof(*pdata->subdev_info) *
+VPIF_CAPTURE_NUM_CHANNELS, GFP_KERNEL);
+
+   if (!pdata->subdev_info)
+   return NULL;
+
+   for (i = 0; i < VPIF_CAPTURE_NUM_CHANNELS; i++) {
+   struct device_node *rem;
+   unsigned int flags;
+   int err;
+
+   endpoint = of_graph_get_next_endpoint(pdev->dev.of_node,
+ endpoint);
+   if (!endpoint)
+   break;
+
+   sdinfo = >subdev_info[i];
+   chan = >chan_config[i];
+   chan->inputs = devm_kzalloc(>dev,
+   sizeof(*chan->inputs) *
+   VPIF_CAPTURE_NUM_CHANNELS,
+   GFP_KERNEL);
+
+   chan->input_count++;
+   chan->inputs[i].input.type = V4L2_INPUT_TYPE_CAMERA;
+   chan->inputs[i].input.std = V4L2_STD_ALL;
+   chan->inputs[i].input.capabilities = V4L2_IN_CAP_STD;
+
+   err = v4l2_of_parse_endpoint(endpoint, _cfg);
+   if (err) {
+   dev_err(>dev, "Could not parse the endpoint\n");
+   goto done;
+   }
+   dev_dbg(>dev, "Endpoint %s, bus_width = %d\n",
+   endpoint->full_name, bus_cfg.bus.parallel.bus_width);
+   flags = bus_cfg.bus.parallel.flags;
+
+   if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
+   chan->vpif_if.hd_pol = 1;
+
+   if (flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
+   chan->vpif_if.vd_pol = 1;
+
+   rem = 

[PATCH v2 1/4] [media] davinci: vpif_capture: drop compliance hack

[Kevin Hilman]

Capture driver silently overrides pixel format with a hack (according to
the comments) to pass v4l2 compliance tests.  This isn't needed for
normal functionality, and works for composite video and raw camera capture
without.

In addition, the hack assumes that it only supports raw capture with a
single format (SBGGR8) which isn't true.  VPIF can also capture 10- and
12-bit raw formats as well.  Forthcoming patches will enable VPIF
input with raw-camera support and has been tested with 10-bit format
from the aptina,mt9v032 sensor.

Any compliance failures should be fixed with a real fix.

Signed-off-by: Kevin Hilman 
---
 drivers/media/platform/davinci/vpif_capture.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/drivers/media/platform/davinci/vpif_capture.c 
b/drivers/media/platform/davinci/vpif_capture.c
index 128e92d1dd5a..fc5c7622660c 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -936,21 +936,6 @@ static int vpif_try_fmt_vid_cap(struct file *file, void 
*priv,
struct channel_obj *ch = video_get_drvdata(vdev);
struct v4l2_pix_format *pixfmt = >fmt.pix;
struct common_obj *common = &(ch->common[VPIF_VIDEO_INDEX]);
-   struct vpif_params *vpif_params = >vpifparams;
-
-   /*
-* to supress v4l-compliance warnings silently correct
-* the pixelformat
-*/
-   if (vpif_params->iface.if_type == VPIF_IF_RAW_BAYER) {
-   if (pixfmt->pixelformat != V4L2_PIX_FMT_SBGGR8)
-   pixfmt->pixelformat = V4L2_PIX_FMT_SBGGR8;
-   } else {
-   if (pixfmt->pixelformat != V4L2_PIX_FMT_NV16)
-   pixfmt->pixelformat = V4L2_PIX_FMT_NV16;
-   }
-
-   common->fmt.fmt.pix.pixelformat = pixfmt->pixelformat;
 
vpif_update_std_info(ch);
 
-- 
2.9.3

Re: [RFC PATCH] [media] v4l2-subdev: check colorimetry in link validate

[Helen Koike]

Hi Sakari,


Thanks for replying

On 2017-05-31 03:31 AM, Sakari Ailus wrote:

Hi Helen,

On Tue, May 30, 2017 at 04:08:08PM -0300, Helen Koike wrote:

colorspace, ycbcr_enc, quantization and xfer_func must match across the
link.
Check if they match in v4l2_subdev_link_validate_default unless they are
set as _DEFAULT.

Signed-off-by: Helen Koike 

---

Hi,

I think we should validate colorimetry as having different colorimetry
across a link doesn't make sense.
But I am confused about what to do when they are set to _DEFAULT, what
do you think?


These fields were added at various points over the course of the past three
years or so. User space code that was written before that will certainly not
set anything and I'm not sure many drivers care about these fields nor they
are relevant for many formats. In practice that means that they are very
likely zero in many cases.


If they are set to zero then they won't be affected by this patch.



Driver changes will probably be necessary for removing the explicit checks
for the default value.


At least in the drivers/media tree I couldn't find many drivers that 
implement its own link_validate, there is only 
platform/omap3isp/ispccdc.c and platform/omap3isp/ispresizer.c that 
implements a custom value, but from a quick look it doesn't seems that 
they will be affected.




The same applies to checking the colour space: drivers should enforce using
the correct colour space before the check can be merged. I might move that
to a separate patch.


I am not sure if I got what you mean. If driver don't care about 
colourspace then probably it will be set to zero and won't be affected 
by this patch, if colourspace is different across the link then the user 
space must set both ends to the same colourspace.






Thanks
---
 drivers/media/v4l2-core/v4l2-subdev.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-subdev.c 
b/drivers/media/v4l2-core/v4l2-subdev.c
index da78497..784ae92 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -502,10 +502,27 @@ int v4l2_subdev_link_validate_default(struct v4l2_subdev 
*sd,
  struct v4l2_subdev_format *source_fmt,
  struct v4l2_subdev_format *sink_fmt)
 {
-   /* The width, height and code must match. */
+   /* The width, height, code and colorspace must match. */
if (source_fmt->format.width != sink_fmt->format.width
|| source_fmt->format.height != sink_fmt->format.height
-   || source_fmt->format.code != sink_fmt->format.code)
+   || source_fmt->format.code != sink_fmt->format.code
+   || source_fmt->format.colorspace != sink_fmt->format.colorspace)
+   return -EPIPE;
+
+   /* Colorimetry must match if they are not set to DEFAULT */
+   if (source_fmt->format.ycbcr_enc != V4L2_YCBCR_ENC_DEFAULT
+   && sink_fmt->format.ycbcr_enc != V4L2_YCBCR_ENC_DEFAULT
+   && source_fmt->format.ycbcr_enc != sink_fmt->format.ycbcr_enc)
+   return -EPIPE;
+
+   if (source_fmt->format.quantization != V4L2_QUANTIZATION_DEFAULT
+   && sink_fmt->format.quantization != V4L2_QUANTIZATION_DEFAULT
+   && source_fmt->format.quantization != sink_fmt->format.quantization)
+   return -EPIPE;
+
+   if (source_fmt->format.xfer_func != V4L2_XFER_FUNC_DEFAULT
+   && sink_fmt->format.xfer_func != V4L2_XFER_FUNC_DEFAULT
+   && source_fmt->format.xfer_func != sink_fmt->format.xfer_func)
return -EPIPE;

/* The field order must match, or the sink field order must be NONE




LN

Re: [PATCH] [media] rc-core: simplify ir_raw_event_store_edge()

[Sean Young]

On Sun, May 28, 2017 at 05:49:27PM +0100, Sean Young wrote:
> There is no need to called ir_raw_event_reset() either after a long
> space or on startup. Many rc drivers never do this.
> 
> Signed-off-by: Sean Young 
> ---
>  drivers/media/pci/saa7134/saa7134-input.c |  2 +-
>  drivers/media/rc/gpio-ir-recv.c   |  6 +++---
>  drivers/media/rc/img-ir/img-ir-raw.c  |  4 ++--
>  drivers/media/rc/rc-core-priv.h   |  1 -
>  drivers/media/rc/rc-ir-raw.c  | 31 
> +--
>  include/media/rc-core.h   |  9 +
>  6 files changed, 12 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/media/pci/saa7134/saa7134-input.c 
> b/drivers/media/pci/saa7134/saa7134-input.c
> index 78849c1..8784bc8 100644
> --- a/drivers/media/pci/saa7134/saa7134-input.c
> +++ b/drivers/media/pci/saa7134/saa7134-input.c
> @@ -1064,7 +1064,7 @@ static int saa7134_raw_decode_irq(struct saa7134_dev 
> *dev)
>   saa_clearb(SAA7134_GPIO_GPMODE3, SAA7134_GPIO_GPRESCAN);
>   saa_setb(SAA7134_GPIO_GPMODE3, SAA7134_GPIO_GPRESCAN);
>   space = saa_readl(SAA7134_GPIO_GPSTATUS0 >> 2) & ir->mask_keydown;
> - ir_raw_event_store_edge(dev->remote->dev, space ? IR_SPACE : IR_PULSE);
> + ir_raw_event_store_edge(dev->remote->dev, !space);
>  
>   /*
>* Wait 15 ms from the start of the first IR event before processing
> diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
> index b4f773b..09889d0 100644
> --- a/drivers/media/rc/gpio-ir-recv.c
> +++ b/drivers/media/rc/gpio-ir-recv.c
> @@ -77,7 +77,7 @@ static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id)
>   struct gpio_rc_dev *gpio_dev = dev_id;
>   int gval;
>   int rc = 0;
> - enum raw_event_type type = IR_SPACE;
> + bool pulse = false;
>  
>   gval = gpio_get_value(gpio_dev->gpio_nr);
>  
> @@ -88,9 +88,9 @@ static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id)
>   gval = !gval;
>  
>   if (gval == 1)
> - type = IR_PULSE;
> + pulse = true;
>  
> - rc = ir_raw_event_store_edge(gpio_dev->rcdev, type);
> + rc = ir_raw_event_store_edge(gpio_dev->rcdev, pulse);
>   if (rc < 0)
>   goto err_get_value;
>  
> diff --git a/drivers/media/rc/img-ir/img-ir-raw.c 
> b/drivers/media/rc/img-ir/img-ir-raw.c
> index 8d2f8e2..ddb7fb4 100644
> --- a/drivers/media/rc/img-ir/img-ir-raw.c
> +++ b/drivers/media/rc/img-ir/img-ir-raw.c
> @@ -40,9 +40,9 @@ static void img_ir_refresh_raw(struct img_ir_priv *priv, 
> u32 irq_status)
>  
>   /* report the edge to the IR raw decoders */
>   if (ir_status) /* low */
> - ir_raw_event_store_edge(rc_dev, IR_SPACE);
> + ir_raw_event_store_edge(rc_dev, false);
>   else /* high */
> - ir_raw_event_store_edge(rc_dev, IR_PULSE);
> + ir_raw_event_store_edge(rc_dev, true);
>   ir_raw_event_handle(rc_dev);
>  }
>  
> diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
> index 0455b27..d31ad6a 100644
> --- a/drivers/media/rc/rc-core-priv.h
> +++ b/drivers/media/rc/rc-core-priv.h
> @@ -41,7 +41,6 @@ struct ir_raw_event_ctrl {
>   /* fifo for the pulse/space durations */
>   DECLARE_KFIFO(kfifo, struct ir_raw_event, MAX_IR_EVENT_SIZE);
>   ktime_t last_event; /* when last event 
> occurred */
> - enum raw_event_type last_type;  /* last event type */
>   struct rc_dev   *dev;   /* pointer to the 
> parent rc_dev */
>  
>   /* raw decoder state follows */
> diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
> index 90f66dc..16ef236 100644
> --- a/drivers/media/rc/rc-ir-raw.c
> +++ b/drivers/media/rc/rc-ir-raw.c
> @@ -88,7 +88,7 @@ EXPORT_SYMBOL_GPL(ir_raw_event_store);
>  /**
>   * ir_raw_event_store_edge() - notify raw ir decoders of the start of a 
> pulse/space
>   * @dev: the struct rc_dev device descriptor
> - * @type:the type of the event that has occurred
> + * @pulse:   true for pulse, false for space
>   *
>   * This routine (which may be called from an interrupt context) is used to
>   * store the beginning of an ir pulse or space (or the start/end of ir
> @@ -96,43 +96,22 @@ EXPORT_SYMBOL_GPL(ir_raw_event_store);
>   * hardware which does not provide durations directly but only interrupts
>   * (or similar events) on state change.
>   */
> -int ir_raw_event_store_edge(struct rc_dev *dev, enum raw_event_type type)
> +int ir_raw_event_store_edge(struct rc_dev *dev, bool pulse)
>  {
>   ktime_t now;
> - s64 delta; /* ns */
>   DEFINE_IR_RAW_EVENT(ev);
>   int rc = 0;
> - int delay;
>  
>   if (!dev->raw)
>   return -EINVAL;
>  
>   now = ktime_get();
> - delta = ktime_to_ns(ktime_sub(now, dev->raw->last_event));
> - 

[GIT PULL FOR v4.13] Various RC fixes

[Sean Young]

Hi Mauro,

Some minor fixes that just missed the first pull request, that would be nice
to have in v4.13.

Thank you

Sean

The following changes since commit 9e9e6a78143bbb6cb9cffd29ab48d5f32def4e20:

  [media] Doc*/media/uapi: fix control name (2017-06-06 16:49:46 -0300)

are available in the git repository at:

  git://linuxtv.org/syoung/media_tree.git for-v4.13b

for you to fetch changes up to 8e35a2305e02ee0c8cb3bf971acab9fbe708e384:

  [media] ir-spi: Fix issues with lirc API (2017-06-06 20:55:36 +0100)


Anton Blanchard (1):
  [media] ir-spi: Fix issues with lirc API

Johan Hovold (2):
  [media] mceusb: fix memory leaks in error path
  [media] mceusb: drop redundant urb reinitialisation

Sean Young (1):
  [media] sir_ir: annotate hardware config module parameters

 drivers/media/rc/ir-spi.c | 9 ++---
 drivers/media/rc/mceusb.c | 5 ++---
 drivers/media/rc/sir_ir.c | 4 ++--
 3 files changed, 10 insertions(+), 8 deletions(-)

Re: [GIT PULL] [PATCH] saa7164: Bug - Double fetch PCIe access condition

[Steven Toth]

> Applied, thanks!

Yay!

>
> Next time, please either send as a patch or use the command:
>
> $ git request-pull
>
> As otherwise I may miss it, as patchwork won't get it.

Will do, thank you.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: [PATCH v3 5/7] docs-rst: media: Sort topic list alphabetically

[Sakari Ailus]

Hi Mauro,

Mauro Carvalho Chehab wrote:

Em Mon, 10 Apr 2017 16:02:54 +0300
Sakari Ailus  escreveu:


Bring some order by alphabetically ordering the list of topics.

Signed-off-by: Sakari Ailus 
---
 Documentation/media/kapi/v4l2-core.rst | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/media/kapi/v4l2-core.rst 
b/Documentation/media/kapi/v4l2-core.rst
index d8f6c46..2fbf532 100644
--- a/Documentation/media/kapi/v4l2-core.rst
+++ b/Documentation/media/kapi/v4l2-core.rst
@@ -4,23 +4,23 @@ Video4Linux devices
 .. toctree::
 :maxdepth: 1

-v4l2-intro


NACK.

The order of the documentation should match what makes sense for the
user that will be reading the docs, and *not* an alphabetical order.


I wrote the patch to address some of the review comments I got over the 
several versions of the patchset. I have no objections to maintaining 
the current order.




I didn't check what order you did, but for sure the introduction should
come first, and then the stuff that all drivers use, like
v4l2-dev, v4l2-device and v4l2-fh. Then, other stuff that it is part of
the framework but are used only by a subset of the drivers.

That's said, it probably makes sense to use multiple toctrees here, and
add some description before each of them, in order to better organize
its contents. Something similar to what it was done with
Documentation/admin-guide/index.rst

I'll rebase patch 6/7 to not depend on this one.


Thanks!

--
Regards,

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

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

[Hans Verkuil]

The following changes since commit 6fb05e0dd32e566facb96ea61a48c7488daa5ac3:

  [media] saa7164: fix double fetch PCIe access condition (2017-06-06 16:55:50 
-0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.13c

for you to fetch changes up to 44cdbd59e84ad2562b760455ac24c7114672ca8f:

  tc358743: Add support for platforms without IRQ line (2017-06-06 22:31:15 
+0200)


Arvind Yadav (1):
  tc358743: Handle return value of clk_prepare_enable

Dave Stevenson (3):
  tc358743: Add enum_mbus_code
  tc358743: Setup default mbus_fmt before registering
  tc358743: Add support for platforms without IRQ line

Hans Verkuil (1):
  cec: improve debug messages

Hugues Fruchet (1):
  atmel-isi: code cleanup

Sakari Ailus (2):
  v4l2-ctrls.c: Implement unlocked variant of v4l2_ctrl_handler_setup()
  v4l2-ctrls: Correctly destroy mutex in v4l2_ctrl_handler_free()

 drivers/media/cec/cec-adap.c | 28 
 drivers/media/i2c/tc358743.c | 65 
+++--
 drivers/media/platform/atmel/atmel-isi.c | 24 ++--
 drivers/media/v4l2-core/v4l2-ctrls.c | 24 +---
 include/media/v4l2-ctrls.h   | 13 +
 5 files changed, 123 insertions(+), 31 deletions(-)

Re: [PATCH 0/4] [media] davinci: vpif_capture: raw camera support

[Hans Verkuil]

Hi Kevin,

On 02/06/17 23:34, Kevin Hilman wrote:
> This series fixes/updates the support for raw camera input to the VPIF.
> 
> Tested on da850-evm boards using the add-on UI board.  Tested with
> both composite video input (on-board tvp514x) and raw camera input
> using the camera board from On-Semi based on the aptina,mt9v032
> sensor[1], as this was the only camera board with the right connector
> for the da850-evm UI board.
> 
> Verified that composite video capture is still working well after these
> updates.

Can you rebase this patch series against the latest media master branch?

Mauro merged a lot of patches, in particular the one switching v4l2_of_ to
v4l2_fwnode_. And that conflicts with patches 2 and 4.

Thanks!

Hans

> 
> [1] 
> http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeyMT9V032C12STCH-GEVB
> 
> Kevin Hilman (4):
>   [media] davinci: vpif_capture: drop compliance hack
>   [media] davinci: vpif_capture: get subdevs from DT when available
>   [media] davinci: vpif_capture: cleanup raw camera support
>   [media] davinci: vpif: adaptions for DT support
> 
>  drivers/media/platform/davinci/vpif.c |  49 +-
>  drivers/media/platform/davinci/vpif_capture.c | 224 
> +++---
>  drivers/media/platform/davinci/vpif_display.c |   5 +
>  include/media/davinci/vpif_types.h|   9 +-
>  4 files changed, 263 insertions(+), 24 deletions(-)
> 

Re: [GIT PULL] [PATCH] saa7164: Bug - Double fetch PCIe access condition

[Mauro Carvalho Chehab]

Em Tue, 6 Jun 2017 09:19:35 -0400
Steven Toth  escreveu:

> Mauro,
> 
> A single commit.
> 
> https://github.com/stoth68000/media-tree/commit/354dd3924a2e43806774953de536257548b5002c
> 
> This pull request addresses the concern raised by Pengfei Wang
>  via
> https://bugzilla.kernel.org/show_bug.cgi?id=195559
> 
> I've tested this patch with two different SAA7164 based cards in both
> analog and digital television modes for US and Europe, no regressions
> were found.
> 
> $ git diff --stat master
>  drivers/media/pci/saa7164/saa7164-bus.c | 13 +
>  1 file changed, 1 insertion(+), 12 deletions(-)

Applied, thanks!

Next time, please either send as a patch or use the command:

$ git request-pull

As otherwise I may miss it, as patchwork won't get it.

Regards,
Mauro

Re: [PATCH RFC 1/2] [media] v4l2: add V4L2_INPUT_TYPE_DEFAULT

[Helen Koike]

Hi All,

Just reviving this discussion

On 2017-04-07 06:53 AM, Laurent Pinchart wrote:

Hi Hans,

On Friday 07 Apr 2017 11:46:48 Hans Verkuil wrote:

On 04/04/2017 03:22 PM, Sakari Ailus wrote:

On Mon, Apr 03, 2017 at 12:11:54PM -0300, Helen Koike wrote:

On 2017-03-31 06:57 AM, Mauro Carvalho Chehab wrote:

Em Fri, 31 Mar 2017 10:29:04 +0200 Hans Verkuil escreveu:

On 30/03/17 18:02, Helen Koike wrote:

Add V4L2_INPUT_TYPE_DEFAULT and helpers functions for input ioctls to
be used when no inputs are available in the device

Signed-off-by: Helen Koike 
---
drivers/media/v4l2-core/v4l2-ioctl.c | 27 +++
include/media/v4l2-ioctl.h   | 26 ++
include/uapi/linux/videodev2.h   |  1 +
3 files changed, 54 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c index 0c3f238..ccaf04b 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2573,6 +2573,33 @@ struct mutex *v4l2_ioctl_get_lock(struct
video_device *vdev, unsigned cmd)
return vdev->lock;
}

+int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
+ struct v4l2_input *i)
+{
+   if (i->index > 0)
+   return -EINVAL;
+
+   memset(i, 0, sizeof(*i));
+   i->type = V4L2_INPUT_TYPE_DEFAULT;
+   strlcpy(i->name, "Default", sizeof(i->name));
+
+   return 0;
+}
+EXPORT_SYMBOL(v4l2_ioctl_enum_input_default);
+
+int v4l2_ioctl_g_input_default(struct file *file, void *priv,
unsigned int *i)
+{
+   *i = 0;
+   return 0;
+}
+EXPORT_SYMBOL(v4l2_ioctl_g_input_default);
+
+int v4l2_ioctl_s_input_default(struct file *file, void *priv,
unsigned int i)
+{
+   return i ? -EINVAL : 0;
+}
+EXPORT_SYMBOL(v4l2_ioctl_s_input_default);
+
/* Common ioctl debug function. This function can be used by
   external ioctl messages as well as internal V4L ioctl */

void v4l_printk_ioctl(const char *prefix, unsigned int cmd)
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index 6cd94e5..accc470 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -652,6 +652,32 @@ struct video_device;
 */

struct mutex *v4l2_ioctl_get_lock(struct video_device *vdev, unsigned
int cmd);
+
+/**
+ * v4l2_ioctl_enum_input_default - v4l2 ioctl helper for
VIDIOC_ENUM_INPUT ioctl
+ *
+ * Plug this function in vidioc_enum_input field of the struct
v4l2_ioctl_ops to
+ * enumerate a single input as V4L2_INPUT_TYPE_DEFAULT
+ */
+int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
+ struct v4l2_input *i);
+
+/**
+ * v4l2_ioctl_g_input_default - v4l2 ioctl helper for VIDIOC_G_INPUT
ioctl
+ *
+ * Plug this function in vidioc_g_input field of the struct
v4l2_ioctl_ops
+ * when using v4l2_ioctl_enum_input_default
+ */
+int v4l2_ioctl_g_input_default(struct file *file, void *priv,
unsigned int *i);
+
+/**
+ * v4l2_ioctl_s_input_default - v4l2 ioctl helper for VIDIOC_S_INPUT
ioctl
+ *
+ * Plug this function in vidioc_s_input field of the struct
v4l2_ioctl_ops
+ * when using v4l2_ioctl_enum_input_default
+ */
+int v4l2_ioctl_s_input_default(struct file *file, void *priv,
unsigned int i);
+
/* names for fancy debug output */
extern const char *v4l2_field_names[];
extern const char *v4l2_type_names[];
diff --git a/include/uapi/linux/videodev2.h
b/include/uapi/linux/videodev2.h index 316be62..c10bbde 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1477,6 +1477,7 @@ struct v4l2_input {
};

/*  Values for the 'type' field */
+#define V4L2_INPUT_TYPE_DEFAULT0


I don't think we should add a new type here.


I second that. Just replied the same thing on a comment from Sakari to
patch 2/2.


The whole point of this exercise is to
allow existing apps to work, and existing apps expect a TYPE_CAMERA.

BTW, don't read to much in the term 'CAMERA': it's really a catch all
for any video stream, whether it is from a sensor, composite input,
HDMI, etc.

The description for V4L2_INPUT_TYPE_CAMERA in the spec is hopelessly
out of date :-(


Yeah, we always used "CAMERA" to mean NOT_TUNER.


Rather than creating a new type I would add a new V4L2_IN_CAP_MC
capability that indicates that this input is controlled via the media
controller. That makes much more sense and it wouldn't potentially
break applications.

Exactly the same can be done for outputs as well: add V4L2_OUT_CAP_MC
and use V4L2_OUTPUT_TYPE_ANALOG as the output type (again, a horrible
outdated name and the spec is again out of date).


I don't see any sense on distinguishing IN and OUT for MC. I mean:
should
we ever allow that any driver to have their inputs controlled via V4L2
API,
and their outputs controlled via MC (or vice-versa)? I don't think so.

Either all device inputs/outputs are controlled via V4L2 or via MC. So,
let's call it just V4L2_CAP_MC.


Regarding the name: 

[PATCH 2/2] [media] coda: copy headers in front of every I-frame

[Philipp Zabel]

That way we don't have to rely on userspace to inject the headers on IDR
requests, and there is always enough information to start decoding at an
I-frame.

Signed-off-by: Philipp Zabel 
---
 drivers/media/platform/coda/coda-bit.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index 22e4630f36711..2ec41375a896f 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -1270,10 +1270,10 @@ static int coda_prepare_encode(struct coda_ctx *ctx)
coda_set_gdi_regs(ctx);
 
/*
-* Copy headers at the beginning of the first frame for H.264 only.
-* In MPEG4 they are already copied by the coda.
+* Copy headers in front of the first frame and forced I frames for
+* H.264 only. In MPEG4 they are already copied by the CODA.
 */
-   if (src_buf->sequence == 0) {
+   if (src_buf->sequence == 0 || force_ipicture) {
pic_stream_buffer_addr =
vb2_dma_contig_plane_dma_addr(_buf->vb2_buf, 0) +
ctx->vpu_header_size[0] +
@@ -1386,7 +1386,8 @@ static void coda_finish_encode(struct coda_ctx *ctx)
wr_ptr = coda_read(dev, CODA_REG_BIT_WR_PTR(ctx->reg_idx));
 
/* Calculate bytesused field */
-   if (dst_buf->sequence == 0) {
+   if (dst_buf->sequence == 0 ||
+   src_buf->flags & V4L2_BUF_FLAG_KEYFRAME) {
vb2_set_plane_payload(_buf->vb2_buf, 0, wr_ptr - start_ptr +
ctx->vpu_header_size[0] +
ctx->vpu_header_size[1] +
-- 
2.11.0

[PATCH 1/2] [media] coda: implement forced key frames

[Philipp Zabel]

Implement the V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME control to force IDR
frames. This is useful to implement VFU (Video Fast Update) on RTP
transmissions.
We already force an IDR frame at the beginning of each GOP to work
around a firmware bug on i.MX27, use the same mechanism to service IDR
requests from userspace.

Signed-off-by: Philipp Zabel 
---
 drivers/media/platform/coda/coda-bit.c| 12 
 drivers/media/platform/coda/coda-common.c |  3 +++
 drivers/media/platform/coda/coda.h|  1 +
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index 403214e00e954..22e4630f36711 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -1247,12 +1247,18 @@ static int coda_prepare_encode(struct coda_ctx *ctx)
dst_buf->sequence = ctx->osequence;
ctx->osequence++;
 
+   force_ipicture = ctx->params.force_ipicture;
+   if (force_ipicture)
+   ctx->params.force_ipicture = false;
+   else if ((src_buf->sequence % ctx->params.gop_size) == 0)
+   force_ipicture = 1;
+
/*
 * Workaround coda firmware BUG that only marks the first
 * frame as IDR. This is a problem for some decoders that can't
 * recover when a frame is lost.
 */
-   if (src_buf->sequence % ctx->params.gop_size) {
+   if (!force_ipicture) {
src_buf->flags |= V4L2_BUF_FLAG_PFRAME;
src_buf->flags &= ~V4L2_BUF_FLAG_KEYFRAME;
} else {
@@ -1291,8 +1297,7 @@ static int coda_prepare_encode(struct coda_ctx *ctx)
pic_stream_buffer_size = q_data_dst->sizeimage;
}
 
-   if (src_buf->flags & V4L2_BUF_FLAG_KEYFRAME) {
-   force_ipicture = 1;
+   if (force_ipicture) {
switch (dst_fourcc) {
case V4L2_PIX_FMT_H264:
quant_param = ctx->params.h264_intra_qp;
@@ -1309,7 +1314,6 @@ static int coda_prepare_encode(struct coda_ctx *ctx)
break;
}
} else {
-   force_ipicture = 0;
switch (dst_fourcc) {
case V4L2_PIX_FMT_H264:
quant_param = ctx->params.h264_inter_qp;
diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index d523e990d5093..f3fe4adf21a7e 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1680,6 +1680,9 @@ static int coda_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB:
ctx->params.intra_refresh = ctrl->val;
break;
+   case V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME:
+   ctx->params.force_ipicture = true;
+   break;
case V4L2_CID_JPEG_COMPRESSION_QUALITY:
coda_set_jpeg_compression_quality(ctx, ctrl->val);
break;
diff --git a/drivers/media/platform/coda/coda.h 
b/drivers/media/platform/coda/coda.h
index 20222befb9b2f..dccb105a1a384 100644
--- a/drivers/media/platform/coda/coda.h
+++ b/drivers/media/platform/coda/coda.h
@@ -135,6 +135,7 @@ struct coda_params {
u32 vbv_size;
u32 slice_max_bits;
u32 slice_max_mb;
+   boolforce_ipicture;
 };
 
 struct coda_buffer_meta {
-- 
2.11.0

[PATCH] [media] sir_ir: annotate hardware config module parameters

[Sean Young]

This module was merged after commit 5a8fc6a3cebb ("Annotate hardware
config module parameters in drivers/media/"), so add add the missing
hardware annotations.

Signed-off-by: Sean Young 
---
 drivers/media/rc/sir_ir.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/sir_ir.c b/drivers/media/rc/sir_ir.c
index 5ee3a23..f8738e5 100644
--- a/drivers/media/rc/sir_ir.c
+++ b/drivers/media/rc/sir_ir.c
@@ -400,10 +400,10 @@ MODULE_DESCRIPTION("Infrared receiver driver for SIR type 
serial ports");
 MODULE_AUTHOR("Milan Pikula");
 MODULE_LICENSE("GPL");
 
-module_param(io, int, 0444);
+module_param_hw(io, int, 0444);
 MODULE_PARM_DESC(io, "I/O address base (0x3f8 or 0x2f8)");
 
-module_param(irq, int, 0444);
+module_param_hw(irq, int, 0444);
 MODULE_PARM_DESC(irq, "Interrupt (4 or 3)");
 
 module_param(threshold, int, 0444);
-- 
2.9.4

Re: HauppaugeTV-quadHD DVB-T mpeg risc op code errors

[Steven Toth]

On Fri, Apr 21, 2017 at 7:57 AM, Steven Toth  wrote:
>> Just a follow up on this. I had a bit more time to dig deeper into this 
>> today.
>>
>> Enabling debug output for the cx23885 driver *fixes* the issue.
>>
>> I added this to my kernel command line: cx23885.debug=8
>
> The driver's been around a very long time and is very stable with
> almost anything anyone has every added, or I originally added during
> the early development. That being said. this sounds like the quad
> is producing some kind of race condition, or the PLX bridge is in
> someway not as transparent as everyone would like.

I happen to have tip installed on a dev box, so I thought I'd install
a quad-hd and test for the issues you'd mentioned.

I do not see any of the issues you are describing, regardless of
whether I tested with w_scan, tzap, dvbtraffic.

No unusual module options used, everything 'default'.

Everything looks fine to me, no fault found, Ubuntu 16.04 Kernel
4.12-rc1, 64bit.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: [RFC PATCH v3 08/11] [media] vimc: Optimize frame generation through the pipe

[Helen Koike]

On 2017-06-02 11:58 PM, Helen Koike wrote:

Add a parameter called vsen_tpg, if true then vimc will work as before:
frames will be generated in the sensor nodes then propagated through the
pipe and processed by each node until a capture node is reached.
If vsen_tpg is false, then the frame is not generated by the sensor, but
directly from the capture node, thus saving intermediate memory buffers
and process time, allowing a higher frame rate.

Signed-off-by: Helen Koike 

---

Changes in v3:
[media] vimc: Optimize frame generation through the pipe
- This is a new patch in the series

Changes in v2: None


---
 drivers/media/platform/vimc/vimc-capture.c | 178 +
 drivers/media/platform/vimc/vimc-common.h  |   2 +
 drivers/media/platform/vimc/vimc-sensor.c  |  30 -
 3 files changed, 156 insertions(+), 54 deletions(-)

diff --git a/drivers/media/platform/vimc/vimc-capture.c 
b/drivers/media/platform/vimc/vimc-capture.c
index e943267..b5da0ea 100644
--- a/drivers/media/platform/vimc/vimc-capture.c
+++ b/drivers/media/platform/vimc/vimc-capture.c
@@ -15,7 +15,10 @@
  *
  */

+#include 
+#include 
 #include 
+#include 
 #include 
 #include 

@@ -38,6 +41,8 @@ struct vimc_cap_device {
struct mutex lock;
u32 sequence;
struct media_pipeline pipe;
+   struct tpg_data tpg;
+   struct task_struct *kthread_cap;
 };

 static const struct v4l2_pix_format fmt_default = {
@@ -246,6 +251,91 @@ static void vimc_cap_return_all_buffers(struct 
vimc_cap_device *vcap,
spin_unlock(>qlock);
 }

+static void vimc_cap_process_frame(struct vimc_ent_device *ved,
+  struct media_pad *sink, const void *frame)
+{
+   struct vimc_cap_device *vcap = container_of(ved, struct vimc_cap_device,
+   ved);
+   struct vimc_cap_buffer *vimc_buf;
+   void *vbuf;
+
+   spin_lock(>qlock);
+
+   /* Get the first entry of the list */
+   vimc_buf = list_first_entry_or_null(>buf_list,
+   typeof(*vimc_buf), list);
+   if (!vimc_buf) {
+   spin_unlock(>qlock);
+   return;
+   }
+
+   /* Remove this entry from the list */
+   list_del(_buf->list);
+
+   spin_unlock(>qlock);
+
+   /* Fill the buffer */
+   vimc_buf->vb2.vb2_buf.timestamp = ktime_get_ns();
+   vimc_buf->vb2.sequence = vcap->sequence++;
+   vimc_buf->vb2.field = vcap->format.field;
+
+   vbuf = vb2_plane_vaddr(_buf->vb2.vb2_buf, 0);
+
+   if (sink)
+   memcpy(vbuf, frame, vcap->format.sizeimage);
+   else
+   tpg_fill_plane_buffer(>tpg, V4L2_STD_PAL, 0, vbuf);
+
+   /* Set it as ready */
+   vb2_set_plane_payload(_buf->vb2.vb2_buf, 0,
+ vcap->format.sizeimage);
+   vb2_buffer_done(_buf->vb2.vb2_buf, VB2_BUF_STATE_DONE);
+}
+
+
+static int vimc_cap_tpg_thread(void *data)
+{
+   struct vimc_cap_device *vcap = data;
+
+   set_freezable();
+   set_current_state(TASK_UNINTERRUPTIBLE);
+
+   for (;;) {
+   try_to_freeze();
+   if (kthread_should_stop())
+   break;
+
+   vimc_cap_process_frame(>ved, NULL, NULL);
+
+   /* 60 frames per second */
+   schedule_timeout(HZ/60);
+   }
+
+   return 0;
+}
+
+static void vimc_cap_tpg_s_format(struct vimc_cap_device *vcap)
+{
+   const struct vimc_pix_map *vpix =
+   vimc_pix_map_by_pixelformat(vcap->format.pixelformat);
+
+   tpg_reset_source(>tpg, vcap->format.width, vcap->format.height,
+vcap->format.field);
+   tpg_s_bytesperline(>tpg, 0, vcap->format.width * vpix->bpp);
+   tpg_s_buf_height(>tpg, vcap->format.height);
+   tpg_s_fourcc(>tpg, vpix->pixelformat);
+   /*
+* TODO: check why the tpg_s_field need this third argument if
+* it is already receiving the field
+*/
+   tpg_s_field(>tpg, vcap->format.field,
+   vcap->format.field == V4L2_FIELD_ALTERNATE);
+   tpg_s_colorspace(>tpg, vcap->format.colorspace);
+   tpg_s_ycbcr_enc(>tpg, vcap->format.ycbcr_enc);
+   tpg_s_quantization(>tpg, vcap->format.quantization);
+   tpg_s_xfer_func(>tpg, vcap->format.xfer_func);
+}
+
 static int vimc_cap_start_streaming(struct vb2_queue *vq, unsigned int count)
 {
struct vimc_cap_device *vcap = vb2_get_drv_priv(vq);
@@ -256,20 +346,43 @@ static int vimc_cap_start_streaming(struct vb2_queue *vq, 
unsigned int count)

/* Start the media pipeline */
ret = media_pipeline_start(entity, >pipe);
-   if (ret) {
-   vimc_cap_return_all_buffers(vcap, VB2_BUF_STATE_QUEUED);
-   return ret;
-   }
+   if (ret)
+   goto err_ret_all_buffs;

/* Enable streaming from the pipe */
ret = 

[GIT PULL] [PATCH] saa7164: Bug - Double fetch PCIe access condition

[Steven Toth]

Mauro,

A single commit.

https://github.com/stoth68000/media-tree/commit/354dd3924a2e43806774953de536257548b5002c

This pull request addresses the concern raised by Pengfei Wang
 via
https://bugzilla.kernel.org/show_bug.cgi?id=195559

I've tested this patch with two different SAA7164 based cards in both
analog and digital television modes for US and Europe, no regressions
were found.

$ git diff --stat master
 drivers/media/pci/saa7164/saa7164-bus.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

Thanks!

- Steve

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: [PATCH v3 5/7] docs-rst: media: Sort topic list alphabetically

[Mauro Carvalho Chehab]

Em Mon, 10 Apr 2017 16:02:54 +0300
Sakari Ailus  escreveu:

> Bring some order by alphabetically ordering the list of topics.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  Documentation/media/kapi/v4l2-core.rst | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/media/kapi/v4l2-core.rst 
> b/Documentation/media/kapi/v4l2-core.rst
> index d8f6c46..2fbf532 100644
> --- a/Documentation/media/kapi/v4l2-core.rst
> +++ b/Documentation/media/kapi/v4l2-core.rst
> @@ -4,23 +4,23 @@ Video4Linux devices
>  .. toctree::
>  :maxdepth: 1
>  
> -v4l2-intro

NACK.

The order of the documentation should match what makes sense for the
user that will be reading the docs, and *not* an alphabetical order. 

I didn't check what order you did, but for sure the introduction should 
come first, and then the stuff that all drivers use, like
v4l2-dev, v4l2-device and v4l2-fh. Then, other stuff that it is part of
the framework but are used only by a subset of the drivers.

That's said, it probably makes sense to use multiple toctrees here, and
add some description before each of them, in order to better organize
its contents. Something similar to what it was done with
Documentation/admin-guide/index.rst

I'll rebase patch 6/7 to not depend on this one.


Regards

Thanks,
Mauro

Re: [GIT PULL FOR v4.13] Add qualcomm venus codec

[Mauro Carvalho Chehab]

Em Mon, 22 May 2017 09:37:48 +0200
Hans Verkuil  escreveu:

> Hi Mauro,
> 
> This pull requests adds support for the Qualcomm venus codec driver.

What's the status of the firmware blobs required by this driver?

Are they already at linux-firmware?

Regards,
Mauro

Thanks,
Mauro

[GIT PULL v3 FOR v4.13] V4L2 fwnode support

[Sakari Ailus]

Hi Mauro,

This pull request introduces the V4L2 fwnode framework which has equivalent
functionality to V4L2 OF framework. The V4L2 OF framework users are
converted to use the V4L2 fwnode framework and the redundant V4L2 OF
framework is removed.

since v2:

- Rebase (no conflicts) and convert the recently merged stm32-dcmi driver to
  V4L2 fwnode.

since v1:

- Merge patch to the series ("v4l: flash led class: Use fwnode_handle
  instead of device_node in init"):

  

Please pull.


The following changes since commit 1656df35d689ac6a93d7503725d9e62ce50c7f38:

  [media] em28xx: fix spelling mistake: "missdetected" -> "misdetected" 
(2017-06-06 08:13:41 -0300)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git v4l2-acpi

for you to fetch changes up to e7e234464d82dc2d3f60a9cb4ccf45c8f965dd51:

  v4l: Remove V4L2 OF framework in favour of V4L2 fwnode framework (2017-06-06 
15:08:34 +0300)


Sakari Ailus (7):
  v4l: fwnode: Support generic fwnode for parsing standardised properties
  v4l: async: Add fwnode match support
  v4l: flash led class: Use fwnode_handle instead of device_node in init
  v4l: Switch from V4L2 OF not V4L2 fwnode API
  docs-rst: media: Sort topic list alphabetically
  docs-rst: media: Switch documentation to V4L2 fwnode API
  v4l: Remove V4L2 OF framework in favour of V4L2 fwnode framework

 Documentation/media/kapi/v4l2-core.rst |  20 +-
 Documentation/media/kapi/v4l2-fwnode.rst   |   3 +
 Documentation/media/kapi/v4l2-of.rst   |   3 -
 drivers/leds/leds-aat1290.c|   5 +-
 drivers/leds/leds-max77693.c   |   5 +-
 drivers/media/i2c/Kconfig  |  11 +
 drivers/media/i2c/adv7604.c|   7 +-
 drivers/media/i2c/mt9v032.c|   7 +-
 drivers/media/i2c/ov2659.c |   8 +-
 drivers/media/i2c/ov5645.c |   7 +-
 drivers/media/i2c/ov5647.c |   7 +-
 drivers/media/i2c/s5c73m3/s5c73m3-core.c   |   7 +-
 drivers/media/i2c/s5k5baf.c|   6 +-
 drivers/media/i2c/smiapp/Kconfig   |   1 +
 drivers/media/i2c/smiapp/smiapp-core.c |  29 ++-
 drivers/media/i2c/tc358743.c   |  11 +-
 drivers/media/i2c/tvp514x.c|   6 +-
 drivers/media/i2c/tvp5150.c|   7 +-
 drivers/media/i2c/tvp7002.c|   6 +-
 drivers/media/platform/Kconfig |   4 +
 drivers/media/platform/am437x/Kconfig  |   1 +
 drivers/media/platform/am437x/am437x-vpfe.c|  15 +-
 drivers/media/platform/atmel/Kconfig   |   2 +
 drivers/media/platform/atmel/atmel-isc.c   |  13 +-
 drivers/media/platform/atmel/atmel-isi.c   |  11 +-
 drivers/media/platform/exynos4-is/Kconfig  |   2 +
 drivers/media/platform/exynos4-is/media-dev.c  |  13 +-
 drivers/media/platform/exynos4-is/mipi-csis.c  |   6 +-
 drivers/media/platform/omap3isp/isp.c  |  49 ++--
 drivers/media/platform/pxa_camera.c|  11 +-
 drivers/media/platform/rcar-vin/Kconfig|   1 +
 drivers/media/platform/rcar-vin/rcar-core.c|  19 +-
 drivers/media/platform/soc_camera/soc_camera.c |   7 +-
 drivers/media/platform/stm32/stm32-dcmi.c  |  13 +-
 drivers/media/platform/ti-vpe/cal.c|  15 +-
 drivers/media/platform/xilinx/Kconfig  |   1 +
 drivers/media/platform/xilinx/xilinx-vipp.c|  63 +++--
 drivers/media/v4l2-core/Kconfig|   3 +
 drivers/media/v4l2-core/Makefile   |   4 +-
 drivers/media/v4l2-core/v4l2-async.c   |  21 +-
 drivers/media/v4l2-core/v4l2-flash-led-class.c |  12 +-
 drivers/media/v4l2-core/v4l2-fwnode.c  | 345 +
 drivers/media/v4l2-core/v4l2-of.c  | 327 ---
 include/media/v4l2-async.h |   8 +-
 include/media/v4l2-flash-led-class.h   |   6 +-
 include/media/{v4l2-of.h => v4l2-fwnode.h} |  96 +++
 include/media/v4l2-subdev.h|   5 +-
 47 files changed, 643 insertions(+), 586 deletions(-)
 create mode 100644 Documentation/media/kapi/v4l2-fwnode.rst
 delete mode 100644 Documentation/media/kapi/v4l2-of.rst
 create mode 100644 drivers/media/v4l2-core/v4l2-fwnode.c
 delete mode 100644 drivers/media/v4l2-core/v4l2-of.c
 rename include/media/{v4l2-of.h => v4l2-fwnode.h} (50%)

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

[PATCH 1/1] v4l2: fwnode: Convert stm32-dcmi driver to V4L2 fwnode

[Sakari Ailus]

The stm32-dcmi driver was still using V4L2 OF, convert it to V4L2 fwnode.

Signed-off-by: Sakari Ailus 
---
I'll squash this to patch "v4l: Switch from V4L2 OF not V4L2 fwnode API"
in the pull request I'll send in a moment.

 drivers/media/platform/Kconfig|  1 +
 drivers/media/platform/stm32/stm32-dcmi.c | 13 +++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 8d50ec8..a4b7cef 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -121,6 +121,7 @@ config VIDEO_STM32_DCMI
depends on VIDEO_V4L2 && OF && HAS_DMA
depends on ARCH_STM32 || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
+   select V4L2_FWNODE
---help---
  This module makes the STM32 Digital Camera Memory Interface (DCMI)
  available as a v4l2 device.
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c 
b/drivers/media/platform/stm32/stm32-dcmi.c
index 348f025..83d32a5 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,9 +30,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 #include 
 
 #define DRV_NAME "stm32-dcmi"
@@ -139,7 +140,7 @@ struct stm32_dcmi {
struct mutexlock;
struct vb2_queuequeue;
 
-   struct v4l2_of_bus_parallel bus;
+   struct v4l2_fwnode_bus_parallel bus;
struct completion   complete;
struct clk  *mclk;
enum state  state;
@@ -1143,8 +1144,8 @@ static int dcmi_graph_parse(struct stm32_dcmi *dcmi, 
struct device_node *node)
 
/* Remote node to connect */
dcmi->entity.node = remote;
-   dcmi->entity.asd.match_type = V4L2_ASYNC_MATCH_OF;
-   dcmi->entity.asd.match.of.node = remote;
+   dcmi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
+   dcmi->entity.asd.match.fwnode.fwnode = of_fwnode_handle(remote);
return 0;
}
 }
@@ -1190,7 +1191,7 @@ static int dcmi_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
const struct of_device_id *match = NULL;
-   struct v4l2_of_endpoint ep;
+   struct v4l2_fwnode_endpoint ep;
struct stm32_dcmi *dcmi;
struct vb2_queue *q;
struct dma_chan *chan;
@@ -1222,7 +1223,7 @@ static int dcmi_probe(struct platform_device *pdev)
return -ENODEV;
}
 
-   ret = v4l2_of_parse_endpoint(np, );
+   ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(np), );
if (ret) {
dev_err(>dev, "Could not parse the endpoint\n");
of_node_put(np);
-- 
2.1.4

Re: [PATCH 02/12] intel-ipu3: mmu: implement driver

[Tomasz Figa]

Hi Yong, Tuukka,

+CC IOMMU ML and Joerg. (Technically you should resend this patch
including them.)

On Tue, Jun 6, 2017 at 5:39 AM, Yong Zhi  wrote:
> From: Tuukka Toivonen 
>
> This driver translates Intel IPU3 internal virtual
> address to physical address.

Please see my comments inline.

>
> Signed-off-by: Yong Zhi 

Tuukka needs to sign off this patch as well (above the sender's
sign-off to maintain the patch flow order) to consent his approval for
the submission.

> ---
>  drivers/media/pci/intel/ipu3/Kconfig|  11 +
>  drivers/media/pci/intel/ipu3/Makefile   |   1 +
>  drivers/media/pci/intel/ipu3/ipu3-mmu.c | 423 
> 
>  drivers/media/pci/intel/ipu3/ipu3-mmu.h |  73 ++
>  4 files changed, 508 insertions(+)
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-mmu.c
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-mmu.h
>
> diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
> b/drivers/media/pci/intel/ipu3/Kconfig
> index 2a895d6..ab2edcb 100644
> --- a/drivers/media/pci/intel/ipu3/Kconfig
> +++ b/drivers/media/pci/intel/ipu3/Kconfig
> @@ -15,3 +15,14 @@ config VIDEO_IPU3_CIO2
> Say Y or M here if you have a Skylake/Kaby Lake SoC with MIPI CSI-2
> connected camera.
> The module will be called ipu3-cio2.
> +
> +config INTEL_IPU3_MMU
> +   tristate "Intel ipu3-mmu driver"
> +   select IOMMU_API
> +   select IOMMU_IOVA
> +   ---help---
> + For IPU3, this option enables its MMU driver to translate its 
> internal
> + virtual address to 39 bits wide physical address for 64GBytes space 
> access.
> +
> + Say Y here if you have Skylake/Kaby Lake SoC with IPU3.
> + Say N if un-sure.

Is the MMU optional? I.e. can you still use the IPU3 without the MMU
driver? If no, then it doesn't make sense to flood the user with
meaningless choice and the driver could simply be selected by other
IPU3 drivers.

And the other way around, is the IPU3 MMU driver useful for anything
else than IPU3? If no (but yes for the above), then it should depend
on some other IPU3 drivers being enabled, as otherwise it would just
confuse the user.

> diff --git a/drivers/media/pci/intel/ipu3/Makefile 
> b/drivers/media/pci/intel/ipu3/Makefile
> index 20186e3..2b669df 100644
> --- a/drivers/media/pci/intel/ipu3/Makefile
> +++ b/drivers/media/pci/intel/ipu3/Makefile
> @@ -1 +1,2 @@
>  obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
> +obj-$(CONFIG_INTEL_IPU3_MMU) += ipu3-mmu.o
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-mmu.c 
> b/drivers/media/pci/intel/ipu3/ipu3-mmu.c
> new file mode 100644
> index 000..a9fb116
> --- /dev/null
> +++ b/drivers/media/pci/intel/ipu3/ipu3-mmu.c
> @@ -0,0 +1,423 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "ipu3-mmu.h"
> +
> +/**
> + * ipu3_mmu_tlb_invalidate - invalidate translation look-aside buffer
> + * @addr: base address to access REG_TLB_INVALIDATE
> + *
> + * This function must be called when MMU has power
> + */
> +static void ipu3_mmu_tlb_invalidate(void __iomem *addr)

Passing a void* argument is kind of shaky. It would make much more
sense to instead pass a const struct ipu3_mmu *pointer to this
function.

> +{
> +   writel(TLB_INVALIDATE, addr + REG_TLB_INVALIDATE);
> +}
> +
> +static int ipu3_mmu_add_device(struct device *dev)
> +{
> +   struct ipu3_mmu *mmu = dev_get_drvdata(dev);

The drvdata of dev belongs only to its driver. Other drivers shouldn't
expect anything in particular to be there.

> +
> +   /* mapping domain must be prepared */
> +   if (!mmu->domain)
> +   return 0;
> +
> +   return iommu_attach_device(mmu->domain, dev);

I believe this should be handled by the IOMMU core. Maybe your
iommu_group somehow ends up without a default_domain?

> +}
> +
> +/**
> + * ipu3_mmu_alloc_page_table - get page to fill entries with dummy defaults
> + * @d: mapping domain to be worked on
> + * @l1: True for L1 page table, false for L2 page table.
> + *
> + * Index of L1 page table points to L2 tbl
> + *
> + * Return: Pointer to allocated page table
> + * or NULL on failure.
> + */
> +static uint32_t *ipu3_mmu_alloc_page_table(struct ipu3_mmu_domain *d, bool 
> l1)
> +{
> +   uint32_t *pt = (uint32_t *)__get_free_page(GFP_KERNEL);

Style: I believe u32 is preferred in the kernel.

> +   int i;
> +
> +   if (!pt)
> + 

Re: [PATCH 01/12] videodev2.h, v4l2-ioctl: add IPU3 meta buffer format

[Tomasz Figa]

On Tue, Jun 6, 2017 at 5:04 PM, Hans Verkuil  wrote:
> On 06/06/17 09:25, Sakari Ailus wrote:
>> Hi Tomasz,
>>
>> On Tue, Jun 06, 2017 at 01:30:41PM +0900, Tomasz Figa wrote:
>>> Uhm, +Laurent. Sorry for the noise.
>>>
>>> On Tue, Jun 6, 2017 at 1:30 PM, Tomasz Figa  wrote:
 Hi Yong,

 On Tue, Jun 6, 2017 at 5:39 AM, Yong Zhi  wrote:
> Add the IPU3 specific processing parameter format
> V4L2_META_FMT_IPU3_PARAMS and metadata formats
> for 3A and other statistics:

 Please see my comments inline.

>
>   V4L2_META_FMT_IPU3_PARAMS
>   V4L2_META_FMT_IPU3_STAT_3A
>   V4L2_META_FMT_IPU3_STAT_DVS
>   V4L2_META_FMT_IPU3_STAT_LACE
>
> Signed-off-by: Yong Zhi 
> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 4 
>  include/uapi/linux/videodev2.h   | 6 ++
>  2 files changed, 10 insertions(+)
 [snip]
> +/* Vendor specific - used for IPU3 camera sub-system */
> +#define V4L2_META_FMT_IPU3_PARAMS  v4l2_fourcc('i', 'p', '3', 'p') 
> /* IPU3 params */
> +#define V4L2_META_FMT_IPU3_STAT_3A v4l2_fourcc('i', 'p', '3', 's') 
> /* IPU3 3A statistics */
> +#define V4L2_META_FMT_IPU3_STAT_DVSv4l2_fourcc('i', 'p', '3', 'd') 
> /* IPU3 DVS statistics */
> +#define V4L2_META_FMT_IPU3_STAT_LACE   v4l2_fourcc('i', 'p', '3', 'l') 
> /* IPU3 LACE statistics */

 We had some discussion about this with Laurent and if I remember
 correctly, the conclusion was that it might make sense to define one
 FourCC for a vendor specific format, ('v', 'n', 'd', 'r') for example,
 and then have a V4L2-specific enum within the v4l2_pix_format(_mplane)
 struct that specifies the exact vendor data type. It seems saner than
 assigning a new FourCC whenever a new hardware revision comes out,
 especially given that FourCCs tend to be used outside of the V4L2
 world as well and being kind of (de facto) standardized (with existing
 exceptions, unfortunately).
>
> I can't remember that discussion

I think that was just a casual chat between Lauren, me and few more guys.

> although I've had other discussions with
> Laurent related to this on how to handle formats that have many variations
> on a theme.
>
> But speaking for this specific case I see no reason to do something special.
> There are only four new formats, which seems perfectly reasonable to me.
>
> I don't see the advantage of adding another layer of pixel formats. You still
> need to define something for this, one way or the other. And this way doesn't
> require API changes.
>
>> If we have four video nodes with different vendor specific formats, how does
>> the user tell the formats apart? I presume the user space could use the
>> entity names for instance, but that would essentially make them device
>> specific.
>
> Well, they are. There really is no way to avoid that.
>
>> I'm not sure if there would be any harm from that in practice though: the
>> user will need to find the device nodes somehow and that will be very likely
>> based on e.g. entity names.
>>
>> How should the documentation be arranged? The documentation is arranged by
>> fourccs currently; we'd probably need a separate section for vendor specific
>> formats. I think the device name should be listed there as well.
>
> There already is a separate section for metadata formats:
>
> https://hverkuil.home.xs4all.nl/spec/uapi/v4l/meta-formats.html
>
> But perhaps that page should be organized by device. And with some more
> detailed information on how to find the video node (i.e. entity names).
>
>> I'd like to have perhaps Hans's comment on that as well.
>>
>> I don't really see a drawback in the current way of doing this either; we
>> may get a few new fourcc codes occasionally of which I'm not really worried
>> about. --- I'd rather ask why should there be an exception on how vendor
>> specific formats are defined. And if we do make an exception, then how do
>> you decide which one is and isn't vendor specific? There are raw bayer
>> format variants that are just raw bayer data but the pixels are arranged
>> differently (e.g. CIO2 driver).
>>
>
> For these unique formats I am happy with the way it is today. The problem
> is more with 'parameterized' formats. A simple example would be the 4:2:2
> interleaved YUV formats where you have four different ways of ordering the
> Y, U and V components. Right now we have four defines for that, but things
> get out of hand quickly when you have multiple parameters like that.
>
> Laurent and myself discussed that with NVidia some time ago, without
> reaching a clear conclusion. Mostly because we couldn't come up with an
> API that is simple enough.

Actually I back off a bit. Still, it looks like we have a metadata
interface already, but it's limited to CAPTURE:

https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/dev-meta.html#metadata

Re: Support for RGB/YUV 10, 12 BPC(bits per color/component) image data formats in kernel

[Hans Verkuil]

On 06/06/17 08:35, Ajay kumar wrote:
> Hi Sakari,
> 
> On Sat, Jun 3, 2017 at 1:48 PM, Sakari Ailus  wrote:
>> Hi Ajay,
>>
>> On Fri, Jun 02, 2017 at 06:38:53PM +0530, Ajay kumar wrote:
>>> Hi all,
>>>
>>> I have tried searching for RGB/YUV 10, 12 BPC formats in videodev2.h,
>>> media-bus-format.h and drm_fourcc.h
>>> I could only find RGB 10BPC support in drm_fourcc.h.
>>> I guess not much support is present for formats with (BPC > 8) in the 
>>> kernel.
>>
>> What's "BPC"? Most YUV and RGB formats have only 8 bits per sample. More
>> format definitions may be added if there's a driver that makes use of them.
> BPC : Bits Per Color/Component
> In my project, we have an image capture device which can capture 10 or
> 12 bits for each of R, G, B colors, i.e:
> R[0:9] G[0:9] B[0:9] and
> R[0:11] G[0:11] B[0:11]
> 
> I want to define macros for the above formats in videodev2.h.
> But, I am not getting the logic behind the naming convention used to
> define v4l2_fourcc macros.
> ex:
> V4L2_PIX_FMT_ARGB32  v4l2_fourcc('A', 'R', '2', '4');
> 
> How did they choose the characters 'A', 'R', '2', '4' in the above case?
> 
> I want to know the logic/naming convention behind that, so that I can create
> new v4l2_fourcc defines for 10, 12 BPC formats and use in my driver.

A = has Alpha channel, R = uses RGB, 24 = uses 24 bits for the RGB part.

So for 10 bit you'd get AR30 and for 12 bit per component it's AR36.
If there is no alpha channel, then use XR30/XR36.

In practice there isn't much of a system behind these formats.

Regards,

Hans

> 
> Thanks,
> Ajay Kumar
>>>
>>> Are there any plans to add fourcc defines for such formats?
>>> Also, I wanted to how to define fourcc code for those formats?
>>
>> --
>> Regards,
>>
>> Sakari Ailus
>> e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

[GIT PULL for v4.12-rc5] media fixes

[Mauro Carvalho Chehab]

Hi Linus,

Please pull from:
  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v4.12-2

For some bug fixes:

- Don't fail build if atomisp has warnings;
- Some CEC Kconfig changes to allow it to be used by DRM without media
  dependencies;
- A race fix at RC initialization code;
- A driver fix at rainshadow-cec.

IMHO, the one that affects most people in this series is a build fix:
if you try to build the Kernel with W=1 or gcc7 and all[yes|mod]config,
build will fail due to -Werror at atomisp makefiles.

The following changes since commit 5ed02dbb497422bf225783f46e6eadd237d23d6b:

  Linux 4.12-rc3 (2017-05-28 17:20:53 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v4.12-2

for you to fetch changes up to 963761a0b2e85663ee4a5630f72930885a06598a:

  [media] rc-core: race condition during ir_raw_event_register() (2017-06-04 
15:25:38 -0300)


media fixes for v4.12-rc4


Colin Ian King (1):
  [media] rainshadow-cec: ensure exit_loop is intialized

Hans Verkuil (3):
  [media] cec: select CEC_CORE instead of depend on it
  [media] cec: rename MEDIA_CEC_NOTIFIER to CEC_NOTIFIER
  [media] cec: drop MEDIA_CEC_DEBUG

Mauro Carvalho Chehab (1):
  [media] atomisp: don't treat warnings as errors

Sean Young (1):
  [media] rc-core: race condition during ir_raw_event_register()

 drivers/media/Kconfig   |  6 ++
 drivers/media/Makefile  |  4 ++--
 drivers/media/cec/Kconfig   | 14 --
 drivers/media/cec/Makefile  |  2 +-
 drivers/media/cec/cec-adap.c|  2 +-
 drivers/media/cec/cec-core.c|  8 
 drivers/media/i2c/Kconfig   |  9 ++---
 drivers/media/platform/Kconfig  | 10 ++
 drivers/media/platform/vivid/Kconfig|  3 ++-
 drivers/media/rc/rc-ir-raw.c| 13 -
 drivers/media/usb/pulse8-cec/Kconfig|  3 ++-
 drivers/media/usb/rainshadow-cec/Kconfig|  3 ++-
 drivers/media/usb/rainshadow-cec/rainshadow-cec.c   |  2 +-
 drivers/staging/media/atomisp/i2c/Makefile  |  2 --
 drivers/staging/media/atomisp/i2c/imx/Makefile  |  2 --
 drivers/staging/media/atomisp/i2c/ov5693/Makefile   |  2 --
 drivers/staging/media/atomisp/pci/atomisp2/Makefile |  2 +-
 include/media/cec-notifier.h|  2 +-
 include/media/cec.h |  4 ++--
 19 files changed, 45 insertions(+), 48 deletions(-)

Re: [PATCH 00/12] Intel IPU3 ImgU patchset

[Hans Verkuil]

On 05/06/17 22:39, Yong Zhi wrote:
> This patchset adds support for the Intel IPU3 (Image Processing Unit)
> ImgU which is essentially a modern memory-to-memory ISP. It implements
> raw Bayer to YUV image format conversion as well as a large number of
> other pixel processing algorithms for improving the image quality.
> 
> Meta data formats are defined for image statistics (3A, i.e. automatic
> white balance, exposure and focus, histogram and local area contrast
> enhancement) as well as for the pixel processing algorithm parameters.
> The documentation for these formats is currently not included in the
> patchset but will be added in a future version of this set.
> 
> The algorithm parameters need to be considered specific to a given frame
> and typically a large number of these parameters change on frame to frame
> basis. Additionally, the parameters are highly structured (and not a flat
> space of independent configuration primitives). They also reflect the
> data structures used by the firmware and the hardware. On top of that,
> the algorithms require highly specialized user space to make meaningful
> use of them. For these reasons it has been chosen video buffers to pass
> the parameters to the device.
> 
> On individual patches:
> 
> The heart of ImgU is the CSS, or Camera Subsystem, which contains the
> image processors and HW accelerators.
> 
> The 3A statistics and other firmware parameter computation related
> functions are implemented in patch 8.
> 
> All h/w programming related code can be found in patch 9.
> 
> To access DDR via ImgU's own memory space, IPU3 is also equipped with
> its own MMU unit, the driver is implemented in patch 2.
> 
> Patch 3 uses above driver for DMA mapping operation.
> 
> Patch 5-10 are basically IPU3 CSS specific implementations:
> 
> 6 and 7 provide some utility functions and manage IPU3 fw download and
> install.
> 
> Patch 9 and 10 are of the same file, the latter implements interface
> functions for access fw & hw capabilities defined in patch 8.
> 
> Patch 12 uses Kconfig and Makefile created by IPU3 cio2 patch set,
> the code path, however is updated to drivers/media/pci/intel/ipu3.
> The path change will be reflected in next revision of the cio2 patch as well.

I need to see the v4l2-compliance output for the various video devices that
are created. Please compile directly from the 
https://git.linuxtv.org/v4l-utils.git/
repository to be sure you use the latest code.

Just run 'v4l2-compliance -d /dev/videoX'.

When you post v2 I'd like to see the output of that utility in the cover email.

If the utility reports fails and you aren't clear what's going on, then just
mail me (with a CC to Sakari).

It hasn't been used much (if at all) for video devices streaming metadata, so
you may run into issues with that.

Regards,

Hans

> 
> Tuukka Toivonen (1):
>   intel-ipu3: mmu: implement driver
> 
> Yong Zhi (11):
>   videodev2.h, v4l2-ioctl: add IPU3 meta buffer format
>   intel-ipu3: Add DMA API implementation
>   intel-ipu3: Add user space ABI definitions
>   intel-ipu3: css: tables
>   intel-ipu3: css: imgu dma buff pool
>   intel-ipu3: css: firmware management
>   intel-ipu3: params: compute and program ccs
>   intel-ipu3: css hardware setup
>   intel-ipu3: css pipeline
>   intel-ipu3: Add imgu v4l2 driver
>   intel-ipu3: imgu top level pci device
> 
>  drivers/media/pci/intel/ipu3/Kconfig   |   32 +
>  drivers/media/pci/intel/ipu3/Makefile  |8 +
>  drivers/media/pci/intel/ipu3/ipu3-abi.h| 1572 
>  drivers/media/pci/intel/ipu3/ipu3-css-fw.c |  272 +
>  drivers/media/pci/intel/ipu3/ipu3-css-fw.h |  215 +
>  drivers/media/pci/intel/ipu3/ipu3-css-params.c | 3113 
>  drivers/media/pci/intel/ipu3/ipu3-css-params.h |  105 +
>  drivers/media/pci/intel/ipu3/ipu3-css-pool.c   |  129 +
>  drivers/media/pci/intel/ipu3/ipu3-css-pool.h   |   53 +
>  drivers/media/pci/intel/ipu3/ipu3-css.c| 2242 ++
>  drivers/media/pci/intel/ipu3/ipu3-css.h|  236 +
>  drivers/media/pci/intel/ipu3/ipu3-dmamap.c |  408 +
>  drivers/media/pci/intel/ipu3/ipu3-dmamap.h |   20 +
>  drivers/media/pci/intel/ipu3/ipu3-mmu.c|  423 ++
>  drivers/media/pci/intel/ipu3/ipu3-mmu.h|   73 +
>  drivers/media/pci/intel/ipu3/ipu3-tables.c | 9621 
> 
>  drivers/media/pci/intel/ipu3/ipu3-tables.h |   82 +
>  drivers/media/pci/intel/ipu3/ipu3-v4l2.c   |  723 ++
>  drivers/media/pci/intel/ipu3/ipu3.c|  712 ++
>  drivers/media/pci/intel/ipu3/ipu3.h|  184 +
>  drivers/media/v4l2-core/v4l2-ioctl.c   |4 +
>  include/uapi/linux/intel-ipu3.h| 2182 ++
>  include/uapi/linux/videodev2.h |6 +
>  23 files changed, 22415 insertions(+)
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-abi.h
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css-fw.c
>  create mode 100644 

Re: [PATCH 11/12] intel-ipu3: Add imgu v4l2 driver

[Hans Verkuil]

On 05/06/17 22:39, Yong Zhi wrote:
> ipu3 imgu video device based on v4l2, vb2 and
> media controller framework.
> 
> Signed-off-by: Yong Zhi 
> ---
>  drivers/media/pci/intel/ipu3/ipu3-v4l2.c | 723 
> +++
>  1 file changed, 723 insertions(+)
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-v4l2.c
> 
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-v4l2.c 
> b/drivers/media/pci/intel/ipu3/ipu3-v4l2.c
> new file mode 100644
> index 000..bc219c1
> --- /dev/null
> +++ b/drivers/media/pci/intel/ipu3/ipu3-v4l2.c
> @@ -0,0 +1,723 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "ipu3.h"
> +
> +/ v4l2_subdev_ops /
> +
> +static int ipu3_subdev_s_stream(struct v4l2_subdev *sd, int enable)
> +{
> + struct ipu3_mem2mem2_device *m2m2 =
> + container_of(sd, struct ipu3_mem2mem2_device, subdev);
> + int r = 0;
> +
> + if (m2m2->ops && m2m2->ops->s_stream)
> + r = m2m2->ops->s_stream(m2m2, enable);
> +
> + if (!r)
> + m2m2->streaming = enable;
> +
> + return r;
> +}
> +
> +static int ipu3_subdev_get_fmt(struct v4l2_subdev *sd,
> +struct v4l2_subdev_pad_config *cfg,
> +struct v4l2_subdev_format *fmt)
> +{
> + struct ipu3_mem2mem2_device *m2m2 =
> + container_of(sd, struct ipu3_mem2mem2_device, subdev);
> + struct v4l2_mbus_framefmt *mf;
> + u32 pad = fmt->pad;
> +
> + if (fmt->which == V4L2_SUBDEV_FORMAT_ACTIVE) {
> + fmt->format = m2m2->nodes[pad].pad_fmt;
> + } else {
> + mf = v4l2_subdev_get_try_format(sd, cfg, pad);
> + fmt->format = *mf;
> + }
> +
> + return 0;
> +}
> +
> +static int ipu3_subdev_set_fmt(struct v4l2_subdev *sd,
> +struct v4l2_subdev_pad_config *cfg,
> +struct v4l2_subdev_format *fmt)
> +{
> + struct ipu3_mem2mem2_device *m2m2 =
> + container_of(sd, struct ipu3_mem2mem2_device, subdev);
> + struct v4l2_mbus_framefmt *mf;
> + u32 pad = fmt->pad;
> +
> + if (fmt->which == V4L2_SUBDEV_FORMAT_TRY)
> + mf = v4l2_subdev_get_try_format(sd, cfg, pad);
> + else
> + mf = >nodes[pad].pad_fmt;
> +
> + /* Clamp the w and h based on the hardware capabilities */
> + if (m2m2->subdev_pads[pad].flags & MEDIA_PAD_FL_SOURCE) {
> +
> + fmt->format.width = clamp(fmt->format.width,
> + IPU3_OUTPUT_MIN_WIDTH,
> + IPU3_OUTPUT_MAX_WIDTH);
> + fmt->format.height = clamp(fmt->format.height,
> + IPU3_OUTPUT_MIN_HEIGHT,
> + IPU3_OUTPUT_MAX_HEIGHT);
> + } else {
> + fmt->format.width = clamp(fmt->format.width,
> + IPU3_INPUT_MIN_WIDTH,
> + IPU3_INPUT_MAX_WIDTH);
> + fmt->format.height = clamp(fmt->format.height,
> + IPU3_INPUT_MIN_HEIGHT,
> + IPU3_INPUT_MAX_HEIGHT);
> + }
> +
> + *mf = fmt->format;
> +
> + return 0;
> +}
> +
> +/ media_entity_operations /
> +
> +static int ipu3_link_setup(struct media_entity *entity,
> +  const struct media_pad *local,
> +  const struct media_pad *remote, u32 flags)
> +{
> + struct ipu3_mem2mem2_device *m2m2 =
> + container_of(entity, struct ipu3_mem2mem2_device, subdev.entity);
> + u32 pad = local->index;
> +
> + WARN_ON(pad >= m2m2->num_nodes);
> +
> + m2m2->nodes[pad].enabled = !!(flags & MEDIA_LNK_FL_ENABLED);
> +
> + return 0;
> +}
> +
> +/ vb2_ops /
> +
> +/* Transfer buffer ownership to me */
> +static void ipu3_vb2_buf_queue(struct vb2_buffer *vb)
> +{
> + struct ipu3_mem2mem2_device *m2m2 = vb2_get_drv_priv(vb->vb2_queue);
> + struct imgu_device *imgu =
> + container_of(m2m2, struct imgu_device, mem2mem2);
> + struct imgu_video_device *node =
> + container_of(vb->vb2_queue, struct imgu_video_device, vbq);
> + struct ipu3_mem2mem2_buffer *b =
> + container_of(vb, struct 

Re: [PATCH 07/12] intel-ipu3: css: firmware management

[Hans Verkuil]

On 05/06/17 22:39, Yong Zhi wrote:
> Functions to load and install imgu FW blobs
> 
> Signed-off-by: Yong Zhi 
> ---
>  drivers/media/pci/intel/ipu3/ipu3-abi.h| 1572 
> 
>  drivers/media/pci/intel/ipu3/ipu3-css-fw.c |  272 +
>  drivers/media/pci/intel/ipu3/ipu3-css-fw.h |  215 
>  drivers/media/pci/intel/ipu3/ipu3-css.h|   54 +
>  4 files changed, 2113 insertions(+)
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-abi.h
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css-fw.c
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css-fw.h
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css.h

Has this been tested for both i686 and x86_64 modes?

Regards,

Hans

Re: [PATCH 04/12] intel-ipu3: Add user space ABI definitions

[Hans Verkuil]

On 05/06/17 22:39, Yong Zhi wrote:

Commit message missing.

> Signed-off-by: Yong Zhi 
> ---
>  include/uapi/linux/intel-ipu3.h | 2182 
> +++
>  1 file changed, 2182 insertions(+)
>  create mode 100644 include/uapi/linux/intel-ipu3.h
> 
> diff --git a/include/uapi/linux/intel-ipu3.h b/include/uapi/linux/intel-ipu3.h
> new file mode 100644
> index 000..9e90aec
> --- /dev/null
> +++ b/include/uapi/linux/intel-ipu3.h
> @@ -0,0 +1,2182 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef __IPU3_UAPI_H
> +#define __IPU3_UAPI_H
> +
> +#include 
> +
> +#define IPU3_UAPI_ISP_VEC_ELEMS  64
> +
> +#define IMGU_ABI_PAD __aligned(IPU3_UAPI_ISP_WORD_BYTES)
> +#define IPU3_ALIGN   __attribute__((aligned(IPU3_UAPI_ISP_WORD_BYTES)))
> +
> +#define IPU3_UAPI_ISP_WORD_BYTES 32
> +#define IPU3_UAPI_MAX_STRIPES2
> +
> +/*** ipu3_uapi_stats_3a ***/
> +
> +#define IPU3_UAPI_MAX_BUBBLE_SIZE10
> +
> +#define IPU3_UAPI_AE_COLORS  4
> +#define IPU3_UAPI_AE_BINS256
> +
> +#define IPU3_UAPI_AWB_MD_ITEM_SIZE   8
> +#define IPU3_UAPI_AWB_MAX_SETS   60
> +#define IPU3_UAPI_AWB_SET_SIZE   0x500
> +#define IPU3_UAPI_AWB_SPARE_FOR_BUBBLES \
> + (IPU3_UAPI_MAX_BUBBLE_SIZE * IPU3_UAPI_MAX_STRIPES * \
> +  IPU3_UAPI_AWB_MD_ITEM_SIZE)
> +#define IPU3_UAPI_AWB_MAX_BUFFER_SIZE \
> + (IPU3_UAPI_AWB_MAX_SETS * \
> +  (IPU3_UAPI_AWB_SET_SIZE + IPU3_UAPI_AWB_SPARE_FOR_BUBBLES))
> +
> +#define IPU3_UAPI_AF_MAX_SETS24
> +#define IPU3_UAPI_AF_MD_ITEM_SIZE4
> +#define IPU3_UAPI_AF_SPARE_FOR_BUBBLES \
> + (IPU3_UAPI_MAX_BUBBLE_SIZE * IPU3_UAPI_MAX_STRIPES * \
> +  IPU3_UAPI_AF_MD_ITEM_SIZE)
> +#define IPU3_UAPI_AF_Y_TABLE_SET_SIZE0x80
> +#define IPU3_UAPI_AF_Y_TABLE_MAX_SIZE \
> + (IPU3_UAPI_AF_MAX_SETS * \
> +  (IPU3_UAPI_AF_Y_TABLE_SET_SIZE + IPU3_UAPI_AF_SPARE_FOR_BUBBLES) * \
> +  IPU3_UAPI_MAX_STRIPES)
> +
> +#define IPU3_UAPI_AWB_FR_MAX_SETS24
> +#define IPU3_UAPI_AWB_FR_MD_ITEM_SIZE8
> +#define IPU3_UAPI_AWB_FR_BAYER_TBL_SIZE  0x100
> +#define IPU3_UAPI_AWB_FR_SPARE_FOR_BUBBLES \
> + (IPU3_UAPI_MAX_BUBBLE_SIZE * IPU3_UAPI_MAX_STRIPES * \
> + IPU3_UAPI_AWB_FR_MD_ITEM_SIZE)
> +#define IPU3_UAPI_AWB_FR_BAYER_TABLE_MAX_SIZE \
> + (IPU3_UAPI_AWB_FR_MAX_SETS * \
> + (IPU3_UAPI_AWB_FR_BAYER_TBL_SIZE + \
> +  IPU3_UAPI_AWB_FR_SPARE_FOR_BUBBLES) * \
> + IPU3_UAPI_MAX_STRIPES)
> +
> +struct ipu3_uapi_grid_config {
> + __u8 width; /* 6 or 7 (rgbs_grd_cfg) bits */
> + __u8 height;
> + __u16 block_width_log2:3;
> + __u16 block_height_log2:3;
> + __u16 height_per_slice:8;   /* default value 1 */
> + __u16 x_start;  /* 12 bits */
> + __u16 y_start;
> +#define IPU3_UAPI_GRID_START_MASK((1 << 12) - 1)
> +#define IPU3_UAPI_GRID_Y_START_EN(1 << 15)
> + __u16 x_end;/* 12 bits */
> + __u16 y_end;
> +};

You can't use bitfields in a public API. It is up to the compiler to
decide how to place bitfields, so this is not a stable API.

The other thing that is broken here is 32 vs 64 bit: many of these
structures have different layouts depending on that. That's not going
to work either.

The third part is lack of documentation. Are there public datasheets?
If so, then you can point to that.

Sakari, how did we do that for the omap3? I believe part of the statistics
etc. was in closed documentation as well. Was it documented in the header
or did we just refer to that closed documentation?

Regards,

Hans

> +
> +struct ipu3_uapi_awb_meta_data {
> + __u8 meta_data_buffer[IPU3_UAPI_AWB_MAX_BUFFER_SIZE];
> +};
> +
> +struct ipu3_uapi_awb_raw_buffer {
> + struct ipu3_uapi_awb_meta_data meta_data;
> +};
> +
> +struct IPU3_ALIGN ipu3_uapi_awb_config_s {
> + __u16 rgbs_thr_gr;
> + __u16 rgbs_thr_r;
> + __u16 rgbs_thr_gb;
> + __u16 rgbs_thr_b;
> +/* controls generation of meta_data (like FF enable/disable) */
> 

Re: [RFC] V4L2 unified low-level decoder API

[Randy Li]

On 06/06/2017 03:59 PM, Hugues FRUCHET wrote:

Hi Randy,

Did you get a chance to review interface ?
Oh, I have had look a quick view on it yesterday. The video IP of that 
platform doesn't come from the On2, right?

I would really appreciate your feedback in order that we move forward on
this topic and get at least one implementation merged.
I am a little busy recently, I will give you a feedback before the next 
Monday.

btw, only the MPEG-2 is supported?
I am not very familiar with MPEG-2 standard, I am more familiar with 
MPEG-4 PART 10 or HEVC. As the MPEG-2 is more simple, I may not meet any 
problem to understand it.


Best regards,
Hugues.

On 05/19/2017 10:15 AM, Randy Li wrote:



On 05/19/2017 04:08 PM, Hugues FRUCHET wrote:

Hi all,

Here is the latest st-delta MPEG2 code:
[PATCH v6 0/3] Add support for MPEG-2 in DELTA video decoder
http://www.mail-archive.com/linux-media@vger.kernel.org/msg112067.html
[PATCH v2 0/3] Add a libv4l plugin for video bitstream parsing
http://www.mail-archive.com/linux-media@vger.kernel.org/msg112076.html


I would review it.

Before merging this work Hans would like to have feedback from peers, in
order to be sure that this is inline with other SoC vendors drivers
expectations.

Thomasz, Pawel, could you give your view regarding ChromeOS and Rockchip
driver ?

The work of the rockchip just re-start a few weeks age, I have just
finished the driver probing type as I decide to make a clean beginning.
The video IP of the rockchip is too complext with a different combine.

The pixel format will begin in JPEG then AVC. I am now more familiar
with those codec now.

Laurent, could you give your view regarding Renesas driver ?

I have also added in appendice [7] the materials presented by Laurent at
ELC 2017 in Portland to introduce stateless video codecs and V4L2
request API, thanks for this presentation Laurent.


Best regards,
Hugues.


On 02/07/2017 08:21 AM, Hugues FRUCHET wrote:
Hi,

Here is an update regarding MPEG-2 implementation based on ST video decoder:
* MPEG-2 API + DELTA kernel driver:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg107405.html
* libv4l-codecparsers plugin including MPEG-2 back-end:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg107812.html

Please note that this is implemented & functional using currently available 
V4L2 control framework (no Request API), assuming that user side keeps unicity of 
S_EXT_CTRL() / QBUF(OUTPUT) pair.
Request API will remove this constraint, but the point here is to define 
control interface, as far as I have understood code, Request API will not 
affect those control definitions.

Some updates inline thereafter regarding activities on this subject; me for 
MPEG-2 on ST platform and Randy Li, Nicolas Dufresne, Ayaka for H264 on 
Rockchip platform:


On 11/14/2016 10:55 AM, Hans Verkuil wrote:

On 10/27/2016 09:42 AM, Hugues FRUCHET wrote:

Hi,

This RFC aims to start discussions in order to define the codec
specific controls structures to fulfill the low-level decoder API
needed by non "Stream API" based decoders ("stateless" or "Frame API" based 
decoders).


Let's refer to this as 'stateful' decoders and 'stateless' decoders.
This is the preferred terminology (and much more descriptive than
'Stream' vs 'Frame'). It's also not really a new API, although it does
rely on the Request API.


Several implementation exists now which runs on several SoC and
various software frameworks.
The idea is to find the communalities between all those
implementations and SoC to define a single unified interface in V4L2 includes.
Even if "Request API" is needed to pass those codec specific controls
from userspace down to kernel on a per-buffer basis, we can start
discussions and define the controls in parallel of its development.
We can even propose some implementations based on existing V4L2
control framework (which doesn't support "per-frame" basis) by
ensuring atomicity of sequence S_EXT_CTRL(header[i])/QBUF(stream[i]).
Constraint can then be relaxed when "Request API" is merged.

I would like to propose to work on a "per-codec" basis, having at
least
2 different SoC and 2 different frameworks to test and validate controls.
To do so, I have tried to identify some people that have worked on
this subject and have proposed some implementations, feel free to
correct me and enhance the list if needed:
* MPEG2/MPEG4
- Florent Revest for Allwinner A13 CedarX support [1] tested with
VLC -> libVA + sunxi-cedrus-drv-video -> V4L2
- Myself for STMicroelectronics Delta support [2] tested with
GStreamer V4L2 -> libv4l2 + libv4l-delta plugin -> V4L2

Available on ST platform with [2] & [2.1] patchset series.



* VP8
- Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [3] tested
with Chromium -> V4L2
- Jung Zhao for Rockchip RK3288 VPU support [4] 

* H264
- Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [5] tested
with Chromium -> V4L2
- Randy Li for Rockchip RK3288  VPU support [6] 

Re: [PATCH 02/12] intel-ipu3: mmu: implement driver

[Hans Verkuil]

On 05/06/17 22:39, Yong Zhi wrote:
> From: Tuukka Toivonen 
> 
> This driver translates Intel IPU3 internal virtual
> address to physical address.
> 
> Signed-off-by: Yong Zhi 
> ---
>  drivers/media/pci/intel/ipu3/Kconfig|  11 +
>  drivers/media/pci/intel/ipu3/Makefile   |   1 +
>  drivers/media/pci/intel/ipu3/ipu3-mmu.c | 423 
> 
>  drivers/media/pci/intel/ipu3/ipu3-mmu.h |  73 ++
>  4 files changed, 508 insertions(+)
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-mmu.c
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-mmu.h
> 

Why is this patch and the next patch (03/12) in drivers/media? I wonder
what the reasoning is behind that since it doesn't seem very media
specific.

Regards,

Hans

Re: [PATCH 01/12] videodev2.h, v4l2-ioctl: add IPU3 meta buffer format

[Hans Verkuil]

On 06/06/17 09:25, Sakari Ailus wrote:
> Hi Tomasz,
> 
> On Tue, Jun 06, 2017 at 01:30:41PM +0900, Tomasz Figa wrote:
>> Uhm, +Laurent. Sorry for the noise.
>>
>> On Tue, Jun 6, 2017 at 1:30 PM, Tomasz Figa  wrote:
>>> Hi Yong,
>>>
>>> On Tue, Jun 6, 2017 at 5:39 AM, Yong Zhi  wrote:
 Add the IPU3 specific processing parameter format
 V4L2_META_FMT_IPU3_PARAMS and metadata formats
 for 3A and other statistics:
>>>
>>> Please see my comments inline.
>>>

   V4L2_META_FMT_IPU3_PARAMS
   V4L2_META_FMT_IPU3_STAT_3A
   V4L2_META_FMT_IPU3_STAT_DVS
   V4L2_META_FMT_IPU3_STAT_LACE

 Signed-off-by: Yong Zhi 
 ---
  drivers/media/v4l2-core/v4l2-ioctl.c | 4 
  include/uapi/linux/videodev2.h   | 6 ++
  2 files changed, 10 insertions(+)
>>> [snip]
 +/* Vendor specific - used for IPU3 camera sub-system */
 +#define V4L2_META_FMT_IPU3_PARAMS  v4l2_fourcc('i', 'p', '3', 'p') /* 
 IPU3 params */
 +#define V4L2_META_FMT_IPU3_STAT_3A v4l2_fourcc('i', 'p', '3', 's') /* 
 IPU3 3A statistics */
 +#define V4L2_META_FMT_IPU3_STAT_DVSv4l2_fourcc('i', 'p', '3', 'd') /* 
 IPU3 DVS statistics */
 +#define V4L2_META_FMT_IPU3_STAT_LACE   v4l2_fourcc('i', 'p', '3', 'l') /* 
 IPU3 LACE statistics */
>>>
>>> We had some discussion about this with Laurent and if I remember
>>> correctly, the conclusion was that it might make sense to define one
>>> FourCC for a vendor specific format, ('v', 'n', 'd', 'r') for example,
>>> and then have a V4L2-specific enum within the v4l2_pix_format(_mplane)
>>> struct that specifies the exact vendor data type. It seems saner than
>>> assigning a new FourCC whenever a new hardware revision comes out,
>>> especially given that FourCCs tend to be used outside of the V4L2
>>> world as well and being kind of (de facto) standardized (with existing
>>> exceptions, unfortunately).

I can't remember that discussion, although I've had other discussions with
Laurent related to this on how to handle formats that have many variations
on a theme.

But speaking for this specific case I see no reason to do something special.
There are only four new formats, which seems perfectly reasonable to me.

I don't see the advantage of adding another layer of pixel formats. You still
need to define something for this, one way or the other. And this way doesn't
require API changes.

> If we have four video nodes with different vendor specific formats, how does
> the user tell the formats apart? I presume the user space could use the
> entity names for instance, but that would essentially make them device
> specific.

Well, they are. There really is no way to avoid that.

> I'm not sure if there would be any harm from that in practice though: the
> user will need to find the device nodes somehow and that will be very likely
> based on e.g. entity names.
> 
> How should the documentation be arranged? The documentation is arranged by
> fourccs currently; we'd probably need a separate section for vendor specific
> formats. I think the device name should be listed there as well.

There already is a separate section for metadata formats:

https://hverkuil.home.xs4all.nl/spec/uapi/v4l/meta-formats.html

But perhaps that page should be organized by device. And with some more
detailed information on how to find the video node (i.e. entity names).

> I'd like to have perhaps Hans's comment on that as well.
> 
> I don't really see a drawback in the current way of doing this either; we
> may get a few new fourcc codes occasionally of which I'm not really worried
> about. --- I'd rather ask why should there be an exception on how vendor
> specific formats are defined. And if we do make an exception, then how do
> you decide which one is and isn't vendor specific? There are raw bayer
> format variants that are just raw bayer data but the pixels are arranged
> differently (e.g. CIO2 driver).
> 

For these unique formats I am happy with the way it is today. The problem
is more with 'parameterized' formats. A simple example would be the 4:2:2
interleaved YUV formats where you have four different ways of ordering the
Y, U and V components. Right now we have four defines for that, but things
get out of hand quickly when you have multiple parameters like that.

Laurent and myself discussed that with NVidia some time ago, without
reaching a clear conclusion. Mostly because we couldn't come up with an
API that is simple enough.

Regards,

Hans

Re: [RFC] V4L2 unified low-level decoder API

[Hugues FRUCHET]

Hi Randy,

Did you get a chance to review interface ?
I would really appreciate your feedback in order that we move forward on 
this topic and get at least one implementation merged.

Best regards,
Hugues.

On 05/19/2017 10:15 AM, Randy Li wrote:
> 
> 
> On 05/19/2017 04:08 PM, Hugues FRUCHET wrote:
>> Hi all,
>>
>> Here is the latest st-delta MPEG2 code:
>> [PATCH v6 0/3] Add support for MPEG-2 in DELTA video decoder
>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg112067.html
>> [PATCH v2 0/3] Add a libv4l plugin for video bitstream parsing
>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg112076.html
>>
> I would review it.
>> Before merging this work Hans would like to have feedback from peers, in
>> order to be sure that this is inline with other SoC vendors drivers
>> expectations.
>>
>> Thomasz, Pawel, could you give your view regarding ChromeOS and Rockchip
>> driver ?
> The work of the rockchip just re-start a few weeks age, I have just
> finished the driver probing type as I decide to make a clean beginning.
> The video IP of the rockchip is too complext with a different combine.
> 
> The pixel format will begin in JPEG then AVC. I am now more familiar
> with those codec now.
>> Laurent, could you give your view regarding Renesas driver ?
>>
>> I have also added in appendice [7] the materials presented by Laurent at
>> ELC 2017 in Portland to introduce stateless video codecs and V4L2
>> request API, thanks for this presentation Laurent.
>>
>>
>> Best regards,
>> Hugues.
>>
>>> On 02/07/2017 08:21 AM, Hugues FRUCHET wrote:
>>> Hi,
>>>
>>> Here is an update regarding MPEG-2 implementation based on ST video decoder:
>>> * MPEG-2 API + DELTA kernel driver:
>>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg107405.html
>>> * libv4l-codecparsers plugin including MPEG-2 back-end:
>>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg107812.html
>>>
>>> Please note that this is implemented & functional using currently available 
>>> V4L2 control framework (no Request API), assuming that user side keeps 
>>> unicity of S_EXT_CTRL() / QBUF(OUTPUT) pair.
>>> Request API will remove this constraint, but the point here is to define 
>>> control interface, as far as I have understood code, Request API will not 
>>> affect those control definitions.
>>>
>>> Some updates inline thereafter regarding activities on this subject; me for 
>>> MPEG-2 on ST platform and Randy Li, Nicolas Dufresne, Ayaka for H264 on 
>>> Rockchip platform:
>>>
>>>
>>> On 11/14/2016 10:55 AM, Hans Verkuil wrote:
 On 10/27/2016 09:42 AM, Hugues FRUCHET wrote:
> Hi,
>
> This RFC aims to start discussions in order to define the codec
> specific controls structures to fulfill the low-level decoder API
> needed by non "Stream API" based decoders ("stateless" or "Frame API" 
> based decoders).

 Let's refer to this as 'stateful' decoders and 'stateless' decoders.
 This is the preferred terminology (and much more descriptive than
 'Stream' vs 'Frame'). It's also not really a new API, although it does
 rely on the Request API.

> Several implementation exists now which runs on several SoC and
> various software frameworks.
> The idea is to find the communalities between all those
> implementations and SoC to define a single unified interface in V4L2 
> includes.
> Even if "Request API" is needed to pass those codec specific controls
> from userspace down to kernel on a per-buffer basis, we can start
> discussions and define the controls in parallel of its development.
> We can even propose some implementations based on existing V4L2
> control framework (which doesn't support "per-frame" basis) by
> ensuring atomicity of sequence S_EXT_CTRL(header[i])/QBUF(stream[i]).
> Constraint can then be relaxed when "Request API" is merged.
>
> I would like to propose to work on a "per-codec" basis, having at
> least
> 2 different SoC and 2 different frameworks to test and validate controls.
> To do so, I have tried to identify some people that have worked on
> this subject and have proposed some implementations, feel free to
> correct me and enhance the list if needed:
> * MPEG2/MPEG4
>- Florent Revest for Allwinner A13 CedarX support [1] tested with
> VLC -> libVA + sunxi-cedrus-drv-video -> V4L2
>- Myself for STMicroelectronics Delta support [2] tested with
> GStreamer V4L2 -> libv4l2 + libv4l-delta plugin -> V4L2
>>> Available on ST platform with [2] & [2.1] patchset series.
>>>
>
> * VP8
> - Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [3] tested
> with Chromium -> V4L2
> - Jung Zhao for Rockchip RK3288 VPU support [4]  framework used>
>
> * H264
> - Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [5] tested
> with Chromium -> V4L2
> - Randy Li for Rockchip RK3288  VPU support [6] tested 

Re: Question about Large Custom Coefficients for V4L2 sub-device drivers

[Hans Verkuil]

On 05/06/17 18:32, Rohit Athavale wrote:
> Hello Media Community,
> 
> I am working on a scaler and gamma correction V4L2 sub-device based drivers. 
> A common theme to both of them is that
> the kernel driver is expected bring-up these devices in a working (good) 
> configuration. As it turns out these coefficients are tailor-made
> or are fairly complex to generate dynamically at run-time.
> 
> This implies the driver has to store at least one set of coefficients for 
> each supported configuration. This could easily become 10-20 KB of data 
> stored as a large static array of shorts or integers.
> 
> I have a couple of questions to ask all here :
> 
> 1. What is the best practice for embedding large coefficients ( > 10 KB) into 
> V4L2 sub-device based drivers ?

Typically it is just a static const array. For large arrays it is best to put 
them in a separate
source so it doesn't overwhelm the actual driver code.

> 2. How can user applications feed coefficients to the sub-device based V4L2 
> drivers ? I'm wondering if there is standard ioctl, write or mmap file op 
> that can be performed to achieve this ?

In most cases you can make an extended control (array or compound) for this. If 
the hardware
supports some sort of DMA hardware to load the coefficients quickly into 
memory, then a video
node can be created. But based on what you write that doesn't appear to be 
necessary.

Regards,

Hans

> 
> All inputs will be greatly appreciated :)
> 
> Best Regards,
> Rohit
> 
> 
> 
> This email and any attachments are intended for the sole use of the named 
> recipient(s) and contain(s) confidential information that may be proprietary, 
> privileged or copyrighted under applicable law. If you are not the intended 
> recipient, do not read, copy, or forward this email message or any 
> attachments. Delete this email message and any attachments immediately.
> 

Re: [PATCH 01/12] videodev2.h, v4l2-ioctl: add IPU3 meta buffer format

[Sakari Ailus]

Hi Tomasz,

On Tue, Jun 06, 2017 at 01:30:41PM +0900, Tomasz Figa wrote:
> Uhm, +Laurent. Sorry for the noise.
> 
> On Tue, Jun 6, 2017 at 1:30 PM, Tomasz Figa  wrote:
> > Hi Yong,
> >
> > On Tue, Jun 6, 2017 at 5:39 AM, Yong Zhi  wrote:
> >> Add the IPU3 specific processing parameter format
> >> V4L2_META_FMT_IPU3_PARAMS and metadata formats
> >> for 3A and other statistics:
> >
> > Please see my comments inline.
> >
> >>
> >>   V4L2_META_FMT_IPU3_PARAMS
> >>   V4L2_META_FMT_IPU3_STAT_3A
> >>   V4L2_META_FMT_IPU3_STAT_DVS
> >>   V4L2_META_FMT_IPU3_STAT_LACE
> >>
> >> Signed-off-by: Yong Zhi 
> >> ---
> >>  drivers/media/v4l2-core/v4l2-ioctl.c | 4 
> >>  include/uapi/linux/videodev2.h   | 6 ++
> >>  2 files changed, 10 insertions(+)
> > [snip]
> >> +/* Vendor specific - used for IPU3 camera sub-system */
> >> +#define V4L2_META_FMT_IPU3_PARAMS  v4l2_fourcc('i', 'p', '3', 'p') /* 
> >> IPU3 params */
> >> +#define V4L2_META_FMT_IPU3_STAT_3A v4l2_fourcc('i', 'p', '3', 's') /* 
> >> IPU3 3A statistics */
> >> +#define V4L2_META_FMT_IPU3_STAT_DVSv4l2_fourcc('i', 'p', '3', 'd') /* 
> >> IPU3 DVS statistics */
> >> +#define V4L2_META_FMT_IPU3_STAT_LACE   v4l2_fourcc('i', 'p', '3', 'l') /* 
> >> IPU3 LACE statistics */
> >
> > We had some discussion about this with Laurent and if I remember
> > correctly, the conclusion was that it might make sense to define one
> > FourCC for a vendor specific format, ('v', 'n', 'd', 'r') for example,
> > and then have a V4L2-specific enum within the v4l2_pix_format(_mplane)
> > struct that specifies the exact vendor data type. It seems saner than
> > assigning a new FourCC whenever a new hardware revision comes out,
> > especially given that FourCCs tend to be used outside of the V4L2
> > world as well and being kind of (de facto) standardized (with existing
> > exceptions, unfortunately).

If we have four video nodes with different vendor specific formats, how does
the user tell the formats apart? I presume the user space could use the
entity names for instance, but that would essentially make them device
specific.

I'm not sure if there would be any harm from that in practice though: the
user will need to find the device nodes somehow and that will be very likely
based on e.g. entity names.

How should the documentation be arranged? The documentation is arranged by
fourccs currently; we'd probably need a separate section for vendor specific
formats. I think the device name should be listed there as well.

I'd like to have perhaps Hans's comment on that as well.

I don't really see a drawback in the current way of doing this either; we
may get a few new fourcc codes occasionally of which I'm not really worried
about. --- I'd rather ask why should there be an exception on how vendor
specific formats are defined. And if we do make an exception, then how do
you decide which one is and isn't vendor specific? There are raw bayer
format variants that are just raw bayer data but the pixels are arranged
differently (e.g. CIO2 driver).

-- 
Regards,

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

Re: Support for RGB/YUV 10, 12 BPC(bits per color/component) image data formats in kernel

[Ajay kumar]

Hi Sakari,

On Sat, Jun 3, 2017 at 1:48 PM, Sakari Ailus  wrote:
> Hi Ajay,
>
> On Fri, Jun 02, 2017 at 06:38:53PM +0530, Ajay kumar wrote:
>> Hi all,
>>
>> I have tried searching for RGB/YUV 10, 12 BPC formats in videodev2.h,
>> media-bus-format.h and drm_fourcc.h
>> I could only find RGB 10BPC support in drm_fourcc.h.
>> I guess not much support is present for formats with (BPC > 8) in the kernel.
>
> What's "BPC"? Most YUV and RGB formats have only 8 bits per sample. More
> format definitions may be added if there's a driver that makes use of them.
BPC : Bits Per Color/Component
In my project, we have an image capture device which can capture 10 or
12 bits for each of R, G, B colors, i.e:
R[0:9] G[0:9] B[0:9] and
R[0:11] G[0:11] B[0:11]

I want to define macros for the above formats in videodev2.h.
But, I am not getting the logic behind the naming convention used to
define v4l2_fourcc macros.
ex:
V4L2_PIX_FMT_ARGB32  v4l2_fourcc('A', 'R', '2', '4');

How did they choose the characters 'A', 'R', '2', '4' in the above case?

I want to know the logic/naming convention behind that, so that I can create
new v4l2_fourcc defines for 10, 12 BPC formats and use in my driver.

Thanks,
Ajay Kumar
>>
>> Are there any plans to add fourcc defines for such formats?
>> Also, I wanted to how to define fourcc code for those formats?
>
> --
> Regards,
>
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk