cron job: media_tree daily build: ERRORS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Sat Oct  7 05:00:07 CEST 2017
media-tree git hash:c1301077213d4dca34f01fc372b64d3c4a49a437
media_build git hash:   b829b621b4c2e6c5cbedbd1ce62b4e958f7d13a4
v4l-utils git hash: 997ed5a4abba619282d9ffb8bb173e8589176d73
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.12.0-164

linux-git-arm-at91: ERRORS
linux-git-arm-davinci: ERRORS
linux-git-arm-multi: ERRORS
linux-git-arm-pxa: ERRORS
linux-git-arm-stm32: ERRORS
linux-git-blackfin-bf561: ERRORS
linux-git-i686: OK
linux-git-m32r: WARNINGS
linux-git-mips: ERRORS
linux-git-powerpc64: OK
linux-git-sh: ERRORS
linux-git-x86_64: OK
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.1-i686: ERRORS
linux-4.13-i686: ERRORS
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.1-x86_64: ERRORS
linux-4.13-x86_64: ERRORS
apps: OK
spec-git: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

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

[Yong Zhi]

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

This series was tested on Kaby Lake based platform with 2 sensor configurations,
media topology was pasted at end for reference.

===
= history =
===

Version 5:
- cio2_vb2_start_streaming():
- cio2_vb2_stop_streaming(): removed redundant call of csi2 sub-dev for 
s_stream.
- cio2_vb2_buf_queue(): disabled interrupts for the duration of the buf queue,
  to prevent this code from being pre-empted, as suggested by Tomasz Figa,
  to mitigate the effects of race conditions around vb2 buf queuing code.
  Switched to a finite loop to check for the first free buffer and errored
  out, when there are no buffers available. Removed calls to vb2_plane_vaddr()
  Maintain correct buf queued count, in error cases.
- Implemented system sleep pm ops to support cio2 driver suspend/resume.
- Made the v4l2 buffer and SOF event use sequence from same source.
- cio2_vb2_queue_setup(): remove validating pixelformat suggested by Tomasz
  Figa.
- cio2_v4l2_g_fmt()/cio2_v4l2_s_fmt(): seperated formats on sub-dev and video
  device suggested by Sakari Ailus.
- cio2_v4l2_try_fmt(): seperated video node and subdev format in the get_fmt,
  try_fmt and set_fmt callbacks.
- cio2_queue_event_sof(): added comments suggested by Hans Verkuil
- cio2_queue_init(): re-ordered q->subdev_pads settings. remove 4 lines for
  quantization init.
- cio2_subdev_get_fmt(): get colorspace/xfer_func/ycbcr_enc/quantization
  from sensor suggested by Hans Verkuil.
- cio2_fbpt_entry_init_buf(): stored offset of the first sg_list entry to
  remove calls to vb2_plane_vaddr().
- cio2_subdev_open(): added new callback to intialize the try format.
- cio2_subdev_video_ops(): removed empty implementation suggested by Sakari 
Ailus.
- cio2_notifier_init(): added fwnode binding support for subdevices using
  v4l2_async_notifier_parse_fwnode_endpoints()
  Patch series v15 Unified fwnode endpoint parser, async sub-device notifier
  support, N9 flash DTS is needed for the fwnode binding code to compile.
  https://www.mail-archive.com/linux-media@vger.kernel.org/msg120239.html
  This also requires the following patch (v1) for the fwnode binding to work
  https://patchwork.kernel.org/patch/9986445/
- cio2_notifier_complete(): removed redundant call of
  fwnode_graph_get_remote_endpoint() and fwnode_graph_parse_endpoint().
- Switched to Multi Plane APIs suggested by Tomasz Figa.
  User space changes supporting multi plane APIs can be found here
  
https://chromium-review.googlesource.com/c/chromiumos/platform/arc-camera/+/683802
- ipu3-cio.h: moved macros out of struct cio2_fbpt_entry suggested by Hans 
Verkuil.
- cio2_hw_mbus_to_mipicode(): replaced with cio2_find_format().
- cio2_pci_probe(): cleaned up goto logic on error conditions suggested by 
Tomasz Figa.
- Fixed v4l2_compliance test failures
  added 3 dummy function to pass v4l2_compliance test.
- Extended format example in pixfmt-srggb10-ipu3.rst to show DMA word boundary.

version 4:
- add cio2_video_link_validate() for video entity suggested by Sakari Ailus
- cio2_notifier_complete(): fix comments suggested by Sakari Ailus
- cio2_vb2_buf_queue(): fix the forever loop suggested by Tomasz Figa
- cio2_v4l2_querycap(): use vdev device_caps commented by Hans Verkuil
- cio2_vb2_buf_init(): allocate LOP table per page suggested by Tomasz Figa
- cio2_hw_init(): call cio2_csi2_calc_timing() earlier suggested by Tomasz Figa
- cio2_csi2_calc_timing(): add defalt settings for rx term/settle
- cio2_vb2_queue_setup(): remove num_planes checking suggested by Tomasz Figa
- cio2_buffer_done(): remove setting b->vbb.flags to V4L2_BUF_FLAG_DONE and
  memset of vbb.timecode, also move vb2_set_plane_payload() to
  cio2_vb2_buf_queue() suggested by Sakari Ailus
- cio2_queue_init(): export VB2_DMABUF io_modes suggested by Tomasz Figa
- cio2_vb2_return_all_buffers(): remove state from param list
  suggested by Tomasz Figa
- cio2_vb2_buf_queue(): use vb2_is_streaming() instead of
  vb2_start_streaming_called() suggested by Tomasz Figa
- cio2_pci_probe(): replace hard-coded linux driver version
  suggested by Hans Verkuil
- ipu3-cio2.h: re-order the reg macros suggested by Sakari Ailus
- ipu3-cio2.h: add inline vb2q_to_cio2_queue() suggested by Sakari Ailus
- ipu3-cio2.h: add comments for CIO2_INT_IOC suggested by Tomasz Figa
- ipu3-cio2.h: adjust PBM watermark threshold from 53 to 48 (internal bugfix)
- run v4l2_compliance suggested by Hans Verkuil

Todo list:

- fix possible racy code in cio2_vb2_buf_queue()
- fix v4l2_compliance test failure
- switch to v4l2_pix_format_mplane API if future needs arise

version 3:
- remove cio2_set_power().
- replace dma_alloc_noncoherent() with dma_alloc_coherent().
- apply ffs tricks at possible places.
- change sensor_vc to local variable.
- move ktime_get_ns() a little earlier in the calling order.
- fix multiple assignments(I.e a = b =c)
- define CIO2_PAGE_SIZE for CIO2 PAGE_SIZE, SEN

[PATCH v5 1/3] 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   | 6 ++
 2 files changed, 10 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 79614992ee21..3937945b12dc 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 185d6a0acc06..bcf6a50f6aac 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -668,6 +668,12 @@ 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 */
 
+/* 10bit raw bayer packed, 32 bytes for every 25 pixels, last LSB 6 bits 
unused */
+#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 v5 3/3] 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 
Signed-off-by: Hyungwoo Yang 
Signed-off-by: Rajmohan Mani 
Signed-off-by: Vijaykumar Ramya 
---
 drivers/media/pci/Kconfig|2 +
 drivers/media/pci/Makefile   |3 +-
 drivers/media/pci/intel/Makefile |5 +
 drivers/media/pci/intel/ipu3/Kconfig |   19 +
 drivers/media/pci/intel/ipu3/Makefile|1 +
 drivers/media/pci/intel/ipu3/ipu3-cio2.c | 2052 ++
 drivers/media/pci/intel/ipu3/ipu3-cio2.h |  452 +++
 7 files changed, 2533 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 da28e68c87d8..5932e225f9c0 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 a7e8af0f64a7..d8f98434fb8c 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 ..745c8b2a7819
--- /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 ..0861077a4dae
--- /dev/null
+++ b/drivers/media/pci/intel/ipu3/Kconfig
@@ -0,0 +1,19 @@
+config VIDEO_IPU3_CIO2
+   tristate "Intel ipu3-cio2 driver"
+   depends on VIDEO_V4L2 && PCI
+   depends on VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CONTROLLER
+   depends on HAS_DMA
+   depends on ACPI
+   depends on X86_64 || COMPILE_TEST
+   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 ..20186e3ff2ae
--- /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 ..2c2faa8f1d25
--- /dev/null
+++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
@@ -0,0 +1,2052 @@
+/*
+ * 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"
+
+struct ipu3_cio2_fmt {
+   u32 mbus_code;
+   u32 fourcc;
+   u8 mipicode;
+};
+
+/*
+ * 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 struct ipu3_cio2_fmt formats[] = {
+   {   /* put default entry at beginning */
+   .mbus_code  = MEDIA_BUS_FMT_SGRBG10_1X10,
+   .fourcc = V4L2_PIX_FMT_IPU3_SGRBG10,
+   .mipicode   = 0x2b,
+   }, {
+   .mbus_code  = MEDIA_BUS_FMT_SGBRG10_1X10,
+   .fourcc = V4L2_PI

[PATCH v5 2/3] 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 
Signed-off-by: Hyungwoo Yang 
---
 Documentation/media/uapi/v4l/pixfmt-rgb.rst|   1 +
 .../media/uapi/v4l/pixfmt-srggb10-ipu3.rst | 166 +
 2 files changed, 167 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 4cc27195dc79..cf2ef7df9616 100644
--- a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
@@ -16,6 +16,7 @@ RGB Formats
 pixfmt-srggb10p
 pixfmt-srggb10alaw8
 pixfmt-srggb10dpcm8
+pixfmt-srggb10-ipu3
 pixfmt-srggb12
 pixfmt-srggb12p
 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 ..50292186a8b4
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst
@@ -0,0 +1,166 @@
+.. -*- 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}|p{1.0cm}|p{10.9cm}|p{10.9cm}|p{10.9cm}|p{1.0cm}|p{1.0cm}|p{10.9cm}|p{10.9cm}|p{10.9cm}|p{1.0cm}|p{1.0cm}|p{10.9cm}|p{10.9cm}|p{10.9cm}|p{1.0cm}|p{1.0cm}|p{10.9cm}|p{10.9cm}|p{10.9cm}|p{1.0cm}|p{1.0cm}|p{10.9cm}|p{10.9cm}|p{10.9cm}|p{1.0cm}|p{1.0cm}|p{10.9cm}|
+
+.. flat-table::
+
+* - start + 0:
+  - B\ :sub:`low`
+  - G\ :sub:`0001low` \ (bits 7--2) B\ :sub:`high`\ (bits 1--0)
+  - B\ :sub:`0002low` \ (bits 7--4) G\ :sub:`0001high`\ (bits 3--0)
+  - G\ :sub:`0003low` \ (bits 7--6) B\ :sub:`0002high`\ (bits 5--0)
+  - G\ :sub:`0003high`
+  - B\ :sub:`0004low`
+  - G\ :sub:`0005low` \ (bits 7--2) B\ :sub:`0004high`\ (bits 1--0)
+  - B\ :sub:`0006low` \ (bits 7--4) G\ :sub:`0005high`\ (bits 3--0)
+  - G\ :sub:`0007low` \ (bits 7--6) B\ :sub:`0006high`\ (bits 5--0)
+  - G\ :sub:`0007high`
+  - B\ :sub:`0008low`
+  - G\ :sub:`0009low` \ (bits 7--2) B\ :sub:`0008high`\ (bits 1--0)
+  - B\ :sub:`0010low` \ (bits 7--4) G\ :sub:`0009high`\ (bits 3--0)
+  - G\ :sub:`0011low` \ (bits 7--6) B\ :sub:`0010high`\ (bits 5--0)
+  - G\ :sub:`0011high`
+  - B\ :sub:`0012low`
+  - G\ :sub:`0013low` \ (bits 7--2) B\ :sub:`0012high`\ (bits 1--0)
+  - B\ :sub:`0014low` \ (bits 7--4) G\ :sub:`0013high`\ (bits 3--0)
+  - G\ :sub:`0015low` \ (bits 7--6) B\ :sub:`0014high`\ (bits 5--0)
+  - G\ :sub:`0015high`
+  - B\ :sub:`0016low`
+  - G\ :sub:`0017low` \ (bits 7--2) B\ :sub:`0016high`\ (bits 1--0)
+  - B\ :sub:`0018low` \ (bits 7--4) G\ :sub:`0017high`\ (bits 3--0)
+  - G\ :sub:`0019low` \ (bits 7--6) B\ :sub:`0018high`\ (bits 5--0)
+  - G\ :sub:`0019high`
+  - B\ :sub:`0020low`
+  - G\ :sub:`0021low` \ (bits 7--2) B\ :sub:`0020high`\ (bits 1--0)
+  - B\ :sub:`0022low` \ (bits 7--4) G\ :sub:`0021high`\ (bits 3--0)
+  - G\ :sub:`0023low` \ (bits 7--6) B\ :sub:`0022high`\ (bits 5--0)
+  - G\ :sub:`0023high`
+  - B\ :sub:`0024low`
+  - B\ :sub:`0024high`\ (bits 1--0)
+* - start + 32:
+  - G\ :sub:`0100low`
+  - R\ :sub:`0101low` \ (bits 7--2) G\ :sub:`0100high`\ (bits 1--0)
+  - G\ :sub:`0102low` \ (bits 7--4) R\ :sub:`0101high`\ (bits 3--0)
+  - R\ :sub:`0103low` \ (bits 7--6) G\ :sub:`0102high`\ (bits 5--0)
+  - R\ :sub:`0103high`
+  - G\ :sub:`0104low`
+  - R\ :sub:`0105low` \ (bits 7--2) G\ :sub:`0104high`\ (bits 1--0)
+  - G\ :sub:`0106low` \ (bits 7--4) R\ :sub:`0105high`\ (bits 3--0)
+  - R\ :sub:`0107low` \ (bits 7--6) G\ :sub:`0106high`\ (bits 5--0)
+  - R\ :sub:`0107high`
+  - G\ :sub:`0108low`
+  - R\ :sub:`0109low` \ (bits 7--2) G\

[PATCH 1/2] media: s5p-mfc: check for firmware allocation before requesting firmware

[Shuah Khan]

Check if firmware is allocated before requesting firmware instead of
requesting firmware only to release it if firmware is not allocated.

Signed-off-by: Shuah Khan 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 69ef9c2..f064a0d1 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -55,6 +55,11 @@ int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
 * into kernel. */
mfc_debug_enter();
 
+   if (!dev->fw_buf.virt) {
+   mfc_err("MFC firmware is not allocated\n");
+   return -EINVAL;
+   }
+
for (i = MFC_FW_MAX_VERSIONS - 1; i >= 0; i--) {
if (!dev->variant->fw_name[i])
continue;
@@ -75,11 +80,6 @@ int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
release_firmware(fw_blob);
return -ENOMEM;
}
-   if (!dev->fw_buf.virt) {
-   mfc_err("MFC firmware is not allocated\n");
-   release_firmware(fw_blob);
-   return -EINVAL;
-   }
memcpy(dev->fw_buf.virt, fw_blob->data, fw_blob->size);
wmb();
release_firmware(fw_blob);
-- 
2.7.4

[PATCH 0/2] Fix s5p-mfc lock contention in request firmware paths

[Shuah Khan]

This patch series fixes inefficiencies and lock contention in the request
firmware paths.

Shuah Khan (2):
  media: s5p-mfc: check for firmware allocation before requesting
firmware
  media: s5p-mfc: fix lock confection - request_firmware() once and keep
state

 drivers/media/platform/s5p-mfc/s5p_mfc.c|  4 
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  3 +++
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   | 15 ++-
 3 files changed, 17 insertions(+), 5 deletions(-)

-- 
2.7.4

[PATCH 2/2] media: s5p-mfc: fix lock confection - request_firmware() once and keep state

[Shuah Khan]

Driver calls request_firmware() whenever the device is opened for the
first time. As the device gets opened and closed, dev->num_inst == 1
is true several times. This is not necessary since the firmware is saved
in the fw_buf. s5p_mfc_load_firmware() copies the buffer returned by
the request_firmware() to dev->fw_buf.

fw_buf sticks around until it gets released from s5p_mfc_remove(), hence
there is no need to keep requesting firmware and copying it to fw_buf.

This might have been overlooked when changes are made to free fw_buf from
the device release interface s5p_mfc_release().

Fix s5p_mfc_load_firmware() to call request_firmware() once and keep state.
Change _probe() to load firmware once fw_buf has been allocated.

s5p_mfc_open() and it continues to call s5p_mfc_load_firmware() and init
hardware which is the step where firmware is written to the device.

This addresses the mfc_mutex contention due to repeated request_firmware()
calls from open() in the following circular locking warning:

[  552.194115] qtdemux0:sink/2710 is trying to acquire lock:
[  552.199488]  (&dev->mfc_mutex){+.+.}, at: [] 
s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
[  552.207459]
   but task is already holding lock:
[  552.213264]  (&mm->mmap_sem){}, at: [] vm_mmap_pgoff+0x44/0xb8
[  552.220284]
   which lock already depends on the new lock.

[  552.228429]
   the existing dependency chain (in reverse order) is:
[  552.235881]
   -> #2 (&mm->mmap_sem){}:
[  552.241259]__might_fault+0x80/0xb0
[  552.245331]filldir64+0xc0/0x2f8
[  552.249144]call_filldir+0xb0/0x14c
[  552.253214]ext4_readdir+0x768/0x90c
[  552.257374]iterate_dir+0x74/0x168
[  552.261360]SyS_getdents64+0x7c/0x1a0
[  552.265608]ret_fast_syscall+0x0/0x28
[  552.269850]
   -> #1 (&type->i_mutex_dir_key#2){}:
[  552.276180]down_read+0x48/0x90
[  552.279904]lookup_slow+0x74/0x178
[  552.283889]walk_component+0x1a4/0x2e4
[  552.288222]link_path_walk+0x174/0x4a0
[  552.292555]path_openat+0x68/0x944
[  552.296541]do_filp_open+0x60/0xc4
[  552.300528]file_open_name+0xe4/0x114
[  552.304772]filp_open+0x28/0x48
[  552.308499]kernel_read_file_from_path+0x30/0x78
[  552.313700]_request_firmware+0x3ec/0x78c
[  552.318291]request_firmware+0x3c/0x54
[  552.322642]s5p_mfc_load_firmware+0x54/0x150 [s5p_mfc]
[  552.328358]s5p_mfc_open+0x4e4/0x550 [s5p_mfc]
[  552.94]v4l2_open+0xa0/0x104 [videodev]
[  552.338137]chrdev_open+0xa4/0x18c
[  552.342121]do_dentry_open+0x208/0x310
[  552.346454]path_openat+0x28c/0x944
[  552.350526]do_filp_open+0x60/0xc4
[  552.354512]do_sys_open+0x118/0x1c8
[  552.358586]ret_fast_syscall+0x0/0x28
[  552.362830]
   -> #0 (&dev->mfc_mutex){+.+.}:
   -> #0 (&dev->mfc_mutex){+.+.}:
[  552.368379]lock_acquire+0x6c/0x88
[  552.372364]__mutex_lock+0x68/0xa34
[  552.376437]mutex_lock_interruptible_nested+0x1c/0x24
[  552.382086]s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
[  552.386939]v4l2_mmap+0x54/0x88 [videodev]
[  552.391601]mmap_region+0x3a8/0x638
[  552.395673]do_mmap+0x330/0x3a4
[  552.399400]vm_mmap_pgoff+0x90/0xb8
[  552.403472]SyS_mmap_pgoff+0x90/0xc0
[  552.407632]ret_fast_syscall+0x0/0x28
[  552.411876]
   other info that might help us debug this:

[  552.419848] Chain exists of:
 &dev->mfc_mutex --> &type->i_mutex_dir_key#2 --> &mm->mmap_sem

[  552.431200]  Possible unsafe locking scenario:

[  552.437092]CPU0CPU1
[  552.441598]
[  552.446104]   lock(&mm->mmap_sem);
[  552.449484]lock(&type->i_mutex_dir_key#2);
[  552.456329]lock(&mm->mmap_sem);
[  552.46]   lock(&dev->mfc_mutex);
[  552.465775]
*** DEADLOCK ***

Signed-off-by: Shuah Khan 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 4 
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 3 +++
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   | 5 +
 3 files changed, 12 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 1afde50..4c253fb 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1315,6 +1315,10 @@ static int s5p_mfc_probe(struct platform_device *pdev)
goto err_dma;
}
 
+   ret = s5p_mfc_load_firmware(dev);
+   if (ret)
+   mfc_err("Failed to load FW - try loading from open()\n");
+
mutex_init(&dev->mfc_mutex);
init_waitqueue_head(&dev->queue);
dev->hw_lock = 0;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5

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

[Zhi, Yong]

Hi, Tomasz,

Sorry for the late reply. I will omit the points that have been fixed in v4 or 
discussed earlier by either Tuukka or Sakari 
(https://patchwork.linuxtv.org/patch/41665)

> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Tomasz Figa
> Sent: Monday, June 12, 2017 2:59 AM
> To: Zhi, Yong 
> Cc: linux-media@vger.kernel.org; Sakari Ailus ;
> Zheng, Jian Xu ; Mani, Rajmohan
> ; Toivonen, Tuukka
> ; Hans Verkuil ; Yang,
> Hyungwoo 
> Subject: Re: [PATCH v2 3/3] [media] intel-ipu3: cio2: Add new MIPI-CSI2
> driver
> 
> Hi Yong,
> 
> Please see my comments inline.
> 
> On Wed, Jun 7, 2017 at 10:34 AM, Yong Zhi  wrote:
> > 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
> [snip]
> > 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
> 
> I wonder if it wouldn't make sense to make this depend on X86 (||
> COMPILE_TEST) as well. Are we expecting a standalone PCI(e) card with this
> device in the future?

Will add depends on (X86 || COMPILE_TEST) && 64BIT

> 
> > +   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
> [snip]
> 
> > +   u32 fbpt_rp =
> > +   (readl(cio2->base + CIO2_REG_CDMARI(CIO2_DMA_CHAN))
> > +>> CIO2_CDMARI_FBPT_RP_SHIFT)
> > +   & CIO2_CDMARI_FBPT_RP_MASK;
> > +
> > +   /*
> > +* fbpt_rp is the fbpt entry that the dma is currently 
> > working
> > +* on, but since it could jump to next entry at any time,
> > +* assume that we might already be there.
> > +*/
> > +   fbpt_rp = (fbpt_rp + 1) % CIO2_MAX_BUFFERS;
> 
> Hmm, this is really racy. This code can be pre-empted and not execute for
> quite long time, depending on system load, resuming after the hardware
> goes even further. Technically you could prevent this using
> *_irq_save()/_irq_restore(), but I'd try to find a way that doesn't rely on 
> the
> timing, if possible.

Ack
Will disable interrupts for the duration of this buffer queueing.

> [snip]
> > +static int cio2_v4l2_querycap(struct file *file, void *fh,
> > + struct v4l2_capability *cap) {
> > +   struct cio2_device *cio2 = video_drvdata(file);
> > +
> > +   strlcpy(cap->driver, CIO2_NAME, sizeof(cap->driver));
> > +   strlcpy(cap->card, CIO2_DEVICE_NAME, sizeof(cap->card));
> > +   snprintf(cap->bus_info, sizeof(cap->bus_info),
> > +"PCI:%s", pci_name(cio2->pci_dev));
> > +   cap->device_caps = V4L2_CAP_VIDEO_CAPTURE |
> > + V4L2_CAP_STREAMING;
> 
> Hmm, I thought single plane queue type was deprecated these days and
> _MPLANE recommended for all new drivers. I'll defer this to other reviewers,
> though.

Will switch to MPLANE support in v5.

Re: [PATCH v3 1/2] dt: bindings: media: Document practices for DT bindings, ports, endpoints

[Rob Herring]

On Fri, Sep 29, 2017 at 11:23:40AM +0300, Sakari Ailus wrote:
> Port and endpoint numbering has been omitted in DT binding documentation
> for a large number of devices. Also common properties the device uses have
> been missed in binding documentation. Make it explicit that these things
> need to be documented.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  Documentation/devicetree/bindings/media/video-interfaces.txt | 9 +
>  1 file changed, 9 insertions(+)

Acked-by: Rob Herring 

RE: [PATCH v4 3/3] intel-ipu3: cio2: Add new MIPI-CSI2 driver

[Zhi, Yong]

Hi, Sakari,

Thanks for the review.

> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Sakari Ailus
> Sent: Tuesday, July 11, 2017 3:34 AM
> To: Zhi, Yong 
> Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com;
> hans.verk...@cisco.com; Zheng, Jian Xu ;
> tf...@chromium.org; Mani, Rajmohan ;
> Toivonen, Tuukka ; Yang, Hyungwoo
> ; Vijaykumar, Ramya
> 
> Subject: Re: [PATCH v4 3/3] intel-ipu3: cio2: Add new MIPI-CSI2 driver
> 
> Hi Yong,
> 
> Thanks for the update! This looks pretty good in general, still some more
> comments below.
> 
> Do you happen to have a todo list for the changes that are still planned?
> AFAIR we should have two items in the list at least ---
> 
> 1. Extend the format example to include the DMA word boundary and
> 
> 2. Separate formats on the sub-device and on the video node.
> 

Will include above in v5 update.

> On Mon, Jul 10, 2017 at 06:43:34PM -0500, Yong Zhi wrote:
> > This patch adds CIO2 CSI-2 device driver for
> > Intel's IPU3 camera sub-system support.
> >
> > Signed-off-by: Yong Zhi 
> > Signed-off-by: Hyungwoo Yang 
> > Signed-off-by: Ramya Vijaykumar 
> > ---
> >  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 | 1873
> ++
> >  drivers/media/pci/intel/ipu3/ipu3-cio2.h |  442 +++
> >  7 files changed, 2342 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
> 
> Could you also add VIDEO_V4L2_SUBDEV_API, please?

Ack.

> 
> > +   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..8ecb17f
> > --- /dev/null
> > +++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> > @@ -0,0 +1,1873 @@
> > +/*
> > + * 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

Re: IMX CSI max pixel rate

[Sakari Ailus]

On Fri, Oct 06, 2017 at 12:14:01PM +0200, Philipp Zabel wrote:
> On Fri, 2017-10-06 at 10:49 +0300, Sakari Ailus wrote:
> > On Thu, Oct 05, 2017 at 10:21:16AM -0700, Tim Harvey wrote:
> > > Greetings,
> > > 
> > > I'm working on a HDMI receiver driver for the TDA1997x
> > > (https://lwn.net/Articles/734692/) and wanted to throw an error if
> > > the
> > > detected input resolution/vidout-output-bus-format exceeded the max
> > > pixel rate of the SoC capture bus the chip connects to (in my case
> > > is
> > > the IMX6 CSI which has a limit of 180MP/sec).
> 
> Where does this number come from? I see there are 180 MP/s advertised
> for burst mode still image capture (with up to 35% blanking overhead) in
> the i.MX6Q reference manual. For continuous still image capture, only
> 160 MP/s are advertised. The CSI really supports up to about 240 MHz
> pixel clock (assuming the IPU is clocked at 264 MHz), so MP/s for video
> really depends a lot on the blanking.
> 
> In the IPU display ports chapter, two different numbers are given for
> CSI-2 input, though: 200 MHz for 4 data lanes, and 250 MHz 2 data lanes.
> For 1-3 data lanes, the limiting factor is the maximum CSI-2 link
> frequency, at up to 500 MHz (1000 Mbps/lane).
> 
> > > Any recommendations on where a dt property should live, its naming,
> > > and location/naming and functions to validate the pixel rate or is
> > > there even any interest in this sort of check?
> > 
> > Why a DT property?
> > 
> > We do have V4L2_CID_PIXEL_RATE, would that be applicable for this?
> 
> Isn't this is meant to return the currently set pixel rate at the input
> of a single subdevice, not the total maximum pixel rate supported by its
> input?

Yes. Couldn't it be used for the purpose?

If the maximum rate supported is specific to a hardware component, it'd be
much better to handle that in drivers than put it to board file.

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

Re: [PATCH v4] staging: atomisp: add a driver for ov5648 camera sensor

[Sakari Ailus]

Hi Devid,

On Wed, Oct 04, 2017 at 01:23:36AM +0200, Devid Antonio Filoni wrote:
> I was not able to properly test this patch on my Lenovo Miix 310 due to other
> issues with atomisp, the output is the same as ov2680 driver (OVTI2680) which
> is very similar to ov5648. As reported by dmesg, atomisp-gmin-platform fails
> to load CamClk, ClkSrc, CsiPort, CsiLanes variables from ACPI (although they
> are set as showed by DSDT) and it fails to get regulators. My Miix 310 uses
> AXP PMIC (INT33F4:00) which, as far as I can understand by looking at
> 01org/ProductionKernelQuilts code, it's yet not supported by mainline kernel.

Hmm. In other words this driver isn't usable due to lack of other drivers.
Even if they'd be in place, this hasn't been tested. What would be the
likelihood of it functioning in the end?

Would it make sense to first get the other drivers to upstream and then see
what's the status of atomisp? The atomisp driver has a number of entries in
its TODO file, one of which is making the sensor drivers to use the
standard kernel interfaces to work with the main driver (atomisp), so that
they could be used with any ISP / bridge driver.

Also, the interface the atomisp uses with the sensor drivers as well as how
the board specific information from firmware is conveyed to the sensor
drivers will change to what the rest of the sensor drivers are using. I
think a most straightforward way would be to amend the ACPI tables to
include the necessary information.

Therefore, applying this patch would not have an effective improvement to
the users in form of support for new systems and would make the upcoming
interface changes more difficult as there would be one more driver to
change (and test).

For this reason I'm tempted to postpone applying this patch at least until
the other drivers are available.

Andy, Alan; any opinion?

-- 
Kind regards,

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

Re: [PATCH v7 5/7] media: open.rst: Adjust some terms to match the glossary

[Sakari Ailus]

Hi Mauro,

On Wed, Sep 27, 2017 at 07:23:47PM -0300, Mauro Carvalho Chehab wrote:
> As we now have a glossary, some terms used on open.rst
> require adjustments.
> 
> Acked-by: Hans Verkuil 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/media/uapi/v4l/open.rst | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/media/uapi/v4l/open.rst 
> b/Documentation/media/uapi/v4l/open.rst
> index f603bc9b49a0..0daf0c122c19 100644
> --- a/Documentation/media/uapi/v4l/open.rst
> +++ b/Documentation/media/uapi/v4l/open.rst
> @@ -143,7 +143,7 @@ Related Devices
>  Devices can support several functions. For example video capturing, VBI
>  capturing and radio support.
>  
> -The V4L2 API creates different nodes for each of these functions.
> +The V4L2 API creates different V4L2 device nodes for each of these functions.

A V4L2 device node is an instance of the V4L2 API. At the very least we
should call them "V4L2 device node types", not device nodes only. This
simply would suggests they're separate.

s/creates/defines/ ?

>  
>  The V4L2 API was designed with the idea that one device node could
>  support all functions. However, in practice this never worked: this
> @@ -153,17 +153,17 @@ switching a device node between different functions 
> only works when
>  using the streaming I/O API, not with the
>  :ref:`read() `/\ :ref:`write() ` API.
>  
> -Today each device node supports just one function.
> +Today each V4L2 device node supports just one function.
>  
>  Besides video input or output the hardware may also support audio
>  sampling or playback. If so, these functions are implemented as ALSA PCM
>  devices with optional ALSA audio mixer devices.
>  
>  One problem with all these devices is that the V4L2 API makes no
> -provisions to find these related devices. Some really complex devices
> -use the Media Controller (see :ref:`media_controller`) which can be
> -used for this purpose. But most drivers do not use it, and while some
> -code exists that uses sysfs to discover related devices (see
> +provisions to find these related V4L2 device nodes. Some really complex
> +hardware use the Media Controller (see :ref:`media_controller`) which can
> +be used for this purpose. But several drivers do not use it, and while some
> +code exists that uses sysfs to discover related V4L2 device nodes (see
>  libmedia_dev in the
>  `v4l-utils `__ git
>  repository), there is no library yet that can provide a single API

-- 
Regards,

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

[PATCH v8 1/3] media: dt: bindings: Add binding for tango HW IR decoder

[Marc Gonzalez]

Add DT binding for the HW IR decoder embedded in SMP86xx/SMP87xx.

Signed-off-by: Marc Gonzalez 
---
 .../devicetree/bindings/media/tango-ir.txt  | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/tango-ir.txt

diff --git a/Documentation/devicetree/bindings/media/tango-ir.txt 
b/Documentation/devicetree/bindings/media/tango-ir.txt
new file mode 100644
index ..a9f00c2bf897
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/tango-ir.txt
@@ -0,0 +1,21 @@
+Sigma Designs Tango IR NEC/RC-5/RC-6 decoder (SMP86xx and SMP87xx)
+
+Required properties:
+
+- compatible: "sigma,smp8642-ir"
+- reg: address/size of NEC+RC5 area, address/size of RC6 area
+- interrupts: spec for IR IRQ
+- clocks: spec for IR clock (typically the crystal oscillator)
+
+Optional properties:
+
+- linux,rc-map-name: see Documentation/devicetree/bindings/media/rc.txt
+
+Example:
+
+   ir@10518 {
+   compatible = "sigma,smp8642-ir";
+   reg = <0x10518 0x18>, <0x105e0 0x1c>;
+   interrupts = <21 IRQ_TYPE_EDGE_RISING>;
+   clocks = <&xtal>;
+   };
-- 
2.14.2

[PATCH v8 3/3] media: rc: Add driver for tango HW IR decoder

[Marc Gonzalez]

From: Mans Rullgard 

The tango HW IR decoder supports NEC, RC-5, RC-6 protocols.

Signed-off-by: Mans Rullgard 
Signed-off-by: Marc Gonzalez 
---
Changes between v7 and v8
* RC_MAP_TANGO as default keymap
* Define and use NEC_ANY macro
---
 drivers/media/rc/Kconfig|  10 ++
 drivers/media/rc/Makefile   |   1 +
 drivers/media/rc/tango-ir.c | 280 
 3 files changed, 291 insertions(+)
 create mode 100644 drivers/media/rc/tango-ir.c

diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index d9ce8ff55d0c..e80d4362e769 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -469,6 +469,16 @@ config IR_SIR
   To compile this driver as a module, choose M here: the module will
   be called sir-ir.
 
+config IR_TANGO
+   tristate "Sigma Designs SMP86xx IR decoder"
+   depends on RC_CORE
+   depends on ARCH_TANGO || COMPILE_TEST
+   ---help---
+  Adds support for the HW IR decoder embedded on Sigma Designs
+  Tango-based systems (SMP86xx, SMP87xx).
+  The HW decoder supports NEC, RC-5, RC-6 IR protocols.
+  When compiled as a module, look for tango-ir.
+
 config IR_ZX
tristate "ZTE ZX IR remote control"
depends on RC_CORE
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 9bc6a3980ed0..643797dc971b 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -44,3 +44,4 @@ obj-$(CONFIG_IR_SERIAL) += serial_ir.o
 obj-$(CONFIG_IR_SIR) += sir_ir.o
 obj-$(CONFIG_IR_MTK) += mtk-cir.o
 obj-$(CONFIG_IR_ZX) += zx-irdec.o
+obj-$(CONFIG_IR_TANGO) += tango-ir.o
diff --git a/drivers/media/rc/tango-ir.c b/drivers/media/rc/tango-ir.c
new file mode 100644
index ..97941a619301
--- /dev/null
+++ b/drivers/media/rc/tango-ir.c
@@ -0,0 +1,280 @@
+/*
+ * Copyright (C) 2015 Mans Rullgard 
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "tango-ir"
+
+#define IR_NEC_CTRL0x00
+#define IR_NEC_DATA0x04
+#define IR_CTRL0x08
+#define IR_RC5_CLK_DIV 0x0c
+#define IR_RC5_DATA0x10
+#define IR_INT 0x14
+
+#define NEC_TIME_BASE  560
+#define RC5_TIME_BASE  1778
+
+#define RC6_CTRL   0x00
+#define RC6_CLKDIV 0x04
+#define RC6_DATA0  0x08
+#define RC6_DATA1  0x0c
+#define RC6_DATA2  0x10
+#define RC6_DATA3  0x14
+#define RC6_DATA4  0x18
+
+#define RC6_CARRIER36000
+#define RC6_TIME_BASE  16
+
+#define NEC_CAP(n) ((n) << 24)
+#define GPIO_SEL(n)((n) << 16)
+#define DISABLE_NEC(BIT(4) | BIT(8))
+#define ENABLE_RC5 (BIT(0) | BIT(9))
+#define ENABLE_RC6 (BIT(0) | BIT(7))
+#define ACK_IR_INT (BIT(0) | BIT(1))
+#define ACK_RC6_INT(BIT(31))
+
+#define NEC_ANY (RC_PROTO_BIT_NEC | RC_PROTO_BIT_NECX | RC_PROTO_BIT_NEC32)
+
+struct tango_ir {
+   void __iomem *rc5_base;
+   void __iomem *rc6_base;
+   struct rc_dev *rc;
+   struct clk *clk;
+};
+
+static void tango_ir_handle_nec(struct tango_ir *ir)
+{
+   u32 v, code;
+   enum rc_proto proto;
+
+   v = readl_relaxed(ir->rc5_base + IR_NEC_DATA);
+   if (!v) {
+   rc_repeat(ir->rc);
+   return;
+   }
+
+   code = ir_nec_bytes_to_scancode(v, v >> 8, v >> 16, v >> 24, &proto);
+   rc_keydown(ir->rc, proto, code, 0);
+}
+
+static void tango_ir_handle_rc5(struct tango_ir *ir)
+{
+   u32 data, field, toggle, addr, cmd, code;
+
+   data = readl_relaxed(ir->rc5_base + IR_RC5_DATA);
+   if (data & BIT(31))
+   return;
+
+   field = data >> 12 & 1;
+   toggle = data >> 11 & 1;
+   addr = data >> 6 & 0x1f;
+   cmd = (data & 0x3f) | (field ^ 1) << 6;
+
+   code = RC_SCANCODE_RC5(addr, cmd);
+   rc_keydown(ir->rc, RC_PROTO_RC5, code, toggle);
+}
+
+static void tango_ir_handle_rc6(struct tango_ir *ir)
+{
+   u32 data0, data1, toggle, mode, addr, cmd, code;
+
+   data0 = readl_relaxed(ir->rc6_base + RC6_DATA0);
+   data1 = readl_relaxed(ir->rc6_base + RC6_DATA1);
+
+   mode = data0 >> 1 & 7;
+   if (mode != 0)
+   return;
+
+   toggle = data0 & 1;
+   addr = data0 >> 16;
+   cmd = data1;
+
+   code = RC_SCANCODE_RC6_0(addr, cmd);
+   rc_keydown(ir->rc, RC_PROTO_RC6_0, code, toggle);
+}
+
+static irqreturn_t tango_ir_irq(int irq, void *dev_id)
+{
+   struct tango_ir *ir = dev_id;
+   unsigned int rc5_stat;
+   unsigned int rc6_stat;
+
+   rc5_stat = readl_relaxed(ir->rc5_base + IR_INT);
+   writel_relaxed(rc5_stat, ir->rc5_base + IR_INT);
+
+   rc6_stat = readl_relaxed(ir->rc6_base + RC6_CTRL);
+   writel_relaxed(

[PATCH v8 2/3] media: rc: Add tango keymap

[Marc Gonzalez]

Add a keymap for the Sigma Designs Vantage (dev board) remote control.

Signed-off-by: Marc Gonzalez 
---
Changes between v7 and v8
* Add legalese boiler plate
* Define RC_PROTO_NECX
* Move RC_MAP_TANGO to alphabetical order
---
 drivers/media/rc/keymaps/Makefile   |  1 +
 drivers/media/rc/keymaps/rc-tango.c | 92 +
 include/media/rc-map.h  |  1 +
 3 files changed, 94 insertions(+)
 create mode 100644 drivers/media/rc/keymaps/rc-tango.c

diff --git a/drivers/media/rc/keymaps/Makefile 
b/drivers/media/rc/keymaps/Makefile
index af6496d709fb..3c1e31321e21 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-reddo.o \
rc-snapstream-firefly.o \
rc-streamzap.o \
+   rc-tango.o \
rc-tbs-nec.o \
rc-technisat-ts35.o \
rc-technisat-usb2.o \
diff --git a/drivers/media/rc/keymaps/rc-tango.c 
b/drivers/media/rc/keymaps/rc-tango.c
new file mode 100644
index ..1c6e8875d46f
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-tango.c
@@ -0,0 +1,92 @@
+/*
+ * Copyright (C) 2017 Sigma Designs
+ *
+ * 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.
+ */
+
+#include 
+#include 
+
+static struct rc_map_table tango_table[] = {
+   { 0x4cb4a, KEY_POWER },
+   { 0x4cb48, KEY_FILE },
+   { 0x4cb0f, KEY_SETUP },
+   { 0x4cb4d, KEY_SUSPEND },
+   { 0x4cb4e, KEY_VOLUMEUP },
+   { 0x4cb44, KEY_EJECTCD },
+   { 0x4cb13, KEY_TV },
+   { 0x4cb51, KEY_MUTE },
+   { 0x4cb52, KEY_VOLUMEDOWN },
+
+   { 0x4cb41, KEY_1 },
+   { 0x4cb03, KEY_2 },
+   { 0x4cb42, KEY_3 },
+   { 0x4cb45, KEY_4 },
+   { 0x4cb07, KEY_5 },
+   { 0x4cb46, KEY_6 },
+   { 0x4cb55, KEY_7 },
+   { 0x4cb17, KEY_8 },
+   { 0x4cb56, KEY_9 },
+   { 0x4cb1b, KEY_0 },
+   { 0x4cb59, KEY_DELETE },
+   { 0x4cb5a, KEY_CAPSLOCK },
+
+   { 0x4cb47, KEY_BACK },
+   { 0x4cb05, KEY_SWITCHVIDEOMODE },
+   { 0x4cb06, KEY_UP },
+   { 0x4cb43, KEY_LEFT },
+   { 0x4cb01, KEY_RIGHT },
+   { 0x4cb0a, KEY_DOWN },
+   { 0x4cb02, KEY_ENTER },
+   { 0x4cb4b, KEY_INFO },
+   { 0x4cb09, KEY_HOME },
+
+   { 0x4cb53, KEY_MENU },
+   { 0x4cb12, KEY_PREVIOUS },
+   { 0x4cb50, KEY_PLAY },
+   { 0x4cb11, KEY_NEXT },
+   { 0x4cb4f, KEY_TITLE },
+   { 0x4cb0e, KEY_REWIND },
+   { 0x4cb4c, KEY_STOP },
+   { 0x4cb0d, KEY_FORWARD },
+   { 0x4cb57, KEY_MEDIA_REPEAT },
+   { 0x4cb16, KEY_ANGLE },
+   { 0x4cb54, KEY_PAUSE },
+   { 0x4cb15, KEY_SLOW },
+   { 0x4cb5b, KEY_TIME },
+   { 0x4cb1a, KEY_AUDIO },
+   { 0x4cb58, KEY_SUBTITLE },
+   { 0x4cb19, KEY_ZOOM },
+
+   { 0x4cb5f, KEY_RED },
+   { 0x4cb1e, KEY_GREEN },
+   { 0x4cb5c, KEY_YELLOW },
+   { 0x4cb1d, KEY_BLUE },
+};
+
+static struct rc_map_list tango_map = {
+   .map = {
+   .scan = tango_table,
+   .size = ARRAY_SIZE(tango_table),
+   .rc_proto = RC_PROTO_NECX,
+   .name = RC_MAP_TANGO,
+   }
+};
+
+static int __init init_rc_map_tango(void)
+{
+   return rc_map_register(&tango_map);
+}
+
+static void __exit exit_rc_map_tango(void)
+{
+   rc_map_unregister(&tango_map);
+}
+
+module_init(init_rc_map_tango)
+module_exit(exit_rc_map_tango)
+
+MODULE_AUTHOR("Sigma Designs");
+MODULE_LICENSE("GPL");
diff --git a/include/media/rc-map.h b/include/media/rc-map.h
index 2a160e6e823c..b4ddcb62c993 100644
--- a/include/media/rc-map.h
+++ b/include/media/rc-map.h
@@ -300,6 +300,7 @@ struct rc_map *rc_map_get(const char *name);
 #define RC_MAP_REDDO "rc-reddo"
 #define RC_MAP_SNAPSTREAM_FIREFLY"rc-snapstream-firefly"
 #define RC_MAP_STREAMZAP "rc-streamzap"
+#define RC_MAP_TANGO "rc-tango"
 #define RC_MAP_TBS_NEC   "rc-tbs-nec"
 #define RC_MAP_TECHNISAT_TS35"rc-technisat-ts35"
 #define RC_MAP_TECHNISAT_USB2"rc-technisat-usb2"
-- 
2.14.2

Re: [PATCH v7 4/7] media: open.rst: document devnode-centric and mc-centric types

[Sakari Ailus]

Hi Mauro,

On Wed, Sep 27, 2017 at 07:23:46PM -0300, Mauro Carvalho Chehab wrote:
> When we added support for omap3, back in 2010, we added a new
> type of V4L2 devices that aren't fully controlled via the V4L2
> device node.
> 
> Yet, we have never clearly documented in the V4L2 specification
> the differences between the two types.
> 
> Let's document them based on the the current implementation.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/media/uapi/v4l/open.rst | 40 
> +++
>  1 file changed, 40 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/open.rst 
> b/Documentation/media/uapi/v4l/open.rst
> index 18030131ef77..f603bc9b49a0 100644
> --- a/Documentation/media/uapi/v4l/open.rst
> +++ b/Documentation/media/uapi/v4l/open.rst
> @@ -7,6 +7,46 @@ Opening and Closing Devices
>  ***
>  
>  
> +.. _v4l2_hardware_control:
> +
> +
> +Types of V4L2 media hardware control
> +
> +
> +V4L2 hardware periferal is usually complex: support for it is
> +implemented via a V4L2 main driver and often by several additional drivers.
> +The main driver always exposes one or more **V4L2 device nodes**
> +(see :ref:`v4l2_device_naming`) with are responsible for implementing
> +data streaming, if applicable.
> +
> +The other drivers are called **V4L2 sub-devices** and provide control to

s/drivers/devices/

> +other hardware components usually connected via a serial bus (like
> +I²C, SMBus or SPI). Depending on the main driver, they can be implicitly
> +controlled directly by the main driver or explicitly via
> +the **V4L2 sub-device API** (see :ref:`subdev`).
> +
> +When V4L2 was originally designed, there was only one type of
> +media hardware control: via the **V4L2 device nodes**. We refer to this kind
> +of control as **V4L2 device node centric** (or, simply, 
> "**vdevnode-centric**").

I think this could be easier understood if we start with the differences
instead of what we call the types. I'd also refer to interfaces rather than
their instances.

How about (pending finalising discussion on naming):

When **V4L2** was originally designed, the **V4L2 device** served the
purpose of both control and data interfaces and there was no separation
between the two interface-wise. V4L2 controls, setting inputs and outputs,
format configuration and buffer related operations were all performed
through the same **V4L2 device nodes**. Devices offering such interface are
called **V4L2 device node centric**.

Later on, support for the **Media controller** interface was added to V4L2
in order to better support complex **V4L2 aggregate devices** where the
**V4L2** interface alone could no longer meaningfully serve as both a
control and a data interface. On such aggregate devices, **V4L2** interface
remains a data interface whereas control takes place through the **Media
controller** and **V4L2 sub-device** interfaces. Stream control is an
exception to this: streaming is enabled and disabled through the **V4L2**
interface. These devices are called **Media controller centric**.

**MC-centric** aggregate devices provide more versatile control of the
hardware than **V4L2 device node centric** devices. On **MC-centric**
aggregate devices the **V4L2 sub-device nodes** represent specific parts of
the **V4L2 aggregate device**, to which they enable control.

Also, the additional versatility of **MC-centric** aggregate devices comes
with additional responsibilities, the main one of which is the requirements
of the user configuring the device pipeline before starting streaming. This
typically involves configuring the links using the **Media controller**
interface and the media bus formats on pads (at both ends of the links)
using the **V4L2 sub-device** interface.

> +
> +Later (kernel 2.6.39), a new type of periferal control was
> +added in order to support complex media hardware that are common for embedded
> +systems. This type of periferal is controlled mainly via the media
> +controller and V4L2 sub-devices. So, it is called
> +**Media controller centric** (or, simply, "**MC-centric**") control.
> +
> +For **vdevnode-centric** media hardware control, the media hardware is
> +controlled via the **V4L2 device nodes**. They may optionally support the
> +:ref:`media controller API ` as well,
> +in order to inform the application which device nodes are available
> +(see :ref:`related`).
> +
> +For **MC-centric** media hardware control it is required to configure
> +the pipelines via the :ref:`media controller API ` before
> +the periferal can be used. For such devices, the sub-devices' configuration
> +can be controlled via the :ref:`sub-device API `, which creates one
> +device node per sub-device.
> +
>  .. _v4l2_device_naming:
>  
>  V4L2 Device Node Naming

-- 
Kind regards,

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

Re: [PATCH v7 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Sakari Ailus]

Hi Mauro,

On Fri, Oct 06, 2017 at 01:22:29PM +0300, Sakari Ailus wrote:
> > +V4L2 device node
> > +   A device node that is associated to a V4L2 main driver,
> > +   as specified in :ref:`v4l2_device_naming`.

I think we need to name the interface, not so much their instances.

How about adding:

V4L2
Video4Linux 2 interface. The interface implemented by **V4L2 device
nodes**.

and:

V4L2 device node
A device node implementing the **V4L2** interface.

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

Re: [PATCH v15 29/32] et8ek8: Add support for flash and lens devices

[Pavel Machek]

On Thu 2017-10-05 00:50:48, Sakari Ailus wrote:
> Parse async sub-devices related to the sensor by switching the async
> sub-device registration function.
> 
> Signed-off-by: Sakari Ailus 
> Acked-by: Hans Verkuil 

Acked-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v15 28/32] smiapp: Add support for flash and lens devices

[Pavel Machek]

On Thu 2017-10-05 00:50:47, Sakari Ailus wrote:
> Parse async sub-devices related to the sensor by switching the async
> sub-device registration function.
> 
> These types devices aren't directly related to the sensor, but are
> nevertheless handled by the smiapp driver due to the relationship of these
> component to the main part of the camera module --- the sensor.
> 
> This does not yet address providing the user space with information on how
> to associate the sensor or lens devices but the kernel now has the
> necessary information to do that.
> 
> Signed-off-by: Sakari Ailus 
> Acked-by: Hans Verkuil 

Acked-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v7 3/3] media: rc: Add tango keymap

[Marc Gonzalez]

On 06/10/2017 12:47, Måns Rullgård wrote:

> Sean Young writes:
> 
>> Looks great, just some minor nitpicks.
>>
>> I think you need a header with copyright statement and GPL version(s).
> 
> Is this even copyrightable?

My thoughts, exactly.

I don't mind *not* providing a copyright statement and GPL boiler plate.
But if Sean requires one to submit, I'll include the proper legalese.

Regards.

Re: [PATCH v7 3/3] media: rc: Add tango keymap

[Måns Rullgård]

Sean Young  writes:

> Hi Marc,
>
> Looks great, just some minor nitpicks.
>
> On Thu, Oct 05, 2017 at 04:54:11PM +0200, Marc Gonzalez wrote:
>> Add a keymap for the Sigma Designs Vantage (dev board) remote control.
>> 
>> Signed-off-by: Marc Gonzalez 
>> ---
>>  drivers/media/rc/keymaps/Makefile   |  1 +
>>  drivers/media/rc/keymaps/rc-tango.c | 84 
>> +
>>  drivers/media/rc/tango-ir.c |  2 +-
>>  include/media/rc-map.h  |  1 +
>>  4 files changed, 87 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/media/rc/keymaps/rc-tango.c
>> 
>> diff --git a/drivers/media/rc/keymaps/Makefile 
>> b/drivers/media/rc/keymaps/Makefile
>> index af6496d709fb..3c1e31321e21 100644
>> --- a/drivers/media/rc/keymaps/Makefile
>> +++ b/drivers/media/rc/keymaps/Makefile
>> @@ -88,6 +88,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
>>  rc-reddo.o \
>>  rc-snapstream-firefly.o \
>>  rc-streamzap.o \
>> +rc-tango.o \
>>  rc-tbs-nec.o \
>>  rc-technisat-ts35.o \
>>  rc-technisat-usb2.o \
>> diff --git a/drivers/media/rc/keymaps/rc-tango.c 
>> b/drivers/media/rc/keymaps/rc-tango.c
>> new file mode 100644
>> index ..c76651695959
>> --- /dev/null
>> +++ b/drivers/media/rc/keymaps/rc-tango.c
>> @@ -0,0 +1,84 @@
>
> I think you need a header with copyright statement and GPL version(s).

Is this even copyrightable?

-- 
Måns Rullgård

Re: [PATCH v2 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver

[Dmitry Osipenko]

On 06.10.2017 06:57, kbuild test robot wrote:
> Hi Dmitry,
> 
> [auto build test WARNING on staging/staging-testing]
> [also build test WARNING on v4.14-rc3 next-20170929]
> [cannot apply to tegra/for-next]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Dmitry-Osipenko/staging-Introduce-NVIDIA-Tegra20-video-decoder-driver/20171006-101015
> config: ia64-allmodconfig (attached as .config)
> compiler: ia64-linux-gcc (GCC) 6.2.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=ia64 
> 
> All warnings (new ones prefixed by >>):
> 
>In file included from include/linux/kernel.h:13:0,
> from include/linux/clk.h:16,
> from drivers/staging/tegra-vde/vde.c:11:
>drivers/staging/tegra-vde/vde.c: In function 'tegra_vde_setup_hw_context':
>>> drivers/staging/tegra-vde/vde.c:51:11: warning: format '%X' expects 
>>> argument of type 'unsigned int', but argument 5 has type 'long long 
>>> unsigned int' [-Wformat=]
>  pr_debug("%s: %d: 0x%08X => " #__addr ")\n", \
>   ^
>include/linux/printk.h:285:21: note: in definition of macro 'pr_fmt'
> #define pr_fmt(fmt) fmt
> ^~~
>include/linux/printk.h:333:2: note: in expansion of macro 
> 'dynamic_pr_debug'
>  dynamic_pr_debug(fmt, ##__VA_ARGS__)
>  ^~~~
>drivers/staging/tegra-vde/vde.c:51:2: note: in expansion of macro 
> 'pr_debug'
>  pr_debug("%s: %d: 0x%08X => " #__addr ")\n", \
>  ^~~~
>drivers/staging/tegra-vde/vde.c:362:2: note: in expansion of macro 'VDE_WR'
>  VDE_WR(bitstream_data_paddr + bitstream_data_size,
>  ^~
>>> drivers/staging/tegra-vde/vde.c:51:11: warning: format '%X' expects 
>>> argument of type 'unsigned int', but argument 5 has type 'phys_addr_t {aka 
>>> long long unsigned int}' [-Wformat=]
>  pr_debug("%s: %d: 0x%08X => " #__addr ")\n", \
>   ^
>include/linux/printk.h:285:21: note: in definition of macro 'pr_fmt'
> #define pr_fmt(fmt) fmt
> ^~~
>include/linux/printk.h:333:2: note: in expansion of macro 
> 'dynamic_pr_debug'
>  dynamic_pr_debug(fmt, ##__VA_ARGS__)
>  ^~~~
>drivers/staging/tegra-vde/vde.c:51:2: note: in expansion of macro 
> 'pr_debug'
>  pr_debug("%s: %d: 0x%08X => " #__addr ")\n", \
>  ^~~~
>drivers/staging/tegra-vde/vde.c:435:2: note: in expansion of macro 'VDE_WR'
>  VDE_WR(bitstream_data_paddr, vde->regs + SXE(0x6C));
>  ^~
>drivers/staging/tegra-vde/vde.c: In function 'tegra_vde_attach_dmabuf':
>drivers/staging/tegra-vde/vde.c:531:40: warning: format '%d' expects 
> argument of type 'int', but argument 3 has type 'size_t {aka long unsigned 
> int}' [-Wformat=]
>   dev_err(dev, "Too small dmabuf size %d @0x%lX, "
>^
>drivers/staging/tegra-vde/vde.c: In function 'tegra_vde_ioctl_decode_h264':
>drivers/staging/tegra-vde/vde.c:855:16: warning: format '%X' expects 
> argument of type 'unsigned int', but argument 3 has type 'phys_addr_t {aka 
> long long unsigned int}' [-Wformat=]
>   dev_err(dev, "Decoding failed, "
>^~~
> 
> vim +51 drivers/staging/tegra-vde/vde.c
> 
>   > 11#include 
> 12#include 
> 13#include 
> 14#include 
> 15#include 
> 16#include 
> 17#include 
> 18#include 
> 19#include 
> 20#include 
> 21#include 
> 22#include 
> 23#include 
> 24
> 25#include 
> 26
> 27#include "uapi.h"
> 28
> 29#define SXE(offt)   (0x + (offt)) /* Syntax 
> Engine */
> 30#define BSEV(offt)  (0x1000 + (offt)) /* Video 
> Bitstream Engine */
> 31#define MBE(offt)   (0x2000 + (offt)) /* Macroblock 
> Engin

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

[Edgar Thier]

Hi Kieran,

> Rather than forward declaring the function ... Could you put the function 
> higher
> in the module please?

Will do. Patch will come as a reply shortly.


>>> +   if (data == NULL)
>>> +   return -ENOMEM;
>>
>> This will set the callers 'flags' to -ENOMEM ? Is that desired?
>>
>> Of course removing the kmalloc will fix that anyway ...
> Perhaps we have to return an empty flags here, which is what we will return if
> the uvc_query_ctrl() fails anyway.

I wanted to keep the changes to a minimum. So I didn't touch the return values.
Are there any checks done for -ENOMEM et al? I didn't see any.

-Edgar

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

[Edgar Thier]

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

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

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

diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index 20397ab..5091086 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -1630,6 +1630,41 @@ static void uvc_ctrl_fixup_xu_info(struct uvc_device 
*dev,
 }

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

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

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

uvc_ctrl_fixup_xu_info(dev, ctrl, info);

@@ -1902,6 +1920,8 @@ static int uvc_ctrl_add_info(struct uvc_device *dev, 
struct uvc_control *ctrl,
goto done;
}

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

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

Re: [PATCH v6 2/7] media: open.rst: better document device node naming

[Sakari Ailus]

On Tue, Aug 29, 2017 at 10:17:51AM -0300, Mauro Carvalho Chehab wrote:
> Right now, only kAPI documentation describes the device naming.
> However, such description is needed at the uAPI too. Add it,
> and describe how to get an unique identify for a given device.
> 
> Acked-by: Hans Verkuil 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Sakari Ailus 

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

Re: [PATCH v7 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Sakari Ailus]

Hi Mauro,

Thanks for continuing the work on this!

On Wed, Sep 27, 2017 at 07:23:43PM -0300, Mauro Carvalho Chehab wrote:
> Add a glossary of terms for V4L2, as several concepts are complex
> enough to cause misunderstandings.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/media/uapi/v4l/glossary.rst | 136 
> ++
>  Documentation/media/uapi/v4l/v4l2.rst |   1 +
>  2 files changed, 137 insertions(+)
>  create mode 100644 Documentation/media/uapi/v4l/glossary.rst
> 
> diff --git a/Documentation/media/uapi/v4l/glossary.rst 
> b/Documentation/media/uapi/v4l/glossary.rst
> new file mode 100644
> index ..b6767da1a46e
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/glossary.rst
> @@ -0,0 +1,136 @@
> +
> +Glossary
> +
> +
> +.. note::
> +
> +   This goal of section is to standardize the terms used within the V4L2
> +   documentation. It is written incrementally as they are standardized in
> +   the V4L2 documentation. So, it is a Work In Progress.
> +
> +.. Please keep the glossary entries in alphabetical order
> +
> +.. glossary::
> +
> +Bridge driver
> + The same as V4L2 main driver.

Not all V4L2 main drivers can be bridge drivers. Mem-to-mem devices, for
instance. How about:

A driver for a device receiving image data from another device (or
transmitting it to a sub-device) controlled by a sub-device driver. Bridge
drivers typically act as V4L2 main drivers.

> +
> +Device Node
> + A character device node in the file system used to control and do
> + input/output data transfers from/to a Kernel driver.
> +
> +Digital Signal Processor - DSP
> + A specialized microprocessor, with its architecture optimized for
> + the operational needs of digital signal processing.
> +
> +Driver
> + The part of the Linux Kernel that implements support
> + for a hardware component.
> +
> +Field-programmable Gate Array - FPGA
> + A field-programmable gate array (FPGA) is an integrated circuit
> + designed to be configured by a customer or a designer after
> + manufacturing.
> +
> + See https://en.wikipedia.org/wiki/Field-programmable_gate_array.
> +
> +Hardware component
> + A subset of the media hardware. For example an I²C or SPI device,
> + or an IP block inside an SoC or FPGA.
> +
> +Image Signal Processor - ISP
> + A specialised processor that implements a set of algorithms for
> + processing image data. ISPs may implement algorithms for lens
> + shading correction, demosaic, scaling and pixel format conversion
> + as well as produce statistics for the use of the control
> + algorithms (e.g. automatic exposure, white balance and focus).

And perhaps add:

ISP drivers often contain a receiver for image data from external source
such as a sensor and act as V4L2 main driver.

> +
> +Inter-Integrated Circuit - I²C
> + A  multi-master, multi-slave, packet switched, single-ended,
> + serial computer bus used to control V4L2 sub-devices.
> +
> + See http://www.nxp.com/docs/en/user-guide/UM10204.pdf.
> +
> +Integrated circuit - IC
> + A set of electronic circuits on one small flat piece of
> + semiconductor material, normally silicon.
> +
> + Also known as chip.
> +
> +Intellectual property core - IP core
> + In electronic design a semiconductor intellectual property core,
> + is a reusable unit of logic, cell, or integrated circuit layout
> + design that is the intellectual property of one party.
> + IP cores may be licensed to another party or can be owned
> + and used by a single party alone.
> +
> + See 
> https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core).
> +
> +IP block
> + The same as IP core.
> +
> +MC-centric
> + V4L2 hardware that requires a Media controller.
> +
> + See :ref:`v4l2_hardware_control`.
> +
> +Media Controller
> + An API designed to expose and control devices and sub-devices
> + relationships to applications.
> +
> + See :ref:`media_controller`.
> +
> +Media hardware
> + A group of hardware components that together make a larger
> + user-facing functional media hardware. For instance the SoC ISP IP
> + cores and external camera sensors together make a
> + camera media hardware.
> +
> +Media hardware control
> + Type of control for a media hardware supported by V4L2 drivers.
> +
> + See :ref:`v4l2_hardware_control`.
> +
> +Microprocessor
> + An electronic circuitry that carries out the instructions
> + of a computer program by performing the basic arithmetic, logical,
> + control and input/output (I/O) operations specified by the
> + instructions on a single integrated circuit.
> +
> +SMBus
> + A subset of I²C, with defines a stricter usage of the bus.
> +
> +Serial Peripheral Interface Bus - SPI
> + Synchronous serial communication interface speci

Re: IMX CSI max pixel rate

[Philipp Zabel]

On Fri, 2017-10-06 at 10:49 +0300, Sakari Ailus wrote:
> On Thu, Oct 05, 2017 at 10:21:16AM -0700, Tim Harvey wrote:
> > Greetings,
> > 
> > I'm working on a HDMI receiver driver for the TDA1997x
> > (https://lwn.net/Articles/734692/) and wanted to throw an error if
> > the
> > detected input resolution/vidout-output-bus-format exceeded the max
> > pixel rate of the SoC capture bus the chip connects to (in my case
> > is
> > the IMX6 CSI which has a limit of 180MP/sec).

Where does this number come from? I see there are 180 MP/s advertised
for burst mode still image capture (with up to 35% blanking overhead) in
the i.MX6Q reference manual. For continuous still image capture, only
160 MP/s are advertised. The CSI really supports up to about 240 MHz
pixel clock (assuming the IPU is clocked at 264 MHz), so MP/s for video
really depends a lot on the blanking.

In the IPU display ports chapter, two different numbers are given for
CSI-2 input, though: 200 MHz for 4 data lanes, and 250 MHz 2 data lanes.
For 1-3 data lanes, the limiting factor is the maximum CSI-2 link
frequency, at up to 500 MHz (1000 Mbps/lane).

> > Any recommendations on where a dt property should live, its naming,
> > and location/naming and functions to validate the pixel rate or is
> > there even any interest in this sort of check?
> 
> Why a DT property?
> 
> We do have V4L2_CID_PIXEL_RATE, would that be applicable for this?

Isn't this is meant to return the currently set pixel rate at the input
of a single subdevice, not the total maximum pixel rate supported by its
input?

regards
Philipp

Re: [PATCH v5 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Sakari Ailus]

Hi Mauro,

On Thu, Oct 05, 2017 at 09:26:51AM -0300, Mauro Carvalho Chehab wrote:
> > > > > +
> > > > > + See :ref:`media_controller`.
> > > > > +
> > > > > +MC-centric
> > > > > + V4L2 hardware that requires a Media controller.
> > > > > +
> > > > > + See :ref:`v4l2_hardware_control`.
> > > > > +
> > > > > +Microprocessor
> > > > > + An electronic circuitry that carries out the instructions
> > > > > + of a computer program by performing the basic arithmetic, 
> > > > > logical,
> > > > > + control and input/output (I/O) operations specified by the
> > > > > + instructions on a single integrated circuit.
> > > > > +
> > > > > +SMBus
> > > > > + A subset of I²C, with defines a stricter usage of the bus.
> > > > > +
> > > > > +Serial Peripheral Interface Bus - SPI
> > > > 
> > > > We don't have "Bus" in I²C, I'd leave it out here, too.  
> > > 
> > > I2C is a serial bus (and it is implemented as a bus inside the Kernel).
> > > Take a look at Documentation/i2c/summary.  
> > 
> > I don't disagree with that, but at the same time this is not related to my
> > suggestion.
> > 
> > "Bus" is not part of the abbreviation SPI, therefore we should not suggest
> > that here.
> 
> Ah, so you proposal here is just to replace:
> 
>   Serial Peripheral Interface Bus - SPI
> 
> To
>   Serial Peripheral Interface - SPI
> 
> Right? If so, it sounds OK.

Yes, please. That's exactly what I had in mind.

...

> > > > > +V4L2 hardware
> > > > > + A hardware used to on a media device supported by the V4L2
> > > > > + subsystem.
> > > > > +
> > > > > +V4L2 hardware control
> > > > > + The type of hardware control that a device supports.
> > > > > +
> > > > > + See :ref:`v4l2_hardware_control`.
> > > > > +
> > > > > +V4L2 main driver
> > > > > + The V4L2 device driver that implements the main logic to talk 
> > > > > with
> > > > > + the V4L2 hardware.
> > > > > +
> > > > > + Also known as bridge driver.
> > > > 
> > > > Is UVC driver a bridge driver? How about instead:  
> > > 
> > > Yes, sure: UVC driver is a bridge driver/main driver. It is the UVC driver
> > > that sends/receives data from the USB bus and send to the sensors.
> > > It also sends data via URB to the USB host driver, with, in turn send it
> > > to send to CPU (usually via DMA - although some USB drivers actually 
> > > implement direct I/O for short messages).
> > >   
> > > > Bridge and ISP drivers typically are V4L2 main drivers.  
> > > 
> > > We don't have a concept of an "ISP driver". Adding it sounds very  
> > 
> > I think we do have that roughly as much as we do have bridge driver. We
> > definitely also support devices that are called ISPs, therefore we do have
> > ISP drivers.
> 
> We have drivers for things implemented via ISP. However, right now,
> there's no distinction at the driver if the functionality is implemented
> on software (ISP) or in hardware. 
> 
> > 
> > > confusing, as an ISP hardware may actually implement different
> > > functions - so it ends by being supported by multiple drivers.  
> > 
> > Typically ISPs are controlled by a single driver as the sub-blocks in an
> > ISP usually can only be found in that very ISP.
> 
> I'm almost sure that this is not true for Exynos drivers. There are
> m2m drivers and normal drivers for the same ISP (doing different things,
> like format conversion, scaling, etc).

I don't know the Exynos hardware. There are exceptions but they tend to be
increasingly rare as extra memory hops hurt performance and increase power
consumption in common use cases.

If there is a split to multiple devices, then usually the first device is
CSI-2 receiver plus DMA (bridge) and the second is the ISP (i.e. where the
processing happens).

-- 
Regards,

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

Re: [PATCHv2 2/2] drm: adv7511/33: add HDMI CEC support

[Hans Verkuil]

On 06/10/17 06:26, Archit Taneja wrote:
> Hi Hans,
> 
> On 09/19/2017 01:03 PM, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> Add support for HDMI CEC to the drm adv7511/adv7533 drivers.
>>
>> The CEC registers that we need to use are identical for both drivers,
>> but they appear at different offsets in the register map.
> 
> The patch looks good to me. I can go ahead an queue it to drm-misc-next.
> 
> There were some minor comments on the DT bindings patch. Are you planning
> to send a new patch for that?

Yes. Now that this patch has been reviewed I'll post a v3 for the first
fixing those comments. Expect to see it Monday at the latest.

Regards,

Hans

Re: [PATCH v5 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

[Sakari Ailus]

On Thu, Oct 05, 2017 at 03:39:29PM -0300, Mauro Carvalho Chehab wrote:
> Em Thu, 5 Oct 2017 11:21:07 +0300
> Sakari Ailus  escreveu:
> 
> > Hi Mauro,
> > 
> > My apologies for the late reply.
> > 
> > On Tue, Aug 29, 2017 at 10:07:50AM -0300, Mauro Carvalho Chehab wrote:
> > > Em Tue, 29 Aug 2017 10:47:48 +0300
> > > Sakari Ailus  escreveu:
> > >   
> > > > Hi Mauro,
> > > > 
> > > > Thanks for the update. A few comments below.
> > > > 
> > > > On Mon, Aug 28, 2017 at 09:53:55AM -0300, Mauro Carvalho Chehab wrote:  
> > > > > Add a glossary of terms for V4L2, as several concepts are complex
> > > > > enough to cause misunderstandings.
> > > > > 
> > > > > Signed-off-by: Mauro Carvalho Chehab 
> > > > > ---
> > > > >  Documentation/media/uapi/v4l/glossary.rst | 147 
> > > > > ++
> > > > >  Documentation/media/uapi/v4l/v4l2.rst |   1 +
> > > > >  2 files changed, 148 insertions(+)
> > > > >  create mode 100644 Documentation/media/uapi/v4l/glossary.rst
> > > > > 
> > > > > diff --git a/Documentation/media/uapi/v4l/glossary.rst 
> > > > > b/Documentation/media/uapi/v4l/glossary.rst
> > > > > new file mode 100644
> > > > > index ..0b6ab5adec81
> > > > > --- /dev/null
> > > > > +++ b/Documentation/media/uapi/v4l/glossary.rst
> > > > > @@ -0,0 +1,147 @@
> > > > > +
> > > > > +Glossary
> > > > > +
> > > > > +
> > > > > +.. note::
> > > > > +
> > > > > +   This goal of section is to standardize the terms used within the 
> > > > > V4L2
> > > > > +   documentation. It is written incrementally as they are 
> > > > > standardized in
> > > > > +   the V4L2 documentation. So, it is a Work In Progress.
> > > > 
> > > > I'd leave the WiP part out.  
> > > 
> > > IMO, it is important to mention it, as the glossary, right now, covers
> > > only what's used on the first two sections of the API book. There are
> > > a lot more to be covered.  
> > 
> > Works for me.
> > 
> > >   
> > > >   
> > > > > +
> > > > > +.. Please keep the glossary entries in alphabetical order
> > > > > +
> > > > > +.. glossary::
> > > > > +
> > > > > +Bridge driver
> > > > > + The same as V4L2 main driver.
> > > > 
> > > > I've understood bridges being essentially a bus receiver + DMA. Most 
> > > > ISPs
> > > > contain both but have more than that. How about:
> > > > 
> > > > A driver for a bus (e.g. parallel, CSI-2) receiver and DMA. Bridge 
> > > > drivers
> > > > typically act as V4L2 main drivers.  
> > > 
> > > No, only on some drivers the bridge driver has DMA. A vast amount of
> > > drivers (USB ones) don't implement any DMA inside the driver, as it is
> > > up to the USB host driver to implement support for DMA.
> > > 
> > > There are even some USB host drivers that don't always use DMA for I/O 
> > > transfers, using direct I/O if the message is smaller than a threshold
> > > or not multiple of the bus word. This is pretty common on SoC USB host
> > > drivers.
> > > 
> > > In any case, for the effect of this spec, and for all discussions we
> > > ever had about it, bridge driver == V4L2 main driver. I don't
> > > see any reason why to distinguish between them.  
> > 
> > I think you should precisely define what a bridge driver means. Generally
> > ISP drivers aren't referred to as bridge drivers albeit they, too, function
> > as V4L2 main drivers.
> 
> Btw, this is already defined, currently, at v4l2-subdev.h:
> 
>  * Sub-devices are devices that are connected somehow to the main bridge
>  * device. These devices are usually audio/video muxers/encoders/decoders or
>  * sensors and webcam controllers.
>  *
>  * Usually these devices are controlled through an i2c bus, but other busses
>  * may also be used.
> 
> Please notice that there it says: "main bridge" :-)
> 
> Such definition was added since the beginning of the subdev concept, back in
> 2008 and was reviewed by several V4L core developers:

A lot has happened since 2008. :-)

Anyway, I'll review the latest set.

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

Re: IMX CSI max pixel rate

[Sakari Ailus]

On Thu, Oct 05, 2017 at 10:21:16AM -0700, Tim Harvey wrote:
> Greetings,
> 
> I'm working on a HDMI receiver driver for the TDA1997x
> (https://lwn.net/Articles/734692/) and wanted to throw an error if the
> detected input resolution/vidout-output-bus-format exceeded the max
> pixel rate of the SoC capture bus the chip connects to (in my case is
> the IMX6 CSI which has a limit of 180MP/sec).
> 
> Any recommendations on where a dt property should live, its naming,
> and location/naming and functions to validate the pixel rate or is
> there even any interest in this sort of check?

Why a DT property?

We do have V4L2_CID_PIXEL_RATE, would that be applicable for this?

https://hverkuil.home.xs4all.nl/spec/uapi/v4l/extended-controls.html#image-process-control-ids>

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