cron job: media_tree daily build: ABI WARNING

[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 Feb 17 05:00:13 CET 2018
media-tree git hash:29422737017b866d4a51014cc7522fa3a99e8852
media_build git hash:   d144cfe4b3c37ece55ae27778c99765d4943c4fa
v4l-utils git hash: 432d9ebfcea65337647fd4e458f76b0417ea1c2f
gcc version:i686-linux-gcc (GCC) 7.3.0
sparse version: v0.5.0-3994-g45eb2282
smatch version: v0.5.0-3994-g45eb2282
host hardware:  x86_64
host os:4.14.0-3-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.98-i686: WARNINGS
linux-3.2.98-x86_64: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-i686: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.53-i686: WARNINGS
linux-3.16.53-x86_64: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.93-i686: WARNINGS
linux-3.18.93-x86_64: WARNINGS
linux-3.19-i686: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.49-i686: WARNINGS
linux-4.1.49-x86_64: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.115-i686: OK
linux-4.4.115-x86_64: OK
linux-4.5.7-i686: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-i686: OK
linux-4.7.5-x86_64: WARNINGS
linux-4.8-i686: OK
linux-4.8-x86_64: WARNINGS
linux-4.9.80-i686: OK
linux-4.9.80-x86_64: OK
linux-4.10.14-i686: OK
linux-4.10.14-x86_64: WARNINGS
linux-4.11-i686: OK
linux-4.11-x86_64: WARNINGS
linux-4.12.1-i686: OK
linux-4.12.1-x86_64: WARNINGS
linux-4.13-i686: OK
linux-4.13-x86_64: OK
linux-4.14.17-i686: OK
linux-4.14.17-x86_64: OK
linux-4.15.2-i686: OK
linux-4.15.2-x86_64: OK
linux-4.16-rc1-i686: OK
linux-4.16-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
ABI WARNING: change for arm-at91
ABI WARNING: change for arm-davinci
ABI WARNING: change for arm-multi
ABI WARNING: change for arm-pxa
ABI WARNING: change for arm-stm32
ABI WARNING: change for arm64
ABI WARNING: change for i686
ABI WARNING: change for m32r
ABI WARNING: change for mips
ABI WARNING: change for powerpc64
ABI WARNING: change for sh
ABI WARNING: change for x86_64
sparse: WARNINGS
smatch: 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] media: imx.rst: Fix formatting errors

[Steve Longerbeam]

Fix a few formatting errors.

Signed-off-by: Steve Longerbeam 
---
 Documentation/media/v4l-drivers/imx.rst | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/Documentation/media/v4l-drivers/imx.rst 
b/Documentation/media/v4l-drivers/imx.rst
index 3c4f58b..18e3141 100644
--- a/Documentation/media/v4l-drivers/imx.rst
+++ b/Documentation/media/v4l-drivers/imx.rst
@@ -213,9 +213,11 @@ To give an example of crop and /2 downscale, this will 
crop a
 1280x960 input frame to 640x480, and then /2 downscale in both
 dimensions to 320x240 (assumes ipu1_csi0 is linked to ipu1_csi0_mux):
 
-media-ctl -V "'ipu1_csi0_mux':2[fmt:UYVY2X8/1280x960]"
-media-ctl -V "'ipu1_csi0':0[crop:(0,0)/640x480]"
-media-ctl -V "'ipu1_csi0':0[compose:(0,0)/320x240]"
+.. code-block:: none
+
+   media-ctl -V "'ipu1_csi0_mux':2[fmt:UYVY2X8/1280x960]"
+   media-ctl -V "'ipu1_csi0':0[crop:(0,0)/640x480]"
+   media-ctl -V "'ipu1_csi0':0[compose:(0,0)/320x240]"
 
 Frame Skipping in ipuX_csiY
 ---
@@ -229,8 +231,10 @@ at the source pad.
 The following example reduces an assumed incoming 60 Hz frame
 rate by half at the IDMAC output source pad:
 
-media-ctl -V "'ipu1_csi0':0[fmt:UYVY2X8/640x480@1/60]"
-media-ctl -V "'ipu1_csi0':2[fmt:UYVY2X8/640x480@1/30]"
+.. code-block:: none
+
+   media-ctl -V "'ipu1_csi0':0[fmt:UYVY2X8/640x480@1/60]"
+   media-ctl -V "'ipu1_csi0':2[fmt:UYVY2X8/640x480@1/30]"
 
 Frame Interval Monitor in ipuX_csiY
 ---
@@ -422,8 +426,7 @@ This pipeline uses the preprocess encode entity to route 
frames directly
 from the CSI to the IC, to carry out scaling up to 1024x1024 resolution,
 CSC, flipping, and image rotation:
 
--> ipuX_csiY:1 -> 0:ipuX_ic_prp:1 -> 0:ipuX_ic_prpenc:1 ->
-   ipuX_ic_prpenc capture
+-> ipuX_csiY:1 -> 0:ipuX_ic_prp:1 -> 0:ipuX_ic_prpenc:1 -> ipuX_ic_prpenc 
capture
 
 Motion Compensated De-interlace:
 
@@ -432,8 +435,7 @@ This pipeline routes frames from the CSI direct pad to the 
VDIC entity to
 support motion-compensated de-interlacing (high motion mode only),
 scaling up to 1024x1024, CSC, flip, and rotation:
 
--> ipuX_csiY:1 -> 0:ipuX_vdic:2 -> 0:ipuX_ic_prp:2 ->
-   0:ipuX_ic_prpvf:1 -> ipuX_ic_prpvf capture
+-> ipuX_csiY:1 -> 0:ipuX_vdic:2 -> 0:ipuX_ic_prp:2 -> 0:ipuX_ic_prpvf:1 -> 
ipuX_ic_prpvf capture
 
 
 Usage Notes
@@ -458,8 +460,8 @@ This platform requires the OmniVision OV5642 module with a 
parallel
 camera interface, and the OV5640 module with a MIPI CSI-2
 interface. Both modules are available from Boundary Devices:
 
-https://boundarydevices.com/product/nit6x_5mp
-https://boundarydevices.com/product/nit6x_5mp_mipi
+- https://boundarydevices.com/product/nit6x_5mp
+- https://boundarydevices.com/product/nit6x_5mp_mipi
 
 Note that if only one camera module is available, the other sensor
 node can be disabled in the device tree.
-- 
2.7.4

Re: i.MX53 using imx-media to capture analog video through ADV7180

[Steve Longerbeam]

Hi Mathew,


On 02/14/2018 07:44 AM, Fabio Estevam wrote:

[Adding Steve and Philipp in case they could provide some suggestions]

On Wed, Feb 14, 2018 at 1:21 PM, Matthew Starr  wrote:

I have successfully modified device tree files in the mainline 4.15.1 kernel to 
get a display product using the i.MX53 processor to initialize the imx-media 
drivers.  I think up to this point they have only been tested on i.MX6 
processors.


Yes that's correct. I have not tested imx-media driver on any i.MX5 targets.
There are likely issues with i.MX5 support.


   I am using two ADV7180 analog capture chips, one per CSI port, on this 
display product.

I have everything initialize successfully at boot, but I am unable to get the 
media-ctl command to link the ADV7180 devices to the CSI ports.  I used the 
following website as guidance of how to setup the links between media devices:
https://linuxtv.org/downloads/v4l-dvb-apis/v4l-drivers/imx.html

When trying to link the ADV7180 chip to a CSI port, I use the following command 
and get the result below:

 media-ctl -v -l "'adv7180 1-0021':0->'ipu1_csi0':0[1]"

 No link between "adv7180 1-0021":0 and "ipu1_csi0":0
 media_parse_setup_link: Unable to parse link
 Unable to parse link: Invalid argument (22)

How do I get the ADV7180 and CSI port on the i.MX53 processor to link?

The difference for the i.MX53 compared to the i.MX6 processor is that there is 
only one IPU and no mipi support, so my device tree does not use any video-mux 
or mux devices.  Could this have something to do with why I can't link the 
ADV7180 to the CSI port?


It probably does. Clearly there was no media link defined from
the adv7180 to any of the CSI ports, which can also be seen from
the media topology you printed below.

As long as the OF graph is correct, I don't see why this would have
happened. Please send two things:

1. Your patches to DT files
2. dmesg output.

There could be more issues with i.MX5 support in imx-media, but
it should be figured out why the media links from adv7180 to the CSI
ports were not established first.


Steve



Here is the output of the "media-ctl -p -v" command:

Opening media device /dev/media0
Enumerating entities
looking up device: 81:10
looking up device: 81:11
looking up device: 81:12
looking up device: 81:4
looking up device: 81:13
looking up device: 81:5
looking up device: 81:14
looking up device: 81:15
looking up device: 81:16
looking up device: 81:17
looking up device: 81:6
looking up device: 81:18
looking up device: 81:7
looking up device: 81:19
looking up device: 81:20
looking up device: 81:8
looking up device: 81:21
looking up device: 81:9
Found 18 entities
Enumerating pads and links
Media controller API version 4.15.1

Media device information

driver  imx-media
model   imx-media
serial
bus info
hw revision 0x0
driver version  4.15.1

Device topology
- entity 1: adv7180 1-0021 (1 pad, 0 link)
 type V4L2 subdev subtype Unknown flags 20004
 device node name /dev/v4l-subdev0
 pad0: Source
 [fmt:UYVY8_2X8/720x480 field:interlaced]

- entity 3: adv7180 1-0020 (1 pad, 0 link)
 type V4L2 subdev subtype Unknown flags 20004
 device node name /dev/v4l-subdev1
 pad0: Source
 [fmt:UYVY8_2X8/720x480 field:interlaced]

- entity 5: ipu1_csi1 (3 pads, 3 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev2
 pad0: Sink
 [fmt:UYVY8_2X8/640x480 field:none
  crop.bounds:(0,0)/640x480
  crop:(0,0)/640x480
  compose.bounds:(0,0)/640x480
  compose:(0,0)/640x480]
 pad1: Source
 [fmt:AYUV8_1X32/640x480 field:none]
 -> "ipu1_ic_prp":0 []
 -> "ipu1_vdic":0 []
 pad2: Source
 [fmt:AYUV8_1X32/640x480 field:none]
 -> "ipu1_csi1 capture":0 []

- entity 9: ipu1_csi1 capture (1 pad, 1 link)
 type Node subtype V4L flags 0
 device node name /dev/video4
 pad0: Sink
 <- "ipu1_csi1":2 []

- entity 15: ipu1_csi0 (3 pads, 3 links)
  type V4L2 subdev subtype Unknown flags 0
  device node name /dev/v4l-subdev3
 pad0: Sink
 [fmt:UYVY8_2X8/640x480 field:none
  crop.bounds:(0,0)/640x480
  crop:(0,0)/640x480
  compose.bounds:(0,0)/640x480
  compose:(0,0)/640x480]
 pad1: Source
 [fmt:AYUV8_1X32/640x480 field:none]
 -> "ipu1_ic_prp":0 []
 -> "ipu1_vdic":0 [ENABLED]
 pad2: Source
 [fmt:AYUV8_1X32/640x480 field:none]
 -> "ipu1_csi0 capture":0 []

- entity 19: ipu1_csi0 capture (1 pad, 1 link)
  type Node subtype 

[PATCH] media: intel-ipu3: cio2: Use SPDX license headers

[Yong Zhi]

Adopt SPDX license headers for ipu3 cio2 driver.

Signed-off-by: Yong Zhi 
---
 drivers/media/pci/intel/ipu3/ipu3-cio2.c | 12 ++--
 drivers/media/pci/intel/ipu3/ipu3-cio2.h | 14 ++
 2 files changed, 4 insertions(+), 22 deletions(-)

diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c 
b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
index 6cb31f4b..af2da03a160f 100644
--- a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
+++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
@@ -1,14 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
- * 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.
+ * Copyright (C) 2017 Intel Corporation
  *
  * Based partially on Intel IPU4 driver written by
  *  Sakari Ailus 
diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.h 
b/drivers/media/pci/intel/ipu3/ipu3-cio2.h
index 78a5799f08e7..240635be7a31 100644
--- a/drivers/media/pci/intel/ipu3/ipu3-cio2.h
+++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.h
@@ -1,15 +1,5 @@
-/*
- * 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.
- */
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2017 Intel Corporation */
 
 #ifndef __IPU3_CIO2_H
 #define __IPU3_CIO2_H
-- 
2.7.4

Re: Mygica 230C defined in two drivers

[Brüns , Stefan]

On Freitag, 5. Januar 2018 16:39:20 CET Olli Salonen wrote:
> Hi Stefan and all,
> 
> I noticed that the Mygica 230C is currently defined in two different
> drivers.
> 
> in dvbsky.c:
> 
> { DVB_USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230C,
> _t230c_props, "MyGica Mini DVB-T2 USB Stick T230C",
> RC_MAP_TOTAL_MEDIA_IN_HAND_02) },
> 
> 
> in cxusb.c:
> 
> [MYGICA_T230] = {
> USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230)
> },
> [MYGICA_T230C] = {
> USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230+1)
> },
> 
> and in dvb-usb-ids.h:
> 
> #define USB_PID_MYGICA_T2300xc688
> #define USB_PID_MYGICA_T230C0xc689
> 
> I think you've played around with this device earlier. Do you have any
> insight on which driver works better or all they all the same?
> 
> Cheers,
> -olli


An patch addressing this issue has been lingering in patchwork for 5+ weeks 
..

https://patchwork.linuxtv.org/patch/46404/
https://patchwork.linuxtv.org/patch/46403/

Regards,

Stefan

Re: [PATCH v3 3/9] uapi: media: New fourcc codes needed by Xilinx Video IP

[Nicolas Dufresne]

Le mercredi 14 février 2018 à 22:42 -0800, Satish Kumar Nagireddy a écrit :
> From: Jeffrey Mouroux 
> 
> The Xilinx Video Framebuffer DMA IP supports video memory formats
> that are not represented in the current V4L2 fourcc library. This
> patch adds those missing fourcc codes. This includes both new
> 8-bit and 10-bit pixel formats.

As Hyon spotted, this is missing Documentation/media/uapi/v4l/ doc.
But there is some comment here that can be improved, see next:

> 
> Signed-off-by: Satish Kumar Nagireddy 
> ---
>  include/uapi/linux/videodev2.h | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 9827189..9fa4313c 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -509,7 +509,10 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_XBGR32  v4l2_fourcc('X', 'R', '2', '4') /* 32  
> BGRX-8-8-8-8  */
>  #define V4L2_PIX_FMT_RGB32   v4l2_fourcc('R', 'G', 'B', '4') /* 32  
> RGB-8-8-8-8   */
>  #define V4L2_PIX_FMT_ARGB32  v4l2_fourcc('B', 'A', '2', '4') /* 32  
> ARGB-8-8-8-8  */
> +#define V4L2_PIX_FMT_BGRA32  v4l2_fourcc('A', 'B', 'G', 'R') /* 32  
> ABGR-8-8-8-8  */
>  #define V4L2_PIX_FMT_XRGB32  v4l2_fourcc('B', 'X', '2', '4') /* 32  
> XRGB-8-8-8-8  */
> +#define V4L2_PIX_FMT_BGRX32  v4l2_fourcc('X', 'B', 'G', 'R') /* 32  
> XBGR-8-8-8-8 */
> +#define V4L2_PIX_FMT_XBGR30  v4l2_fourcc('R', 'X', '3', '0') /* 32  
> XBGR-2-10-10-10 */
> 
>  /* Grey formats */
>  #define V4L2_PIX_FMT_GREYv4l2_fourcc('G', 'R', 'E', 'Y') /*  8  
> Greyscale */
> @@ -537,12 +540,16 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_VYUYv4l2_fourcc('V', 'Y', 'U', 'Y') /* 16  YUV 
> 4:2:2 */
>  #define V4L2_PIX_FMT_Y41Pv4l2_fourcc('Y', '4', '1', 'P') /* 12  YUV 
> 4:1:1 */
>  #define V4L2_PIX_FMT_YUV444  v4l2_fourcc('Y', '4', '4', '4') /* 16   
>  */
> +#define V4L2_PIX_FMT_XVUY32  v4l2_fourcc('X', 'V', '3', '2') /* 32  XVUY 
> 8:8:8:8 */
> +#define V4L2_PIX_FMT_AVUY32  v4l2_fourcc('A', 'V', '3', '2') /* 32  AVUY 
> 8:8:8:8 */
> +#define V4L2_PIX_FMT_VUY24   v4l2_fourcc('V', 'U', '2', '4') /* 24  VUY 
> 8:8:8 */

If you read the convention, X:Y:Z is used to illustrate the sub-
sampling. The three previous are representing the number of bits, so
should have a comment like:
  XVUY-8-8-8-8
  AVUY-8-8-8-8
  VUY-8-8-8

>  #define V4L2_PIX_FMT_YUV555  v4l2_fourcc('Y', 'U', 'V', 'O') /* 16  
> YUV-5-5-5 */
>  #define V4L2_PIX_FMT_YUV565  v4l2_fourcc('Y', 'U', 'V', 'P') /* 16  
> YUV-5-6-5 */
>  #define V4L2_PIX_FMT_YUV32   v4l2_fourcc('Y', 'U', 'V', '4') /* 32  
> YUV-8-8-8-8   */
>  #define V4L2_PIX_FMT_HI240   v4l2_fourcc('H', 'I', '2', '4') /*  8  8-bit 
> color   */
>  #define V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1', '2') /*  8  YUV 
> 4:2:0 16x16 macroblocks */
>  #define V4L2_PIX_FMT_M420v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 
> 4:2:0 2 lines y, 1 line uv interleaved */
> +#define V4L2_PIX_FMT_XVUY10  v4l2_fourcc('X', 'Y', '1', '0') /* 32  XVUY 
> 2-10-10-10 */
> 
>  /* two planes -- one Y, one Cr + Cb interleaved  */
>  #define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2') /* 12  Y/CbCr 
> 4:2:0  */
> @@ -551,6 +558,8 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16  Y/CrCb 
> 4:2:2  */
>  #define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24  Y/CbCr 
> 4:4:4  */
>  #define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24  Y/CrCb 
> 4:4:4  */
> +#define V4L2_PIX_FMT_XV20v4l2_fourcc('X', 'V', '2', '0') /* 32  XY/UV 
> 4:2:2 10-bit */
> +#define V4L2_PIX_FMT_XV15v4l2_fourcc('X', 'V', '1', '5') /* 32  XY/UV 
> 4:2:0 10-bit */
> 
>  /* two non contiguous planes - one Y, one Cr + Cb interleaved  */
>  #define V4L2_PIX_FMT_NV12M   v4l2_fourcc('N', 'M', '1', '2') /* 12  Y/CbCr 
> 4:2:0  */
> @@ -558,6 +567,8 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_NV16M   v4l2_fourcc('N', 'M', '1', '6') /* 16  Y/CbCr 
> 4:2:2  */
>  #define V4L2_PIX_FMT_NV61M   v4l2_fourcc('N', 'M', '6', '1') /* 16  Y/CrCb 
> 4:2:2  */
>  #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M', '1', '2') /* 12  Y/CbCr 
> 4:2:0 64x32 macroblocks */
> +#define V4L2_PIX_FMT_XV20M   v4l2_fourcc('X', 'M', '2', '0') /* 32  XY/UV 
> 4:2:2 10-bit */
> +#define V4L2_PIX_FMT_XV15M   v4l2_fourcc('X', 'M', '1', '5') /* 32  XY/UV 
> 4:2:0 10-bit */
>  #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  
> Y/CbCr 4:2:0 16x16 macroblocks */
> 
>  /* three planes - Y Cb, Cr */
> --
> 2.7.4
> 
> 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 

Re: [PATCH v3 9/9] v4l: xilinx: dma: Get scaling and padding factor to calculate DMA params

[Hyun Kwon]

Hi Satish,

Thanks for that patch.

On Wed, 2018-02-14 at 22:43:00 -0800, Satish Kumar Nagireddy wrote:
> Get multiplying factor to calculate bpp especially
> in case of 10 bit formats.
> Get multiplying factor to calculate padding width
> 
> Signed-off-by: Satish Kumar Nagireddy 
> ---
>  drivers/media/platform/xilinx/xilinx-dma.c | 29 ++---
>  1 file changed, 26 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/platform/xilinx/xilinx-dma.c 
> b/drivers/media/platform/xilinx/xilinx-dma.c
> index 664981b..3c2fd02 100644
> --- a/drivers/media/platform/xilinx/xilinx-dma.c
> +++ b/drivers/media/platform/xilinx/xilinx-dma.c
> @@ -417,6 +417,7 @@ static void xvip_dma_buffer_queue(struct vb2_buffer *vb)
>   struct xvip_dma_buffer *buf = to_xvip_dma_buffer(vbuf);
>   struct dma_async_tx_descriptor *desc;
>   u32 flags, luma_size;
> + u32 padding_factor_nume, padding_factor_deno, bpl_nume, bpl_deno;
>   dma_addr_t addr = vb2_dma_contig_plane_dma_addr(vb, 0);
>  
>   if (dma->queue.type == V4L2_BUF_TYPE_VIDEO_CAPTURE ||
> @@ -442,8 +443,15 @@ static void xvip_dma_buffer_queue(struct vb2_buffer *vb)
>   struct v4l2_pix_format_mplane *pix_mp;
>  
>   pix_mp = >format.fmt.pix_mp;
> + xvip_width_padding_factor(pix_mp->pixelformat,
> +   _factor_nume,
> +   _factor_deno);
> + xvip_bpl_scaling_factor(pix_mp->pixelformat, _nume,
> + _deno);
>   dma->xt.frame_size = dma->fmtinfo->num_planes;
> - dma->sgl[0].size = pix_mp->width * dma->fmtinfo->bpl_factor;
> + dma->sgl[0].size = (pix_mp->width * dma->fmtinfo->bpl_factor *
> + padding_factor_nume * bpl_nume) /
> + (padding_factor_deno * bpl_deno);

We don't want to lose fractional here. DIV_ROUND_UP()? Then just nit, my 
personal
preference is not to use extra parenthesis where order is clear.

>   dma->sgl[0].icg = pix_mp->plane_fmt[0].bytesperline -
>   dma->sgl[0].size;
>   dma->xt.numf = pix_mp->height;
> @@ -472,8 +480,15 @@ static void xvip_dma_buffer_queue(struct vb2_buffer *vb)
>   struct v4l2_pix_format *pix;
>  
>   pix = >format.fmt.pix;
> + xvip_width_padding_factor(pix->pixelformat,
> +   _factor_nume,
> +   _factor_deno);
> + xvip_bpl_scaling_factor(pix->pixelformat, _nume,
> + _deno);
>   dma->xt.frame_size = dma->fmtinfo->num_planes;
> - dma->sgl[0].size = pix->width * dma->fmtinfo->bpl_factor;
> + dma->sgl[0].size = (pix->width * dma->fmtinfo->bpl_factor *
> + padding_factor_nume * bpl_nume) /
> + (padding_factor_deno * bpl_deno);
>   dma->sgl[0].icg = pix->bytesperline - dma->sgl[0].size;
>   dma->xt.numf = pix->height;
>   dma->sgl[0].dst_icg = dma->sgl[0].size;
> @@ -682,6 +697,8 @@ __xvip_dma_try_format(struct xvip_dma *dma,
>   unsigned int align;
>   unsigned int bpl;
>   unsigned int i, hsub, vsub, plane_width, plane_height;
> + unsigned int padding_factor_nume, padding_factor_deno;
> + unsigned int bpl_nume, bpl_deno;
>  
>   /* Retrieve format information and select the default format if the
>* requested format isn't supported.
> @@ -694,6 +711,10 @@ __xvip_dma_try_format(struct xvip_dma *dma,
>   if (IS_ERR(info))
>   info = xvip_get_format_by_fourcc(XVIP_DMA_DEF_FORMAT);
>  
> + xvip_width_padding_factor(info->fourcc, _factor_nume,
> +   _factor_deno);
> + xvip_bpl_scaling_factor(info->fourcc, _nume, _deno);
> +
>   /* The transfer alignment requirements are expressed in bytes. Compute
>* the minimum and maximum values, clamp the requested width and convert
>* it back to pixels.
> @@ -737,7 +758,9 @@ __xvip_dma_try_format(struct xvip_dma *dma,
>   for (i = 0; i < info->num_planes; i++) {
>   plane_width = pix_mp->width / (i ? hsub : 1);
>   plane_height = pix_mp->height / (i ? vsub : 1);
> - min_bpl = plane_width * info->bpl_factor;
> + min_bpl = (plane_width * info->bpl_factor *
> +padding_factor_nume * bpl_nume) /
> +(padding_factor_deno * bpl_deno);

Ditto as above.

This can be squashed into the previous patch that addsfunctions, but I let you 
decide.
Please consider if use of macro-pixel or any other approach can simplify this 
change.

Re: [PATCH v3 8/9] v4l: xilinx: dma: Add scaling and padding factor functions

[Hyun Kwon]

Hi Satish,

Thanks for the patch.

On Wed, 2018-02-14 at 22:42:50 -0800, Satish Kumar Nagireddy wrote:
> scaling_factor function returns multiplying factor to calculate
> bytes per component based on color format.
> For eg. scaling factor of YUV420 8 bit format is 1
> so multiplying factor is 1 (8/8)
> scaling factor of YUV420 10 bit format is 1.25 (10/8)
> 
> padding_factor function returns multiplying factor to calculate
> actual width of video according to color format.
> For eg. padding factor of YUV420 8 bit format: 8 bits per 1 component
> no padding bits here, so multiplying factor is 1
> padding factor of YUV422 10 bit format: 32 bits per 3 components
> each component is 10 bit and the factor is 32/30
> 
> Signed-off-by: Satish Kumar Nagireddy 
> ---
>  drivers/media/platform/xilinx/xilinx-vip.c | 43 
> ++
>  drivers/media/platform/xilinx/xilinx-vip.h |  2 ++
>  2 files changed, 45 insertions(+)
> 
> diff --git a/drivers/media/platform/xilinx/xilinx-vip.c 
> b/drivers/media/platform/xilinx/xilinx-vip.c
> index 51b7ef6..7543b75 100644
> --- a/drivers/media/platform/xilinx/xilinx-vip.c
> +++ b/drivers/media/platform/xilinx/xilinx-vip.c
> @@ -94,6 +94,49 @@ const struct xvip_video_format 
> *xvip_get_format_by_fourcc(u32 fourcc)
>  EXPORT_SYMBOL_GPL(xvip_get_format_by_fourcc);
>  
>  /**
> + * xvip_bpl_scaling_factor - Retrieve bpl scaling factor for a 4CC
> + * @fourcc: the format 4CC
> + *
> + * Return: Return numerator and denominator values by address
> + */
> +void xvip_bpl_scaling_factor(u32 fourcc, u32 *numerator, u32 *denominator)
> +{
> + switch (fourcc) {
> + case V4L2_PIX_FMT_XV15M:
> + *numerator = 10;
> + *denominator = 8;
> + break;
> + default:
> + *numerator   = 1;
> + *denominator = 1;
> + break;
> + }
> +}
> +EXPORT_SYMBOL_GPL(xvip_bpl_scaling_factor);
> +
> +/**
> + * xvip_width_padding_factor - Retrieve width's padding factor for a 4CC
> + * @fourcc: the format 4CC
> + *
> + * Return: Return numerator and denominator values by address
> + */
> +void xvip_width_padding_factor(u32 fourcc, u32 *numerator, u32 *denominator)
> +{
> + switch (fourcc) {
> + case V4L2_PIX_FMT_XV15M:
> + /* 32 bits are required per 30 bits of data */
> + *numerator = 32;
> + *denominator = 30;
> + break;
> + default:
> + *numerator   = 1;
> + *denominator = 1;
> + break;
> + }
> +}
> +EXPORT_SYMBOL_GPL(xvip_width_padding_factor);

Could you please take a look at the link below?
https://lists.freedesktop.org/archives/dri-devel/2018-February/165313.html

This approach has been replaced with the macro-pixel concept in DRM patch set.
The set is still on going, but in my opinion that's simpler, ex, as
all needed information can be added to the table. Similar approach may be
useful here.

Thanks,
-hyun

> +
> +/**
>   * xvip_of_get_format - Parse a device tree node and return format 
> information
>   * @node: the device tree node
>   *
> diff --git a/drivers/media/platform/xilinx/xilinx-vip.h 
> b/drivers/media/platform/xilinx/xilinx-vip.h
> index 006dcf77..26fada7 100644
> --- a/drivers/media/platform/xilinx/xilinx-vip.h
> +++ b/drivers/media/platform/xilinx/xilinx-vip.h
> @@ -135,6 +135,8 @@ struct xvip_video_format {
>  const struct xvip_video_format *xvip_get_format_by_code(unsigned int code);
>  const struct xvip_video_format *xvip_get_format_by_fourcc(u32 fourcc);
>  const struct xvip_video_format *xvip_of_get_format(struct device_node *node);
> +void xvip_bpl_scaling_factor(u32 fourcc, u32 *numerator, u32 *denominator);
> +void xvip_width_padding_factor(u32 fourcc, u32 *numerator, u32 *denominator);
>  void xvip_set_format_size(struct v4l2_mbus_framefmt *format,
> const struct v4l2_subdev_format *fmt);
>  int xvip_enum_mbus_code(struct v4l2_subdev *subdev,
> -- 
> 2.7.4
> 

Re: [PATCH v3 7/9] v4l: xilinx: dma: Add multi-planar support

[Hyun Kwon]

Hi Satish,

Thanks for the patch.

On Wed, 2018-02-14 at 22:42:43 -0800, Satish Kumar Nagireddy wrote:
> The current v4l driver supports single plane formats. This patch
> will add support to handle multi-planar formats. Updated driver
> capabilities to multi-planar, where it can handle both single and
> multi-planar formats
> 
> Signed-off-by: Satish Kumar Nagireddy 
> ---
>  drivers/media/platform/xilinx/xilinx-dma.c  | 341 
> +++-
>  drivers/media/platform/xilinx/xilinx-dma.h  |   2 +-
>  drivers/media/platform/xilinx/xilinx-vipp.c |  22 +-
>  3 files changed, 307 insertions(+), 58 deletions(-)
> 
> diff --git a/drivers/media/platform/xilinx/xilinx-dma.c 
> b/drivers/media/platform/xilinx/xilinx-dma.c
> index cb20ada..664981b 100644
> --- a/drivers/media/platform/xilinx/xilinx-dma.c
> +++ b/drivers/media/platform/xilinx/xilinx-dma.c
> @@ -63,6 +63,7 @@ static int xvip_dma_verify_format(struct xvip_dma *dma)
>   struct v4l2_subdev_format fmt;
>   struct v4l2_subdev *subdev;
>   int ret;
> + int width, height;
>  
>   subdev = xvip_dma_remote_subdev(>pad, );
>   if (subdev == NULL)
> @@ -73,9 +74,18 @@ static int xvip_dma_verify_format(struct xvip_dma *dma)
>   if (ret < 0)
>   return ret == -ENOIOCTLCMD ? -EINVAL : ret;
>  
> - if (dma->fmtinfo->code != fmt.format.code ||
> - dma->format.height != fmt.format.height ||
> - dma->format.width != fmt.format.width)
> + if (dma->fmtinfo->code != fmt.format.code)
> + return -EINVAL;
> +
> + if (V4L2_TYPE_IS_MULTIPLANAR(dma->format.type)) {

As discussed, let's plan to remove this check. :-) I think now it's
safe to assume there's no backward compatibility issue.

> + width = dma->format.fmt.pix_mp.width;
> + height = dma->format.fmt.pix_mp.height;
> + } else {
> + width = dma->format.fmt.pix.width;
> + height = dma->format.fmt.pix.height;
> + }
> +
> + if (width != fmt.format.width || height != fmt.format.height)
>   return -EINVAL;
>  
>   return 0;
> @@ -302,6 +312,8 @@ static void xvip_dma_complete(void *param)
>  {
>   struct xvip_dma_buffer *buf = param;
>   struct xvip_dma *dma = buf->dma;
> + u8 num_planes, i;
> + int sizeimage;
>  
>   spin_lock(>queued_lock);
>   list_del(>queue);
> @@ -310,7 +322,28 @@ static void xvip_dma_complete(void *param)
>   buf->buf.field = V4L2_FIELD_NONE;
>   buf->buf.sequence = dma->sequence++;
>   buf->buf.vb2_buf.timestamp = ktime_get_ns();
> - vb2_set_plane_payload(>buf.vb2_buf, 0, dma->format.sizeimage);
> +
> + if (V4L2_TYPE_IS_MULTIPLANAR(dma->format.type)) {
> + /* Handling contiguous data with mplanes */
> + if (dma->fmtinfo->buffers == 1) {
> + sizeimage =
> + dma->format.fmt.pix_mp.plane_fmt[0].sizeimage;
> + vb2_set_plane_payload(>buf.vb2_buf, 0, sizeimage);
> + } else {
> + /* Handling non-contiguous data with mplanes */
> + num_planes = dma->format.fmt.pix_mp.num_planes;
> + for (i = 0; i < num_planes; i++) {
> + sizeimage =
> +  dma->format.fmt.pix_mp.plane_fmt[i].sizeimage;
> + vb2_set_plane_payload(>buf.vb2_buf, i,
> +   sizeimage);
> + }
> + }

Can this be done in a single loop with number of buffers?

> + } else {
> + sizeimage = dma->format.fmt.pix.sizeimage;
> + vb2_set_plane_payload(>buf.vb2_buf, 0, sizeimage);
> + }
> +
>   vb2_buffer_done(>buf.vb2_buf, VB2_BUF_STATE_DONE);
>  }
>  
> @@ -320,13 +353,48 @@ xvip_dma_queue_setup(struct vb2_queue *vq,
>unsigned int sizes[], struct device *alloc_devs[])
>  {
>   struct xvip_dma *dma = vb2_get_drv_priv(vq);
> + u8 i;
> + int sizeimage;
> +
> + /* Multi planar case: Make sure the image size is large enough */
> + if (V4L2_TYPE_IS_MULTIPLANAR(dma->format.type)) {
> + if (*nplanes) {
> + if (*nplanes != dma->format.fmt.pix_mp.num_planes)
> + return -EINVAL;
> +
> + for (i = 0; i < *nplanes; i++) {
> +  sizeimage =
> +   dma->format.fmt.pix_mp.plane_fmt[i].sizeimage;
> + if (sizes[i] < sizeimage)
> + return -EINVAL;
> + }
> + } else {
> + /* Handling contiguous data with mplanes */
> + if (dma->fmtinfo->buffers == 1) {
> + *nplanes = 1;

It seems a little confusing as use of 'nplanes' and 'number of buffers' is
mixed. Looks like definitions in v4l and this 

Re: [PATCH v3 6/9] v4l: xilinx: dma: Update video format descriptor

[Hyun Kwon]

On Wed, 2018-02-14 at 22:42:36 -0800, Satish Kumar Nagireddy wrote:
> This patch updates video format descriptor to help information
> viz., number of planes per color format and chroma sub sampling
> factors.
> 
> This commit adds the various 8-bit and 10-bit that are supported
> to the table queried by drivers.
> 
> Signed-off-by: Satish Kumar Nagireddy 
> ---
>  drivers/media/platform/xilinx/xilinx-vip.c | 18 ++
>  drivers/media/platform/xilinx/xilinx-vip.h | 11 ++-
>  2 files changed, 20 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/platform/xilinx/xilinx-vip.c 
> b/drivers/media/platform/xilinx/xilinx-vip.c
> index d306f44..51b7ef6 100644
> --- a/drivers/media/platform/xilinx/xilinx-vip.c
> +++ b/drivers/media/platform/xilinx/xilinx-vip.c
> @@ -27,22 +27,24 @@
>   */
>  
>  static const struct xvip_video_format xvip_video_formats[] = {
> + { XVIP_VF_YUV_420, 10, NULL, MEDIA_BUS_FMT_VYYUYY8_1X24,
> +   1, 15, V4L2_PIX_FMT_XV15M, 2, 2, 1, 2, "4:2:0, 10-bit 2-plane 
> non-cont" },

So is the pixel scaling from 8 bit to 10 bit done hardware? In long term, I 
think
pixel format should be separate from bus formats.

Then why is bpp 15 for this? I think it's average of bpp from multiple planes.
The format can be modeled more clearly with per plane information instead.

>   { XVIP_VF_YUV_422, 8, NULL, MEDIA_BUS_FMT_UYVY8_1X16,
> -   2, V4L2_PIX_FMT_YUYV, "4:2:2, packed, YUYV" },
> +   2, 16, V4L2_PIX_FMT_YUYV, 1, 1, 2, 1, "4:2:2, packed, YUYV" },
>   { XVIP_VF_YUV_444, 8, NULL, MEDIA_BUS_FMT_VUY8_1X24,
> -   3, V4L2_PIX_FMT_YUV444, "4:4:4, packed, YUYV" },
> +   3, 24, V4L2_PIX_FMT_VUY24, 1, 1, 1, 1, "4:4:4, packed, YUYV" },
>   { XVIP_VF_RBG, 8, NULL, MEDIA_BUS_FMT_RBG888_1X24,
> -   3, V4L2_PIX_FMT_RGB24, "24-bit RGB" },
> +   3, 24, V4L2_PIX_FMT_RGB24, 1, 1, 1, 1, "24-bit RGB" },
>   { XVIP_VF_MONO_SENSOR, 8, "mono", MEDIA_BUS_FMT_Y8_1X8,
> -   1, V4L2_PIX_FMT_GREY, "Greyscale 8-bit" },
> +   1, 8, V4L2_PIX_FMT_GREY, 1, 1, 1, 1, "Greyscale 8-bit" },
>   { XVIP_VF_MONO_SENSOR, 8, "rggb", MEDIA_BUS_FMT_SRGGB8_1X8,
> -   1, V4L2_PIX_FMT_SGRBG8, "Bayer 8-bit RGGB" },
> +   1, 8, V4L2_PIX_FMT_SGRBG8, 1, 1, 1, 1, "Bayer 8-bit RGGB" },
>   { XVIP_VF_MONO_SENSOR, 8, "grbg", MEDIA_BUS_FMT_SGRBG8_1X8,
> -   1, V4L2_PIX_FMT_SGRBG8, "Bayer 8-bit GRBG" },
> +   1, 8, V4L2_PIX_FMT_SGRBG8, 1, 1, 1, 1, "Bayer 8-bit GRBG" },
>   { XVIP_VF_MONO_SENSOR, 8, "gbrg", MEDIA_BUS_FMT_SGBRG8_1X8,
> -   1, V4L2_PIX_FMT_SGBRG8, "Bayer 8-bit GBRG" },
> +   1, 8, V4L2_PIX_FMT_SGBRG8, 1, 1, 1, 1, "Bayer 8-bit GBRG" },
>   { XVIP_VF_MONO_SENSOR, 8, "bggr", MEDIA_BUS_FMT_SBGGR8_1X8,
> -   1, V4L2_PIX_FMT_SBGGR8, "Bayer 8-bit BGGR" },
> +   1, 8, V4L2_PIX_FMT_SBGGR8, 1, 1, 1, 1, "Bayer 8-bit BGGR" },
>  };
>  
>  /**
> diff --git a/drivers/media/platform/xilinx/xilinx-vip.h 
> b/drivers/media/platform/xilinx/xilinx-vip.h
> index 42fee20..006dcf77 100644
> --- a/drivers/media/platform/xilinx/xilinx-vip.h
> +++ b/drivers/media/platform/xilinx/xilinx-vip.h
> @@ -109,8 +109,12 @@ struct xvip_device {
>   * @width: AXI4 format width in bits per component
>   * @pattern: CFA pattern for Mono/Sensor formats
>   * @code: media bus format code
> - * @bpp: bytes per pixel (when stored in memory)

This member is still there.

> + * @bpl_factor: Bytes per line factor

'bpl_factor' is not needed in my opinion.

I think you meant to add bpp here. Then it seems like bpp definition is
changed to bits per pixel in the table, and that should come with changes
in code where it's used, ex, 'bpp' to 'bpp / 8'.

Thanks,
-hyun

>   * @fourcc: V4L2 pixel format FCC identifier
> + * @num_planes: number of planes w.r.t. color format
> + * @buffers: number of buffers per format
> + * @hsub: Horizontal sampling factor of Chroma
> + * @vsub: Vertical sampling factor of Chroma
>   * @description: format description, suitable for userspace
>   */
>  struct xvip_video_format {
> @@ -118,8 +122,13 @@ struct xvip_video_format {
>   unsigned int width;
>   const char *pattern;
>   unsigned int code;
> + unsigned int bpl_factor;
>   unsigned int bpp;
>   u32 fourcc;
> + u8 num_planes;
> + u8 buffers;
> + u8 hsub;
> + u8 vsub;
>   const char *description;
>  };
>  
> -- 
> 2.7.4
> 

Re: [PATCH v3 5/9] [media] Add documentation for YUV420 bus format

[Hyun Kwon]

Hi Satish,

Thanks for the patch.

On Wed, 2018-02-14 at 22:42:28 -0800, Satish Kumar Nagireddy wrote:
> The code is MEDIA_BUS_FMT_VYYUYY8_1X24
> 
> Signed-off-by: Satish Kumar Nagireddy 
> ---
>  Documentation/media/uapi/v4l/subdev-formats.rst | 34 
> +
>  1 file changed, 34 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst 
> b/Documentation/media/uapi/v4l/subdev-formats.rst
> index b1eea44..afff6d5 100644
> --- a/Documentation/media/uapi/v4l/subdev-formats.rst
> +++ b/Documentation/media/uapi/v4l/subdev-formats.rst
> @@ -7283,6 +7283,40 @@ The following table list existing packed 48bit wide 
> YUV formats.
>- y\ :sub:`1`
>- y\ :sub:`0`
>  
> +  - MEDIA_BUS_FMT_VYYUYY8_1X24
> +  - 0x202c
> +  -
> +  -
> +  -
> +  -
> +  -
> +  -
> +  -
> +  -
> +  - v\ :sub:`3`
> +  - v\ :sub:`2`
> +  - v\ :sub:`1`
> +  - v\ :sub:`0`
> +  - y\ :sub:`7`
> +  - y\ :sub:`6`
> +  - y\ :sub:`5`
> +  - y\ :sub:`4`
> +  - y\ :sub:`3`
> +  - y\ :sub:`2`
> +  - y\ :sub:`1`
> +  - y\ :sub:`0`
> +  - u\ :sub:`3`
> +  - u\ :sub:`2`
> +  - u\ :sub:`1`
> +  - u\ :sub:`0`
> +  - y\ :sub:`7`
> +  - y\ :sub:`6`
> +  - y\ :sub:`5`
> +  - y\ :sub:`4`
> +  - y\ :sub:`3`
> +  - y\ :sub:`2`
> +  - y\ :sub:`1`
> +  - y\ :sub:`0`

This is under 48bit yub bus format section. Better to be grouped with
other similar formats, ex 24bit yuv bus formats.

Then this can be squashed into the patch where the bus format is added.

Thanks,
-hyun

>  
>  .. raw:: latex
>  
> -- 
> 2.7.4
> 

Re: [PATCH v3 3/9] uapi: media: New fourcc codes needed by Xilinx Video IP

[Hyun Kwon]

Hi Satish,

Thanks for the patch.

On Wed, 2018-02-14 at 22:42:11 -0800, Satish Kumar Nagireddy wrote:
> From: Jeffrey Mouroux 
> 
> The Xilinx Video Framebuffer DMA IP supports video memory formats
> that are not represented in the current V4L2 fourcc library. This
> patch adds those missing fourcc codes. This includes both new
> 8-bit and 10-bit pixel formats.
> 
> Signed-off-by: Satish Kumar Nagireddy 
> ---
>  include/uapi/linux/videodev2.h | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 9827189..9fa4313c 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -509,7 +509,10 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_XBGR32  v4l2_fourcc('X', 'R', '2', '4') /* 32  
> BGRX-8-8-8-8  */
>  #define V4L2_PIX_FMT_RGB32   v4l2_fourcc('R', 'G', 'B', '4') /* 32  
> RGB-8-8-8-8   */
>  #define V4L2_PIX_FMT_ARGB32  v4l2_fourcc('B', 'A', '2', '4') /* 32  
> ARGB-8-8-8-8  */
> +#define V4L2_PIX_FMT_BGRA32  v4l2_fourcc('A', 'B', 'G', 'R') /* 32  
> ABGR-8-8-8-8  */
>  #define V4L2_PIX_FMT_XRGB32  v4l2_fourcc('B', 'X', '2', '4') /* 32  
> XRGB-8-8-8-8  */
> +#define V4L2_PIX_FMT_BGRX32  v4l2_fourcc('X', 'B', 'G', 'R') /* 32  
> XBGR-8-8-8-8 */
> +#define V4L2_PIX_FMT_XBGR30  v4l2_fourcc('R', 'X', '3', '0') /* 32  
> XBGR-2-10-10-10 */
>  
>  /* Grey formats */
>  #define V4L2_PIX_FMT_GREYv4l2_fourcc('G', 'R', 'E', 'Y') /*  8  
> Greyscale */
> @@ -537,12 +540,16 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_VYUYv4l2_fourcc('V', 'Y', 'U', 'Y') /* 16  YUV 
> 4:2:2 */
>  #define V4L2_PIX_FMT_Y41Pv4l2_fourcc('Y', '4', '1', 'P') /* 12  YUV 
> 4:1:1 */
>  #define V4L2_PIX_FMT_YUV444  v4l2_fourcc('Y', '4', '4', '4') /* 16   
>  */
> +#define V4L2_PIX_FMT_XVUY32  v4l2_fourcc('X', 'V', '3', '2') /* 32  XVUY 
> 8:8:8:8 */
> +#define V4L2_PIX_FMT_AVUY32  v4l2_fourcc('A', 'V', '3', '2') /* 32  AVUY 
> 8:8:8:8 */
> +#define V4L2_PIX_FMT_VUY24   v4l2_fourcc('V', 'U', '2', '4') /* 24  VUY 
> 8:8:8 */
>  #define V4L2_PIX_FMT_YUV555  v4l2_fourcc('Y', 'U', 'V', 'O') /* 16  
> YUV-5-5-5 */
>  #define V4L2_PIX_FMT_YUV565  v4l2_fourcc('Y', 'U', 'V', 'P') /* 16  
> YUV-5-6-5 */
>  #define V4L2_PIX_FMT_YUV32   v4l2_fourcc('Y', 'U', 'V', '4') /* 32  
> YUV-8-8-8-8   */
>  #define V4L2_PIX_FMT_HI240   v4l2_fourcc('H', 'I', '2', '4') /*  8  8-bit 
> color   */
>  #define V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1', '2') /*  8  YUV 
> 4:2:0 16x16 macroblocks */
>  #define V4L2_PIX_FMT_M420v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 
> 4:2:0 2 lines y, 1 line uv interleaved */
> +#define V4L2_PIX_FMT_XVUY10  v4l2_fourcc('X', 'Y', '1', '0') /* 32  XVUY 
> 2-10-10-10 */
>  
>  /* two planes -- one Y, one Cr + Cb interleaved  */
>  #define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2') /* 12  Y/CbCr 
> 4:2:0  */
> @@ -551,6 +558,8 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16  Y/CrCb 
> 4:2:2  */
>  #define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24  Y/CbCr 
> 4:4:4  */
>  #define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24  Y/CrCb 
> 4:4:4  */
> +#define V4L2_PIX_FMT_XV20v4l2_fourcc('X', 'V', '2', '0') /* 32  XY/UV 
> 4:2:2 10-bit */
> +#define V4L2_PIX_FMT_XV15v4l2_fourcc('X', 'V', '1', '5') /* 32  XY/UV 
> 4:2:0 10-bit */
>  
>  /* two non contiguous planes - one Y, one Cr + Cb interleaved  */
>  #define V4L2_PIX_FMT_NV12M   v4l2_fourcc('N', 'M', '1', '2') /* 12  Y/CbCr 
> 4:2:0  */
> @@ -558,6 +567,8 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_NV16M   v4l2_fourcc('N', 'M', '1', '6') /* 16  Y/CbCr 
> 4:2:2  */
>  #define V4L2_PIX_FMT_NV61M   v4l2_fourcc('N', 'M', '6', '1') /* 16  Y/CrCb 
> 4:2:2  */
>  #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M', '1', '2') /* 12  Y/CbCr 
> 4:2:0 64x32 macroblocks */
> +#define V4L2_PIX_FMT_XV20M   v4l2_fourcc('X', 'M', '2', '0') /* 32  XY/UV 
> 4:2:2 10-bit */
> +#define V4L2_PIX_FMT_XV15M   v4l2_fourcc('X', 'M', '1', '5') /* 32  XY/UV 
> 4:2:0 10-bit */

These pixel formats should be documented in Documentation/media/uapi/v4l/.

Thanks,
-hyun

>  #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  
> Y/CbCr 4:2:0 16x16 macroblocks */
>  
>  /* three planes - Y Cb, Cr */
> -- 
> 2.7.4
> 

Re: [BUG] musb: broken isochronous transfer at TI AM335x platform

[Tony Lindgren]

* Matwey V. Kornilov  [180215 17:55]:
> []   7.219456 d=  0.000997 [181.0 +  3.667] [  3] IN   : 4.5
> [T   ]   7.219459 d=  0.03 [181.0 +  7.083] [800] DATA0: 53 da ...
> []   7.220456 d=  0.000997 [182   +  3.667] [  3] IN   : 4.5
> [T   ]   7.220459 d=  0.03 [182   +  7.000] [800] DATA0: 13 36 ...
> []   7.222456 d=  0.001997 [184   +  3.667] [  3] IN   : 4.5
> []   7.222459 d=  0.03 [184   +  7.000] [  3] DATA0: 00 00
> []   7.223456 d=  0.000997 [185.0 +  3.667] [  3] IN   : 4.5
> []   7.223459 d=  0.03 [185.0 +  7.000] [  3] DATA0: 00 00
> 
> Please note, that the time moment "7.221456" has missed IN request
> packet which must be sent out every 1ms in this low-speed USB case.
> Then, all incoming packets became empty ones. Such moments coincide
> with frame discarding in pwc driver.

Well sounds like you may be able to fix it since you have a test
case for it :)

> Even though IN sending is usually handled by USB host hardware, it is
> not fully true for MUSB. Every IN is triggered by musb kernel driver
> (see MUSB_RXCSR_H_REQPKT usage in musb_host_packet_rx() and
> musb_ep_program()) since auto IN is not used. Rather complicated logic
> is incorporated to decide whether IN packet has to be sent. First,
> musb_host_packet_rx() handles IN sending when current URB is not
> completed (i.e. current URB has another packet which has to be
> received next). Second, musb_advance_schedule() (via musb_start_urb())
> handles the case when current URB is completed but there is another
> URB pending. It seems that there is a hardware logic to fire IN packet
> in a way to have exactly 1ms between two consequent INs. So,
> MUSB_RXCSR_H_REQPKT is considered as IN requesting flag.

Yeah this is a known issue with musb, there is not much ISO support
currently really. The regression should be fixed though.

Sorry I don't have much ideas on how to improve things here. One
way might be to attempt to split the large musb functions into
smaller functions and see if that then allows finer grained control.

Just to try to come up with some new ideas.. Maybe there's some way
to swap the hardware EP config dynamically and have some packets
mostly preconfigured and waiting to be triggered?

Regards,

Tony

Re: [PATCH v4 16/18] scripts: kernel-doc: improve nested logic to handle multiple identifiers

[Mauro Carvalho Chehab]

Em Wed, 14 Feb 2018 20:20:21 +0200
Jani Nikula  escreveu:

> On Wed, 14 Feb 2018, Mauro Carvalho Chehab  wrote:
> > There is a simple fix, though. Make inline comments to accept a dot:
> >
> > diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> > index fee8952037b1..06d7f3f2c094 100755
> > --- a/scripts/kernel-doc
> > +++ b/scripts/kernel-doc
> > @@ -363,7 +363,7 @@ my $doc_sect = $doc_com .
> >  my $doc_content = $doc_com_body . '(.*)';
> >  my $doc_block = $doc_com . 'DOC:\s*(.*)?';
> >  my $doc_inline_start = '^\s*/\*\*\s*$';
> > -my $doc_inline_sect = '\s*\*\s*(@[\w\s]+):(.*)';
> > +my $doc_inline_sect = '\s*\*\s*(@\s*[\w][\w\.]*\s*):(.*)';
> >  my $doc_inline_end = '^\s*\*/\s*$';
> >  my $doc_inline_oneline = '^\s*/\*\*\s*(@[\w\s]+):\s*(.*)\s*\*/\s*$';
> >  my $export_symbol = '^\s*EXPORT_SYMBOL(_GPL)?\s*\(\s*(\w+)\s*\)\s*;';
> >
> > That requires a small change at the inline parameters, though:
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
> > b/drivers/gpu/drm/i915/intel_dpio_phy.c
> > index 76473e9836c6..c8e9e44e5981 100644
> > --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> > +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> > @@ -147,7 +147,7 @@ struct bxt_ddi_phy_info {
> >  */
> > struct {
> > /**
> > -* @port: which port maps to this channel.
> > +* @channel.port: which port maps to this channel.
> >  */
> > enum port port;
> > } channel[2];  
> 
> Perhaps it would be slightly more elegant to be able to leave out
> "channel." here and deduce that from the context... but the above
> matches what you'd write in the higher level struct comment, and
> produces the same output. It works and it's really simple. I like it.
> 
> Please submit this as a proper patch, with
> 
> Tested-by: Jani Nikula 

Submitted. I ended by submitting as a patch series, as, when I
did some tests with the examples, I found that kernel-doc have
issues parsing them.


Thanks,
Mauro

Re: [PATCHv2 4/9] staging: atomisp: i2c: Disable non-preview configurations

[Mauro Carvalho Chehab]

Em Fri, 16 Feb 2018 12:12:20 +0200
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Wed, Feb 14, 2018 at 02:20:50PM -0200, Mauro Carvalho Chehab wrote:
> > Em Mon, 22 Jan 2018 13:31:20 +0100
> > Hans Verkuil  escreveu:
> >   
> > > From: Sakari Ailus 
> > > 
> > > Disable configurations for non-preview modes until configuration selection
> > > is improved.  
> > 
> > Again, a poor description. It just repeats the subject.
> > A good subject/description should answer 3 questions:
> > 
> > what?
> > why?
> > how?
> > 
> > Anyway, looking at this patch's contents, it partially answers my
> > questions:
> > 
> > the previous patch do cause regressions at the code.
> > 
> > Ok, this is staging. So, we don't have very strict rules here,
> > but still causing regressions without providing a very good
> > reason why sucks.
> > 
> > I would also merge this with the previous one, in order to place all
> > regressions on a single patch.  
> 
> It's trivial to bring back the configurations disabled here by just
> reverting this patch. The other patch does not disable any. That's why
> they're separate.

Yes, and I'm not saying otherwise.

The main issue here is that it lacks a description (as what's
there is just a copy of the subject).

Why is it needed to "disable non-preview configurations"?

Also, as you're actually commenting the code with #if 0, I'm assuming
that you're thinking on re-enable the code (or re-implement with a
different logic) in the future.

So, please add a note before the #if 0, as otherwise I'm pretty
sure someone will end by sending us patches just stripping it.

Regards,
Mauro

Re: [PATCHv2 3/9] staging: atomisp: Kill subdev s_parm abuse

[Mauro Carvalho Chehab]

Em Fri, 16 Feb 2018 11:04:36 +0200
Sakari Ailus  escreveu:

> On Wed, Feb 14, 2018 at 02:14:30PM -0200, Mauro Carvalho Chehab wrote:
> > Sakari,
> > 
> > Em Mon, 22 Jan 2018 13:31:19 +0100
> > Hans Verkuil  escreveu:
> >   
> > > From: Sakari Ailus 
> > > 
> > > Remove sensor driver's interface that made use of use case specific
> > > knowledge of platform capabilities.  
> > 
> > Could you better describe it? What s_param abuse?
> > What happens after this patch? It seems that atomISP relies on  
> 
> I'd like to remind you this is a staging driver that got where it is
> without any review.

Ok, but this is not an excuse to not properly document any further
patches to it.

> If you insist on improving the commit message, then
> this is what I propose:
> 
> Remove sensor driver's interface for setting the use case specific mode
> list as well as the mode lists that are related to other than
> CI_MODE_PREVIEW. This removes s_parm abuse in using driver specific values
> in v4l2_streamparm.capture.capturemode. The drivers already support
> [gs]_frame_interval so removing support for [gs]_parm is enough.

Works for me.

> 
> > gc0310_res. So, I would be expecting that a patch removing
> > s_param would be also adding/changing other parts of the code
> > accordingly, in order to get rid of that as a hole (or initialize
> > it somewhere else).
> > 
> > Regards,
> > Mauro
> >   
> > > 
> > > Signed-off-by: Sakari Ailus 
> > > Signed-off-by: Hans Verkuil 
> > > ---
> > >  drivers/staging/media/atomisp/i2c/atomisp-gc0310.c | 26 -
> > >  drivers/staging/media/atomisp/i2c/atomisp-gc2235.c | 26 -
> > >  drivers/staging/media/atomisp/i2c/atomisp-ov2680.c | 29 -
> > >  drivers/staging/media/atomisp/i2c/atomisp-ov2722.c | 26 -
> > >  drivers/staging/media/atomisp/i2c/gc0310.h | 43 --
> > >  drivers/staging/media/atomisp/i2c/gc2235.h |  1 -
> > >  drivers/staging/media/atomisp/i2c/ov2680.h | 68 
> > > --
> > >  .../media/atomisp/i2c/ov5693/atomisp-ov5693.c  | 27 -
> > >  .../media/atomisp/pci/atomisp2/atomisp_cmd.c   |  9 +--
> > >  .../media/atomisp/pci/atomisp2/atomisp_subdev.c| 12 +---
> > >  10 files changed, 3 insertions(+), 264 deletions(-)
> > > 
> > > diff --git a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c 
> > > b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
> > > index 61b7598469eb..572c9127c24d 100644
> > > --- a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
> > > +++ b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
> > > @@ -1224,37 +1224,12 @@ static int gc0310_g_parm(struct v4l2_subdev *sd,
> > >   if (dev->fmt_idx >= 0 && dev->fmt_idx < N_RES) {
> > >   param->parm.capture.capability = V4L2_CAP_TIMEPERFRAME;
> > >   param->parm.capture.timeperframe.numerator = 1;
> > > - param->parm.capture.capturemode = dev->run_mode;
> > >   param->parm.capture.timeperframe.denominator =
> > >   gc0310_res[dev->fmt_idx].fps;
> > >   }
> > >   return 0;
> > >  }
> > >  
> > > -static int gc0310_s_parm(struct v4l2_subdev *sd,
> > > - struct v4l2_streamparm *param)
> > > -{
> > > - struct gc0310_device *dev = to_gc0310_sensor(sd);
> > > - dev->run_mode = param->parm.capture.capturemode;
> > > -
> > > - mutex_lock(>input_lock);
> > > - switch (dev->run_mode) {
> > > - case CI_MODE_VIDEO:
> > > - gc0310_res = gc0310_res_video;
> > > - N_RES = N_RES_VIDEO;
> > > - break;
> > > - case CI_MODE_STILL_CAPTURE:
> > > - gc0310_res = gc0310_res_still;
> > > - N_RES = N_RES_STILL;
> > > - break;
> > > - default:
> > > - gc0310_res = gc0310_res_preview;
> > > - N_RES = N_RES_PREVIEW;
> > > - }
> > > - mutex_unlock(>input_lock);
> > > - return 0;
> > > -}
> > > -
> > >  static int gc0310_g_frame_interval(struct v4l2_subdev *sd,
> > >  struct v4l2_subdev_frame_interval *interval)
> > >  {
> > > @@ -1314,7 +1289,6 @@ static const struct v4l2_subdev_sensor_ops 
> > > gc0310_sensor_ops = {
> > >  static const struct v4l2_subdev_video_ops gc0310_video_ops = {
> > >   .s_stream = gc0310_s_stream,
> > >   .g_parm = gc0310_g_parm,
> > > - .s_parm = gc0310_s_parm,
> > >   .g_frame_interval = gc0310_g_frame_interval,
> > >  };
> > >  
> > > diff --git a/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c 
> > > b/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
> > > index d8de46da64ae..2bc179f3afe5 100644
> > > --- a/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
> > > +++ b/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
> > > @@ -964,37 +964,12 @@ static int gc2235_g_parm(struct v4l2_subdev *sd,
> > >   if (dev->fmt_idx >= 0 && dev->fmt_idx < N_RES) {
> > >   param->parm.capture.capability = V4L2_CAP_TIMEPERFRAME;
> > > 

Trying to build V4L on an Orange Pi One Plus - Build failed - Help wanted

[Aurelius Wendelken]

Hey guys,

I want to build V4L on an Orange Pi One Plus. Unfortunately I am running 
in an error while building on ARM64.

https://www.aliexpress.com/store/product/Orange-Pi-One-Plus-H6-1GB-Quad-core-64bit-development-board-Support-android7-0-mini-PC/1553371_32848891030.html.


BOARD IMAGE:
http://www.orangepi.org/downloadresources/orangepioneplus/2018-01-24/orangepioneplus6e6042bd7a15ee4b06ad1.html

ENVIROMENT:
Ubuntu_Server from vendor


BOARD KERNEL: (uname -a)
Linux OrangePi 3.10.65 #35 SMP PREEMPT Tue Jan 23 18:13:02 CST 2018 
aarch64 aarch64 aarch64 GNU/Linux



DVB STICK:
HMP-Combo DVB C/T2 Hybrid USB TUNER

lsusb
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 0572:0320 Conexant Systems (Rockwell), Inc. 
DVBSky T330 DVB-T2/C tuner
Bus 002 Device 002: ID 04b4:6560 Cypress Semiconductor Corp. CY7C65640 
USB-2.0 "TetraHub"

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

dmesg
[    2.250891] usb 2-1.4: New USB device found, idVendor=0572, 
idProduct=0320
[    2.250895] usb 2-1.4: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[    2.250899] usb 2-1.4: Product: DVB-T2/C USB-Stick
[    2.250902] usb 2-1.4: Manufacturer: Bestunar Inc
[    2.250906] usb 2-1.4: SerialNumber: 20140126


cat /etc/apt/sources.list from vendor
deb http://mirrors.ustc.edu.cn/ubuntu-ports/ xenial main restricted 
universe multiverse
deb http://mirrors.ustc.edu.cn/ubuntu-ports/ xenial-updates main 
restricted universe multiverse
deb http://mirrors.ustc.edu.cn/ubuntu-ports/ xenial-backports main 
restricted universe multiverse
deb http://mirrors.ustc.edu.cn/ubuntu-ports/ xenial-security main 
restricted universe multiverse

deb https://dl.bintray.com/tvheadend/deb xenial release-4.2


BUILD V4L:
./build
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
    LANGUAGE = (unset),
    LC_ALL = (unset),
    LC_CTYPE = "de_DE.UTF-8",
    LANG = "de_DE.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Checking if the needed tools for Ubuntu 16.04.3 LTS are available
Needed package dependencies are met.


* This script will download the latest tarball and build it*
* Assuming that your kernel is compatible with the latest  *
* drivers. If not, you'll need to add some extra backports,*
* ./backports/ directory.  *
* It will also update this tree to be sure that all compat *
* bits are there, to avoid compilation failures    *


* All drivers and build system are under GPLv2 License *
* Firmware files are under the license terms found at: *
* http://www.linuxtv.org/downloads/firmware/   *
* Please abort in the next 5 secs if you don't agree with  *
* the license  *


Not aborted. It means that the licence was agreed. Proceeding...


Updating the building system

From git://linuxtv.org/media_build
 * branch    master -> FETCH_HEAD
Already up-to-date.
make: Entering directory '/root/git/media_build/linux'
wget http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2.md5 
-O linux-media.tar.bz2.md5.tmp
--2018-02-15 12:08:02-- 
http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2.md5

Resolving linuxtv.org (linuxtv.org)... 130.149.80.248
Connecting to linuxtv.org (linuxtv.org)|130.149.80.248|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: 
https://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2.md5 
[following]
--2018-02-15 12:08:02-- 
https://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2.md5

Connecting to linuxtv.org (linuxtv.org)|130.149.80.248|:443... connected.
WARNING: cannot verify linuxtv.org's certificate, issued by 'CN=Let\'s 
Encrypt Authority X3,O=Let\'s Encrypt,C=US':

  Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response... 200 OK
Length: 105 [application/x-bzip2]
Saving to: 'linux-media.tar.bz2.md5.tmp'

linux-media.tar.bz2.md5.tmp 
100%[==>] 
105  --.-KB/s    in 0s


2018-02-15 12:08:02 (1.40 MB/s) - 'linux-media.tar.bz2.md5.tmp' saved 
[105/105]


make: Leaving directory '/root/git/media_build/linux'
make: Entering directory '/root/git/media_build/linux'
tar xfj linux-media.tar.bz2
rm -f .patches_applied 

Re: [PATCHv2 4/9] staging: atomisp: i2c: Disable non-preview configurations

[Sakari Ailus]

Hi Mauro,

On Wed, Feb 14, 2018 at 02:20:50PM -0200, Mauro Carvalho Chehab wrote:
> Em Mon, 22 Jan 2018 13:31:20 +0100
> Hans Verkuil  escreveu:
> 
> > From: Sakari Ailus 
> > 
> > Disable configurations for non-preview modes until configuration selection
> > is improved.
> 
> Again, a poor description. It just repeats the subject.
> A good subject/description should answer 3 questions:
> 
>   what?
>   why?
>   how?
> 
> Anyway, looking at this patch's contents, it partially answers my
> questions:
> 
> the previous patch do cause regressions at the code.
> 
> Ok, this is staging. So, we don't have very strict rules here,
> but still causing regressions without providing a very good
> reason why sucks.
> 
> I would also merge this with the previous one, in order to place all
> regressions on a single patch.

It's trivial to bring back the configurations disabled here by just
reverting this patch. The other patch does not disable any. That's why
they're separate.

> 
> 
> > 
> > Signed-off-by: Sakari Ailus 
> > Signed-off-by: Hans Verkuil 
> > ---
> >  drivers/staging/media/atomisp/i2c/gc2235.h| 2 ++
> >  drivers/staging/media/atomisp/i2c/ov2722.h| 2 ++
> >  drivers/staging/media/atomisp/i2c/ov5693/ov5693.h | 2 ++
> >  3 files changed, 6 insertions(+)
> > 
> > diff --git a/drivers/staging/media/atomisp/i2c/gc2235.h 
> > b/drivers/staging/media/atomisp/i2c/gc2235.h
> > index 45a54fea5466..817c0068c1d3 100644
> > --- a/drivers/staging/media/atomisp/i2c/gc2235.h
> > +++ b/drivers/staging/media/atomisp/i2c/gc2235.h
> > @@ -574,6 +574,7 @@ static struct gc2235_resolution gc2235_res_preview[] = {
> >  };
> >  #define N_RES_PREVIEW (ARRAY_SIZE(gc2235_res_preview))
> >  
> > +#if 0 /* Disable non-previes configurations for now */
> 
> typo (here and other cut-and-paste paces)
>   non-previes -> non-previews
> 
> also, please add a FIXME: or HACK: and describe the need for a fix
> on atomisp TODO file.
> 
> >  static struct gc2235_resolution gc2235_res_still[] = {
> > {
> > .desc = "gc2235_1600_900_30fps",
> > @@ -658,6 +659,7 @@ static struct gc2235_resolution gc2235_res_video[] = {
> >  
> >  };
> >  #define N_RES_VIDEO (ARRAY_SIZE(gc2235_res_video))
> > +#endif
> >  
> >  static struct gc2235_resolution *gc2235_res = gc2235_res_preview;
> >  static unsigned long N_RES = N_RES_PREVIEW;
> > diff --git a/drivers/staging/media/atomisp/i2c/ov2722.h 
> > b/drivers/staging/media/atomisp/i2c/ov2722.h
> > index d8a973d71699..f133439adfd5 100644
> > --- a/drivers/staging/media/atomisp/i2c/ov2722.h
> > +++ b/drivers/staging/media/atomisp/i2c/ov2722.h
> > @@ -1148,6 +1148,7 @@ struct ov2722_resolution ov2722_res_preview[] = {
> >  };
> >  #define N_RES_PREVIEW (ARRAY_SIZE(ov2722_res_preview))
> >  
> > +#if 0 /* Disable non-previes configurations for now */
> >  struct ov2722_resolution ov2722_res_still[] = {
> > {
> > .desc = "ov2722_480P_30fps",
> > @@ -1250,6 +1251,7 @@ struct ov2722_resolution ov2722_res_video[] = {
> > },
> >  };
> >  #define N_RES_VIDEO (ARRAY_SIZE(ov2722_res_video))
> > +#endif
> >  
> >  static struct ov2722_resolution *ov2722_res = ov2722_res_preview;
> >  static unsigned long N_RES = N_RES_PREVIEW;
> > diff --git a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h 
> > b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
> > index 68cfcb4a6c3c..15a33dcd2d59 100644
> > --- a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
> > +++ b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
> > @@ -1147,6 +1147,7 @@ struct ov5693_resolution ov5693_res_preview[] = {
> >  };
> >  #define N_RES_PREVIEW (ARRAY_SIZE(ov5693_res_preview))
> >  
> > +#if 0 /* Disable non-previes configurations for now */
> >  struct ov5693_resolution ov5693_res_still[] = {
> > {
> > .desc = "ov5693_736x496_30fps",
> > @@ -1364,6 +1365,7 @@ struct ov5693_resolution ov5693_res_video[] = {
> > },
> >  };
> >  #define N_RES_VIDEO (ARRAY_SIZE(ov5693_res_video))
> > +#endif
> >  
> >  static struct ov5693_resolution *ov5693_res = ov5693_res_preview;
> >  static unsigned long N_RES = N_RES_PREVIEW;
> 
> 
> 
> Thanks,
> Mauro

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

Re: [PATCH 2/2] media: Add a driver for the ov7251 camera sensor

[jacopo mondi]

Hi Todor,
thanks for the patch.

Is the datsheet for this sensor public? I failed to find any reference
to it online, am I wrong?

On Thu, Feb 08, 2018 at 10:53:38AM +0200, Todor Tomov wrote:
> The ov7251 sensor is a 1/7.5-Inch B VGA (640x480) CMOS Digital Image
> Sensor from Omnivision.
>
> The driver supports the following modes:
> - 640x480 30fps
> - 640x480 60fps
> - 640x480 90fps
>
> Output format is MIPI RAW 10.
>
> The driver supports configuration via user controls for:
> - exposure and gain;
> - horizontal and vertical flip;
> - test pattern.
>
> Signed-off-by: Todor Tomov 
> ---
>  drivers/media/i2c/Kconfig  |   13 +
>  drivers/media/i2c/Makefile |1 +
>  drivers/media/i2c/ov7251.c | 1523 
> 
>  3 files changed, 1537 insertions(+)
>  create mode 100644 drivers/media/i2c/ov7251.c
>
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 9f18cd2..bfa9aab 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -645,6 +645,19 @@ config VIDEO_OV5670
> To compile this driver as a module, choose M here: the
> module will be called ov5670.
>
> +config VIDEO_OV7251
> + tristate "OmniVision OV7251 sensor support"
> + depends on OF
> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + depends on MEDIA_CAMERA_SUPPORT
> + select V4L2_FWNODE
> + ---help---
> +   This is a Video4Linux2 sensor-level driver for the OmniVision
> +   OV7251 camera.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called ov7251.
> +
>  config VIDEO_OV7640
>   tristate "OmniVision OV7640 sensor support"
>   depends on I2C && VIDEO_V4L2
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index c0f94cd..be6b3d3 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -66,6 +66,7 @@ obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
>  obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
>  obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
>  obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
> +obj-$(CONFIG_VIDEO_OV7251) += ov7251.o
>  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
>  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
>  obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
> diff --git a/drivers/media/i2c/ov7251.c b/drivers/media/i2c/ov7251.c
> new file mode 100644
> index 000..f217177
> --- /dev/null
> +++ b/drivers/media/i2c/ov7251.c
> @@ -0,0 +1,1523 @@
> +/*
> + * Driver for the OV7251 camera sensor.
> + *
> + * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2017-2018, Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only 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.
> + */

Please use SPDX identifiers instead of the license text

// SPDX-License-Identifier: GPL-2.0

> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define OV7251_VOLTAGE_ANALOG   280
> +#define OV7251_VOLTAGE_DIGITAL_CORE 150
> +#define OV7251_VOLTAGE_DIGITAL_IO   180
> +
> +#define OV7251_SC_MODE_SELECT0x0100
> +#define OV7251_SC_MODE_SELECT_SW_STANDBY 0x0
> +#define OV7251_SC_MODE_SELECT_STREAMING  0x1
> +
> +#define OV7251_CHIP_ID_HIGH  0x300a
> +#define  OV7251_CHIP_ID_HIGH_BYTE0x77
> +#define OV7251_CHIP_ID_LOW   0x300b
> +#define  OV7251_CHIP_ID_LOW_BYTE 0x50
> +#define OV7251_SC_GP_IO_IN1  0x3029
> +#define OV7251_AEC_EXPO_00x3500
> +#define OV7251_AEC_EXPO_10x3501
> +#define OV7251_AEC_EXPO_20x3502
> +#define OV7251_AEC_AGC_ADJ_0 0x350a
> +#define OV7251_AEC_AGC_ADJ_1 0x350b
> +#define OV7251_TIMING_FORMAT10x3820
> +#define  OV7251_SENSOR_VFLIP BIT(2)
> +#define OV7251_TIMING_FORMAT20x3821
> +#define  OV7251_SENSOR_MIRRORBIT(2)
> +#define OV7251_PRE_ISP_000x5e00
> +#define  OV7251_TEST_PATTERN_BAR_ENABLE  BIT(7)

Are those tabs between the define and the macro name there by purpose?

If they are bits in the register address defined above them, wouldn't
it be better to capture there in the name?

Eg.
OV7251_TIMING_FMT1  0x3820
OV7251_TIMING_FMT1_VFLIPBIT(2)

> +
> +struct reg_value {
> + u16 reg;
> + u8 val;
> +};
> +
> +struct 

Re: [PATCHv2 3/9] staging: atomisp: Kill subdev s_parm abuse

[Sakari Ailus]

On Wed, Feb 14, 2018 at 02:14:30PM -0200, Mauro Carvalho Chehab wrote:
> Sakari,
> 
> Em Mon, 22 Jan 2018 13:31:19 +0100
> Hans Verkuil  escreveu:
> 
> > From: Sakari Ailus 
> > 
> > Remove sensor driver's interface that made use of use case specific
> > knowledge of platform capabilities.
> 
> Could you better describe it? What s_param abuse?
> What happens after this patch? It seems that atomISP relies on

I'd like to remind you this is a staging driver that got where it is
without any review. If you insist on improving the commit message, then
this is what I propose:

Remove sensor driver's interface for setting the use case specific mode
list as well as the mode lists that are related to other than
CI_MODE_PREVIEW. This removes s_parm abuse in using driver specific values
in v4l2_streamparm.capture.capturemode. The drivers already support
[gs]_frame_interval so removing support for [gs]_parm is enough.

> gc0310_res. So, I would be expecting that a patch removing
> s_param would be also adding/changing other parts of the code
> accordingly, in order to get rid of that as a hole (or initialize
> it somewhere else).
> 
> Regards,
> Mauro
> 
> > 
> > Signed-off-by: Sakari Ailus 
> > Signed-off-by: Hans Verkuil 
> > ---
> >  drivers/staging/media/atomisp/i2c/atomisp-gc0310.c | 26 -
> >  drivers/staging/media/atomisp/i2c/atomisp-gc2235.c | 26 -
> >  drivers/staging/media/atomisp/i2c/atomisp-ov2680.c | 29 -
> >  drivers/staging/media/atomisp/i2c/atomisp-ov2722.c | 26 -
> >  drivers/staging/media/atomisp/i2c/gc0310.h | 43 --
> >  drivers/staging/media/atomisp/i2c/gc2235.h |  1 -
> >  drivers/staging/media/atomisp/i2c/ov2680.h | 68 
> > --
> >  .../media/atomisp/i2c/ov5693/atomisp-ov5693.c  | 27 -
> >  .../media/atomisp/pci/atomisp2/atomisp_cmd.c   |  9 +--
> >  .../media/atomisp/pci/atomisp2/atomisp_subdev.c| 12 +---
> >  10 files changed, 3 insertions(+), 264 deletions(-)
> > 
> > diff --git a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c 
> > b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
> > index 61b7598469eb..572c9127c24d 100644
> > --- a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
> > +++ b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
> > @@ -1224,37 +1224,12 @@ static int gc0310_g_parm(struct v4l2_subdev *sd,
> > if (dev->fmt_idx >= 0 && dev->fmt_idx < N_RES) {
> > param->parm.capture.capability = V4L2_CAP_TIMEPERFRAME;
> > param->parm.capture.timeperframe.numerator = 1;
> > -   param->parm.capture.capturemode = dev->run_mode;
> > param->parm.capture.timeperframe.denominator =
> > gc0310_res[dev->fmt_idx].fps;
> > }
> > return 0;
> >  }
> >  
> > -static int gc0310_s_parm(struct v4l2_subdev *sd,
> > -   struct v4l2_streamparm *param)
> > -{
> > -   struct gc0310_device *dev = to_gc0310_sensor(sd);
> > -   dev->run_mode = param->parm.capture.capturemode;
> > -
> > -   mutex_lock(>input_lock);
> > -   switch (dev->run_mode) {
> > -   case CI_MODE_VIDEO:
> > -   gc0310_res = gc0310_res_video;
> > -   N_RES = N_RES_VIDEO;
> > -   break;
> > -   case CI_MODE_STILL_CAPTURE:
> > -   gc0310_res = gc0310_res_still;
> > -   N_RES = N_RES_STILL;
> > -   break;
> > -   default:
> > -   gc0310_res = gc0310_res_preview;
> > -   N_RES = N_RES_PREVIEW;
> > -   }
> > -   mutex_unlock(>input_lock);
> > -   return 0;
> > -}
> > -
> >  static int gc0310_g_frame_interval(struct v4l2_subdev *sd,
> >struct v4l2_subdev_frame_interval *interval)
> >  {
> > @@ -1314,7 +1289,6 @@ static const struct v4l2_subdev_sensor_ops 
> > gc0310_sensor_ops = {
> >  static const struct v4l2_subdev_video_ops gc0310_video_ops = {
> > .s_stream = gc0310_s_stream,
> > .g_parm = gc0310_g_parm,
> > -   .s_parm = gc0310_s_parm,
> > .g_frame_interval = gc0310_g_frame_interval,
> >  };
> >  
> > diff --git a/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c 
> > b/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
> > index d8de46da64ae..2bc179f3afe5 100644
> > --- a/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
> > +++ b/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
> > @@ -964,37 +964,12 @@ static int gc2235_g_parm(struct v4l2_subdev *sd,
> > if (dev->fmt_idx >= 0 && dev->fmt_idx < N_RES) {
> > param->parm.capture.capability = V4L2_CAP_TIMEPERFRAME;
> > param->parm.capture.timeperframe.numerator = 1;
> > -   param->parm.capture.capturemode = dev->run_mode;
> > param->parm.capture.timeperframe.denominator =
> > gc2235_res[dev->fmt_idx].fps;
> > }
> > return 0;
> >  }
> >  
> > -static int gc2235_s_parm(struct v4l2_subdev *sd,
> > - 

Re: [PATCH v3 3/9] uapi: media: New fourcc codes needed by Xilinx Video IP

[Sakari Ailus]

Hi Satish,

On Wed, Feb 14, 2018 at 10:42:11PM -0800, Satish Kumar Nagireddy wrote:
> From: Jeffrey Mouroux 
> 
> The Xilinx Video Framebuffer DMA IP supports video memory formats
> that are not represented in the current V4L2 fourcc library. This
> patch adds those missing fourcc codes. This includes both new
> 8-bit and 10-bit pixel formats.
> 
> Signed-off-by: Satish Kumar Nagireddy 
> ---
>  include/uapi/linux/videodev2.h | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 9827189..9fa4313c 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -509,7 +509,10 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_XBGR32  v4l2_fourcc('X', 'R', '2', '4') /* 32  
> BGRX-8-8-8-8  */
>  #define V4L2_PIX_FMT_RGB32   v4l2_fourcc('R', 'G', 'B', '4') /* 32  
> RGB-8-8-8-8   */
>  #define V4L2_PIX_FMT_ARGB32  v4l2_fourcc('B', 'A', '2', '4') /* 32  
> ARGB-8-8-8-8  */
> +#define V4L2_PIX_FMT_BGRA32  v4l2_fourcc('A', 'B', 'G', 'R') /* 32  
> ABGR-8-8-8-8  */
>  #define V4L2_PIX_FMT_XRGB32  v4l2_fourcc('B', 'X', '2', '4') /* 32  
> XRGB-8-8-8-8  */
> +#define V4L2_PIX_FMT_BGRX32  v4l2_fourcc('X', 'B', 'G', 'R') /* 32  
> XBGR-8-8-8-8 */
> +#define V4L2_PIX_FMT_XBGR30  v4l2_fourcc('R', 'X', '3', '0') /* 32  
> XBGR-2-10-10-10 */

Can you add documentation to the formats added by this patch, please?

> 
>  /* Grey formats */
>  #define V4L2_PIX_FMT_GREYv4l2_fourcc('G', 'R', 'E', 'Y') /*  8  
> Greyscale */
> @@ -537,12 +540,16 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_VYUYv4l2_fourcc('V', 'Y', 'U', 'Y') /* 16  YUV 
> 4:2:2 */
>  #define V4L2_PIX_FMT_Y41Pv4l2_fourcc('Y', '4', '1', 'P') /* 12  YUV 
> 4:1:1 */
>  #define V4L2_PIX_FMT_YUV444  v4l2_fourcc('Y', '4', '4', '4') /* 16   
>  */
> +#define V4L2_PIX_FMT_XVUY32  v4l2_fourcc('X', 'V', '3', '2') /* 32  XVUY 
> 8:8:8:8 */
> +#define V4L2_PIX_FMT_AVUY32  v4l2_fourcc('A', 'V', '3', '2') /* 32  AVUY 
> 8:8:8:8 */
> +#define V4L2_PIX_FMT_VUY24   v4l2_fourcc('V', 'U', '2', '4') /* 24  VUY 
> 8:8:8 */
>  #define V4L2_PIX_FMT_YUV555  v4l2_fourcc('Y', 'U', 'V', 'O') /* 16  
> YUV-5-5-5 */
>  #define V4L2_PIX_FMT_YUV565  v4l2_fourcc('Y', 'U', 'V', 'P') /* 16  
> YUV-5-6-5 */
>  #define V4L2_PIX_FMT_YUV32   v4l2_fourcc('Y', 'U', 'V', '4') /* 32  
> YUV-8-8-8-8   */
>  #define V4L2_PIX_FMT_HI240   v4l2_fourcc('H', 'I', '2', '4') /*  8  8-bit 
> color   */
>  #define V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1', '2') /*  8  YUV 
> 4:2:0 16x16 macroblocks */
>  #define V4L2_PIX_FMT_M420v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 
> 4:2:0 2 lines y, 1 line uv interleaved */
> +#define V4L2_PIX_FMT_XVUY10  v4l2_fourcc('X', 'Y', '1', '0') /* 32  XVUY 
> 2-10-10-10 */
> 
>  /* two planes -- one Y, one Cr + Cb interleaved  */
>  #define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2') /* 12  Y/CbCr 
> 4:2:0  */
> @@ -551,6 +558,8 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16  Y/CrCb 
> 4:2:2  */
>  #define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24  Y/CbCr 
> 4:4:4  */
>  #define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24  Y/CrCb 
> 4:4:4  */
> +#define V4L2_PIX_FMT_XV20v4l2_fourcc('X', 'V', '2', '0') /* 32  XY/UV 
> 4:2:2 10-bit */
> +#define V4L2_PIX_FMT_XV15v4l2_fourcc('X', 'V', '1', '5') /* 32  XY/UV 
> 4:2:0 10-bit */
> 
>  /* two non contiguous planes - one Y, one Cr + Cb interleaved  */
>  #define V4L2_PIX_FMT_NV12M   v4l2_fourcc('N', 'M', '1', '2') /* 12  Y/CbCr 
> 4:2:0  */
> @@ -558,6 +567,8 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_NV16M   v4l2_fourcc('N', 'M', '1', '6') /* 16  Y/CbCr 
> 4:2:2  */
>  #define V4L2_PIX_FMT_NV61M   v4l2_fourcc('N', 'M', '6', '1') /* 16  Y/CrCb 
> 4:2:2  */
>  #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M', '1', '2') /* 12  Y/CbCr 
> 4:2:0 64x32 macroblocks */
> +#define V4L2_PIX_FMT_XV20M   v4l2_fourcc('X', 'M', '2', '0') /* 32  XY/UV 
> 4:2:2 10-bit */
> +#define V4L2_PIX_FMT_XV15M   v4l2_fourcc('X', 'M', '1', '5') /* 32  XY/UV 
> 4:2:0 10-bit */
>  #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  
> Y/CbCr 4:2:0 16x16 macroblocks */
> 
>  /* three planes - Y Cb, Cr */
> --
> 2.7.4
> 
> 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.

How is this related to the patches? Can you remove it in the next version?

-- 
Regards,

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