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:   Fri Feb 16 05:00:09 CET 2018
media-tree git hash:29422737017b866d4a51014cc7522fa3a99e8852
media_build git hash:   0e5cdef4c99fc927bcf7a216215a323ac85d1d3a
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: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.98-i686: ERRORS
linux-3.2.98-x86_64: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-i686: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.12.67-x86_64: ERRORS
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/Friday.log

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

[PATCH v2] media: video-i2c: add video-i2c driver

[Matt Ranostay]

There are several thermal sensors that only have a low-speed bus
interface but output valid video data. This patchset enables support
for the AMG88xx "Grid-Eye" sensor family.

Cc: Luca Barbato 
Cc: Laurent Pinchart 
Signed-off-by: Matt Ranostay 
---
Changes from v1:
* Switch to SPDX tags versus GPLv2 license text
* Remove unneeded zeroing of data structures
* Add video_i2c_try_fmt_vid_cap call in video_i2c_s_fmt_vid_cap function

 drivers/media/i2c/Kconfig |   9 +
 drivers/media/i2c/Makefile|   1 +
 drivers/media/i2c/video-i2c.c | 546 ++
 3 files changed, 556 insertions(+)
 create mode 100644 drivers/media/i2c/video-i2c.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 9f18cd296841..549f1e9fc01e 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -908,6 +908,15 @@ config VIDEO_M52790
 
 To compile this driver as a module, choose M here: the
 module will be called m52790.
+
+config VIDEO_I2C
+   tristate "I2C transport video support"
+   depends on VIDEO_V4L2 && I2C
+   select VIDEOBUF2_VMALLOC
+   ---help---
+ Enable the I2C transport video support which supports the
+ following:
+  * Panasonic AMG88xx Grid-Eye Sensors
 endmenu
 
 menu "Sensors used on soc_camera driver"
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index c0f94cd8d56d..5ca4c98a4bea 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -90,6 +90,7 @@ obj-$(CONFIG_VIDEO_LM3646)+= lm3646.o
 obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
 obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
 obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
+obj-$(CONFIG_VIDEO_I2C)+= video-i2c.o
 obj-$(CONFIG_VIDEO_ML86V7667)  += ml86v7667.o
 obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
 obj-$(CONFIG_VIDEO_TC358743)   += tc358743.o
diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
new file mode 100644
index ..936baaae2c7f
--- /dev/null
+++ b/drivers/media/i2c/video-i2c.c
@@ -0,0 +1,546 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * video-i2c.c - Support for I2C transport video devices
+ *
+ * Copyright (C) 2018 Matt Ranostay 
+ *
+ * Supported:
+ * - Panasonic AMG88xx Grid-Eye Sensors
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define VIDEO_I2C_DRIVER   "video-i2c"
+#define MAX_BUFFER_SIZE128
+
+struct video_i2c_chip;
+
+struct video_i2c_buffer {
+   struct vb2_v4l2_buffer vb;
+   struct list_head list;
+};
+
+struct video_i2c_data {
+   struct i2c_client *client;
+   const struct video_i2c_chip *chip;
+   struct mutex lock;
+   spinlock_t slock;
+   struct mutex queue_lock;
+
+   struct v4l2_device v4l2_dev;
+   struct video_device vdev;
+   struct vb2_queue vb_vidq;
+
+   struct task_struct *kthread_vid_cap;
+   struct list_head vid_cap_active;
+};
+
+static struct v4l2_fmtdesc amg88xx_format = {
+   .pixelformat = V4L2_PIX_FMT_Y12,
+};
+
+static struct v4l2_frmsize_discrete amg88xx_size = {
+   .width = 8,
+   .height = 8,
+};
+
+struct video_i2c_chip {
+   /* video dimensions */
+   const struct v4l2_fmtdesc *format;
+   const struct v4l2_frmsize_discrete *size;
+
+   /* max frames per second */
+   unsigned int max_fps;
+
+   /* pixel buffer size */
+   unsigned int buffer_size;
+
+   /* pixel size in bits */
+   unsigned int bpp;
+
+   /* xfer function */
+   int (*xfer)(struct video_i2c_data *data, char *buf);
+};
+
+static int amg88xx_xfer(struct video_i2c_data *data, char *buf)
+{
+   struct i2c_client *client = data->client;
+   struct i2c_msg msg[2];
+   u8 reg = 0x80;
+   int ret;
+
+   msg[0].addr = client->addr;
+   msg[0].flags = 0;
+   msg[0].len = 1;
+   msg[0].buf  = (char *) 
+
+   msg[1].addr = client->addr;
+   msg[1].flags = I2C_M_RD;
+   msg[1].len = data->chip->buffer_size;
+   msg[1].buf = (char *) buf;
+
+   ret = i2c_transfer(client->adapter, msg, 2);
+
+   return (ret == 2) ? 0 : -EIO;
+}
+
+static const struct video_i2c_chip video_i2c_chip = {
+   .size   = _size,
+   .format = _format,
+   .max_fps= 10,
+   .buffer_size= 128,
+   .bpp= 16,
+   .xfer   = _xfer,
+};
+
+static const struct v4l2_file_operations video_i2c_fops = {
+   .owner  = THIS_MODULE,
+   .open   = v4l2_fh_open,
+   .release= vb2_fop_release,
+   .poll   = vb2_fop_poll,
+   .read   = vb2_fop_read,
+   .mmap   = vb2_fop_mmap,
+   .unlocked_ioctl = 

Re: [PATCH RESEND] media: video-i2c: add video-i2c driver

[Matt Ranostay]

On Thu, Feb 15, 2018 at 7:49 AM, Hans Verkuil  wrote:
> Hi Matt,
>
> Here is a quick review. Apologies for the delay, it has been very busy for
> the last few weeks.
>
> On 13/01/18 04:57, Matt Ranostay wrote:
>> There are several thermal sensors that only have a low-speed bus
>> interface but output valid video data. This patchset enables support
>> for the AMG88xx "Grid-Eye" sensor family.
>>
>> Cc: Luca Barbato 
>> Cc: Laurent Pinchart 
>> Signed-off-by: Matt Ranostay 
>> ---
>>  drivers/media/i2c/Kconfig |   9 +
>>  drivers/media/i2c/Makefile|   1 +
>>  drivers/media/i2c/video-i2c.c | 556 
>> ++
>>  3 files changed, 566 insertions(+)
>>  create mode 100644 drivers/media/i2c/video-i2c.c
>>
>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>> index 9f18cd296841..549f1e9fc01e 100644
>> --- a/drivers/media/i2c/Kconfig
>> +++ b/drivers/media/i2c/Kconfig
>> @@ -908,6 +908,15 @@ config VIDEO_M52790
>>
>>To compile this driver as a module, choose M here: the
>>module will be called m52790.
>> +
>> +config VIDEO_I2C
>> + tristate "I2C transport video support"
>> + depends on VIDEO_V4L2 && I2C
>> + select VIDEOBUF2_VMALLOC
>> + ---help---
>> +   Enable the I2C transport video support which supports the
>> +   following:
>> +* Panasonic AMG88xx Grid-Eye Sensors
>>  endmenu
>>
>>  menu "Sensors used on soc_camera driver"
>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
>> index c0f94cd8d56d..5ca4c98a4bea 100644
>> --- a/drivers/media/i2c/Makefile
>> +++ b/drivers/media/i2c/Makefile
>> @@ -90,6 +90,7 @@ obj-$(CONFIG_VIDEO_LM3646)  += lm3646.o
>>  obj-$(CONFIG_VIDEO_SMIAPP_PLL)   += smiapp-pll.o
>>  obj-$(CONFIG_VIDEO_AK881X)   += ak881x.o
>>  obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
>> +obj-$(CONFIG_VIDEO_I2C)  += video-i2c.o
>>  obj-$(CONFIG_VIDEO_ML86V7667)+= ml86v7667.o
>>  obj-$(CONFIG_VIDEO_OV2659)   += ov2659.o
>>  obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
>> diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
>> new file mode 100644
>> index ..9df9b5ebd156
>> --- /dev/null
>> +++ b/drivers/media/i2c/video-i2c.c
>> @@ -0,0 +1,556 @@
>> +/*
>> + * video-i2c.c - Support for I2C transport video devices
>> + *
>> + * Copyright (C) 2018 Matt Ranostay 
>> + *
>> + * 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.
>> + *
>> + * 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 the SPDX tags instead of this license text. See
> https://git.linuxtv.org/media_tree.git/tree/Documentation/process/license-rules.rst
>
>> + *
>> + * Supported:
>> + * - Panasonic AMG88xx Grid-Eye Sensors
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define VIDEO_I2C_DRIVER "video-i2c"
>> +#define MAX_BUFFER_SIZE  128
>> +
>> +struct video_i2c_chip;
>> +
>> +struct video_i2c_buffer {
>> + struct vb2_v4l2_buffer vb;
>> + struct list_head list;
>> +};
>> +
>> +struct video_i2c_data {
>> + struct i2c_client *client;
>> + const struct video_i2c_chip *chip;
>> + struct mutex lock;
>> + spinlock_t slock;
>> + struct mutex queue_lock;
>> +
>> + struct v4l2_device v4l2_dev;
>> + struct video_device vdev;
>> + struct vb2_queue vb_vidq;
>> +
>> + struct task_struct *kthread_vid_cap;
>> + struct list_head vid_cap_active;
>> +};
>> +
>> +static struct v4l2_fmtdesc amg88xx_format = {
>> + .pixelformat = V4L2_PIX_FMT_Y12,
>> +};
>> +
>> +static struct v4l2_frmsize_discrete amg88xx_size = {
>> + .width = 8,
>> + .height = 8,
>> +};
>> +
>> +struct video_i2c_chip {
>> + /* video dimensions */
>> + const struct v4l2_fmtdesc *format;
>> + const struct v4l2_frmsize_discrete *size;
>> +
>> + /* max frames per second */
>> + unsigned int max_fps;
>> +
>> + /* pixel buffer size */
>> + unsigned int buffer_size;
>> +
>> + /* pixel size in bits */
>> + unsigned int bpp;
>> +
>> + /* xfer function */
>> + int (*xfer)(struct video_i2c_data *data, char *buf);
>> +};
>> +
>> +static int amg88xx_xfer(struct video_i2c_data *data, char *buf)
>> +{
>> + struct i2c_client *client = data->client;
>> 

Please its for you

[Mrs.Gangadai Nankishore]

Dear Good day,
I sent this mail praying for it to reach you in good health, since I myself are 
in a very critical health condition in which I sleep every night without 
knowing if I may be alive to see the next day. I am Mrs. Gangadai Nankishore, a 
widow suffering from long time illness. I have some funds I inherited from my 
late husband, the sum of (US$18,3 Million Dollars) my Doctor told me recently 
that I would not last due to the illness. Having known my condition, I decided 
to donate this fund to a good person that will utilize it the way i am going to 
instruct herein. I need a very honest and God fearing person who can claim this 
money and use it for Charity works, for orphanages, widows and also build 
schools for less privilege that will be named after my late husband if possible.

I accept this decision because I do not have any child who will inherit this 
money after I die.

Please I want your sincerely and urgent answer to know if you will be able to 
execute this project, and I will give you more information on how the fund will 
be transferred to your bank account.

I am waiting for your reply,

Mrs.Gangadai Nankishore

Re: [PATCH v13 7/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx

[Tim Harvey]

On Thu, Feb 15, 2018 at 10:36 AM, Hans Verkuil  wrote:
> On 15/02/18 18:55, Tim Harvey wrote:
>> The GW54xx has a front-panel microHDMI connector routed to a TDA19971
>> which is connected the the IPU CSI when using IMX6Q.
>
> I assume that this and the next patch go through another subsystem for arm
> and/or imx?
>
> Regards,
>
> Hans
>

Hans,

Yes - Shawn should pick up the two dts patches:
0007-ARM-dts-imx-Add-TDA19971-HDMI-Receiver-to-GW54xx.patch
0008-ARM-dts-imx-Add-TDA19971-HDMI-Receiver-to-GW551x.patch

Shawn you've seen these before but haven't ack'd them - are they good
to merge to your imx tree?

Regards,

Tim

[GIT PULL FOR v4.17] uvcvideo changes

[Laurent Pinchart]

Hi Mauro,

The following changes since commit 29422737017b866d4a51014cc7522fa3a99e8852:

  media: rc: get start time just before calling driver tx (2018-02-14 14:17:21 
-0500)

are available in the git repository at:

  git://linuxtv.org/pinchartl/media.git uvc/next

for you to fetch changes up to df0d402a05dfe57cc6069d189ae9844f5bb4e852:

  uvcvideo: Fixed ktime_t to ns conversion (2018-02-15 10:16:34 +0200)


Edgar Thier (1):
  uvcvideo: Apply flags from device to actual properties

Jasmin Jessich (1):
  uvcvideo: Fixed ktime_t to ns conversion

Laurent Pinchart (4):
  uvcvideo: Drop extern keyword in function declarations
  uvcvideo: Use kernel integer types
  uvcvideo: Use internal kernel integer types
  uvcvideo: Use parentheses around sizeof operand

Philipp Zabel (1):
  uvcvideo: Support multiple frame descriptors with the same dimensions

 drivers/media/usb/uvc/uvc_ctrl.c   | 114 +---
 drivers/media/usb/uvc/uvc_driver.c |  97 +++---
 drivers/media/usb/uvc/uvc_isight.c |   6 +-
 drivers/media/usb/uvc/uvc_status.c |   4 +-
 drivers/media/usb/uvc/uvc_v4l2.c   | 139 +---
 drivers/media/usb/uvc/uvc_video.c  |  47 +++
 drivers/media/usb/uvc/uvcvideo.h   | 320 +-
 7 files changed, 395 insertions(+), 332 deletions(-)

-- 
Regards,

Laurent Pinchart

Re: [PATCH v13 7/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx

[Hans Verkuil]

On 15/02/18 18:55, Tim Harvey wrote:
> The GW54xx has a front-panel microHDMI connector routed to a TDA19971
> which is connected the the IPU CSI when using IMX6Q.

I assume that this and the next patch go through another subsystem for arm
and/or imx?

Regards,

Hans

> 
> Signed-off-by: Tim Harvey 
> ---
> v5:
>  - remove leading 0 from unit address
>  - add newline between property list and child node
> 
> v4: no changes
> v3: no changes
> 
> v2:
>  - add HDMI audio input support
> 
>  arch/arm/boot/dts/imx6q-gw54xx.dts| 105 
> ++
>  arch/arm/boot/dts/imx6qdl-gw54xx.dtsi |  29 +-
>  2 files changed, 131 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx6q-gw54xx.dts 
> b/arch/arm/boot/dts/imx6q-gw54xx.dts
> index 56e5b50..0477120 100644
> --- a/arch/arm/boot/dts/imx6q-gw54xx.dts
> +++ b/arch/arm/boot/dts/imx6q-gw54xx.dts
> @@ -12,10 +12,30 @@
>  /dts-v1/;
>  #include "imx6q.dtsi"
>  #include "imx6qdl-gw54xx.dtsi"
> +#include 
>  
>  / {
>   model = "Gateworks Ventana i.MX6 Dual/Quad GW54XX";
>   compatible = "gw,imx6q-gw54xx", "gw,ventana", "fsl,imx6q";
> +
> + sound-digital {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "tda1997x-audio";
> +
> + simple-audio-card,dai-link@0 {
> + format = "i2s";
> +
> + cpu {
> + sound-dai = <>;
> + };
> +
> + codec {
> + bitclock-master;
> + frame-master;
> + sound-dai = <>;
> + };
> + };
> + };
>  };
>  
>   {
> @@ -35,6 +55,61 @@
>   };
>   };
>   };
> +
> + tda1997x: codec@48 {
> + compatible = "nxp,tda19971";
> + pinctrl-names = "default";
> + pinctrl-0 = <_tda1997x>;
> + reg = <0x48>;
> + interrupt-parent = <>;
> + interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> + DOVDD-supply = <_3p3v>;
> + AVDD-supply = <_reg>;
> + DVDD-supply = <_reg>;
> + #sound-dai-cells = <0>;
> + nxp,audout-format = "i2s";
> + nxp,audout-layout = <0>;
> + nxp,audout-width = <16>;
> + nxp,audout-mclk-fs = <128>;
> + /*
> +  * The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
> +  * and Y[11:4] across 16bits in the same cycle
> +  * which we map to VP[15:08]<->CSI_DATA[19:12]
> +  */
> + nxp,vidout-portcfg =
> + /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
> + < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
> + /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
> + < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
> + /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
> + < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
> + /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
> + < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
> +
> + port {
> + tda1997x_to_ipu1_csi0_mux: endpoint {
> + remote-endpoint = 
> <_csi0_mux_from_parallel_sensor>;
> + bus-width = <16>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + data-active = <1>;
> + };
> + };
> + };
> +};
> +
> +_csi0_from_ipu1_csi0_mux {
> + bus-width = <16>;
> +};
> +
> +_csi0_mux_from_parallel_sensor {
> + remote-endpoint = <_to_ipu1_csi0_mux>;
> + bus-width = <16>;
> +};
> +
> +_csi0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_ipu1_csi0>;
>  };
>  
>  _csi1_from_ipu2_csi1_mux {
> @@ -63,6 +138,30 @@
>   >;
>   };
>  
> + pinctrl_ipu1_csi0: ipu1_csi0grp {
> + fsl,pins = <
> + MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04  0x1b0b0
> + MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05  0x1b0b0
> + MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06  0x1b0b0
> + MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07  0x1b0b0
> + MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08  0x1b0b0
> + MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09  0x1b0b0
> + MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x1b0b0
> + 

[GIT PULL FOR v4.17] Add tda1997x.c

[Hans Verkuil]

This pull requests adds the new tda1997x HDMI receiver.

Regards,

Hans

The following changes since commit 29422737017b866d4a51014cc7522fa3a99e8852:

  media: rc: get start time just before calling driver tx (2018-02-14 14:17:21 
-0500)

are available in the Git repository at:

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

for you to fetch changes up to feecd372500a8470d68a4320996201e47b0f19f9:

  media: i2c: Add TDA1997x HDMI receiver driver (2018-02-15 19:25:54 +0100)


Hans Verkuil (1):
  v4l2-dv-timings: add v4l2_hdmi_colorimetry()

Tim Harvey (5):
  media: v4l-ioctl: fix clearing pad for VIDIOC_DV_TIMINGS_CAP
  media: add digital video decoder entity functions
  MAINTAINERS: add entry for NXP TDA1997x driver
  media: dt-bindings: Add bindings for TDA1997X
  media: i2c: Add TDA1997x HDMI receiver driver

 Documentation/devicetree/bindings/media/i2c/tda1997x.txt |  178 +++
 Documentation/media/uapi/mediactl/media-types.rst|   11 +
 MAINTAINERS  |8 +
 drivers/media/i2c/Kconfig|9 +
 drivers/media/i2c/Makefile   |1 +
 drivers/media/i2c/tda1997x.c | 2820 
+
 drivers/media/i2c/tda1997x_regs.h|  641 +++
 drivers/media/v4l2-core/v4l2-dv-timings.c|  141 +++
 drivers/media/v4l2-core/v4l2-ioctl.c |2 +-
 include/dt-bindings/media/tda1997x.h |   74 ++
 include/media/i2c/tda1997x.h |   42 +
 include/media/v4l2-dv-timings.h  |   21 +
 include/uapi/linux/media.h   |5 +
 13 files changed, 3952 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
 create mode 100644 drivers/media/i2c/tda1997x.c
 create mode 100644 drivers/media/i2c/tda1997x_regs.h
 create mode 100644 include/dt-bindings/media/tda1997x.h
 create mode 100644 include/media/i2c/tda1997x.h

[PATCH v13 2/8] media: v4l-ioctl: fix clearing pad for VIDIOC_DV_TIMIGNS_CAP

[Tim Harvey]

Signed-off-by: Tim Harvey 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 7961499..5f3670d 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2638,7 +2638,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO_FNC(VIDIOC_PREPARE_BUF, v4l_prepare_buf, v4l_print_buffer, 
INFO_FL_QUEUE),
IOCTL_INFO_STD(VIDIOC_ENUM_DV_TIMINGS, vidioc_enum_dv_timings, 
v4l_print_enum_dv_timings, INFO_FL_CLEAR(v4l2_enum_dv_timings, pad)),
IOCTL_INFO_STD(VIDIOC_QUERY_DV_TIMINGS, vidioc_query_dv_timings, 
v4l_print_dv_timings, INFO_FL_ALWAYS_COPY),
-   IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap, 
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, type)),
+   IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap, 
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, pad)),
IOCTL_INFO_FNC(VIDIOC_ENUM_FREQ_BANDS, v4l_enum_freq_bands, 
v4l_print_freq_band, 0),
IOCTL_INFO_FNC(VIDIOC_DBG_G_CHIP_INFO, v4l_dbg_g_chip_info, 
v4l_print_dbg_chip_info, INFO_FL_CLEAR(v4l2_dbg_chip_info, match)),
IOCTL_INFO_FNC(VIDIOC_QUERY_EXT_CTRL, v4l_query_ext_ctrl, 
v4l_print_query_ext_ctrl, INFO_FL_CTRL | INFO_FL_CLEAR(v4l2_query_ext_ctrl, 
id)),
-- 
2.7.4

[PATCH v13 0/8] TDA1997x HDMI video reciver

[Tim Harvey]

This is a v4l2 subdev driver supporting the TDA1997x HDMI video receiver.

I've tested this on a Gateworks GW54xx/GW551x with an IMX6Q/IMX6DL which
uses the TDA19971 with 16bits connected to the IMX6 CSI and single-lane
I2S audio providing 2-channel audio.

For this configuration I've tested both 16bit YUV422 and 8bit
BT656 parallel video bus modes.

While the driver should support the TDA1993 I do not have one for testing.

Further potential development efforts include:
 - CEC support
 - HDCP support
 - TDA19972 support (2 inputs)

Media graphs can be found at http://dev.gateworks.com/docs/linux/media

See details below for configuration and compliance tests

History:
v13:
 - fix coccinelle warnings

v12:
 - fix coccinelle warnings

v11:
 - return -ERANGE from tda1997x_detect_std (Hans)
 - clean up tda1997x_g_input_status (Hans)
 - show detected timings on resolution change if debug enabled
 - fix unitialized ret var in tda1997x_query_dv_timings
 - update log status to show detected timings

v10:
 - removed unnecessary check for !timings in get/set/query dv timings (Hans)
 - dropped pointless s_stream handler (Hans)
 - remove need for detected_timings and always use set timings (Hans)

v9:
 - add digital video decoder video interface entity function

v8:
 - fix clearing pad for VIDIOC_DV_TIMIGNS_CAP
 - support full range of input modes based on timings_cap
 - add patch to fix clearing pad for VIDIOC_DV_TIMIGINGS
 - fix available formats for tda19971 bt656 bus width >12
 - fix set_format (compliance)
 - fixed get/set edid (compliance)
 - add init_cfg to setup default pad config (compliance)
 - added missing pad checks to get_dv_timings_cap/enum_dv_timings (compliance)
 - fix alignment of if statement and whitespace in comment (Hans)
 - move regs to tda1997x_regs.h to clean up (Hans)
 - add define and sanity check for num of mbus_codes (Hans)

v7:
 - fix interlaced mode
 - support no AVI infoframe (ie DVI) (Hans)
 - add support for multiple output formats (Hans)

v6:
 - tda1997x: fix return on regulator enablei in tda1997x_set_power() (Fabio)
 - tda1997x: fix colorspace handling (Hans)
 - bindings: added Robs's ack (Rob)
 - replace copyright with SPDX tag (Philippe)

v5:
 - added v4l2_hdmi_colorimetry() patch from Hans to series
 - bindings: added Sakari's ack
 - tda1997x: uppercase string constants
 - tda1997x: use v4l2_hdmi_rx_coloriemtry to fill format
 - tda1997x: fix V4L2_CID_DV_RX_RGB_RANGE
 - tda1997x: fix interlaced mode format
 - dts: remove leading 0 from unit address
 - dts: add newline between property list and child node
 - dts: added missing audmux in GW551x dts

v4:
 - move include/dt-bindings/media/tda1997x.h to bindings patch
 - clarify port node details in bindings
 - fix typos
 - fix default quant range for VGA
 - fix quant range handling and conv matrix
 - add additional standards and capabilities to timings_cap

v3:
 - fix typo in dt bindings
 - added dt bindings for GW551x
 - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros
 - fixed missing break
 - use only hdmi_infoframe_log for infoframe logging
 - simplify tda1997x_s_stream error handling
 - add delayed work proc to handle hotplug enable/disable
 - fix set_edid (disable HPD before writing, enable after)
 - remove enabling edid by default
 - initialize timings
 - take quant range into account in colorspace conversion
 - remove vendor/product tracking (we provide this in log_status via
   infoframes)
 - add v4l_controls
 - add more detail to log_status
 - calculate vhref generator timings
 - timing detection fixes (rounding errors, hswidth errors)
 - rename configure_input/configure_conv functions

v2:
 - encorporate feedback into dt bindings
 - change audio dt bindings
 - implement dv timings enum/cap
 - remove deprecated g_mbus_config op
 - fix dv_query_timings
 - add EDID get/set handling
 - remove max-pixel-rate support
 - add audio codec DAI support
 - added media-ctl and v4l2-compliance details

v1:
 - initial RFC

Pipeline configuration:
$ media-ctl -e 'tda19971 2-0048'
/dev/v4l-subdev1
$ v4l2-ctl -d /dev/v4l-subdev1 --set-dv-bt-timings=query
BT timings set
$ media-ctl --get-v4l2 '"tda19971 2-0048":0'
[fmt:UYVY8_2X8/1280x720 field:none colorspace:srgb]

$ media-ctl --link "tda19971 2-0048":0 -> "ipu1_csi0_mux":1[1]
$ media-ctl --link "ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]
$ media-ctl --link "ipu1_csi0":2 -> "ipu1_csi0 capture":0[1]
$ media-ctl --set-v4l2 'tda19971 2-0048':0[fmt:UYVY8_2X8/1280x720]
$ media-ctl --set-v4l2 'ipu1_csi0_mux':2[fmt:UYVY8_2X8/1280x720]
$ media-ctl --set-v4l2 'ipu1_csi0':0[fmt:UYVY8_2X8/1280x720]
$ gst-launch-1.0 v4l2src device=/dev/video4 ! 
video/x-raw,width=1280,height=720,format=UYVY ! jpegenc ! rtpjpegpay ! udpsink 
host=172.24.40.6 port=5000

$ media-ctl -d /dev/media0 -p
Media controller API version 4.15.0

Media device information

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

[PATCH v13 1/8] v4l2-dv-timings: add v4l2_hdmi_colorimetry()

[Tim Harvey]

From: Hans Verkuil 

Add the v4l2_hdmi_colorimetry() function so we have a single function
that determines the colorspace, YCbCr encoding, quantization range and
transfer function from the InfoFrame data.

Cc: Randy Dunlap 
Signed-off-by: Hans Verkuil 
---
v9:
 - fix kernel-doc format (Randy)

 drivers/media/v4l2-core/v4l2-dv-timings.c | 141 ++
 include/media/v4l2-dv-timings.h   |  21 +
 2 files changed, 162 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c 
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index 930f9c5..5663d86 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 MODULE_AUTHOR("Hans Verkuil");
 MODULE_DESCRIPTION("V4L2 DV Timings Helper Functions");
@@ -814,3 +815,143 @@ struct v4l2_fract v4l2_calc_aspect_ratio(u8 
hor_landscape, u8 vert_portrait)
return aspect;
 }
 EXPORT_SYMBOL_GPL(v4l2_calc_aspect_ratio);
+
+/** v4l2_hdmi_rx_colorimetry - determine HDMI colorimetry information
+ * based on various InfoFrames.
+ * @avi: the AVI InfoFrame
+ * @hdmi: the HDMI Vendor InfoFrame, may be NULL
+ * @height: the frame height
+ *
+ * Determines the HDMI colorimetry information, i.e. how the HDMI
+ * pixel color data should be interpreted.
+ *
+ * Note that some of the newer features (DCI-P3, HDR) are not yet
+ * implemented: the hdmi.h header needs to be updated to the HDMI 2.0
+ * and CTA-861-G standards.
+ */
+struct v4l2_hdmi_colorimetry
+v4l2_hdmi_rx_colorimetry(const struct hdmi_avi_infoframe *avi,
+const struct hdmi_vendor_infoframe *hdmi,
+unsigned int height)
+{
+   struct v4l2_hdmi_colorimetry c = {
+   V4L2_COLORSPACE_SRGB,
+   V4L2_YCBCR_ENC_DEFAULT,
+   V4L2_QUANTIZATION_FULL_RANGE,
+   V4L2_XFER_FUNC_SRGB
+   };
+   bool is_ce = avi->video_code || (hdmi && hdmi->vic);
+   bool is_sdtv = height <= 576;
+   bool default_is_lim_range_rgb = avi->video_code > 1;
+
+   switch (avi->colorspace) {
+   case HDMI_COLORSPACE_RGB:
+   /* RGB pixel encoding */
+   switch (avi->colorimetry) {
+   case HDMI_COLORIMETRY_EXTENDED:
+   switch (avi->extended_colorimetry) {
+   case HDMI_EXTENDED_COLORIMETRY_ADOBE_RGB:
+   c.colorspace = V4L2_COLORSPACE_ADOBERGB;
+   c.xfer_func = V4L2_XFER_FUNC_ADOBERGB;
+   break;
+   case HDMI_EXTENDED_COLORIMETRY_BT2020:
+   c.colorspace = V4L2_COLORSPACE_BT2020;
+   c.xfer_func = V4L2_XFER_FUNC_709;
+   break;
+   default:
+   break;
+   }
+   break;
+   default:
+   break;
+   }
+   switch (avi->quantization_range) {
+   case HDMI_QUANTIZATION_RANGE_LIMITED:
+   c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+   break;
+   case HDMI_QUANTIZATION_RANGE_FULL:
+   break;
+   default:
+   if (default_is_lim_range_rgb)
+   c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+   break;
+   }
+   break;
+
+   default:
+   /* YCbCr pixel encoding */
+   c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+   switch (avi->colorimetry) {
+   case HDMI_COLORIMETRY_NONE:
+   if (!is_ce)
+   break;
+   if (is_sdtv) {
+   c.colorspace = V4L2_COLORSPACE_SMPTE170M;
+   c.ycbcr_enc = V4L2_YCBCR_ENC_601;
+   } else {
+   c.colorspace = V4L2_COLORSPACE_REC709;
+   c.ycbcr_enc = V4L2_YCBCR_ENC_709;
+   }
+   c.xfer_func = V4L2_XFER_FUNC_709;
+   break;
+   case HDMI_COLORIMETRY_ITU_601:
+   c.colorspace = V4L2_COLORSPACE_SMPTE170M;
+   c.ycbcr_enc = V4L2_YCBCR_ENC_601;
+   c.xfer_func = V4L2_XFER_FUNC_709;
+   break;
+   case HDMI_COLORIMETRY_ITU_709:
+   c.colorspace = V4L2_COLORSPACE_REC709;
+   c.ycbcr_enc = V4L2_YCBCR_ENC_709;
+   c.xfer_func = V4L2_XFER_FUNC_709;
+   break;
+   case HDMI_COLORIMETRY_EXTENDED:
+   switch 

[PATCH v13 3/8] media: add digital video decoder entity functions

[Tim Harvey]

Add a new media entity function definition for digital TV decoders:
MEDIA_ENT_F_DTV_DECODER

Signed-off-by: Tim Harvey 
---
 Documentation/media/uapi/mediactl/media-types.rst | 11 +++
 include/uapi/linux/media.h|  5 +
 2 files changed, 16 insertions(+)

diff --git a/Documentation/media/uapi/mediactl/media-types.rst 
b/Documentation/media/uapi/mediactl/media-types.rst
index 8d64b0c..195400e 100644
--- a/Documentation/media/uapi/mediactl/media-types.rst
+++ b/Documentation/media/uapi/mediactl/media-types.rst
@@ -321,6 +321,17 @@ Types and flags used to represent the media graph elements
  MIPI CSI-2, ...), and outputs them on its source pad to an output
  video bus of another type (eDP, MIPI CSI-2, parallel, ...).
 
+-  ..  row 31
+
+   ..  _MEDIA-ENT-F-DTV-DECODER:
+
+   -  ``MEDIA_ENT_F_DTV_DECODER``
+
+   -  Digital video decoder. The basic function of the video decoder is
+ to accept digital video from a wide variety of sources
+ and output it in some digital video standard, with appropriate
+ timing signals.
+
 ..  tabularcolumns:: |p{5.5cm}|p{12.0cm}|
 
 .. _media-entity-flag:
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index b9b9446..2f12328 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -110,6 +110,11 @@ struct media_device_info {
 #define MEDIA_ENT_F_VID_IF_BRIDGE  (MEDIA_ENT_F_BASE + 0x5002)
 
 /*
+ * Digital video decoder entities
+ */
+#define MEDIA_ENT_F_DTV_DECODER(MEDIA_ENT_F_BASE + 
0x6001)
+
+/*
  * Connectors
  */
 /* It is a responsibility of the entity drivers to add connectors and links */
-- 
2.7.4

[PATCH v13 5/8] media: dt-bindings: Add bindings for TDA1997X

[Tim Harvey]

Acked-by: Rob Herring 
Acked-by: Sakari Ailus 
Signed-off-by: Tim Harvey 
---
v6:
 - replace copyright with SPDX tag
 - added Rob's ack

v5:
 - added Sakari's ack

v4:
 - move include/dt-bindings/media/tda1997x.h to bindings patch
 - clarify port node details

v3:
 - fix typo

v2:
 - add vendor prefix and remove _ from vidout-portcfg
 - remove _ from labels
 - remove max-pixel-rate property
 - describe and provide example for single output port
 - update to new audio port bindings

 .../devicetree/bindings/media/i2c/tda1997x.txt | 179 +
 include/dt-bindings/media/tda1997x.h   |  74 +
 2 files changed, 253 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
 create mode 100644 include/dt-bindings/media/tda1997x.h

diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt 
b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
new file mode 100644
index 000..9ab53c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
@@ -0,0 +1,179 @@
+Device-Tree bindings for the NXP TDA1997x HDMI receiver
+
+The TDA19971/73 are HDMI video receivers.
+
+The TDA19971 Video port output pins can be used as follows:
+ - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
+ - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
+ - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
+ - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
+ - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0]
+ - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
+ - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The TDA19973 Video port output pins can be used as follows:
+ - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
+ - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
+ - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The Video port output pins are mapped via 4-bit 'pin groups' allowing
+for a variety of connection possibilities including swapping pin order within
+pin groups. The video_portcfg device-tree property consists of register mapping
+pairs which map a chip-specific VP output register to a 4-bit pin group. If
+the pin group needs to be bit-swapped you can use the *_S pin-group defines.
+
+Required Properties:
+ - compatible  :
+  - "nxp,tda19971" for the TDA19971
+  - "nxp,tda19973" for the TDA19973
+ - reg : I2C slave address
+ - interrupts  : The interrupt number
+ - DOVDD-supply: Digital I/O supply
+ - DVDD-supply : Digital Core supply
+ - AVDD-supply : Analog supply
+ - nxp,vidout-portcfg  : array of pairs mapping VP output pins to pin groups.
+
+Optional Properties:
+ - nxp,audout-format   : DAI bus format: "i2s" or "spdif".
+ - nxp,audout-width: width of audio output data bus (1-4).
+ - nxp,audout-layout   : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used).
+ - nxp,audout-mclk-fs  : Multiplication factor between stream rate and codec
+ mclk.
+
+The port node shall contain one endpoint child node for its digital
+output video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Optional Endpoint Properties:
+  The following three properties are defined in video-interfaces.txt and
+  are valid for the output parallel bus endpoint:
+  - hsync-active: Horizontal synchronization polarity. Defaults to active high.
+  - vsync-active: Vertical synchronization polarity. Defaults to active high.
+  - data-active: Data polarity. Defaults to active high.
+
+Examples:
+ - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422
+   16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
+   hdmi-receiver@48 {
+   compatible = "nxp,tda19971";
+   pinctrl-names = "default";
+   pinctrl-0 = <_tda1997x>;
+   reg = <0x48>;
+   interrupt-parent = <>;
+   interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+   DOVDD-supply = <_3p3v>;
+   AVDD-supply = <_1p8v>;
+   DVDD-supply = <_1p8v>;
+   /* audio */
+   #sound-dai-cells = <0>;
+   nxp,audout-format = "i2s";
+   nxp,audout-layout = <0>;
+   nxp,audout-width = <16>;
+   nxp,audout-mclk-fs = <128>;
+   /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same pixclk cycle.
+*/
+   nxp,vidout-portcfg =
+  

[PATCH v13 4/8] MAINTAINERS: add entry for NXP TDA1997x driver

[Tim Harvey]

Signed-off-by: Tim Harvey 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 845fc25..439b500 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13262,6 +13262,14 @@ T: git git://linuxtv.org/mkrufky/tuners.git
 S: Maintained
 F: drivers/media/tuners/tda18271*
 
+TDA1997x MEDIA DRIVER
+M: Tim Harvey 
+L: linux-media@vger.kernel.org
+W: https://linuxtv.org
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+S: Maintained
+F: drivers/media/i2c/tda1997x.*
+
 TDA827x MEDIA DRIVER
 M: Michael Krufky 
 L: linux-media@vger.kernel.org
-- 
2.7.4

[PATCH v13 8/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x

[Tim Harvey]

Signed-off-by: Tim Harvey 
---
v5:
 - add missing audmux config

 arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 138 ++
 1 file changed, 138 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
index 30d4662..749548a 100644
--- a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
@@ -46,6 +46,8 @@
  */
 
 #include 
+#include 
+#include 
 
 / {
/* these are used by bootloader for disabling nodes */
@@ -98,6 +100,50 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
};
+
+   sound-digital {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "tda1997x-audio";
+
+   simple-audio-card,dai-link@0 {
+   format = "i2s";
+
+   cpu {
+   sound-dai = <>;
+   };
+
+   codec {
+   bitclock-master;
+   frame-master;
+   sound-dai = <>;
+   };
+   };
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_audmux>; /* AUD5<->tda1997x */
+   status = "okay";
+
+   ssi1 {
+   fsl,audmux-port = <0>;
+   fsl,port-config = <
+   (IMX_AUDMUX_V2_PTCR_TFSDIR |
+   IMX_AUDMUX_V2_PTCR_TFSEL(4+8) | /* RXFS */
+   IMX_AUDMUX_V2_PTCR_TCLKDIR |
+   IMX_AUDMUX_V2_PTCR_TCSEL(4+8) | /* RXC */
+   IMX_AUDMUX_V2_PTCR_SYN)
+   IMX_AUDMUX_V2_PDCR_RXDSEL(4)
+   >;
+   };
+
+   aud5 {
+   fsl,audmux-port = <4>;
+   fsl,port-config = <
+   IMX_AUDMUX_V2_PTCR_SYN
+   IMX_AUDMUX_V2_PDCR_RXDSEL(0)>;
+   };
 };
 
  {
@@ -263,6 +309,60 @@
#gpio-cells = <2>;
};
 
+   tda1997x: tda1997x@48 {
+   compatible = "nxp,tda19971";
+   pinctrl-names = "default";
+   pinctrl-0 = <_tda1997x>;
+   reg = <0x48>;
+   interrupt-parent = <>;
+   interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+   DOVDD-supply = <_3p3>;
+   AVDD-supply = <_1p8b>;
+   DVDD-supply = <_1p8a>;
+   #sound-dai-cells = <0>;
+   nxp,audout-format = "i2s";
+   nxp,audout-layout = <0>;
+   nxp,audout-width = <16>;
+   nxp,audout-mclk-fs = <128>;
+   /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+   nxp,vidout-portcfg =
+   /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+   < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+   /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+   < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+   /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+   < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+   /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+   < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+   port {
+   tda1997x_to_ipu1_csi0_mux: endpoint {
+   remote-endpoint = 
<_csi0_mux_from_parallel_sensor>;
+   bus-width = <16>;
+   hsync-active = <1>;
+   vsync-active = <1>;
+   data-active = <1>;
+   };
+   };
+   };
+};
+
+_csi0_from_ipu1_csi0_mux {
+   bus-width = <16>;
+};
+
+_csi0_mux_from_parallel_sensor {
+   remote-endpoint = <_to_ipu1_csi0_mux>;
+   bus-width = <16>;
+};
+
+_csi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ipu1_csi0>;
 };
 
  {
@@ -320,6 +420,14 @@
 };
 
  {
+   pinctrl_audmux: audmuxgrp {
+   fsl,pins = <
+   MX6QDL_PAD_DISP0_DAT19__AUD5_RXD0x130b0
+   MX6QDL_PAD_DISP0_DAT14__AUD5_RXC0x130b0
+   MX6QDL_PAD_DISP0_DAT13__AUD5_RXFS   0x130b0
+   >;
+   };
+
pinctrl_flexcan1: flexcan1grp {
fsl,pins = <
MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX0x1b0b1
@@ -375,6 +483,30 @@
>;
};
 
+   pinctrl_ipu1_csi0: ipu1_csi0grp {
+   fsl,pins = <
+   MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04  0x1b0b0
+   

[PATCH v13 6/8] media: i2c: Add TDA1997x HDMI receiver driver

[Tim Harvey]

Add support for the TDA1997x HDMI receivers.

Cc: Hans Verkuil 
Signed-off-by: Tim Harvey 
---
v13:
 - fix coccinelle warnings

v12:
 - fix coccinelle warnings

v11:
 - return -ERANGE from tda1997x_detect_std (Hans)
 - clean up tda1997x_g_input_status (Hans)
 - show detected timings on resolution change if debug enabled
 - fix unitialized ret var in tda1997x_query_dv_timings
 - update log status to show detected timings

v10:
 - removed unnecessary check for !timings in get/set/query dv timings (Hans)
 - dropped pointless s_stream handler (Hans)
 - remove need for detected_timings and always use set timings (Hans)

v9:
 - remove redundant pad bounds check already in v4l2-subdev.c
 - assign entity function (Hans)
 - properly assign/check/free ctrl_handler (Hans)
 - fixed typo 'Rull Range' -> 'Full Range'
 - update csc after quant range change

v8:
 - fix available formats for tda19971 bt656 bus width >12
 - support full range of input modes based on timings_cap
 - fix set_format (compliance)
 - fixed get/set edid (compliance)
 - add init_cfg to setup default pad config (compliance)
 - added missing pad checks to get_dv_timings_cap/enum_dv_timings (compliance)
 - fix alignment of if statement and whitespace in comment (Hans)
 - move regs to tda1997x_regs.h to clean up (Hans)
 - add define and sanity check for num of mbus_codes (Hans)

v7:
 - fix interlaced mode
 - support no AVI infoframe (ie DVI) (Hans)
 - add support for multiple output formats (Hans)

v6:
 - fix return on regulator enablei in tda1997x_set_power()
 - replace copyright with SPDX tag
 - fix colorspace handling

v5:
 - uppercase string constants
 - use v4l2_hdmi_rx_coloriemtry to fill format
 - fix V4L2_CID_DV_RX_RGB_RANGE
 - fix interlaced mode format

v4:
 - move include/dt-bindings/media/tda1997x.h to bindings patch
 - fix typos
 - fix default quant range for VGA
 - fix quant range handling and conv matrix
 - add additional standards and capabilities to timings_cap

v3:
 - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros
 - fixed missing break
 - use only hdmi_infoframe_log for infoframe logging
 - simplify tda1997x_s_stream error handling
 - add delayed work proc to handle hotplug enable/disable
 - fix set_edid (disable HPD before writing, enable after)
 - remove enabling edid by default
 - initialize timings
 - take quant range into account in colorspace conversion
 - remove vendor/product tracking (we provide this in log_status via infoframes)
 - add v4l_controls
 - add more detail to log_status
 - calculate vhref generator timings
 - timing detection fixes (rounding errors, hswidth errors)
 - rename configure_input/configure_conv functions

v2:
 - implement dv timings enum/cap
 - remove deprecated g_mbus_config op
 - fix dv_query_timings
 - add EDID get/set handling
 - remove max-pixel-rate support
 - add audio codec DAI support
 - change audio bindings

 drivers/media/i2c/Kconfig |9 +
 drivers/media/i2c/Makefile|1 +
 drivers/media/i2c/tda1997x.c  | 2820 +
 drivers/media/i2c/tda1997x_regs.h |  641 +
 include/media/i2c/tda1997x.h  |   42 +
 5 files changed, 3513 insertions(+)
 create mode 100644 drivers/media/i2c/tda1997x.c
 create mode 100644 drivers/media/i2c/tda1997x_regs.h
 create mode 100644 include/media/i2c/tda1997x.h

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cb5d7ff..3522641 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -56,6 +56,15 @@ config VIDEO_TDA9840
  To compile this driver as a module, choose M here: the
  module will be called tda9840.
 
+config VIDEO_TDA1997X
+   tristate "NXP TDA1997x HDMI receiver"
+   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+   ---help---
+ V4L2 subdevice driver for the NXP TDA1997x HDMI receivers.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tda1997x.
+
 config VIDEO_TEA6415C
tristate "Philips TEA6415C audio processor"
depends on I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9ef..adfcae9 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o
 obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o
 obj-$(CONFIG_VIDEO_SAA6588) += saa6588.o
 obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o
+obj-$(CONFIG_VIDEO_TDA1997X) += tda1997x.o
 obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o
 obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o
 obj-$(CONFIG_VIDEO_SAA7110) += saa7110.o
diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c
new file mode 100644
index 000..b25c50a
--- /dev/null
+++ b/drivers/media/i2c/tda1997x.c
@@ -0,0 +1,2820 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Gateworks Corporation
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 

[PATCH v13 7/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx

[Tim Harvey]

The GW54xx has a front-panel microHDMI connector routed to a TDA19971
which is connected the the IPU CSI when using IMX6Q.

Signed-off-by: Tim Harvey 
---
v5:
 - remove leading 0 from unit address
 - add newline between property list and child node

v4: no changes
v3: no changes

v2:
 - add HDMI audio input support

 arch/arm/boot/dts/imx6q-gw54xx.dts| 105 ++
 arch/arm/boot/dts/imx6qdl-gw54xx.dtsi |  29 +-
 2 files changed, 131 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-gw54xx.dts 
b/arch/arm/boot/dts/imx6q-gw54xx.dts
index 56e5b50..0477120 100644
--- a/arch/arm/boot/dts/imx6q-gw54xx.dts
+++ b/arch/arm/boot/dts/imx6q-gw54xx.dts
@@ -12,10 +12,30 @@
 /dts-v1/;
 #include "imx6q.dtsi"
 #include "imx6qdl-gw54xx.dtsi"
+#include 
 
 / {
model = "Gateworks Ventana i.MX6 Dual/Quad GW54XX";
compatible = "gw,imx6q-gw54xx", "gw,ventana", "fsl,imx6q";
+
+   sound-digital {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "tda1997x-audio";
+
+   simple-audio-card,dai-link@0 {
+   format = "i2s";
+
+   cpu {
+   sound-dai = <>;
+   };
+
+   codec {
+   bitclock-master;
+   frame-master;
+   sound-dai = <>;
+   };
+   };
+   };
 };
 
  {
@@ -35,6 +55,61 @@
};
};
};
+
+   tda1997x: codec@48 {
+   compatible = "nxp,tda19971";
+   pinctrl-names = "default";
+   pinctrl-0 = <_tda1997x>;
+   reg = <0x48>;
+   interrupt-parent = <>;
+   interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+   DOVDD-supply = <_3p3v>;
+   AVDD-supply = <_reg>;
+   DVDD-supply = <_reg>;
+   #sound-dai-cells = <0>;
+   nxp,audout-format = "i2s";
+   nxp,audout-layout = <0>;
+   nxp,audout-width = <16>;
+   nxp,audout-mclk-fs = <128>;
+   /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+   nxp,vidout-portcfg =
+   /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+   < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+   /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+   < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+   /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+   < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+   /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+   < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+   port {
+   tda1997x_to_ipu1_csi0_mux: endpoint {
+   remote-endpoint = 
<_csi0_mux_from_parallel_sensor>;
+   bus-width = <16>;
+   hsync-active = <1>;
+   vsync-active = <1>;
+   data-active = <1>;
+   };
+   };
+   };
+};
+
+_csi0_from_ipu1_csi0_mux {
+   bus-width = <16>;
+};
+
+_csi0_mux_from_parallel_sensor {
+   remote-endpoint = <_to_ipu1_csi0_mux>;
+   bus-width = <16>;
+};
+
+_csi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ipu1_csi0>;
 };
 
 _csi1_from_ipu2_csi1_mux {
@@ -63,6 +138,30 @@
>;
};
 
+   pinctrl_ipu1_csi0: ipu1_csi0grp {
+   fsl,pins = <
+   MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x1b0b0
+   

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

[Matwey V. Kornilov]

Hi all,

Almost two years ago I faced an issue related to PWC-driven V4L2
webcam attached to BeagleBone Black SBC. [1][2] The issue still
persists in 4.16-rc1. However, some research has been carried out
since then. I would like to summarize my findings below. I also would
like to receive feedback since the issue appears not to have one
single source and probably may affect setups other than mine.

Initial issue signs were the following. When Philips SPC 900 webcam
(handled by pwc kernel module) is attached to BeagleBone Black SBC
(equipped with TI AM335x Cortex-A8 CPU and Inventra MUSB Dual-Role USB
controller), no frames can be received from the camera. In other
words, the major functional purpose of the camera was broken. From
user-space point of view,

ioctl(fd, VIDIOC_DQBUF, )

indefinitely waits for a frame, yet all other functionalities (i.e.
setting formats) works as usual. This happens always when "ondemand"
cpufreq policy is set and from time to time when "performance" is
used. This also happens disregarding whether DMA USB is used.

Other instances of the camera (same model) have been tested and found
to have same behavior. Then, I've found that the reason for such
behavior is that pwc module never feeds V4L2 subsystem with frames
from the module side, because frame completion criteria never
satisfied in pwc_isoc_handler(). PWC considers the "shorter" or empty
incoming USB ISO packet as end-of-frame sign. Usually, every URB has
10 packets and every packet consists of 956 payload data bytes in case
of PWC. Also, when end-of-frame is received the accumulated amount of
bytes must be equal to expected (known from frame format, i.e width *
height * pixel-depth). It appeared that it was never the case, empty
USB packet was always received in advance to expected frame end and
then every frame was discarded.

I've also bisected the following. The USB ISO transfer works well since commit

2035772010db ("usb: musb: musb_host: Enable HCD_BH flag to handle
urb return in bottom half")

and stops working after commit

f551e1352983 ("Revert "usb: musb: musb_host: Enable HCD_BH flag to
handle urb return in bottom half"")

To reliably connect these two facts, I had to assembly OpenVizsla
hardware USB monitor (sniffer). [3] Using this tool the following MUSB
Host + PWC webcam behavior patterns were found [4]:

[]   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.

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.

Both functions are triggered by musb_host_rx() interrupt handler. And
there are a lot of other important things between interrupt triggering
and next IN requesting. It appears that sometimes it takes 0.4-0.5 ms
between the interrupt and MUSB_RXCSR_H_REQPKT writing. This delays
also lead to missed IN (It is actually sent, but at (last)+2ms time
instead of (last)+1ms) and confusing the peripheral as shown above.
This is a case of URB-completion branch.

The most time-consuming part is urb->giveback() calling.
Unfortunately, it is performed synchronously before requesting IN.
This explains why commit

2035772010db ("usb: musb: musb_host: Enable HCD_BH flag to handle
urb return in bottom half")

masks the issue. Moving (postponing) urb->giveback() call out of
interrupt context eliminated extra delays between IN requesting.
(Un)fortunately, this commit was reverted and the issue returned back.
I proposed a patch to swap time-consuming urb->giveback() and
MUSB_RXCSR_H_REQPKT writing but the 

Re: [PATCH v12 6/8] media: i2c: Add TDA1997x HDMI receiver driver

[Tim Harvey]

On Thu, Feb 15, 2018 at 9:16 AM, Hans Verkuil  wrote:
> On 15/02/18 17:39, Tim Harvey wrote:
>> Add support for the TDA1997x HDMI receivers.
>>
>> Cc: Hans Verkuil 
>> Signed-off-by: Tim Harvey 
>> ---
>> v12:
>>  - fix coccinelle warnings
>
> Did you post the right version? I still see the owner being set and the
> other kbuild warning ('note: in expansion of macro 'v4l_dbg'') is also
> still there.
>
> Note that the last one also shows these errors:
>
> drivers/media/i2c/tda1997x.c:387:5-8: WARNING: Unsigned expression compared 
> with zero: val < 0
> drivers/media/i2c/tda1997x.c:391:5-8: WARNING: Unsigned expression compared 
> with zero: val < 0
> drivers/media/i2c/tda1997x.c:404:5-8: WARNING: Unsigned expression compared 
> with zero: val < 0
> drivers/media/i2c/tda1997x.c:408:5-8: WARNING: Unsigned expression compared 
> with zero: val < 0
> drivers/media/i2c/tda1997x.c:412:5-8: WARNING: Unsigned expression compared 
> with zero: val < 0
> drivers/media/i2c/tda1997x.c:427:6-9: WARNING: Unsigned expression compared 
> with zero: val < 0
>
> This is indeed wrong.
>
> Regards,
>
> Hans

oh geez... no I goofed that up. I'll send a v13 now.

Tim

Re: [PATCH v2] media: imx: capture: reformat line to 80 chars or less

[Steve Longerbeam]

Acked-by: Steve Longerbeam 


On 02/15/2018 01:25 AM, Parthiban Nallathambi wrote:

This is a cleanup patch to fix line length issue found
by checkpatch.pl script.

In this patch, line 144 have been wrapped.

Signed-off-by: Parthiban Nallathambi 
---
Changes in v2:
- Changed commit message

  drivers/staging/media/imx/imx-media-capture.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/imx/imx-media-capture.c 
b/drivers/staging/media/imx/imx-media-capture.c
index 576bdc7e9c42..0ccabe04b0e1 100644
--- a/drivers/staging/media/imx/imx-media-capture.c
+++ b/drivers/staging/media/imx/imx-media-capture.c
@@ -141,7 +141,8 @@ static int capture_enum_frameintervals(struct file *file, 
void *fh,
  
  	fie.code = cc->codes[0];
  
-	ret = v4l2_subdev_call(priv->src_sd, pad, enum_frame_interval, NULL, );

+   ret = v4l2_subdev_call(priv->src_sd, pad, enum_frame_interval,
+  NULL, );
if (ret)
return ret;
  

Re: [PATCH] imx/Kconfig: add depends on HAS_DMA

[Steve Longerbeam]

Acked-by: Steve Longerbeam 


On 02/15/2018 07:54 AM, Hans Verkuil wrote:

Add missing dependency.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/staging/media/imx/Kconfig 
b/drivers/staging/media/imx/Kconfig
index 59b380cc6d22..bfc17de56b17 100644
--- a/drivers/staging/media/imx/Kconfig
+++ b/drivers/staging/media/imx/Kconfig
@@ -3,6 +3,7 @@ config VIDEO_IMX_MEDIA
depends on ARCH_MXC || COMPILE_TEST
depends on MEDIA_CONTROLLER && VIDEO_V4L2 && IMX_IPUV3_CORE
depends on VIDEO_V4L2_SUBDEV_API
+   depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
---help---

Re: [PATCH v12 6/8] media: i2c: Add TDA1997x HDMI receiver driver

[Hans Verkuil]

On 15/02/18 17:39, Tim Harvey wrote:
> Add support for the TDA1997x HDMI receivers.
> 
> Cc: Hans Verkuil 
> Signed-off-by: Tim Harvey 
> ---
> v12:
>  - fix coccinelle warnings

Did you post the right version? I still see the owner being set and the
other kbuild warning ('note: in expansion of macro 'v4l_dbg'') is also
still there.

Note that the last one also shows these errors:

drivers/media/i2c/tda1997x.c:387:5-8: WARNING: Unsigned expression compared 
with zero: val < 0
drivers/media/i2c/tda1997x.c:391:5-8: WARNING: Unsigned expression compared 
with zero: val < 0
drivers/media/i2c/tda1997x.c:404:5-8: WARNING: Unsigned expression compared 
with zero: val < 0
drivers/media/i2c/tda1997x.c:408:5-8: WARNING: Unsigned expression compared 
with zero: val < 0
drivers/media/i2c/tda1997x.c:412:5-8: WARNING: Unsigned expression compared 
with zero: val < 0
drivers/media/i2c/tda1997x.c:427:6-9: WARNING: Unsigned expression compared 
with zero: val < 0

This is indeed wrong.

Regards,

Hans

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

[Zhi, Yong]

Hi, Sakari,

Sorry for the late response, somehow, I missed this email in my Inbox.

> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Sakari Ailus
> Sent: Wednesday, February 7, 2018 2:36 PM
> To: Zhi, Yong 
> Cc: linux-media@vger.kernel.org; Zheng, Jian Xu ;
> Mani, Rajmohan 
> Subject: Re: [PATCH] media: intel-ipu3: cio2: Use SPDX license headers
> 
> Hi Yong,
> 
> Thanks for the patch.
> 
> On Mon, Feb 05, 2018 at 08:19:53PM -0800, Yong Zhi wrote:
> > Adopt SPDX license headers and update year to 2018.
> >
> > 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 6cb..725973f 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) 2018 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 78a5799..6a11051 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) 2018 Intel Corporation */
> 
> Should this be:
> 
> /* Copyright (C) 2017 -- 2018 Intel Corporation */
> 
> ?
> 
> Same for the one above.
> 

Sure, will send an update. Thanks!!

> >
> >  #ifndef __IPU3_CIO2_H
> >  #define __IPU3_CIO2_H
> > --
> > 1.9.1
> >
> 
> --
> Sakari Ailus
> sakari.ai...@linux.intel.com

[PATCH v12 1/8] v4l2-dv-timings: add v4l2_hdmi_colorimetry()

[Tim Harvey]

From: Hans Verkuil 

Add the v4l2_hdmi_colorimetry() function so we have a single function
that determines the colorspace, YCbCr encoding, quantization range and
transfer function from the InfoFrame data.

Cc: Randy Dunlap 
Signed-off-by: Hans Verkuil 
---
v9:
 - fix kernel-doc format (Randy)

 drivers/media/v4l2-core/v4l2-dv-timings.c | 141 ++
 include/media/v4l2-dv-timings.h   |  21 +
 2 files changed, 162 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c 
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index 930f9c5..5663d86 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 MODULE_AUTHOR("Hans Verkuil");
 MODULE_DESCRIPTION("V4L2 DV Timings Helper Functions");
@@ -814,3 +815,143 @@ struct v4l2_fract v4l2_calc_aspect_ratio(u8 
hor_landscape, u8 vert_portrait)
return aspect;
 }
 EXPORT_SYMBOL_GPL(v4l2_calc_aspect_ratio);
+
+/** v4l2_hdmi_rx_colorimetry - determine HDMI colorimetry information
+ * based on various InfoFrames.
+ * @avi: the AVI InfoFrame
+ * @hdmi: the HDMI Vendor InfoFrame, may be NULL
+ * @height: the frame height
+ *
+ * Determines the HDMI colorimetry information, i.e. how the HDMI
+ * pixel color data should be interpreted.
+ *
+ * Note that some of the newer features (DCI-P3, HDR) are not yet
+ * implemented: the hdmi.h header needs to be updated to the HDMI 2.0
+ * and CTA-861-G standards.
+ */
+struct v4l2_hdmi_colorimetry
+v4l2_hdmi_rx_colorimetry(const struct hdmi_avi_infoframe *avi,
+const struct hdmi_vendor_infoframe *hdmi,
+unsigned int height)
+{
+   struct v4l2_hdmi_colorimetry c = {
+   V4L2_COLORSPACE_SRGB,
+   V4L2_YCBCR_ENC_DEFAULT,
+   V4L2_QUANTIZATION_FULL_RANGE,
+   V4L2_XFER_FUNC_SRGB
+   };
+   bool is_ce = avi->video_code || (hdmi && hdmi->vic);
+   bool is_sdtv = height <= 576;
+   bool default_is_lim_range_rgb = avi->video_code > 1;
+
+   switch (avi->colorspace) {
+   case HDMI_COLORSPACE_RGB:
+   /* RGB pixel encoding */
+   switch (avi->colorimetry) {
+   case HDMI_COLORIMETRY_EXTENDED:
+   switch (avi->extended_colorimetry) {
+   case HDMI_EXTENDED_COLORIMETRY_ADOBE_RGB:
+   c.colorspace = V4L2_COLORSPACE_ADOBERGB;
+   c.xfer_func = V4L2_XFER_FUNC_ADOBERGB;
+   break;
+   case HDMI_EXTENDED_COLORIMETRY_BT2020:
+   c.colorspace = V4L2_COLORSPACE_BT2020;
+   c.xfer_func = V4L2_XFER_FUNC_709;
+   break;
+   default:
+   break;
+   }
+   break;
+   default:
+   break;
+   }
+   switch (avi->quantization_range) {
+   case HDMI_QUANTIZATION_RANGE_LIMITED:
+   c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+   break;
+   case HDMI_QUANTIZATION_RANGE_FULL:
+   break;
+   default:
+   if (default_is_lim_range_rgb)
+   c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+   break;
+   }
+   break;
+
+   default:
+   /* YCbCr pixel encoding */
+   c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+   switch (avi->colorimetry) {
+   case HDMI_COLORIMETRY_NONE:
+   if (!is_ce)
+   break;
+   if (is_sdtv) {
+   c.colorspace = V4L2_COLORSPACE_SMPTE170M;
+   c.ycbcr_enc = V4L2_YCBCR_ENC_601;
+   } else {
+   c.colorspace = V4L2_COLORSPACE_REC709;
+   c.ycbcr_enc = V4L2_YCBCR_ENC_709;
+   }
+   c.xfer_func = V4L2_XFER_FUNC_709;
+   break;
+   case HDMI_COLORIMETRY_ITU_601:
+   c.colorspace = V4L2_COLORSPACE_SMPTE170M;
+   c.ycbcr_enc = V4L2_YCBCR_ENC_601;
+   c.xfer_func = V4L2_XFER_FUNC_709;
+   break;
+   case HDMI_COLORIMETRY_ITU_709:
+   c.colorspace = V4L2_COLORSPACE_REC709;
+   c.ycbcr_enc = V4L2_YCBCR_ENC_709;
+   c.xfer_func = V4L2_XFER_FUNC_709;
+   break;
+   case HDMI_COLORIMETRY_EXTENDED:
+   switch 

[PATCH v12 2/8] media: v4l-ioctl: fix clearing pad for VIDIOC_DV_TIMIGNS_CAP

[Tim Harvey]

Signed-off-by: Tim Harvey 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 7961499..5f3670d 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2638,7 +2638,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO_FNC(VIDIOC_PREPARE_BUF, v4l_prepare_buf, v4l_print_buffer, 
INFO_FL_QUEUE),
IOCTL_INFO_STD(VIDIOC_ENUM_DV_TIMINGS, vidioc_enum_dv_timings, 
v4l_print_enum_dv_timings, INFO_FL_CLEAR(v4l2_enum_dv_timings, pad)),
IOCTL_INFO_STD(VIDIOC_QUERY_DV_TIMINGS, vidioc_query_dv_timings, 
v4l_print_dv_timings, INFO_FL_ALWAYS_COPY),
-   IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap, 
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, type)),
+   IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap, 
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, pad)),
IOCTL_INFO_FNC(VIDIOC_ENUM_FREQ_BANDS, v4l_enum_freq_bands, 
v4l_print_freq_band, 0),
IOCTL_INFO_FNC(VIDIOC_DBG_G_CHIP_INFO, v4l_dbg_g_chip_info, 
v4l_print_dbg_chip_info, INFO_FL_CLEAR(v4l2_dbg_chip_info, match)),
IOCTL_INFO_FNC(VIDIOC_QUERY_EXT_CTRL, v4l_query_ext_ctrl, 
v4l_print_query_ext_ctrl, INFO_FL_CTRL | INFO_FL_CLEAR(v4l2_query_ext_ctrl, 
id)),
-- 
2.7.4

[PATCH v12 8/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x

[Tim Harvey]

Signed-off-by: Tim Harvey 
---
v5:
 - add missing audmux config

 arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 138 ++
 1 file changed, 138 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
index 30d4662..749548a 100644
--- a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
@@ -46,6 +46,8 @@
  */
 
 #include 
+#include 
+#include 
 
 / {
/* these are used by bootloader for disabling nodes */
@@ -98,6 +100,50 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
};
+
+   sound-digital {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "tda1997x-audio";
+
+   simple-audio-card,dai-link@0 {
+   format = "i2s";
+
+   cpu {
+   sound-dai = <>;
+   };
+
+   codec {
+   bitclock-master;
+   frame-master;
+   sound-dai = <>;
+   };
+   };
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_audmux>; /* AUD5<->tda1997x */
+   status = "okay";
+
+   ssi1 {
+   fsl,audmux-port = <0>;
+   fsl,port-config = <
+   (IMX_AUDMUX_V2_PTCR_TFSDIR |
+   IMX_AUDMUX_V2_PTCR_TFSEL(4+8) | /* RXFS */
+   IMX_AUDMUX_V2_PTCR_TCLKDIR |
+   IMX_AUDMUX_V2_PTCR_TCSEL(4+8) | /* RXC */
+   IMX_AUDMUX_V2_PTCR_SYN)
+   IMX_AUDMUX_V2_PDCR_RXDSEL(4)
+   >;
+   };
+
+   aud5 {
+   fsl,audmux-port = <4>;
+   fsl,port-config = <
+   IMX_AUDMUX_V2_PTCR_SYN
+   IMX_AUDMUX_V2_PDCR_RXDSEL(0)>;
+   };
 };
 
  {
@@ -263,6 +309,60 @@
#gpio-cells = <2>;
};
 
+   tda1997x: tda1997x@48 {
+   compatible = "nxp,tda19971";
+   pinctrl-names = "default";
+   pinctrl-0 = <_tda1997x>;
+   reg = <0x48>;
+   interrupt-parent = <>;
+   interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+   DOVDD-supply = <_3p3>;
+   AVDD-supply = <_1p8b>;
+   DVDD-supply = <_1p8a>;
+   #sound-dai-cells = <0>;
+   nxp,audout-format = "i2s";
+   nxp,audout-layout = <0>;
+   nxp,audout-width = <16>;
+   nxp,audout-mclk-fs = <128>;
+   /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+   nxp,vidout-portcfg =
+   /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+   < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+   /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+   < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+   /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+   < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+   /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+   < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+   port {
+   tda1997x_to_ipu1_csi0_mux: endpoint {
+   remote-endpoint = 
<_csi0_mux_from_parallel_sensor>;
+   bus-width = <16>;
+   hsync-active = <1>;
+   vsync-active = <1>;
+   data-active = <1>;
+   };
+   };
+   };
+};
+
+_csi0_from_ipu1_csi0_mux {
+   bus-width = <16>;
+};
+
+_csi0_mux_from_parallel_sensor {
+   remote-endpoint = <_to_ipu1_csi0_mux>;
+   bus-width = <16>;
+};
+
+_csi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ipu1_csi0>;
 };
 
  {
@@ -320,6 +420,14 @@
 };
 
  {
+   pinctrl_audmux: audmuxgrp {
+   fsl,pins = <
+   MX6QDL_PAD_DISP0_DAT19__AUD5_RXD0x130b0
+   MX6QDL_PAD_DISP0_DAT14__AUD5_RXC0x130b0
+   MX6QDL_PAD_DISP0_DAT13__AUD5_RXFS   0x130b0
+   >;
+   };
+
pinctrl_flexcan1: flexcan1grp {
fsl,pins = <
MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX0x1b0b1
@@ -375,6 +483,30 @@
>;
};
 
+   pinctrl_ipu1_csi0: ipu1_csi0grp {
+   fsl,pins = <
+   MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04  0x1b0b0
+   

[PATCH v12 7/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx

[Tim Harvey]

The GW54xx has a front-panel microHDMI connector routed to a TDA19971
which is connected the the IPU CSI when using IMX6Q.

Signed-off-by: Tim Harvey 
---
v5:
 - remove leading 0 from unit address
 - add newline between property list and child node

v4: no changes
v3: no changes

v2:
 - add HDMI audio input support

 arch/arm/boot/dts/imx6q-gw54xx.dts| 105 ++
 arch/arm/boot/dts/imx6qdl-gw54xx.dtsi |  29 +-
 2 files changed, 131 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-gw54xx.dts 
b/arch/arm/boot/dts/imx6q-gw54xx.dts
index 56e5b50..0477120 100644
--- a/arch/arm/boot/dts/imx6q-gw54xx.dts
+++ b/arch/arm/boot/dts/imx6q-gw54xx.dts
@@ -12,10 +12,30 @@
 /dts-v1/;
 #include "imx6q.dtsi"
 #include "imx6qdl-gw54xx.dtsi"
+#include 
 
 / {
model = "Gateworks Ventana i.MX6 Dual/Quad GW54XX";
compatible = "gw,imx6q-gw54xx", "gw,ventana", "fsl,imx6q";
+
+   sound-digital {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "tda1997x-audio";
+
+   simple-audio-card,dai-link@0 {
+   format = "i2s";
+
+   cpu {
+   sound-dai = <>;
+   };
+
+   codec {
+   bitclock-master;
+   frame-master;
+   sound-dai = <>;
+   };
+   };
+   };
 };
 
  {
@@ -35,6 +55,61 @@
};
};
};
+
+   tda1997x: codec@48 {
+   compatible = "nxp,tda19971";
+   pinctrl-names = "default";
+   pinctrl-0 = <_tda1997x>;
+   reg = <0x48>;
+   interrupt-parent = <>;
+   interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+   DOVDD-supply = <_3p3v>;
+   AVDD-supply = <_reg>;
+   DVDD-supply = <_reg>;
+   #sound-dai-cells = <0>;
+   nxp,audout-format = "i2s";
+   nxp,audout-layout = <0>;
+   nxp,audout-width = <16>;
+   nxp,audout-mclk-fs = <128>;
+   /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+   nxp,vidout-portcfg =
+   /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+   < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+   /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+   < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+   /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+   < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+   /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+   < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+   port {
+   tda1997x_to_ipu1_csi0_mux: endpoint {
+   remote-endpoint = 
<_csi0_mux_from_parallel_sensor>;
+   bus-width = <16>;
+   hsync-active = <1>;
+   vsync-active = <1>;
+   data-active = <1>;
+   };
+   };
+   };
+};
+
+_csi0_from_ipu1_csi0_mux {
+   bus-width = <16>;
+};
+
+_csi0_mux_from_parallel_sensor {
+   remote-endpoint = <_to_ipu1_csi0_mux>;
+   bus-width = <16>;
+};
+
+_csi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ipu1_csi0>;
 };
 
 _csi1_from_ipu2_csi1_mux {
@@ -63,6 +138,30 @@
>;
};
 
+   pinctrl_ipu1_csi0: ipu1_csi0grp {
+   fsl,pins = <
+   MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x1b0b0
+   MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x1b0b0
+   

[PATCH v12 6/8] media: i2c: Add TDA1997x HDMI receiver driver

[Tim Harvey]

Add support for the TDA1997x HDMI receivers.

Cc: Hans Verkuil 
Signed-off-by: Tim Harvey 
---
v12:
 - fix coccinelle warnings

v11:
 - return -ERANGE from tda1997x_detect_std (Hans)
 - clean up tda1997x_g_input_status (Hans)
 - show detected timings on resolution change if debug enabled
 - fix unitialized ret var in tda1997x_query_dv_timings
 - update log status to show detected timings

v10:
 - removed unnecessary check for !timings in get/set/query dv timings (Hans)
 - dropped pointless s_stream handler (Hans)
 - remove need for detected_timings and always use set timings (Hans)

v9:
 - remove redundant pad bounds check already in v4l2-subdev.c
 - assign entity function (Hans)
 - properly assign/check/free ctrl_handler (Hans)
 - fixed typo 'Rull Range' -> 'Full Range'
 - update csc after quant range change

v8:
 - fix available formats for tda19971 bt656 bus width >12
 - support full range of input modes based on timings_cap
 - fix set_format (compliance)
 - fixed get/set edid (compliance)
 - add init_cfg to setup default pad config (compliance)
 - added missing pad checks to get_dv_timings_cap/enum_dv_timings (compliance)
 - fix alignment of if statement and whitespace in comment (Hans)
 - move regs to tda1997x_regs.h to clean up (Hans)
 - add define and sanity check for num of mbus_codes (Hans)

v7:
 - fix interlaced mode
 - support no AVI infoframe (ie DVI) (Hans)
 - add support for multiple output formats (Hans)

v6:
 - fix return on regulator enablei in tda1997x_set_power()
 - replace copyright with SPDX tag
 - fix colorspace handling

v5:
 - uppercase string constants
 - use v4l2_hdmi_rx_coloriemtry to fill format
 - fix V4L2_CID_DV_RX_RGB_RANGE
 - fix interlaced mode format

v4:
 - move include/dt-bindings/media/tda1997x.h to bindings patch
 - fix typos
 - fix default quant range for VGA
 - fix quant range handling and conv matrix
 - add additional standards and capabilities to timings_cap

v3:
 - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros
 - fixed missing break
 - use only hdmi_infoframe_log for infoframe logging
 - simplify tda1997x_s_stream error handling
 - add delayed work proc to handle hotplug enable/disable
 - fix set_edid (disable HPD before writing, enable after)
 - remove enabling edid by default
 - initialize timings
 - take quant range into account in colorspace conversion
 - remove vendor/product tracking (we provide this in log_status via infoframes)
 - add v4l_controls
 - add more detail to log_status
 - calculate vhref generator timings
 - timing detection fixes (rounding errors, hswidth errors)
 - rename configure_input/configure_conv functions

v2:
 - implement dv timings enum/cap
 - remove deprecated g_mbus_config op
 - fix dv_query_timings
 - add EDID get/set handling
 - remove max-pixel-rate support
 - add audio codec DAI support
 - change audio bindings

 drivers/media/i2c/Kconfig |9 +
 drivers/media/i2c/Makefile|1 +
 drivers/media/i2c/tda1997x.c  | 2822 +
 drivers/media/i2c/tda1997x_regs.h |  641 +
 include/media/i2c/tda1997x.h  |   42 +
 5 files changed, 3515 insertions(+)
 create mode 100644 drivers/media/i2c/tda1997x.c
 create mode 100644 drivers/media/i2c/tda1997x_regs.h
 create mode 100644 include/media/i2c/tda1997x.h

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cb5d7ff..3522641 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -56,6 +56,15 @@ config VIDEO_TDA9840
  To compile this driver as a module, choose M here: the
  module will be called tda9840.
 
+config VIDEO_TDA1997X
+   tristate "NXP TDA1997x HDMI receiver"
+   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+   ---help---
+ V4L2 subdevice driver for the NXP TDA1997x HDMI receivers.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tda1997x.
+
 config VIDEO_TEA6415C
tristate "Philips TEA6415C audio processor"
depends on I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9ef..adfcae9 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o
 obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o
 obj-$(CONFIG_VIDEO_SAA6588) += saa6588.o
 obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o
+obj-$(CONFIG_VIDEO_TDA1997X) += tda1997x.o
 obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o
 obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o
 obj-$(CONFIG_VIDEO_SAA7110) += saa7110.o
diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c
new file mode 100644
index 000..ce6b694
--- /dev/null
+++ b/drivers/media/i2c/tda1997x.c
@@ -0,0 +1,2822 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Gateworks Corporation
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 

[PATCH v12 4/8] MAINTAINERS: add entry for NXP TDA1997x driver

[Tim Harvey]

Signed-off-by: Tim Harvey 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 845fc25..439b500 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13262,6 +13262,14 @@ T: git git://linuxtv.org/mkrufky/tuners.git
 S: Maintained
 F: drivers/media/tuners/tda18271*
 
+TDA1997x MEDIA DRIVER
+M: Tim Harvey 
+L: linux-media@vger.kernel.org
+W: https://linuxtv.org
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+S: Maintained
+F: drivers/media/i2c/tda1997x.*
+
 TDA827x MEDIA DRIVER
 M: Michael Krufky 
 L: linux-media@vger.kernel.org
-- 
2.7.4

[PATCH v12 5/8] media: dt-bindings: Add bindings for TDA1997X

[Tim Harvey]

Acked-by: Rob Herring 
Acked-by: Sakari Ailus 
Signed-off-by: Tim Harvey 
---
v6:
 - replace copyright with SPDX tag
 - added Rob's ack

v5:
 - added Sakari's ack

v4:
 - move include/dt-bindings/media/tda1997x.h to bindings patch
 - clarify port node details

v3:
 - fix typo

v2:
 - add vendor prefix and remove _ from vidout-portcfg
 - remove _ from labels
 - remove max-pixel-rate property
 - describe and provide example for single output port
 - update to new audio port bindings

 .../devicetree/bindings/media/i2c/tda1997x.txt | 179 +
 include/dt-bindings/media/tda1997x.h   |  74 +
 2 files changed, 253 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
 create mode 100644 include/dt-bindings/media/tda1997x.h

diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt 
b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
new file mode 100644
index 000..9ab53c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
@@ -0,0 +1,179 @@
+Device-Tree bindings for the NXP TDA1997x HDMI receiver
+
+The TDA19971/73 are HDMI video receivers.
+
+The TDA19971 Video port output pins can be used as follows:
+ - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
+ - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
+ - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
+ - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
+ - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0]
+ - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
+ - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The TDA19973 Video port output pins can be used as follows:
+ - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
+ - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
+ - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The Video port output pins are mapped via 4-bit 'pin groups' allowing
+for a variety of connection possibilities including swapping pin order within
+pin groups. The video_portcfg device-tree property consists of register mapping
+pairs which map a chip-specific VP output register to a 4-bit pin group. If
+the pin group needs to be bit-swapped you can use the *_S pin-group defines.
+
+Required Properties:
+ - compatible  :
+  - "nxp,tda19971" for the TDA19971
+  - "nxp,tda19973" for the TDA19973
+ - reg : I2C slave address
+ - interrupts  : The interrupt number
+ - DOVDD-supply: Digital I/O supply
+ - DVDD-supply : Digital Core supply
+ - AVDD-supply : Analog supply
+ - nxp,vidout-portcfg  : array of pairs mapping VP output pins to pin groups.
+
+Optional Properties:
+ - nxp,audout-format   : DAI bus format: "i2s" or "spdif".
+ - nxp,audout-width: width of audio output data bus (1-4).
+ - nxp,audout-layout   : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used).
+ - nxp,audout-mclk-fs  : Multiplication factor between stream rate and codec
+ mclk.
+
+The port node shall contain one endpoint child node for its digital
+output video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Optional Endpoint Properties:
+  The following three properties are defined in video-interfaces.txt and
+  are valid for the output parallel bus endpoint:
+  - hsync-active: Horizontal synchronization polarity. Defaults to active high.
+  - vsync-active: Vertical synchronization polarity. Defaults to active high.
+  - data-active: Data polarity. Defaults to active high.
+
+Examples:
+ - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422
+   16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
+   hdmi-receiver@48 {
+   compatible = "nxp,tda19971";
+   pinctrl-names = "default";
+   pinctrl-0 = <_tda1997x>;
+   reg = <0x48>;
+   interrupt-parent = <>;
+   interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+   DOVDD-supply = <_3p3v>;
+   AVDD-supply = <_1p8v>;
+   DVDD-supply = <_1p8v>;
+   /* audio */
+   #sound-dai-cells = <0>;
+   nxp,audout-format = "i2s";
+   nxp,audout-layout = <0>;
+   nxp,audout-width = <16>;
+   nxp,audout-mclk-fs = <128>;
+   /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same pixclk cycle.
+*/
+   nxp,vidout-portcfg =
+  

[PATCH v12 3/8] media: add digital video decoder entity functions

[Tim Harvey]

Add a new media entity function definition for digital TV decoders:
MEDIA_ENT_F_DTV_DECODER

Signed-off-by: Tim Harvey 
---
 Documentation/media/uapi/mediactl/media-types.rst | 11 +++
 include/uapi/linux/media.h|  5 +
 2 files changed, 16 insertions(+)

diff --git a/Documentation/media/uapi/mediactl/media-types.rst 
b/Documentation/media/uapi/mediactl/media-types.rst
index 8d64b0c..195400e 100644
--- a/Documentation/media/uapi/mediactl/media-types.rst
+++ b/Documentation/media/uapi/mediactl/media-types.rst
@@ -321,6 +321,17 @@ Types and flags used to represent the media graph elements
  MIPI CSI-2, ...), and outputs them on its source pad to an output
  video bus of another type (eDP, MIPI CSI-2, parallel, ...).
 
+-  ..  row 31
+
+   ..  _MEDIA-ENT-F-DTV-DECODER:
+
+   -  ``MEDIA_ENT_F_DTV_DECODER``
+
+   -  Digital video decoder. The basic function of the video decoder is
+ to accept digital video from a wide variety of sources
+ and output it in some digital video standard, with appropriate
+ timing signals.
+
 ..  tabularcolumns:: |p{5.5cm}|p{12.0cm}|
 
 .. _media-entity-flag:
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index b9b9446..2f12328 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -110,6 +110,11 @@ struct media_device_info {
 #define MEDIA_ENT_F_VID_IF_BRIDGE  (MEDIA_ENT_F_BASE + 0x5002)
 
 /*
+ * Digital video decoder entities
+ */
+#define MEDIA_ENT_F_DTV_DECODER(MEDIA_ENT_F_BASE + 
0x6001)
+
+/*
  * Connectors
  */
 /* It is a responsibility of the entity drivers to add connectors and links */
-- 
2.7.4

[PATCH v12 0/8] TDA1997x HDMI video reciver

[Tim Harvey]

This is a v4l2 subdev driver supporting the TDA1997x HDMI video receiver.

I've tested this on a Gateworks GW54xx/GW551x with an IMX6Q/IMX6DL which
uses the TDA19971 with 16bits connected to the IMX6 CSI and single-lane
I2S audio providing 2-channel audio.

For this configuration I've tested both 16bit YUV422 and 8bit
BT656 parallel video bus modes.

While the driver should support the TDA1993 I do not have one for testing.

Further potential development efforts include:
 - CEC support
 - HDCP support
 - TDA19972 support (2 inputs)

Media graphs can be found at http://dev.gateworks.com/docs/linux/media

See details below for configuration and compliance tests

History:
v12:
 - fix coccinelle warnings

v11:
 - return -ERANGE from tda1997x_detect_std (Hans)
 - clean up tda1997x_g_input_status (Hans)
 - show detected timings on resolution change if debug enabled
 - fix unitialized ret var in tda1997x_query_dv_timings
 - update log status to show detected timings

v10:
 - removed unnecessary check for !timings in get/set/query dv timings (Hans)
 - dropped pointless s_stream handler (Hans)
 - remove need for detected_timings and always use set timings (Hans)

v9:
 - add digital video decoder video interface entity function

v8:
 - fix clearing pad for VIDIOC_DV_TIMIGNS_CAP
 - support full range of input modes based on timings_cap
 - add patch to fix clearing pad for VIDIOC_DV_TIMIGINGS
 - fix available formats for tda19971 bt656 bus width >12
 - fix set_format (compliance)
 - fixed get/set edid (compliance)
 - add init_cfg to setup default pad config (compliance)
 - added missing pad checks to get_dv_timings_cap/enum_dv_timings (compliance)
 - fix alignment of if statement and whitespace in comment (Hans)
 - move regs to tda1997x_regs.h to clean up (Hans)
 - add define and sanity check for num of mbus_codes (Hans)

v7:
 - fix interlaced mode
 - support no AVI infoframe (ie DVI) (Hans)
 - add support for multiple output formats (Hans)

v6:
 - tda1997x: fix return on regulator enablei in tda1997x_set_power() (Fabio)
 - tda1997x: fix colorspace handling (Hans)
 - bindings: added Robs's ack (Rob)
 - replace copyright with SPDX tag (Philippe)

v5:
 - added v4l2_hdmi_colorimetry() patch from Hans to series
 - bindings: added Sakari's ack
 - tda1997x: uppercase string constants
 - tda1997x: use v4l2_hdmi_rx_coloriemtry to fill format
 - tda1997x: fix V4L2_CID_DV_RX_RGB_RANGE
 - tda1997x: fix interlaced mode format
 - dts: remove leading 0 from unit address
 - dts: add newline between property list and child node
 - dts: added missing audmux in GW551x dts

v4:
 - move include/dt-bindings/media/tda1997x.h to bindings patch
 - clarify port node details in bindings
 - fix typos
 - fix default quant range for VGA
 - fix quant range handling and conv matrix
 - add additional standards and capabilities to timings_cap

v3:
 - fix typo in dt bindings
 - added dt bindings for GW551x
 - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros
 - fixed missing break
 - use only hdmi_infoframe_log for infoframe logging
 - simplify tda1997x_s_stream error handling
 - add delayed work proc to handle hotplug enable/disable
 - fix set_edid (disable HPD before writing, enable after)
 - remove enabling edid by default
 - initialize timings
 - take quant range into account in colorspace conversion
 - remove vendor/product tracking (we provide this in log_status via
   infoframes)
 - add v4l_controls
 - add more detail to log_status
 - calculate vhref generator timings
 - timing detection fixes (rounding errors, hswidth errors)
 - rename configure_input/configure_conv functions

v2:
 - encorporate feedback into dt bindings
 - change audio dt bindings
 - implement dv timings enum/cap
 - remove deprecated g_mbus_config op
 - fix dv_query_timings
 - add EDID get/set handling
 - remove max-pixel-rate support
 - add audio codec DAI support
 - added media-ctl and v4l2-compliance details

v1:
 - initial RFC

Pipeline configuration:
$ media-ctl -e 'tda19971 2-0048'
/dev/v4l-subdev1
$ v4l2-ctl -d /dev/v4l-subdev1 --set-dv-bt-timings=query
BT timings set
$ media-ctl --get-v4l2 '"tda19971 2-0048":0'
[fmt:UYVY8_2X8/1280x720 field:none colorspace:srgb]

$ media-ctl --link "tda19971 2-0048":0 -> "ipu1_csi0_mux":1[1]
$ media-ctl --link "ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]
$ media-ctl --link "ipu1_csi0":2 -> "ipu1_csi0 capture":0[1]
$ media-ctl --set-v4l2 'tda19971 2-0048':0[fmt:UYVY8_2X8/1280x720]
$ media-ctl --set-v4l2 'ipu1_csi0_mux':2[fmt:UYVY8_2X8/1280x720]
$ media-ctl --set-v4l2 'ipu1_csi0':0[fmt:UYVY8_2X8/1280x720]
$ gst-launch-1.0 v4l2src device=/dev/video4 ! 
video/x-raw,width=1280,height=720,format=UYVY ! jpegenc ! rtpjpegpay ! udpsink 
host=172.24.40.6 port=5000

$ media-ctl -d /dev/media0 -p
Media controller API version 4.15.0

Media device information

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

Device topology
- entity 1: adv7180 

Re: [PATCH v3 4/8] i2c: ov9650: use 64-bit arithmetic instead of 32-bit

[Gustavo A. R. Silva]

On 02/15/2018 07:52 AM, Hans Verkuil wrote:

On 08/02/18 17:39, Gustavo A. R. Silva wrote:

Hi Sakari,

On 02/07/2018 03:59 PM, Sakari Ailus wrote:

Hi Gustavo,

On Tue, Feb 06, 2018 at 10:47:50AM -0600, Gustavo A. R. Silva wrote:

Add suffix ULL to constants 1 and 100 in order to give the
compiler complete information about the proper arithmetic to use.
Notice that these constants are used in contexts that expect
expressions of type u64 (64 bits, unsigned).

The following expressions:

(u64)(fi->interval.numerator * 1)
(u64)(iv->interval.numerator * 1)
fiv->interval.numerator * 100 / fiv->interval.denominator

are currently being evaluated using 32-bit arithmetic.

Notice that those casts to u64 for the first two expressions are only
effective after such expressions are evaluated using 32-bit arithmetic,
which leads to potential integer overflows. So based on those casts, it
seems that the original intention of the code is to actually use 64-bit
arithmetic instead of 32-bit.

Also, notice that once the suffix ULL is added to the constants, the
outer casts to u64 are no longer needed.

Addresses-Coverity-ID: 1324146 ("Unintentional integer overflow")
Fixes: 84a15ded76ec ("[media] V4L: Add driver for OV9650/52 image sensors")
Fixes: 79211c8ed19c ("remove abs64()")
Signed-off-by: Gustavo A. R. Silva 
---
Changes in v2:
   - Update subject and changelog to better reflect the proposed code changes.
   - Add suffix ULL to constants instead of casting variables.
   - Remove unnecessary casts to u64 as part of the code change.
   - Extend the same code change to other similar expressions.

Changes in v3:
   - None.

   drivers/media/i2c/ov9650.c | 9 +
   1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index e519f27..e716e98 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -1130,7 +1130,7 @@ static int __ov965x_set_frame_interval(struct ov965x 
*ov965x,
   if (fi->interval.denominator == 0)
   return -EINVAL;
   -    req_int = (u64)(fi->interval.numerator * 1) /
+    req_int = fi->interval.numerator * 1ULL /
   fi->interval.denominator;


This has been addressed by your earlier patch "i2c: ov9650: fix potential 
integer overflow in
__ov965x_set_frame_interval" I tweaked a little. It's not in media tree
master yet.



Yeah. Actually this patch is supposed to be an improved version of the one you 
mention. That is why this is version 3.

Also, I wonder if the same issue you mention below regarding 32-bit ARM applies 
in this case too?


     for (i = 0; i < ARRAY_SIZE(ov965x_intervals); i++) {
@@ -1139,7 +1139,7 @@ static int __ov965x_set_frame_interval(struct ov965x 
*ov965x,
   if (mbus_fmt->width != iv->size.width ||
   mbus_fmt->height != iv->size.height)
   continue;
-    err = abs((u64)(iv->interval.numerator * 1) /
+    err = abs(iv->interval.numerator * 1ULL /


This and the chunk below won't work on e.g. 32-bit ARM. do_div(), please.



Thanks for pointing this out.


   iv->interval.denominator - req_int);
   if (err < min_err) {
   fiv = iv;
@@ -1148,8 +1148,9 @@ static int __ov965x_set_frame_interval(struct ov965x 
*ov965x,
   }
   ov965x->fiv = fiv;
   -    v4l2_dbg(1, debug, >sd, "Changed frame interval to %u us\n",
- fiv->interval.numerator * 100 / fiv->interval.denominator);
+    v4l2_dbg(1, debug, >sd, "Changed frame interval to %llu us\n",
+ fiv->interval.numerator * 100ULL /
+ fiv->interval.denominator);


I wonder if do_div should be used for the code above?


Yes, do_div should be used.



I got it.

Thanks, Hans.
--
Gustavo

[PATCH] imx/Kconfig: add depends on HAS_DMA

[Hans Verkuil]

Add missing dependency.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/staging/media/imx/Kconfig 
b/drivers/staging/media/imx/Kconfig
index 59b380cc6d22..bfc17de56b17 100644
--- a/drivers/staging/media/imx/Kconfig
+++ b/drivers/staging/media/imx/Kconfig
@@ -3,6 +3,7 @@ config VIDEO_IMX_MEDIA
depends on ARCH_MXC || COMPILE_TEST
depends on MEDIA_CONTROLLER && VIDEO_V4L2 && IMX_IPUV3_CORE
depends on VIDEO_V4L2_SUBDEV_API
+   depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
---help---

Re: [PATCH RESEND] media: video-i2c: add video-i2c driver

[Hans Verkuil]

Hi Matt,

Here is a quick review. Apologies for the delay, it has been very busy for
the last few weeks.

On 13/01/18 04:57, Matt Ranostay wrote:
> There are several thermal sensors that only have a low-speed bus
> interface but output valid video data. This patchset enables support
> for the AMG88xx "Grid-Eye" sensor family.
> 
> Cc: Luca Barbato 
> Cc: Laurent Pinchart 
> Signed-off-by: Matt Ranostay 
> ---
>  drivers/media/i2c/Kconfig |   9 +
>  drivers/media/i2c/Makefile|   1 +
>  drivers/media/i2c/video-i2c.c | 556 
> ++
>  3 files changed, 566 insertions(+)
>  create mode 100644 drivers/media/i2c/video-i2c.c
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 9f18cd296841..549f1e9fc01e 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -908,6 +908,15 @@ config VIDEO_M52790
>  
>To compile this driver as a module, choose M here: the
>module will be called m52790.
> +
> +config VIDEO_I2C
> + tristate "I2C transport video support"
> + depends on VIDEO_V4L2 && I2C
> + select VIDEOBUF2_VMALLOC
> + ---help---
> +   Enable the I2C transport video support which supports the
> +   following:
> +* Panasonic AMG88xx Grid-Eye Sensors
>  endmenu
>  
>  menu "Sensors used on soc_camera driver"
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index c0f94cd8d56d..5ca4c98a4bea 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -90,6 +90,7 @@ obj-$(CONFIG_VIDEO_LM3646)  += lm3646.o
>  obj-$(CONFIG_VIDEO_SMIAPP_PLL)   += smiapp-pll.o
>  obj-$(CONFIG_VIDEO_AK881X)   += ak881x.o
>  obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
> +obj-$(CONFIG_VIDEO_I2C)  += video-i2c.o
>  obj-$(CONFIG_VIDEO_ML86V7667)+= ml86v7667.o
>  obj-$(CONFIG_VIDEO_OV2659)   += ov2659.o
>  obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
> diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
> new file mode 100644
> index ..9df9b5ebd156
> --- /dev/null
> +++ b/drivers/media/i2c/video-i2c.c
> @@ -0,0 +1,556 @@
> +/*
> + * video-i2c.c - Support for I2C transport video devices
> + *
> + * Copyright (C) 2018 Matt Ranostay 
> + *
> + * 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.
> + *
> + * 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 the SPDX tags instead of this license text. See
https://git.linuxtv.org/media_tree.git/tree/Documentation/process/license-rules.rst

> + *
> + * Supported:
> + * - Panasonic AMG88xx Grid-Eye Sensors
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define VIDEO_I2C_DRIVER "video-i2c"
> +#define MAX_BUFFER_SIZE  128
> +
> +struct video_i2c_chip;
> +
> +struct video_i2c_buffer {
> + struct vb2_v4l2_buffer vb;
> + struct list_head list;
> +};
> +
> +struct video_i2c_data {
> + struct i2c_client *client;
> + const struct video_i2c_chip *chip;
> + struct mutex lock;
> + spinlock_t slock;
> + struct mutex queue_lock;
> +
> + struct v4l2_device v4l2_dev;
> + struct video_device vdev;
> + struct vb2_queue vb_vidq;
> +
> + struct task_struct *kthread_vid_cap;
> + struct list_head vid_cap_active;
> +};
> +
> +static struct v4l2_fmtdesc amg88xx_format = {
> + .pixelformat = V4L2_PIX_FMT_Y12,
> +};
> +
> +static struct v4l2_frmsize_discrete amg88xx_size = {
> + .width = 8,
> + .height = 8,
> +};
> +
> +struct video_i2c_chip {
> + /* video dimensions */
> + const struct v4l2_fmtdesc *format;
> + const struct v4l2_frmsize_discrete *size;
> +
> + /* max frames per second */
> + unsigned int max_fps;
> +
> + /* pixel buffer size */
> + unsigned int buffer_size;
> +
> + /* pixel size in bits */
> + unsigned int bpp;
> +
> + /* xfer function */
> + int (*xfer)(struct video_i2c_data *data, char *buf);
> +};
> +
> +static int amg88xx_xfer(struct video_i2c_data *data, char *buf)
> +{
> + struct i2c_client *client = data->client;
> + struct i2c_msg msg[2];
> + u8 reg = 0x80;
> + int ret;
> +
> + msg[0].addr = client->addr;
> + msg[0].flags = 0;
> + msg[0].len = 1;
> + msg[0].buf  = (char *) 
> +
> + msg[1].addr = 

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

[Hans Verkuil]

Fixes/improvements all over the place.

Finally had time to clean out most of the random patches in my queue :-)

Regards,

Hans

The following changes since commit 29422737017b866d4a51014cc7522fa3a99e8852:

  media: rc: get start time just before calling driver tx (2018-02-14 14:17:21 
-0500)

are available in the Git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.17a

for you to fetch changes up to 262f1f7863999b92165ab1bb9fe0f148cfc826fb:

  media: i2c: adv748x: fix HDMI field heights (2018-02-15 16:04:12 +0100)


Alexandre Courbot (2):
  v4l: vidioc-prepare-buf.rst: fix link to VIDIOC_QBUF
  media: v4l2_fh.h: add missing kconfig.h include

Antonio Cardace (2):
  em28xx: use %*phC to print small buffers
  gspca: dtcs033: use %*ph to print small buffer

Arnd Bergmann (1):
  media: au0828: fix VIDEO_V4L2 dependency

Benjamin Gaignard (1):
  media: platform: stm32: Adopt SPDX identifier

Christopher Díaz Riveros (1):
  media: s2255drv: Remove unneeded if else blocks

Colin Ian King (1):
  media: cx25821: prevent out-of-bounds read on array card

Corentin Labbe (2):
  media: cx18: remove unused cx18-alsa-mixer
  media: ivtv: remove ivtv-alsa-mixer

Gustavo A. R. Silva (9):
  venus: hfi: use true for boolean values
  staging: imx-media-vdic: fix inconsistent IS_ERR and PTR_ERR
  rtl2832: use 64-bit arithmetic instead of 32-bit in rtl2832_set_frontend
  dvb-frontends: ves1820: use 64-bit arithmetic instead of 32-bit
  i2c: max2175: use 64-bit arithmetic instead of 32-bit
  pci: cx88-input: use 64-bit arithmetic instead of 32-bit
  rockchip/rga: use 64-bit arithmetic instead of 32-bit
  platform: sh_veu: use 64-bit arithmetic instead of 32-bit
  platform: vivid-cec: use 64-bit arithmetic instead of 32-bit

Gustavo Padovan (1):
  buffer.rst: fix link text of VIDIOC_QBUF

Hans Verkuil (4):
  vivid: fix incorrect capabilities for radio
  v4l2-ctrls.h: fix wrong copy-and-paste comment
  cec: improve debugging
  vivid: check if the cec_adapter is valid

Ian Douglas Scott (1):
  media: usbtv: Add USB ID 1f71:3306 to the UTV007 driver

Kieran Bingham (2):
  v4l: doc: Clarify v4l2_mbus_fmt height definition
  media: i2c: adv748x: fix HDMI field heights

Masami Hiramatsu (1):
  media: vb2: Fix videobuf2 to map correct area

Niklas Söderlund (1):
  v4l2-dev.h: fix symbol collision in media_entity_to_video_device()

Oliver Neukum (1):
  media: usbtv: prevent double free in error case

Philipp Zabel (4):
  media: dt-bindings: coda: Add compatible for CodaHx4 on i.MX51
  media: coda: Add i.MX51 (CodaHx4) support
  media: imx: allow to build with COMPILE_TEST
  media: coda: bump maximum number of internal framebuffers to 19

Sakari Ailus (1):
  vb2: core: Finish buffers at the end of the stream

Shuah Khan (1):
  media: v4l2-core: v4l2-mc: Add SPDX license identifier

Tomasz Figa (1):
  media: mtk-vcodec: Always signal source change event on format change

Wei Yongjun (2):
  media: atmel-isc: Make local symbol fmt_configs_list static
  media: rcar_drif: fix error return code in rcar_drif_alloc_dmachannels()

Xiongfeng Wang (1):
  media: media-device: use strlcpy() instead of strncpy()

 Documentation/devicetree/bindings/media/coda.txt|   5 +-
 Documentation/media/uapi/v4l/buffer.rst |   2 +-
 Documentation/media/uapi/v4l/subdev-formats.rst |   8 ++-
 Documentation/media/uapi/v4l/vidioc-prepare-buf.rst |   2 +-
 drivers/media/cec/cec-adap.c|  32 +-
 drivers/media/common/videobuf2/videobuf2-core.c |   9 +++
 drivers/media/common/videobuf2/videobuf2-vmalloc.c  |   2 +-
 drivers/media/dvb-frontends/rtl2832.c   |   4 +-
 drivers/media/dvb-frontends/ves1820.c   |   2 +-
 drivers/media/i2c/adv748x/adv748x-hdmi.c|   3 +
 drivers/media/i2c/max2175.c |   2 +-
 drivers/media/media-device.c|   2 +-
 drivers/media/pci/cx18/cx18-alsa-main.c |   1 -
 drivers/media/pci/cx18/cx18-alsa-mixer.c| 170 
---
 drivers/media/pci/cx18/cx18-alsa-mixer.h|  18 --
 drivers/media/pci/cx25821/cx25821-core.c|   7 ++-
 drivers/media/pci/cx88/cx88-input.c |   4 +-
 drivers/media/pci/ivtv/ivtv-alsa-main.c |  11 +---
 drivers/media/pci/ivtv/ivtv-alsa-mixer.c| 165 
-
 drivers/media/pci/ivtv/ivtv-alsa-mixer.h|  18 --
 drivers/media/platform/atmel/atmel-isc.c|   2 +-
 drivers/media/platform/coda/coda-bit.c  |  46 ++
 drivers/media/platform/coda/coda-common.c   |  44 +++--
 drivers/media/platform/coda/coda.h  |  

Re: [PATCH] media: imx: add 8-bit grayscale support

[Hans Verkuil]

Hi Philipp,

Can you let me know if/when I can merge this? It looks good, so when the other
patch is merged, then this can be merged as well.

Regards,

Hans

On 22/01/18 17:16, Philipp Zabel wrote:
> The IPUv3 code has 8-bit grayscale capture support.
> Enable imx-media to use it.
> 
> Signed-off-by: Philipp Zabel 
> ---
> This patch depends on https://patchwork.kernel.org/patch/10178777/
> to work, otherwise STREAMON will fail with -EINVAL.
> ---
>  drivers/staging/media/imx/imx-media-csi.c   | 1 +
>  drivers/staging/media/imx/imx-media-utils.c | 8 +++-
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/imx/imx-media-csi.c 
> b/drivers/staging/media/imx/imx-media-csi.c
> index eb7be5093a9d5..e280ba31262a8 100644
> --- a/drivers/staging/media/imx/imx-media-csi.c
> +++ b/drivers/staging/media/imx/imx-media-csi.c
> @@ -400,6 +400,7 @@ static int csi_idmac_setup_channel(struct csi_priv *priv)
>   case V4L2_PIX_FMT_SGBRG8:
>   case V4L2_PIX_FMT_SGRBG8:
>   case V4L2_PIX_FMT_SRGGB8:
> + case V4L2_PIX_FMT_GREY:
>   burst_size = 16;
>   passthrough = true;
>   passthrough_bits = 8;
> diff --git a/drivers/staging/media/imx/imx-media-utils.c 
> b/drivers/staging/media/imx/imx-media-utils.c
> index 13dafa77a2eba..5f61eecb81f1e 100644
> --- a/drivers/staging/media/imx/imx-media-utils.c
> +++ b/drivers/staging/media/imx/imx-media-utils.c
> @@ -93,7 +93,7 @@ static const struct imx_media_pixfmt rgb_formats[] = {
>   .bpp= 32,
>   .ipufmt = true,
>   },
> - /*** raw bayer formats start here ***/
> + /*** raw bayer and grayscale formats start here ***/
>   {
>   .fourcc = V4L2_PIX_FMT_SBGGR8,
>   .codes  = {MEDIA_BUS_FMT_SBGGR8_1X8},
> @@ -162,6 +162,12 @@ static const struct imx_media_pixfmt rgb_formats[] = {
>   .cs = IPUV3_COLORSPACE_RGB,
>   .bpp= 16,
>   .bayer  = true,
> + }, {
> + .fourcc = V4L2_PIX_FMT_GREY,
> + .codes = {MEDIA_BUS_FMT_Y8_1X8},
> + .cs = IPUV3_COLORSPACE_RGB,
> + .bpp= 8,
> + .bayer  = true,
>   },
>   /***
>* non-mbus RGB formats start here. NOTE! when adding non-mbus
> 

Re: [PATCH] media: radio: Critical interrupt bugfix for si470x over i2c

[Hans Verkuil]

On 27/01/18 00:42, Douglas Fischer wrote:
> Fixed si470x_start() disabling the interrupt signal, causing tune
> operations to never complete. This does not affect USB radios
> because they poll the registers instead of using the IRQ line.
> 
> Signed-off-by: Douglas Fischer 
> ---
> 
> diff -uprN linux.orig/drivers/media/radio/si470x/radio-si470x-common.c
> linux/drivers/media/radio/si470x/radio-si470x-common.c ---
> linux.orig/drivers/media/radio/si470x/radio-si470x-common.c
> 2018-01-15 21:58:10.675620432 -0500 +++
> linux/drivers/media/radio/si470x/radio-si470x-common.c
> 2018-01-16 16:54:23.699770645 -0500 @@ -377,8 +377,13 @@ int
> si470x_start(struct si470x_device *r goto done; /* sysconfig 1 */
> - radio->registers[SYSCONFIG1] =
> - (de << 11) & SYSCONFIG1_DE; /* DE*/
> + radio->registers[SYSCONFIG1] |= SYSCONFIG1_RDSIEN;
> + radio->registers[SYSCONFIG1] |= SYSCONFIG1_STCIEN;
> + radio->registers[SYSCONFIG1] |= SYSCONFIG1_RDS;

Just do:

radio->registers[SYSCONFIG1] |= SYSCONFIG1_RDSIEN | SYSCONFIG1_STCIEN |
SYSCONFIG1_RDS;

> + radio->registers[SYSCONFIG1] &= ~SYSCONFIG1_GPIO2;

Why is this cleared?

> + radio->registers[SYSCONFIG1] |= 0x1 << 2;

What's this? It doesn't use a define, so either add one or add a comment.

> + if (de)
> + radio->registers[SYSCONFIG1] |= SYSCONFIG1_DE;
>   retval = si470x_set_register(radio, SYSCONFIG1);
>   if (retval < 0)
>   goto done;
> 

Also, this is now set in si470x_start, so the same code can now be removed
in si470x_fops_open for i2c.

In general I would feel happier if you just add a 'bool is_i2c' argument to
si470x_start and only change SYSCONFIG1 for the i2c case.

Regards,

Hans

Re: [PATCH] media: radio: Critical v4l2 registration bugfix for si470x over i2c

[Hans Verkuil]

Hi Douglas,

On 20/01/18 20:19, Douglas Fischer wrote:
> Added the call to v4l2_device_register() required to add a new radio
> device. Without this patch, it is impossible for the driver to load.
> This does not affect USB devices.
> 
> Signed-off-by: Douglas Fischer 
> ---
> 
> diff -uprN linux.orig/drivers/media/radio/si470x/radio-si470x-i2c.c
> linux/drivers/media/radio/si470x/radio-si470x-i2c.c ---
> linux.orig/drivers/media/radio/si470x/radio-si470x-i2c.c
> 2018-01-15 21:58:10.675620432 -0500 +++
> linux/drivers/media/radio/si470x/radio-si470x-i2c.c   2018-01-16
> 17:08:02.929734342 -0500 @@ -43,7 +43,6 @@ static const struct
> i2c_device_id si470x MODULE_DEVICE_TABLE(i2c, si470x_i2c_id); 
> -
>  /**
>   * Module Parameters
>   **/
> @@ -362,8 +361,29 @@ static int si470x_i2c_probe(struct i2c_c
>   mutex_init(>lock);
>   init_completion(>completion);
>  
> + retval = v4l2_device_register(>dev, >v4l2_dev);
> + if (retval < 0) {
> + dev_err(>dev, "couldn't register
> v4l2_device\n");
> + goto err_initial;
> + }
> +
> + v4l2_ctrl_handler_init(>hdl, 2);
> + v4l2_ctrl_new_std(>hdl, _ctrl_ops,
> + V4L2_CID_AUDIO_MUTE, 0, 1, 1, 1);
> + v4l2_ctrl_new_std(>hdl, _ctrl_ops,
> + V4L2_CID_AUDIO_VOLUME, 0, 15, 1, 15);
> + if (radio->hdl.error) {
> + retval = radio->hdl.error;
> + dev_err(>dev, "couldn't register control\n");
> + goto err_dev;
> + }

You don't explain in the commit log why this is added as well.

> +
>   /* video device initialization */
>   radio->videodev = si470x_viddev_template;
> + radio->videodev.ctrl_handler =
> >hdl;  // no?
> + radio->videodev.lock =
> >lock; // no?

'no?' what?

> + radio->videodev.v4l2_dev = >v4l2_dev;
> + radio->videodev.release = video_device_release_empty;
>   video_set_drvdata(>videodev, radio);
>  
>   /* power up : need 110ms */
> @@ -435,6 +455,8 @@ static int si470x_i2c_probe(struct i2c_c
>   return 0;
>  err_all:
>   free_irq(client->irq, radio);
> +err_dev:
> + v4l2_device_unregister(>v4l2_dev);

This can't be right. radio->buffer is allocated after the v4l2_device, so the
kfree for that should come before err_dev.

Please double check the cleanup order.

>  err_rds:
>   kfree(radio->buffer);
>  err_radio:
> 

Regards,

Hans

Re: [PATCH] media: radio: Tuning bugfix for si470x over i2c

[Hans Verkuil]

Hi Douglas,

My apologies for the delay, but I have finally time to look at this.

First of all: all your patches are mangles. Your mailer probably is trying
to wrap around long lines and the end result is not usable. Please check this
next time.

Also, when you post newer versions of patches it is good practice to add a
version number: e.g. '[PATCHv3] media: radio: Tuning bugfix for si470x over 
i2c'.

That helps us keeping track of different versions.

On 20/01/18 20:19, Douglas Fischer wrote:
> Fixed si470x_set_channel() trying to tune before chip is turned
> on, which causes warnings in dmesg and when probing, makes driver
> wait for 3s for tuning timeout. This issue did not affect USB
> devices because they have a different probing sequence.
> 
> Signed-off-by: Douglas Fischer 
> ---
> 
> diff -uprN linux.orig/drivers/media/radio/si470x/radio-si470x-common.c
> linux/drivers/media/radio/si470x/radio-si470x-common.c ---
> linux.orig/drivers/media/radio/si470x/radio-si470x-common.c
> 2018-01-15 21:58:10.675620432 -0500 +++
> linux/drivers/media/radio/si470x/radio-si470x-common.c
> 2018-01-16 17:04:59.706409128 -0500 @@ -207,29 +207,37 @@ static int
> si470x_set_chan(struct si470x unsigned long time_left; bool timed_out =
> false; 
> - /* start tuning */
> - radio->registers[CHANNEL] &= ~CHANNEL_CHAN;
> - radio->registers[CHANNEL] |= CHANNEL_TUNE | chan;
> - retval = si470x_set_register(radio, CHANNEL);
> - if (retval < 0)
> - goto done;
> + retval = si470x_get_register(radio, POWERCFG);
> + if (retval)
> + return retval;
>  
> - /* wait till tune operation has completed */
> - reinit_completion(>completion);
> - time_left = wait_for_completion_timeout(>completion,
> -
> msecs_to_jiffies(tune_timeout));
> - if (time_left == 0)
> - timed_out = true;
> + if ( (radio->registers[POWERCFG] & POWERCFG_ENABLE) && 
> + (radio->registers[POWERCFG] & POWERCFG_DMUTE) ) { 
>  

Just do:

if (radio->registers[POWERCFG] & POWERCFG_ENABLE) & (POWERCFG_ENABLE | 
POWERCFG_DMUTE) !=
POWERCFG_ENABLE | POWERCFG_DMUTE)
return 0;

And the remainder of the code can be indented one tab to the left. It's easier 
to read
and the diff is also smaller.

Regards,

Hans

> - if ((radio->registers[STATUSRSSI] & STATUSRSSI_STC) == 0)
> - dev_warn(>videodev.dev, "tune does not
> complete\n");
> - if (timed_out)
> - dev_warn(>videodev.dev,
> - "tune timed out after %u ms\n", tune_timeout);
> + /* start tuning */
> + radio->registers[CHANNEL] &= ~CHANNEL_CHAN;
> + radio->registers[CHANNEL] |= CHANNEL_TUNE | chan;
> + retval = si470x_set_register(radio, CHANNEL);
> + if (retval < 0)
> + goto done;
>  
> - /* stop tuning */
> - radio->registers[CHANNEL] &= ~CHANNEL_TUNE;
> - retval = si470x_set_register(radio, CHANNEL);
> + /* wait till tune operation has completed */
> + reinit_completion(>completion);
> + time_left =
> wait_for_completion_timeout(>completion,
> +
> msecs_to_jiffies(tune_timeout));
> + if (time_left == 0)
> + timed_out = true;
> + 
> + if ((radio->registers[STATUSRSSI] & STATUSRSSI_STC) ==
> 0)
> + dev_warn(>videodev.dev, "tune does not
> complete\n");
> + if (timed_out)
> + dev_warn(>videodev.dev,
> + "tune timed out after %u ms\n",
> tune_timeout);
> + 
> + /* stop tuning */
> + radio->registers[CHANNEL] &= ~CHANNEL_TUNE;
> + retval = si470x_set_register(radio, CHANNEL);
> + }
>  
>  done:
>   return retval;
> 

Targeted B2B Companies Emails List

[sally . grant]

Hi,

I was wondering if you would be interested in targeting a customized list  
of your competitors End Users Install Base for your upcoming Marketing  
Strategy.


• ERP- JD Edwards, Infor Baan, SAP, Exact Software, NetSuite, PeopleSoft,  
etc.
• CRM- Salesforce, MS Dynamics, NetSuite, Siebel, Teradata, Epicor, Infor,  
CDC Software, etc.
• Engineering Software- Autodesk, Siemens PLM, Adobe, AutoCAD, MAYA, Revit,  
Solid works, PTC, MADCAD, etc.

• Cloud Computing- Amazon, Rack Space, Google APPS, Hyper-V, NetApp, etc.
• Storage application - NetApp, EMC, Citrix, HP, Brocade, DELL, etc.
• Security Software- Symantec, McAfee, IBM, Riverbed, Tabberg, Commvault,  
Juniper Networks, F5, etc.

• Networking- Brocade, Symantec, Avaya, Cisco, Shoretel, etc.
• Medical Software- NextGen, All Scripts, EMR, McKesson, Practice Fusion,  
eClinical Works, etc.
• Accounting Software- Sage, Peachtree, Timberline, MS Dynamics, NetSuite,  
Deltek, Lawson, QuickBooks, etc.
• Business Intelligence- SAP Business Objects, Microstratergy, Tibco,  
Microsoft BI, QlikTech, Information Builders, etc.
We provide data across the globe - North America, EMEA, Asia Pacific and  
LATAM. We provide the decision Makers contacts like CIO, CTO, CISO, IT VP,  
IT Director, IT manager, IT head, etc.


Please review and let me know if you are looking for any type of list and  
we can service you.


If you are interested, let me know your targeted geography so that I will  
get back to you with the counts and more information.


Await your response!
Thanks,
Sally Grant
Marketing Executive

 If you are not interested in receiving further emails, please answer back  
with "overlook" in the title.

Targeted B2B Companies Emails List

[sally . grant]

Hi,

I was wondering if you would be interested in targeting a customized list  
of your competitors End Users Install Base for your upcoming Marketing  
Strategy.


• ERP- JD Edwards, Infor Baan, SAP, Exact Software, NetSuite, PeopleSoft,  
etc.
• CRM- Salesforce, MS Dynamics, NetSuite, Siebel, Teradata, Epicor, Infor,  
CDC Software, etc.
• Engineering Software- Autodesk, Siemens PLM, Adobe, AutoCAD, MAYA, Revit,  
Solid works, PTC, MADCAD, etc.

• Cloud Computing- Amazon, Rack Space, Google APPS, Hyper-V, NetApp, etc.
• Storage application - NetApp, EMC, Citrix, HP, Brocade, DELL, etc.
• Security Software- Symantec, McAfee, IBM, Riverbed, Tabberg, Commvault,  
Juniper Networks, F5, etc.

• Networking- Brocade, Symantec, Avaya, Cisco, Shoretel, etc.
• Medical Software- NextGen, All Scripts, EMR, McKesson, Practice Fusion,  
eClinical Works, etc.
• Accounting Software- Sage, Peachtree, Timberline, MS Dynamics, NetSuite,  
Deltek, Lawson, QuickBooks, etc.
• Business Intelligence- SAP Business Objects, Microstratergy, Tibco,  
Microsoft BI, QlikTech, Information Builders, etc.
We provide data across the globe - North America, EMEA, Asia Pacific and  
LATAM. We provide the decision Makers contacts like CIO, CTO, CISO, IT VP,  
IT Director, IT manager, IT head, etc.


Please review and let me know if you are looking for any type of list and  
we can service you.


If you are interested, let me know your targeted geography so that I will  
get back to you with the counts and more information.


Await your response!
Thanks,
Sally Grant
Marketing Executive

 If you are not interested in receiving further emails, please answer back  
with "overlook" in the title.

Re: [PATCH v3 4/8] i2c: ov9650: use 64-bit arithmetic instead of 32-bit

[Hans Verkuil]

On 08/02/18 17:39, Gustavo A. R. Silva wrote:
> Hi Sakari,
> 
> On 02/07/2018 03:59 PM, Sakari Ailus wrote:
>> Hi Gustavo,
>>
>> On Tue, Feb 06, 2018 at 10:47:50AM -0600, Gustavo A. R. Silva wrote:
>>> Add suffix ULL to constants 1 and 100 in order to give the
>>> compiler complete information about the proper arithmetic to use.
>>> Notice that these constants are used in contexts that expect
>>> expressions of type u64 (64 bits, unsigned).
>>>
>>> The following expressions:
>>>
>>> (u64)(fi->interval.numerator * 1)
>>> (u64)(iv->interval.numerator * 1)
>>> fiv->interval.numerator * 100 / fiv->interval.denominator
>>>
>>> are currently being evaluated using 32-bit arithmetic.
>>>
>>> Notice that those casts to u64 for the first two expressions are only
>>> effective after such expressions are evaluated using 32-bit arithmetic,
>>> which leads to potential integer overflows. So based on those casts, it
>>> seems that the original intention of the code is to actually use 64-bit
>>> arithmetic instead of 32-bit.
>>>
>>> Also, notice that once the suffix ULL is added to the constants, the
>>> outer casts to u64 are no longer needed.
>>>
>>> Addresses-Coverity-ID: 1324146 ("Unintentional integer overflow")
>>> Fixes: 84a15ded76ec ("[media] V4L: Add driver for OV9650/52 image sensors")
>>> Fixes: 79211c8ed19c ("remove abs64()")
>>> Signed-off-by: Gustavo A. R. Silva 
>>> ---
>>> Changes in v2:
>>>   - Update subject and changelog to better reflect the proposed code 
>>> changes.
>>>   - Add suffix ULL to constants instead of casting variables.
>>>   - Remove unnecessary casts to u64 as part of the code change.
>>>   - Extend the same code change to other similar expressions.
>>>
>>> Changes in v3:
>>>   - None.
>>>
>>>   drivers/media/i2c/ov9650.c | 9 +
>>>   1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
>>> index e519f27..e716e98 100644
>>> --- a/drivers/media/i2c/ov9650.c
>>> +++ b/drivers/media/i2c/ov9650.c
>>> @@ -1130,7 +1130,7 @@ static int __ov965x_set_frame_interval(struct ov965x 
>>> *ov965x,
>>>   if (fi->interval.denominator == 0)
>>>   return -EINVAL;
>>>   -    req_int = (u64)(fi->interval.numerator * 1) /
>>> +    req_int = fi->interval.numerator * 1ULL /
>>>   fi->interval.denominator;
>>
>> This has been addressed by your earlier patch "i2c: ov9650: fix potential 
>> integer overflow in
>> __ov965x_set_frame_interval" I tweaked a little. It's not in media tree
>> master yet.
>>
> 
> Yeah. Actually this patch is supposed to be an improved version of the one 
> you mention. That is why this is version 3.
> 
> Also, I wonder if the same issue you mention below regarding 32-bit ARM 
> applies in this case too?
> 
>>>     for (i = 0; i < ARRAY_SIZE(ov965x_intervals); i++) {
>>> @@ -1139,7 +1139,7 @@ static int __ov965x_set_frame_interval(struct ov965x 
>>> *ov965x,
>>>   if (mbus_fmt->width != iv->size.width ||
>>>   mbus_fmt->height != iv->size.height)
>>>   continue;
>>> -    err = abs((u64)(iv->interval.numerator * 1) /
>>> +    err = abs(iv->interval.numerator * 1ULL /
>>
>> This and the chunk below won't work on e.g. 32-bit ARM. do_div(), please.
>>
> 
> Thanks for pointing this out.
> 
>>>   iv->interval.denominator - req_int);
>>>   if (err < min_err) {
>>>   fiv = iv;
>>> @@ -1148,8 +1148,9 @@ static int __ov965x_set_frame_interval(struct ov965x 
>>> *ov965x,
>>>   }
>>>   ov965x->fiv = fiv;
>>>   -    v4l2_dbg(1, debug, >sd, "Changed frame interval to %u us\n",
>>> - fiv->interval.numerator * 100 / fiv->interval.denominator);
>>> +    v4l2_dbg(1, debug, >sd, "Changed frame interval to %llu us\n",
>>> + fiv->interval.numerator * 100ULL /
>>> + fiv->interval.denominator);
> 
> I wonder if do_div should be used for the code above?

Yes, do_div should be used.

Hans

> 
> I appreciate your feedback.
> 
> Thank you!

[PATCH v8 2/2] v4l: cadence: Add Cadence MIPI-CSI2 RX driver

[Maxime Ripard]

The Cadence CSI-2 RX Controller is an hardware block meant to be used as a
bridge between a CSI-2 bus and pixel grabbers.

It supports operating with internal or external D-PHY, with up to 4 lanes,
or without any D-PHY. The current code only supports the latter case.

It also support dynamic mapping of the CSI-2 virtual channels to the
associated pixel grabbers, but that isn't allowed at the moment either.

Acked-by: Sakari Ailus 
Signed-off-by: Maxime Ripard 
---
 drivers/media/platform/Kconfig   |   1 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/cadence/Kconfig   |  17 +
 drivers/media/platform/cadence/Makefile  |   1 +
 drivers/media/platform/cadence/cdns-csi2rx.c | 499 +++
 5 files changed, 520 insertions(+)
 create mode 100644 drivers/media/platform/cadence/Kconfig
 create mode 100644 drivers/media/platform/cadence/Makefile
 create mode 100644 drivers/media/platform/cadence/cdns-csi2rx.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 614fbef08ddc..c001b646d441 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -26,6 +26,7 @@ config VIDEO_VIA_CAMERA
 #
 # Platform multimedia device configuration
 #
+source "drivers/media/platform/cadence/Kconfig"
 
 source "drivers/media/platform/davinci/Kconfig"
 
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 7f3080437be6..3d29082fcf72 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -3,6 +3,8 @@
 # Makefile for the video capture/playback device drivers.
 #
 
+obj-$(CONFIG_VIDEO_CADENCE)+= cadence/
+
 obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o
 
 obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
diff --git a/drivers/media/platform/cadence/Kconfig 
b/drivers/media/platform/cadence/Kconfig
new file mode 100644
index ..18f061e5cbd1
--- /dev/null
+++ b/drivers/media/platform/cadence/Kconfig
@@ -0,0 +1,17 @@
+config VIDEO_CADENCE
+   bool "Cadence Video Devices"
+
+if VIDEO_CADENCE
+
+config VIDEO_CADENCE_CSI2RX
+   tristate "Cadence MIPI-CSI2 RX Controller"
+   depends on MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+ Support for the Cadence MIPI CSI2 Receiver controller.
+
+ To compile this driver as a module, choose M here: the module will be
+ called cdns-csi2rx.
+
+endif
diff --git a/drivers/media/platform/cadence/Makefile 
b/drivers/media/platform/cadence/Makefile
new file mode 100644
index ..99a4086b7448
--- /dev/null
+++ b/drivers/media/platform/cadence/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_CADENCE_CSI2RX) += cdns-csi2rx.o
diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c 
b/drivers/media/platform/cadence/cdns-csi2rx.c
new file mode 100644
index ..99662e1a536b
--- /dev/null
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -0,0 +1,499 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for Cadence MIPI-CSI2 RX Controller v1.3
+ *
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define CSI2RX_DEVICE_CFG_REG  0x000
+
+#define CSI2RX_SOFT_RESET_REG  0x004
+#define CSI2RX_SOFT_RESET_PROTOCOL BIT(1)
+#define CSI2RX_SOFT_RESET_FRONTBIT(0)
+
+#define CSI2RX_STATIC_CFG_REG  0x008
+#define CSI2RX_STATIC_CFG_DLANE_MAP(llane, plane)  ((plane) << (16 + 
(llane) * 4))
+#define CSI2RX_STATIC_CFG_LANES_MASK   GENMASK(11, 8)
+
+#define CSI2RX_STREAM_BASE(n)  (((n) + 1) * 0x100)
+
+#define CSI2RX_STREAM_CTRL_REG(n)  (CSI2RX_STREAM_BASE(n) + 0x000)
+#define CSI2RX_STREAM_CTRL_START   BIT(0)
+
+#define CSI2RX_STREAM_DATA_CFG_REG(n)  (CSI2RX_STREAM_BASE(n) + 0x008)
+#define CSI2RX_STREAM_DATA_CFG_EN_VC_SELECTBIT(31)
+#define CSI2RX_STREAM_DATA_CFG_VC_SELECT(n)BIT((n) + 16)
+
+#define CSI2RX_STREAM_CFG_REG(n)   (CSI2RX_STREAM_BASE(n) + 0x00c)
+#define CSI2RX_STREAM_CFG_FIFO_MODE_LARGE_BUF  (1 << 8)
+
+#define CSI2RX_LANES_MAX   4
+#define CSI2RX_STREAMS_MAX 4
+
+enum csi2rx_pads {
+   CSI2RX_PAD_SINK,
+   CSI2RX_PAD_SOURCE_STREAM0,
+   CSI2RX_PAD_SOURCE_STREAM1,
+   CSI2RX_PAD_SOURCE_STREAM2,
+   CSI2RX_PAD_SOURCE_STREAM3,
+   CSI2RX_PAD_MAX,
+};
+
+struct csi2rx_priv {
+   struct device   *dev;
+   unsigned intcount;
+
+   /*
+* Used to prevent race conditions between multiple,
+* concurrent calls to start and stop.
+*/
+   struct mutexlock;
+
+   

[PATCH v8 1/2] dt-bindings: media: Add Cadence MIPI-CSI2 RX Device Tree bindings

[Maxime Ripard]

The Cadence MIPI-CSI2 RX controller is a CSI2RX bridge that supports up to
4 CSI-2 lanes, and can route the frames to up to 4 streams, depending on
the hardware implementation.

It can operate with an external D-PHY, an internal one or no D-PHY at all
in some configurations.

Acked-by: Rob Herring 
Acked-by: Benoit Parrot 
Acked-by: Sakari Ailus 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/media/cdns,csi2rx.txt  | 100 +
 1 file changed, 100 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.txt

diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt 
b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
new file mode 100644
index ..6b02a0657ad9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
@@ -0,0 +1,100 @@
+Cadence MIPI-CSI2 RX controller
+===
+
+The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
+lanes in input, and 4 different pixel streams in output.
+
+Required properties:
+  - compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible
+  - reg: base address and size of the memory mapped region
+  - clocks: phandles to the clocks driving the controller
+  - clock-names: must contain:
+* sys_clk: main clock
+* p_clk: register bank clock
+* pixel_if[0-3]_clk: pixel stream output clock, one for each stream
+ implemented in hardware, between 0 and 3
+
+Optional properties:
+  - phys: phandle to the external D-PHY, phy-names must be provided
+  - phy-names: must contain "dphy", if the implementation uses an
+   external D-PHY
+
+Required subnodes:
+  - ports: A ports node with one port child node per device input and output
+   port, in accordance with the video interface bindings defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The
+   port nodes are numbered as follows:
+
+   Port Description
+   -
+   0CSI-2 input
+   1Stream 0 output
+   2Stream 1 output
+   3Stream 2 output
+   4Stream 3 output
+
+   The stream output port nodes are optional if they are not
+   connected to anything at the hardware level or implemented
+   in the design.Since there is only one endpoint per port,
+   the endpoints are not numbered.
+
+
+Example:
+
+csi2rx: csi-bridge@0d06 {
+   compatible = "cdns,csi2rx";
+   reg = <0x0d06 0x1000>;
+   clocks = <>, <>
+<>, <>,
+<>, <>;
+   clock-names = "sys_clk", "p_clk",
+ "pixel_if0_clk", "pixel_if1_clk",
+ "pixel_if2_clk", "pixel_if3_clk";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   csi2rx_in_sensor: endpoint {
+   remote-endpoint = <_out_csi2rx>;
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   csi2rx_out_grabber0: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   csi2rx_out_grabber1: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+
+   port@3 {
+   reg = <3>;
+
+   csi2rx_out_grabber2: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+
+   port@4 {
+   reg = <4>;
+
+   csi2rx_out_grabber3: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+   };
+};
-- 
2.14.3

[PATCH v8 0/2] media: v4l: Add support for the Cadence MIPI-CSI2 RX

[Maxime Ripard]

Hi,

Here is another attempt at supporting the MIPI-CSI2 RX block from
Cadence.

This IP block is able to receive CSI data over up to 4 lanes, and
split it to over 4 streams. Those streams are basically the interfaces
to the video grabbers that will perform the capture.

It is able to map streams to both CSI datatypes and virtual channels,
dynamically. This is unclear at this point what the right way to
support it would be, so the driver only uses a static mapping between
the virtual channels and streams, and ignores the data types.

Let me know what you think!
Maxime

Changes from v7:
  - Changed calls to usleep_range to udelay
  - Rebased on top of 4.16
  - Renamed the reg variable in _get_resources to dev_cfg
  - Checked for the clk_prepare_enable return codes
  - Fixed a race condition in concurrent calls to s_stream by moving
from the atomic counter to a mutex.

Changes from v6:
  - Added Sakari's Acked-by
  - Added Kconfig help
  - Removed the comment in the probe next to the kmalloc

Changes from v5:
  - Use SPDX license header
  - Fix the lane mapping logic and map unused logical lanes only to unused
physical lanes. Added a comment to explain why.

Changes from v4:
  - Rebased on top of 4.15
  - Fixed a lane mapping issue that prevented the CSI2-RX device to operate
properly.
  - Reworded the output endpoints documentation in the binding

Changes from v3:
  - Removed stale printk
  - Propagate start/stop functions error code to s_stream
  - Renamed the DT bindings files
  - Clarified the output ports wording in the DT binding doc
  - Added a define for the maximum number of lanes
  - Rebased on top of Sakari's serie
  - Gathered tags based on the reviews

Changes from v2:
  - Added reference counting for the controller initialisation
  - Fixed checkpatch warnings
  - Moved the sensor initialisation after the DPHY configuration
  - Renamed the sensor fields to source for consistency
  - Defined some variables
  - Renamed a few structures variables
  - Added internal and external phy errors messages
  - Reworked the binding slighty by making the external D-PHY optional
  - Moved the notifier registration in the probe function
  - Removed some clocks that are not system clocks
  - Added clocks enabling where needed
  - Added the code to remap the data lanes
  - Changed the memory allocator for the non-devm function, and a
comment explaining why
  - Reworked the binding wording

Changes from v1:
  - Amended the DT bindings as suggested by Rob
  - Rebase on top of 4.13-rc1 and latest Niklas' serie iteration

Maxime Ripard (2):
  dt-bindings: media: Add Cadence MIPI-CSI2 RX Device Tree bindings
  v4l: cadence: Add Cadence MIPI-CSI2 RX driver

 .../devicetree/bindings/media/cdns,csi2rx.txt  | 100 +
 drivers/media/platform/Kconfig |   1 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/cadence/Kconfig |  17 +
 drivers/media/platform/cadence/Makefile|   1 +
 drivers/media/platform/cadence/cdns-csi2rx.c   | 499 +
 6 files changed, 620 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.txt
 create mode 100644 drivers/media/platform/cadence/Kconfig
 create mode 100644 drivers/media/platform/cadence/Makefile
 create mode 100644 drivers/media/platform/cadence/cdns-csi2rx.c

-- 
2.14.3

[PATCH v4 0/2] media: v4l: Add support for the Cadence MIPI-CSI2 TX controller

[Maxime Ripard]

Hi,

Here is an attempt at supporting the MIPI-CSI2 TX block from Cadence.

This IP block is able to receive 4 video streams and stream them over
a MIPI-CSI2 link using up to 4 lanes. Those streams are basically the
interfaces to controllers generating some video signals, like a camera
or a pattern generator.

It is able to map input streams to CSI2 virtual channels and datatypes
dynamically. The streaming devices choose their virtual channels
through an additional signal that is transparent to the CSI2-TX. The
datatypes however are yet another additional input signal, and can be
mapped to any CSI2 datatypes.

Since v4l2 doesn't really allow for that setup at the moment, this
preliminary version is a rather dumb one in order to start the
discussion on how to address this properly.

Let me know what you think!
Maxime

Changes from v3:
  - Added a comment about entity links walk concurrency
  - Changed the default resolution to 1280x720
  - Changed usleep_range calls to udelay
  - Reworked the reference counting mechanism to remove a race
condition by adding a mutex instead of an atomic count
  - Changed the entity function to MEDIA_ENT_F_VID_IF_BRIDGE
  - Changed the name of the reg variable in _get_resources to dev_cfg
  - Removed the redundant error message in the devm_ioremap_resource
error path
  - Moved the subdev s_stream call before enabling the TX bridge
  - Changed some int types to unsigned
  - Init'd the pad formats properly
  - Fixed typo in the CSI2TX_LANES_MAX define name
  - Added Sakari Acked-by

Changes from v2:
  - Use SPDX license header
  - Use the lane mapping from DT

Changes from v1:
  - Add a subdev notifier and start our downstream subdevice in
s_stream  
  - Based the decision to enable the stream or not on the link state
instead of whether a format was being set on the pad
  - Put the controller back in reset when stopping the pipeline
  - Clarified the enpoints number in the DT binding
  - Added a default format for the pads
  - Added some missing const
  - Added more explicit comments
  - Rebased on 4.15

Maxime Ripard (2):
  dt-bindings: media: Add Cadence MIPI-CSI2 TX Device Tree bindings
  v4l: cadence: Add Cadence MIPI-CSI2 TX driver

 .../devicetree/bindings/media/cdns,csi2tx.txt  |  98 
 drivers/media/platform/cadence/Kconfig |  11 +
 drivers/media/platform/cadence/Makefile|   1 +
 drivers/media/platform/cadence/cdns-csi2tx.c   | 602 +
 4 files changed, 712 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2tx.txt
 create mode 100644 drivers/media/platform/cadence/cdns-csi2tx.c

-- 
2.14.3

[PATCH v4 2/2] v4l: cadence: Add Cadence MIPI-CSI2 TX driver

[Maxime Ripard]

The Cadence MIPI-CSI2 TX controller is an hardware block meant to be used
as a bridge between pixel interfaces and a CSI-2 bus.

It supports operating with an internal or external D-PHY, with up to 4
lanes, or without any D-PHY. The current code only supports the latter
case.

While the virtual channel input on the pixel interface can be directly
mapped to CSI2, the datatype input is actually a selection signal (3-bits)
mapping to a table of up to 8 preconfigured datatypes/formats (programmed
at start-up)

The block supports up to 8 input datatypes.

Signed-off-by: Maxime Ripard 
---
 drivers/media/platform/cadence/Kconfig   |  11 +
 drivers/media/platform/cadence/Makefile  |   1 +
 drivers/media/platform/cadence/cdns-csi2tx.c | 602 +++
 3 files changed, 614 insertions(+)
 create mode 100644 drivers/media/platform/cadence/cdns-csi2tx.c

diff --git a/drivers/media/platform/cadence/Kconfig 
b/drivers/media/platform/cadence/Kconfig
index 18f061e5cbd1..83dcf2b1814b 100644
--- a/drivers/media/platform/cadence/Kconfig
+++ b/drivers/media/platform/cadence/Kconfig
@@ -14,4 +14,15 @@ config VIDEO_CADENCE_CSI2RX
  To compile this driver as a module, choose M here: the module will be
  called cdns-csi2rx.
 
+config VIDEO_CADENCE_CSI2TX
+   tristate "Cadence MIPI-CSI2 TX Controller"
+   depends on MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+ Support for the Cadence MIPI CSI2 Transceiver controller.
+
+ To compile this driver as a module, choose M here: the module will be
+ called cdns-csi2tx.
+
 endif
diff --git a/drivers/media/platform/cadence/Makefile 
b/drivers/media/platform/cadence/Makefile
index 99a4086b7448..7fe992273162 100644
--- a/drivers/media/platform/cadence/Makefile
+++ b/drivers/media/platform/cadence/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_VIDEO_CADENCE_CSI2RX) += cdns-csi2rx.o
+obj-$(CONFIG_VIDEO_CADENCE_CSI2TX) += cdns-csi2tx.o
diff --git a/drivers/media/platform/cadence/cdns-csi2tx.c 
b/drivers/media/platform/cadence/cdns-csi2tx.c
new file mode 100644
index ..6d37b64db46f
--- /dev/null
+++ b/drivers/media/platform/cadence/cdns-csi2tx.c
@@ -0,0 +1,602 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for Cadence MIPI-CSI2 TX Controller
+ *
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define CSI2TX_DEVICE_CONFIG_REG   0x00
+
+#define CSI2TX_CONFIG_REG  0x20
+#define CSI2TX_CONFIG_CFG_REQ  BIT(2)
+#define CSI2TX_CONFIG_SRST_REQ BIT(1)
+
+#define CSI2TX_DPHY_CFG_REG0x28
+#define CSI2TX_DPHY_CFG_CLK_RESET  BIT(16)
+#define CSI2TX_DPHY_CFG_LANE_RESET(n)  BIT((n) + 12)
+#define CSI2TX_DPHY_CFG_MODE_MASK  GENMASK(9, 8)
+#define CSI2TX_DPHY_CFG_MODE_LPDT  (2 << 8)
+#define CSI2TX_DPHY_CFG_MODE_HS(1 << 8)
+#define CSI2TX_DPHY_CFG_MODE_ULPS  (0 << 8)
+#define CSI2TX_DPHY_CFG_CLK_ENABLE BIT(4)
+#define CSI2TX_DPHY_CFG_LANE_ENABLE(n) BIT(n)
+
+#define CSI2TX_DPHY_CLK_WAKEUP_REG 0x2c
+#define CSI2TX_DPHY_CLK_WAKEUP_ULPS_CYCLES(n)  ((n) & 0x)
+
+#define CSI2TX_DT_CFG_REG(n)   (0x80 + (n) * 8)
+#define CSI2TX_DT_CFG_DT(n)(((n) & 0x3f) << 2)
+
+#define CSI2TX_DT_FORMAT_REG(n)(0x84 + (n) * 8)
+#define CSI2TX_DT_FORMAT_BYTES_PER_LINE(n) (((n) & 0x) << 16)
+#define CSI2TX_DT_FORMAT_MAX_LINE_NUM(n)   ((n) & 0x)
+
+#define CSI2TX_STREAM_IF_CFG_REG(n)(0x100 + (n) * 4)
+#define CSI2TX_STREAM_IF_CFG_FILL_LEVEL(n) ((n) & 0x1f)
+
+#define CSI2TX_LANES_MAX   4
+#define CSI2TX_STREAMS_MAX 4
+
+enum csi2tx_pads {
+   CSI2TX_PAD_SOURCE,
+   CSI2TX_PAD_SINK_STREAM0,
+   CSI2TX_PAD_SINK_STREAM1,
+   CSI2TX_PAD_SINK_STREAM2,
+   CSI2TX_PAD_SINK_STREAM3,
+   CSI2TX_PAD_MAX,
+};
+
+struct csi2tx_fmt {
+   u32 mbus;
+   u32 dt;
+   u32 bpp;
+};
+
+struct csi2tx_priv {
+   struct device   *dev;
+   unsigned intcount;
+
+   /*
+* Used to prevent race conditions between multiple,
+* concurrent calls to start and stop.
+*/
+   struct mutexlock;
+
+   void __iomem*base;
+
+   struct clk  *esc_clk;
+   struct clk  *p_clk;
+   struct clk  *pixel_clk[CSI2TX_STREAMS_MAX];
+
+   struct v4l2_subdev  subdev;
+   struct v4l2_async_notifier  notifier;
+   struct media_padpads[CSI2TX_PAD_MAX];
+   struct v4l2_mbus_framefmt   pad_fmts[CSI2TX_PAD_MAX];
+
+   bool 

[PATCH v4 1/2] dt-bindings: media: Add Cadence MIPI-CSI2 TX Device Tree bindings

[Maxime Ripard]

The Cadence MIPI-CSI2 TX controller is a CSI2 bridge that supports up to 4
video streams and can output on up to 4 CSI-2 lanes, depending on the
hardware implementation.

It can operate with an external D-PHY, an internal one or no D-PHY at all
in some configurations.

Acked-by: Rob Herring 
Acked-by: Sakari Ailus 
Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/media/cdns,csi2tx.txt  | 98 ++
 1 file changed, 98 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2tx.txt

diff --git a/Documentation/devicetree/bindings/media/cdns,csi2tx.txt 
b/Documentation/devicetree/bindings/media/cdns,csi2tx.txt
new file mode 100644
index ..459c6e332f52
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cdns,csi2tx.txt
@@ -0,0 +1,98 @@
+Cadence MIPI-CSI2 TX controller
+===
+
+The Cadence MIPI-CSI2 TX controller is a CSI-2 bridge supporting up to
+4 CSI lanes in output, and up to 4 different pixel streams in input.
+
+Required properties:
+  - compatible: must be set to "cdns,csi2tx"
+  - reg: base address and size of the memory mapped region
+  - clocks: phandles to the clocks driving the controller
+  - clock-names: must contain:
+* esc_clk: escape mode clock
+* p_clk: register bank clock
+* pixel_if[0-3]_clk: pixel stream output clock, one for each stream
+ implemented in hardware, between 0 and 3
+
+Optional properties
+  - phys: phandle to the D-PHY. If it is set, phy-names need to be set
+  - phy-names: must contain "dphy"
+
+Required subnodes:
+  - ports: A ports node with one port child node per device input and output
+   port, in accordance with the video interface bindings defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The
+   port nodes are numbered as follows.
+
+   Port Description
+   -
+   0CSI-2 output
+   1Stream 0 input
+   2Stream 1 input
+   3Stream 2 input
+   4Stream 3 input
+
+   The stream input port nodes are optional if they are not
+   connected to anything at the hardware level or implemented
+   in the design. Since there is only one endpoint per port,
+   the endpoints are not numbered.
+
+Example:
+
+csi2tx: csi-bridge@0d0e1000 {
+   compatible = "cdns,csi2tx";
+   reg = <0x0d0e1000 0x1000>;
+   clocks = <>, <>,
+<>, <>,
+<>, <>;
+   clock-names = "p_clk", "esc_clk",
+ "pixel_if0_clk", "pixel_if1_clk",
+ "pixel_if2_clk", "pixel_if3_clk";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   csi2tx_out: endpoint {
+   remote-endpoint = <_in>;
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   csi2tx_in_stream0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   csi2tx_in_stream1: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@3 {
+   reg = <3>;
+
+   csi2tx_in_stream2: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@4 {
+   reg = <4>;
+
+   csi2tx_in_stream3: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+};
-- 
2.14.3

Re: [PATCH v2] videodev2.h: add helper to validate colorspace

[Laurent Pinchart]

Hi Hans,

On Thursday, 15 February 2018 14:32:55 EET Hans Verkuil wrote:
> On 15/02/18 13:06, Laurent Pinchart wrote:
> > On Thursday, 15 February 2018 13:56:44 EET Hans Verkuil wrote:
> >> On 15/02/18 12:08, Laurent Pinchart wrote:
> >>> On Thursday, 15 February 2018 12:57:44 EET Hans Verkuil wrote:
>  On 14/02/18 16:16, Laurent Pinchart wrote:
> > On Wednesday, 14 February 2018 12:36:43 EET Niklas Söderlund wrote:
> >> There is no way for drivers to validate a colorspace value, which
> >> could be provided by user-space by VIDIOC_S_FMT for example. Add a
> >> helper to validate that the colorspace value is part of enum
> >> v4l2_colorspace.
> >> 
> >> Signed-off-by: Niklas Söderlund
> >> 
> >> ---
> >> 
> >>  include/uapi/linux/videodev2.h | 4 
> >>  1 file changed, 4 insertions(+)
> >> 
> >> Hi,
> >> 
> >> I hope this is the correct header to add this helper to. I think it's
> >> since if it's in uapi not only can v4l2 drivers use it but tools like
> >> v4l-compliance gets access to it and can be updated to use this
> >> instead of the hard-coded check of just < 0xff as it was last time I
> >> checked.
> >> 
> >> * Changes since v1
> >> - Cast colorspace to u32 as suggested by Sakari and only check the
> >>   upper boundary to address a potential issue brought up by Laurent
> >>   if the data type tested is u32 which is not uncommon:
> >> enum.c:30:16: warning: comparison of unsigned expression >= 0 is
> >> always true [-Wtype-limits]
> >> 
> >>   return V4L2_COLORSPACE_IS_VALID(colorspace);
> >> 
> >> diff --git a/include/uapi/linux/videodev2.h
> >> b/include/uapi/linux/videodev2.h index
> >> 9827189651801e12..1f27c0f4187cbded 100644
> >> --- a/include/uapi/linux/videodev2.h
> >> +++ b/include/uapi/linux/videodev2.h
> >> @@ -238,6 +238,10 @@ enum v4l2_colorspace {
> >>V4L2_COLORSPACE_DCI_P3= 12,
> >>  };
> >> 
> >> +/* Determine if a colorspace is defined in enum v4l2_colorspace */
> >> +#define V4L2_COLORSPACE_IS_VALID(colorspace)  \
> >> +  ((u32)(colorspace) <= V4L2_COLORSPACE_DCI_P3)
>  
>  Sorry, this won't work. Use __u32. u32 is only available in the kernel,
>  not in userspace and this is a public header.
> >>> 
> >>> Indeed, that I should have caught.
> >>> 
>  I am not convinced about the usefulness of this check either. Drivers
>  will typically only support a subset of the available colorspaces, so
>  they need a switch to test for that.
> >>> 
> >>> Most MC drivers won't, as they don't care about colorspaces in most
> >>> subdevs. It's important for the colorspace to be propagated within
> >>> subdevs, and validated across the pipeline, but in most case, apart from
> >>> the image source subdev, other subdevs won't care. They should accept
> >>> any valid colorspace given to them and propagate it to their source pads
> >>> unchanged (except of course for subdevs that can change the colorspace,
> >>> but that's the exception, not the rule).
> >> 
> >> Right. So 'passthrough' subdevs should just copy this information from
> >> source to sink, and only pure source or pure sink subdevs should validate
> >> these fields. That makes sense.
> >> 
>  There is nothing wrong with userspace giving them an unknown
>  colorspace: either they will map anything they don't support to
>  something that they DO support, or they will return -EINVAL.
> >>> 
> >>> The former, not the latter. S_FMT should not return -EINVAL for
> >>> unsupported colorspace, the same way it doesn't return -EINVAL for
> >>> unsupported pixel formats.
> >>> 
>  If memory serves the spec requires the first option, so anything
>  unknown will just be replaced.
>  
>  And anyway, this raises the question of why you do this for the
>  colorspace but not for all the other enums in the V4L2 API.
> >>> 
> >>> Because v4l2-compliance tries to set a colorspace > 0xff and expects
> >>> that to be replaced by a colorspace <= 0xff. That seems like a bogus
> >>> check to me, 0xff is as random as it can get.
> >> 
> >> v4l2-compliance fills all fields with 0xff, then it checks after calling
> >> the ioctl if all fields have been set to valid values.
> >> 
> >> But in this case it should ignore the colorspace-related fields for
> >> passthrough subdevs. The only passthrough devices that should set
> >> colorspace are colorspace converter devices. I'm not sure if we can
> >> reliably detect that.
> >> 
>  It all seems rather pointless to me.
>  
>  I won't accept this unless I see it being used in a driver in a usefu
>  way.
>  
>  So for now:
>  
>  Nacked-by: Hans Verkuil 
> >>> 
> >>> Can you then fix v4l2-compliance to stop testing colorspace against 0xff
> >>> ?
> >> 
> >> For 

Re: [PATCH v2] videodev2.h: add helper to validate colorspace

[Hans Verkuil]

On 15/02/18 13:32, Hans Verkuil wrote:
> On 15/02/18 13:06, Laurent Pinchart wrote:
>> Hi Hans,
>>
>> On Thursday, 15 February 2018 13:56:44 EET Hans Verkuil wrote:
>>> On 15/02/18 12:08, Laurent Pinchart wrote:
 On Thursday, 15 February 2018 12:57:44 EET Hans Verkuil wrote:
> On 14/02/18 16:16, Laurent Pinchart wrote:
>> On Wednesday, 14 February 2018 12:36:43 EET Niklas Söderlund wrote:
>>> There is no way for drivers to validate a colorspace value, which could
>>> be provided by user-space by VIDIOC_S_FMT for example. Add a helper to
>>> validate that the colorspace value is part of enum v4l2_colorspace.
>>>
>>> Signed-off-by: Niklas Söderlund 
>>> ---
>>>
>>>  include/uapi/linux/videodev2.h | 4 
>>>  1 file changed, 4 insertions(+)
>>>
>>> Hi,
>>>
>>> I hope this is the correct header to add this helper to. I think it's
>>> since if it's in uapi not only can v4l2 drivers use it but tools like
>>> v4l-compliance gets access to it and can be updated to use this instead
>>> of the hard-coded check of just < 0xff as it was last time I checked.
>>>
>>> * Changes since v1
>>> - Cast colorspace to u32 as suggested by Sakari and only check the
>>>   upper boundary to address a potential issue brought up by Laurent if
>>>   the data type tested is u32 which is not uncommon:
>>> enum.c:30:16: warning: comparison of unsigned expression >= 0 is
>>> always true [-Wtype-limits]
>>>
>>>   return V4L2_COLORSPACE_IS_VALID(colorspace);
>>>
>>> diff --git a/include/uapi/linux/videodev2.h
>>> b/include/uapi/linux/videodev2.h index
>>> 9827189651801e12..1f27c0f4187cbded 100644
>>> --- a/include/uapi/linux/videodev2.h
>>> +++ b/include/uapi/linux/videodev2.h
>>> @@ -238,6 +238,10 @@ enum v4l2_colorspace {
>>> V4L2_COLORSPACE_DCI_P3= 12,
>>>  };
>>>
>>> +/* Determine if a colorspace is defined in enum v4l2_colorspace */
>>> +#define V4L2_COLORSPACE_IS_VALID(colorspace)   \
>>> +   ((u32)(colorspace) <= V4L2_COLORSPACE_DCI_P3)
>
> Sorry, this won't work. Use __u32. u32 is only available in the kernel,
> not in userspace and this is a public header.

 Indeed, that I should have caught.

> I am not convinced about the usefulness of this check either. Drivers
> will typically only support a subset of the available colorspaces, so
> they need a switch to test for that.

 Most MC drivers won't, as they don't care about colorspaces in most
 subdevs. It's important for the colorspace to be propagated within
 subdevs, and validated across the pipeline, but in most case, apart from
 the image source subdev, other subdevs won't care. They should accept any
 valid colorspace given to them and propagate it to their source pads
 unchanged (except of course for subdevs that can change the colorspace,
 but that's the exception, not the rule).
>>>
>>> Right. So 'passthrough' subdevs should just copy this information from
>>> source to sink, and only pure source or pure sink subdevs should validate
>>> these fields. That makes sense.
>>>
> There is nothing wrong with userspace giving them an unknown colorspace:
> either they will map anything they don't support to something that they
> DO
> support, or they will return -EINVAL.

 The former, not the latter. S_FMT should not return -EINVAL for
 unsupported
 colorspace, the same way it doesn't return -EINVAL for unsupported pixel
 formats.

> If memory serves the spec requires the first option, so anything unknown
> will just be replaced.
>
> And anyway, this raises the question of why you do this for the
> colorspace
> but not for all the other enums in the V4L2 API.

 Because v4l2-compliance tries to set a colorspace > 0xff and expects that
 to be replaced by a colorspace <= 0xff. That seems like a bogus check to
 me, 0xff is as random as it can get.
>>>
>>> v4l2-compliance fills all fields with 0xff, then it checks after calling the
>>> ioctl if all fields have been set to valid values.
>>>
>>> But in this case it should ignore the colorspace-related fields for
>>> passthrough subdevs. The only passthrough devices that should set
>>> colorspace are colorspace converter devices. I'm not sure if we can
>>> reliably detect that.
>>>
> It all seems rather pointless to me.
>
> I won't accept this unless I see it being used in a driver in a useful
> way.
>
> So for now:
>
> Nacked-by: Hans Verkuil 

 Can you then fix v4l2-compliance to stop testing colorspace against 0xff ?
>>>
>>> For now I can simply relax this test for subdevs with sources and sinks.
>>
>> You also need to relax it for video nodes with MC drivers, as the DMA 
>> engines 
>> 

Re: [PATCH v2] videodev2.h: add helper to validate colorspace

[Hans Verkuil]

On 15/02/18 13:06, Laurent Pinchart wrote:
> Hi Hans,
> 
> On Thursday, 15 February 2018 13:56:44 EET Hans Verkuil wrote:
>> On 15/02/18 12:08, Laurent Pinchart wrote:
>>> On Thursday, 15 February 2018 12:57:44 EET Hans Verkuil wrote:
 On 14/02/18 16:16, Laurent Pinchart wrote:
> On Wednesday, 14 February 2018 12:36:43 EET Niklas Söderlund wrote:
>> There is no way for drivers to validate a colorspace value, which could
>> be provided by user-space by VIDIOC_S_FMT for example. Add a helper to
>> validate that the colorspace value is part of enum v4l2_colorspace.
>>
>> Signed-off-by: Niklas Söderlund 
>> ---
>>
>>  include/uapi/linux/videodev2.h | 4 
>>  1 file changed, 4 insertions(+)
>>
>> Hi,
>>
>> I hope this is the correct header to add this helper to. I think it's
>> since if it's in uapi not only can v4l2 drivers use it but tools like
>> v4l-compliance gets access to it and can be updated to use this instead
>> of the hard-coded check of just < 0xff as it was last time I checked.
>>
>> * Changes since v1
>> - Cast colorspace to u32 as suggested by Sakari and only check the
>>   upper boundary to address a potential issue brought up by Laurent if
>>   the data type tested is u32 which is not uncommon:
>> enum.c:30:16: warning: comparison of unsigned expression >= 0 is
>> always true [-Wtype-limits]
>>
>>   return V4L2_COLORSPACE_IS_VALID(colorspace);
>>
>> diff --git a/include/uapi/linux/videodev2.h
>> b/include/uapi/linux/videodev2.h index
>> 9827189651801e12..1f27c0f4187cbded 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -238,6 +238,10 @@ enum v4l2_colorspace {
>>  V4L2_COLORSPACE_DCI_P3= 12,
>>  };
>>
>> +/* Determine if a colorspace is defined in enum v4l2_colorspace */
>> +#define V4L2_COLORSPACE_IS_VALID(colorspace)\
>> +((u32)(colorspace) <= V4L2_COLORSPACE_DCI_P3)

 Sorry, this won't work. Use __u32. u32 is only available in the kernel,
 not in userspace and this is a public header.
>>>
>>> Indeed, that I should have caught.
>>>
 I am not convinced about the usefulness of this check either. Drivers
 will typically only support a subset of the available colorspaces, so
 they need a switch to test for that.
>>>
>>> Most MC drivers won't, as they don't care about colorspaces in most
>>> subdevs. It's important for the colorspace to be propagated within
>>> subdevs, and validated across the pipeline, but in most case, apart from
>>> the image source subdev, other subdevs won't care. They should accept any
>>> valid colorspace given to them and propagate it to their source pads
>>> unchanged (except of course for subdevs that can change the colorspace,
>>> but that's the exception, not the rule).
>>
>> Right. So 'passthrough' subdevs should just copy this information from
>> source to sink, and only pure source or pure sink subdevs should validate
>> these fields. That makes sense.
>>
 There is nothing wrong with userspace giving them an unknown colorspace:
 either they will map anything they don't support to something that they
 DO
 support, or they will return -EINVAL.
>>>
>>> The former, not the latter. S_FMT should not return -EINVAL for
>>> unsupported
>>> colorspace, the same way it doesn't return -EINVAL for unsupported pixel
>>> formats.
>>>
 If memory serves the spec requires the first option, so anything unknown
 will just be replaced.

 And anyway, this raises the question of why you do this for the
 colorspace
 but not for all the other enums in the V4L2 API.
>>>
>>> Because v4l2-compliance tries to set a colorspace > 0xff and expects that
>>> to be replaced by a colorspace <= 0xff. That seems like a bogus check to
>>> me, 0xff is as random as it can get.
>>
>> v4l2-compliance fills all fields with 0xff, then it checks after calling the
>> ioctl if all fields have been set to valid values.
>>
>> But in this case it should ignore the colorspace-related fields for
>> passthrough subdevs. The only passthrough devices that should set
>> colorspace are colorspace converter devices. I'm not sure if we can
>> reliably detect that.
>>
 It all seems rather pointless to me.

 I won't accept this unless I see it being used in a driver in a useful
 way.

 So for now:

 Nacked-by: Hans Verkuil 
>>>
>>> Can you then fix v4l2-compliance to stop testing colorspace against 0xff ?
>>
>> For now I can simply relax this test for subdevs with sources and sinks.
> 
> You also need to relax it for video nodes with MC drivers, as the DMA engines 
> don't care about colorspaces.

Yes, they do. Many DMA engines can at least do RGB <-> YUV conversions, so they
should get the colorspace info from their 

Re: [PATCH v2] videodev2.h: add helper to validate colorspace

[Laurent Pinchart]

Hi Hans,

On Thursday, 15 February 2018 13:56:44 EET Hans Verkuil wrote:
> On 15/02/18 12:08, Laurent Pinchart wrote:
> > On Thursday, 15 February 2018 12:57:44 EET Hans Verkuil wrote:
> >> On 14/02/18 16:16, Laurent Pinchart wrote:
> >>> On Wednesday, 14 February 2018 12:36:43 EET Niklas Söderlund wrote:
>  There is no way for drivers to validate a colorspace value, which could
>  be provided by user-space by VIDIOC_S_FMT for example. Add a helper to
>  validate that the colorspace value is part of enum v4l2_colorspace.
>  
>  Signed-off-by: Niklas Söderlund 
>  ---
>  
>   include/uapi/linux/videodev2.h | 4 
>   1 file changed, 4 insertions(+)
>  
>  Hi,
>  
>  I hope this is the correct header to add this helper to. I think it's
>  since if it's in uapi not only can v4l2 drivers use it but tools like
>  v4l-compliance gets access to it and can be updated to use this instead
>  of the hard-coded check of just < 0xff as it was last time I checked.
>  
>  * Changes since v1
>  - Cast colorspace to u32 as suggested by Sakari and only check the
>    upper boundary to address a potential issue brought up by Laurent if
>    the data type tested is u32 which is not uncommon:
>  enum.c:30:16: warning: comparison of unsigned expression >= 0 is
>  always true [-Wtype-limits]
>  
>    return V4L2_COLORSPACE_IS_VALID(colorspace);
>  
>  diff --git a/include/uapi/linux/videodev2.h
>  b/include/uapi/linux/videodev2.h index
>  9827189651801e12..1f27c0f4187cbded 100644
>  --- a/include/uapi/linux/videodev2.h
>  +++ b/include/uapi/linux/videodev2.h
>  @@ -238,6 +238,10 @@ enum v4l2_colorspace {
>   V4L2_COLORSPACE_DCI_P3= 12,
>   };
>  
>  +/* Determine if a colorspace is defined in enum v4l2_colorspace */
>  +#define V4L2_COLORSPACE_IS_VALID(colorspace)\
>  +((u32)(colorspace) <= V4L2_COLORSPACE_DCI_P3)
> >> 
> >> Sorry, this won't work. Use __u32. u32 is only available in the kernel,
> >> not in userspace and this is a public header.
> > 
> > Indeed, that I should have caught.
> > 
> >> I am not convinced about the usefulness of this check either. Drivers
> >> will typically only support a subset of the available colorspaces, so
> >> they need a switch to test for that.
> > 
> > Most MC drivers won't, as they don't care about colorspaces in most
> > subdevs. It's important for the colorspace to be propagated within
> > subdevs, and validated across the pipeline, but in most case, apart from
> > the image source subdev, other subdevs won't care. They should accept any
> > valid colorspace given to them and propagate it to their source pads
> > unchanged (except of course for subdevs that can change the colorspace,
> > but that's the exception, not the rule).
> 
> Right. So 'passthrough' subdevs should just copy this information from
> source to sink, and only pure source or pure sink subdevs should validate
> these fields. That makes sense.
> 
> >> There is nothing wrong with userspace giving them an unknown colorspace:
> >> either they will map anything they don't support to something that they
> >> DO
> >> support, or they will return -EINVAL.
> > 
> > The former, not the latter. S_FMT should not return -EINVAL for
> > unsupported
> > colorspace, the same way it doesn't return -EINVAL for unsupported pixel
> > formats.
> > 
> >> If memory serves the spec requires the first option, so anything unknown
> >> will just be replaced.
> >> 
> >> And anyway, this raises the question of why you do this for the
> >> colorspace
> >> but not for all the other enums in the V4L2 API.
> > 
> > Because v4l2-compliance tries to set a colorspace > 0xff and expects that
> > to be replaced by a colorspace <= 0xff. That seems like a bogus check to
> > me, 0xff is as random as it can get.
> 
> v4l2-compliance fills all fields with 0xff, then it checks after calling the
> ioctl if all fields have been set to valid values.
> 
> But in this case it should ignore the colorspace-related fields for
> passthrough subdevs. The only passthrough devices that should set
> colorspace are colorspace converter devices. I'm not sure if we can
> reliably detect that.
> 
> >> It all seems rather pointless to me.
> >> 
> >> I won't accept this unless I see it being used in a driver in a useful
> >> way.
> >> 
> >> So for now:
> >> 
> >> Nacked-by: Hans Verkuil 
> > 
> > Can you then fix v4l2-compliance to stop testing colorspace against 0xff ?
> 
> For now I can simply relax this test for subdevs with sources and sinks.

You also need to relax it for video nodes with MC drivers, as the DMA engines 
don't care about colorspaces.

>  +
> >>> 
> >>> Casting to u32 has the added benefit that the colorspace expression is
> >>> evaluated once only, I like that.
> >>> 
> >>> Reviewed-by: Laurent 

Re: [PATCH v2] videodev2.h: add helper to validate colorspace

[Hans Verkuil]

On 15/02/18 12:08, Laurent Pinchart wrote:
> Hi Hans,
> 
> On Thursday, 15 February 2018 12:57:44 EET Hans Verkuil wrote:
>> On 14/02/18 16:16, Laurent Pinchart wrote:
>>> On Wednesday, 14 February 2018 12:36:43 EET Niklas Söderlund wrote:
 There is no way for drivers to validate a colorspace value, which could
 be provided by user-space by VIDIOC_S_FMT for example. Add a helper to
 validate that the colorspace value is part of enum v4l2_colorspace.

 Signed-off-by: Niklas Söderlund 
 ---

  include/uapi/linux/videodev2.h | 4 
  1 file changed, 4 insertions(+)

 Hi,

 I hope this is the correct header to add this helper to. I think it's
 since if it's in uapi not only can v4l2 drivers use it but tools like
 v4l-compliance gets access to it and can be updated to use this instead
 of the hard-coded check of just < 0xff as it was last time I checked.

 * Changes since v1
 - Cast colorspace to u32 as suggested by Sakari and only check the upper

   boundary to address a potential issue brought up by Laurent if the
   
   data type tested is u32 which is not uncommon:
 enum.c:30:16: warning: comparison of unsigned expression >= 0 is
 always

 true [-Wtype-limits]

   return V4L2_COLORSPACE_IS_VALID(colorspace);

 diff --git a/include/uapi/linux/videodev2.h
 b/include/uapi/linux/videodev2.h index
 9827189651801e12..1f27c0f4187cbded 100644
 --- a/include/uapi/linux/videodev2.h
 +++ b/include/uapi/linux/videodev2.h
 @@ -238,6 +238,10 @@ enum v4l2_colorspace {

V4L2_COLORSPACE_DCI_P3= 12,
  
  };

 +/* Determine if a colorspace is defined in enum v4l2_colorspace */
 +#define V4L2_COLORSPACE_IS_VALID(colorspace)  \
 +  ((u32)(colorspace) <= V4L2_COLORSPACE_DCI_P3)
>>
>> Sorry, this won't work. Use __u32. u32 is only available in the kernel, not
>> in userspace and this is a public header.
> 
> Indeed, that I should have caught.
> 
>> I am not convinced about the usefulness of this check either. Drivers will
>> typically only support a subset of the available colorspaces, so they need
>> a switch to test for that.
> 
> Most MC drivers won't, as they don't care about colorspaces in most subdevs. 
> It's important for the colorspace to be propagated within subdevs, and 
> validated across the pipeline, but in most case, apart from the image source 
> subdev, other subdevs won't care. They should accept any valid colorspace 
> given to them and propagate it to their source pads unchanged (except of 
> course for subdevs that can change the colorspace, but that's the exception, 
> not the rule).

Right. So 'passthrough' subdevs should just copy this information from source
to sink, and only pure source or pure sink subdevs should validate these
fields. That makes sense.

> 
>> There is nothing wrong with userspace giving them an unknown colorspace:
>> either they will map anything they don't support to something that they DO
>> support, or they will return -EINVAL.
> 
> The former, not the latter. S_FMT should not return -EINVAL for unsupported 
> colorspace, the same way it doesn't return -EINVAL for unsupported pixel 
> formats.
> 
>> If memory serves the spec requires the first option, so anything unknown
>> will just be replaced.
>>
>> And anyway, this raises the question of why you do this for the colorspace
>> but not for all the other enums in the V4L2 API.
> 
> Because v4l2-compliance tries to set a colorspace > 0xff and expects that to 
> be replaced by a colorspace <= 0xff. That seems like a bogus check to me, 
> 0xff 
> is as random as it can get.

v4l2-compliance fills all fields with 0xff, then it checks after calling the
ioctl if all fields have been set to valid values.

But in this case it should ignore the colorspace-related fields for passthrough
subdevs. The only passthrough devices that should set colorspace are colorspace
converter devices. I'm not sure if we can reliably detect that.

> 
>> It all seems rather pointless to me.
>>
>> I won't accept this unless I see it being used in a driver in a useful way.
>>
>> So for now:
>>
>> Nacked-by: Hans Verkuil 
> 
> Can you then fix v4l2-compliance to stop testing colorspace against 0xff ?

For now I can simply relax this test for subdevs with sources and sinks.

Regards,

Hans

> 
 +
>>>
>>> Casting to u32 has the added benefit that the colorspace expression is
>>> evaluated once only, I like that.
>>>
>>> Reviewed-by: Laurent Pinchart 
>>>
  /*
   * Determine how COLORSPACE_DEFAULT should map to a proper colorspace.
   * This depends on whether this is a SDTV image (use SMPTE 170M), an
> 

Re: [GIT PULL FOR v4.17] rc changes

[Sean Young]

On Thu, Feb 15, 2018 at 09:16:18AM -0200, Mauro Carvalho Chehab wrote:
> Em Wed, 14 Feb 2018 21:32:07 +
> Sean Young  escreveu:
> 
> > Hi Mauro,
> > 
> > On Wed, Feb 14, 2018 at 04:44:48PM -0200, Mauro Carvalho Chehab wrote:
> > > Hi Sean,
> > > 
> > > Em Mon, 12 Feb 2018 20:03:18 +
> > > Sean Young  escreveu:
> > >   
> > > > Hi Mauro,
> > > > 
> > > > Just very minor changes this time (other stuff is not ready yet). I 
> > > > would
> > > > really appreciate if you could cast an extra critical eye on the commit 
> > > > "no need to check for transitions", just to be sure it is the right 
> > > > change.  
> > > 
> > > Did you send all patches in separate? This is important to allow us
> > > to comment on an specific issue inside a patch...  
> > 
> > All the patches were emailed to linux-media, some of them on the same day
> > as the pull request. Maybe I should wait longer. The patch below was sent
> > out on the 28th of January.
> > 
> > > >   media: rc: no need to check for transitions  
> 
> No need to wait longer. Yet, it seems that I lost the above patch, as I
> couldn't find anything on my email with the above subject.
> 
> Perhaps the e-mail got lost somehow on my inbox.

Actually, this is my bad. I changed the subject line of the commit after
sending it to the list, without resending it. I should have sent out a v2.

> > > I don't remember the exact reason for that, but, as far as I
> > > remember, on a few devices, a pulse (or space) event could be
> > > broken into two consecutive events of the same type, e. g.,
> > > a pulse with a 125 ms could be broken into two pulses, like
> > > one with 100 ms and the other with 25 ms.  
> > 
> > If that is the case, then the IR decoders could not deal with this anyway.
> > For example, the first state transition rc6 is:
> > 
> > if (!eq_margin(ev.duration, RC6_PREFIX_PULSE, RC6_UNIT))
> > 
> > So if ev.duration is not the complete duration, then decoding will fail;
> > I tried to explain in the commit message that if this was the case, then
> > decoding would not work so the check was unnecessary.
> > 
> > > That's said, I'm not sure if the current implementation are
> > > adding the timings for both pulses into a single one.  
> > 
> > That depends on whether the driver uses ir_raw_event_store() or
> > ir_raw_event_store_with_filter(). The latter exists precisely for this
> > reason.
> 
> OK.
> 
> > 
> > > For now, I'll keep this patch out of the merge.  
> > 
> > Ok. So in summary, I think:
> > 
> > 1. Any driver which produces consequentive pulse events is broken
> >and should be fixed;
> 
> Agreed.
> 
> > 2. The IR decoders cannot deal with consequentive pulses and the current
> >prev_ev code does not help with this (possibly in very special
> >cases).
> 
> Ok. Yet, maybe it would worth to produce a warning if this happen, and
> reset the state machine, as it would help to identify problems at
> the driver or at the hardware.

That's not a bad idea. I will look a this.

Thanks
Sean

Re: [GIT PULL FOR v4.17] rc changes

[Mauro Carvalho Chehab]

Em Wed, 14 Feb 2018 21:32:07 +
Sean Young  escreveu:

> Hi Mauro,
> 
> On Wed, Feb 14, 2018 at 04:44:48PM -0200, Mauro Carvalho Chehab wrote:
> > Hi Sean,
> > 
> > Em Mon, 12 Feb 2018 20:03:18 +
> > Sean Young  escreveu:
> >   
> > > Hi Mauro,
> > > 
> > > Just very minor changes this time (other stuff is not ready yet). I would
> > > really appreciate if you could cast an extra critical eye on the commit 
> > > "no need to check for transitions", just to be sure it is the right 
> > > change.  
> > 
> > Did you send all patches in separate? This is important to allow us
> > to comment on an specific issue inside a patch...  
> 
> All the patches were emailed to linux-media, some of them on the same day
> as the pull request. Maybe I should wait longer. The patch below was sent
> out on the 28th of January.
> 
> > >   media: rc: no need to check for transitions  

No need to wait longer. Yet, it seems that I lost the above patch, as I
couldn't find anything on my email with the above subject.

Perhaps the e-mail got lost somehow on my inbox.

> > 
> > I don't remember the exact reason for that, but, as far as I
> > remember, on a few devices, a pulse (or space) event could be
> > broken into two consecutive events of the same type, e. g.,
> > a pulse with a 125 ms could be broken into two pulses, like
> > one with 100 ms and the other with 25 ms.  
> 
> If that is the case, then the IR decoders could not deal with this anyway.
> For example, the first state transition rc6 is:
> 
>   if (!eq_margin(ev.duration, RC6_PREFIX_PULSE, RC6_UNIT))
> 
> So if ev.duration is not the complete duration, then decoding will fail;
> I tried to explain in the commit message that if this was the case, then
> decoding would not work so the check was unnecessary.
> 
> > That's said, I'm not sure if the current implementation are
> > adding the timings for both pulses into a single one.  
> 
> That depends on whether the driver uses ir_raw_event_store() or
> ir_raw_event_store_with_filter(). The latter exists precisely for this
> reason.

OK.

> 
> > For now, I'll keep this patch out of the merge.  
> 
> Ok. So in summary, I think:
> 
> 1. Any driver which produces consequentive pulse events is broken
>and should be fixed;

Agreed.

> 2. The IR decoders cannot deal with consequentive pulses and the current
>prev_ev code does not help with this (possibly in very special
>cases).

Ok. Yet, maybe it would worth to produce a warning if this happen, and
reset the state machine, as it would help to identify problems at
the driver or at the hardware.


Thanks,
Mauro

Re: [PATCH v2] videodev2.h: add helper to validate colorspace

[Laurent Pinchart]

Hi Hans,

On Thursday, 15 February 2018 12:57:44 EET Hans Verkuil wrote:
> On 14/02/18 16:16, Laurent Pinchart wrote:
> > On Wednesday, 14 February 2018 12:36:43 EET Niklas Söderlund wrote:
> >> There is no way for drivers to validate a colorspace value, which could
> >> be provided by user-space by VIDIOC_S_FMT for example. Add a helper to
> >> validate that the colorspace value is part of enum v4l2_colorspace.
> >> 
> >> Signed-off-by: Niklas Söderlund 
> >> ---
> >> 
> >>  include/uapi/linux/videodev2.h | 4 
> >>  1 file changed, 4 insertions(+)
> >> 
> >> Hi,
> >> 
> >> I hope this is the correct header to add this helper to. I think it's
> >> since if it's in uapi not only can v4l2 drivers use it but tools like
> >> v4l-compliance gets access to it and can be updated to use this instead
> >> of the hard-coded check of just < 0xff as it was last time I checked.
> >> 
> >> * Changes since v1
> >> - Cast colorspace to u32 as suggested by Sakari and only check the upper
> >> 
> >>   boundary to address a potential issue brought up by Laurent if the
> >>   
> >>   data type tested is u32 which is not uncommon:
> >> enum.c:30:16: warning: comparison of unsigned expression >= 0 is
> >> always
> >> 
> >> true [-Wtype-limits]
> >> 
> >>   return V4L2_COLORSPACE_IS_VALID(colorspace);
> >> 
> >> diff --git a/include/uapi/linux/videodev2.h
> >> b/include/uapi/linux/videodev2.h index
> >> 9827189651801e12..1f27c0f4187cbded 100644
> >> --- a/include/uapi/linux/videodev2.h
> >> +++ b/include/uapi/linux/videodev2.h
> >> @@ -238,6 +238,10 @@ enum v4l2_colorspace {
> >> 
> >>V4L2_COLORSPACE_DCI_P3= 12,
> >>  
> >>  };
> >> 
> >> +/* Determine if a colorspace is defined in enum v4l2_colorspace */
> >> +#define V4L2_COLORSPACE_IS_VALID(colorspace)  \
> >> +  ((u32)(colorspace) <= V4L2_COLORSPACE_DCI_P3)
> 
> Sorry, this won't work. Use __u32. u32 is only available in the kernel, not
> in userspace and this is a public header.

Indeed, that I should have caught.

> I am not convinced about the usefulness of this check either. Drivers will
> typically only support a subset of the available colorspaces, so they need
> a switch to test for that.

Most MC drivers won't, as they don't care about colorspaces in most subdevs. 
It's important for the colorspace to be propagated within subdevs, and 
validated across the pipeline, but in most case, apart from the image source 
subdev, other subdevs won't care. They should accept any valid colorspace 
given to them and propagate it to their source pads unchanged (except of 
course for subdevs that can change the colorspace, but that's the exception, 
not the rule).

> There is nothing wrong with userspace giving them an unknown colorspace:
> either they will map anything they don't support to something that they DO
> support, or they will return -EINVAL.

The former, not the latter. S_FMT should not return -EINVAL for unsupported 
colorspace, the same way it doesn't return -EINVAL for unsupported pixel 
formats.

> If memory serves the spec requires the first option, so anything unknown
> will just be replaced.
> 
> And anyway, this raises the question of why you do this for the colorspace
> but not for all the other enums in the V4L2 API.

Because v4l2-compliance tries to set a colorspace > 0xff and expects that to 
be replaced by a colorspace <= 0xff. That seems like a bogus check to me, 0xff 
is as random as it can get.

> It all seems rather pointless to me.
> 
> I won't accept this unless I see it being used in a driver in a useful way.
> 
> So for now:
> 
> Nacked-by: Hans Verkuil 

Can you then fix v4l2-compliance to stop testing colorspace against 0xff ?

> >> +
> > 
> > Casting to u32 has the added benefit that the colorspace expression is
> > evaluated once only, I like that.
> > 
> > Reviewed-by: Laurent Pinchart 
> > 
> >>  /*
> >>   * Determine how COLORSPACE_DEFAULT should map to a proper colorspace.
> >>   * This depends on whether this is a SDTV image (use SMPTE 170M), an

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2] videodev2.h: add helper to validate colorspace

[Hans Verkuil]

On 14/02/18 16:16, Laurent Pinchart wrote:
> Hi Niklas,
> 
> Thank you for the patch.
> 
> On Wednesday, 14 February 2018 12:36:43 EET Niklas Söderlund wrote:
>> There is no way for drivers to validate a colorspace value, which could
>> be provided by user-space by VIDIOC_S_FMT for example. Add a helper to
>> validate that the colorspace value is part of enum v4l2_colorspace.
>>
>> Signed-off-by: Niklas Söderlund 
>> ---
>>  include/uapi/linux/videodev2.h | 4 
>>  1 file changed, 4 insertions(+)
>>
>> Hi,
>>
>> I hope this is the correct header to add this helper to. I think it's
>> since if it's in uapi not only can v4l2 drivers use it but tools like
>> v4l-compliance gets access to it and can be updated to use this instead
>> of the hard-coded check of just < 0xff as it was last time I checked.
>>
>> * Changes since v1
>> - Cast colorspace to u32 as suggested by Sakari and only check the upper
>>   boundary to address a potential issue brought up by Laurent if the
>>   data type tested is u32 which is not uncommon:
>>
>> enum.c:30:16: warning: comparison of unsigned expression >= 0 is always
>> true [-Wtype-limits]
>>   return V4L2_COLORSPACE_IS_VALID(colorspace);
>>
>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>> index 9827189651801e12..1f27c0f4187cbded 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -238,6 +238,10 @@ enum v4l2_colorspace {
>>  V4L2_COLORSPACE_DCI_P3= 12,
>>  };
>>
>> +/* Determine if a colorspace is defined in enum v4l2_colorspace */
>> +#define V4L2_COLORSPACE_IS_VALID(colorspace)\
>> +((u32)(colorspace) <= V4L2_COLORSPACE_DCI_P3)

Sorry, this won't work. Use __u32. u32 is only available in the kernel, not
in userspace and this is a public header.

I am not convinced about the usefulness of this check either. Drivers will
typically only support a subset of the available colorspaces, so they need
a switch to test for that. There is nothing wrong with userspace giving them
an unknown colorspace: either they will map anything they don't support to
something that they DO support, or they will return -EINVAL. If memory serves
the spec requires the first option, so anything unknown will just be replaced.

And anyway, this raises the question of why you do this for the colorspace
but not for all the other enums in the V4L2 API.

It all seems rather pointless to me.

I won't accept this unless I see it being used in a driver in a useful way.

So for now:

Nacked-by: Hans Verkuil 

Sorry,

Hans

>> +
> 
> Casting to u32 has the added benefit that the colorspace expression is 
> evaluated once only, I like that.
> 
> Reviewed-by: Laurent Pinchart 
> 
>>  /*
>>   * Determine how COLORSPACE_DEFAULT should map to a proper colorspace.
>>   * This depends on whether this is a SDTV image (use SMPTE 170M), an
> 
> 

Re: [GIT PULL FOR v4.17] rc changes

[Sean Young]

On Wed, Feb 14, 2018 at 04:49:08PM -0200, Mauro Carvalho Chehab wrote:
> Em Mon, 12 Feb 2018 20:03:18 +
> Sean Young  escreveu:
> 
> >   media: rc: unnecessary use of do_div
> > 
> > From c52920c524d96db55b9b82440504a7ec40df0b32 Mon Sep 17 00:00:00 2001
> > From: Sean Young 
> > Date: Sun, 11 Feb 2018 17:23:14 +
> > Subject: media: rc: unnecessary use of do_div
> > Cc: Linux Media Mailing List ,
> > Mauro Carvalho Chehab 
> > 
> > No need to use do_div() when the remainder is thrown away.
> 
> That's not true at all! We need do_div() every time we're dividing an u64
> number, as otherwise, it will cause link errors when built with 32 bits.

I completely missed that. Thank you!


Sean

Re: [PATCH v7 2/2] v4l: cadence: Add Cadence MIPI-CSI2 RX driver

[Maxime Ripard]

On Wed, Feb 14, 2018 at 05:03:26PM +0200, Laurent Pinchart wrote:
> On Wednesday, 14 February 2018 15:19:33 EET Maxime Ripard wrote:
> > On Thu, Feb 08, 2018 at 08:17:19PM +0200, Laurent Pinchart wrote:
> > >> +/*
> > >> + * Create a static mapping between the CSI virtual channels
> > >> + * and the output stream.
> > >> + *
> > >> + * This should be enhanced, but v4l2 lacks the support for
> > >> + * changing that mapping dynamically.
> > >> + *
> > >> + * We also cannot enable and disable independant streams here,
> > >> + * hence the reference counting.
> > >> + */
> > > 
> > > If you start all streams in one go, will s_stream(1) be called multiple
> > > times ? If not, you could possibly skip the whole reference counting and
> > > avoid locking.
> > 
> > I guess that while we should expect the CSI-2 bus to be always
> > enabled, the downstream camera interface could be shutdown
> > independently, so I guess s_stream would be called each time one is
> > brought up or brought down?
> 
> That's the idea. However, we don't have support for multiplexed streams in 
> mainline yet, so there's no way it can be implemented today in your driver.

Ok, but we definitely plan on supporting that soon, so I guess that
wouldn't too much of a burden to keep it there.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com


signature.asc
Description: PGP signature

[PATCH v2] media: imx: capture: reformat line to 80 chars or less

[Parthiban Nallathambi]

This is a cleanup patch to fix line length issue found
by checkpatch.pl script.

In this patch, line 144 have been wrapped.

Signed-off-by: Parthiban Nallathambi 
---
Changes in v2:
- Changed commit message

 drivers/staging/media/imx/imx-media-capture.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/imx/imx-media-capture.c 
b/drivers/staging/media/imx/imx-media-capture.c
index 576bdc7e9c42..0ccabe04b0e1 100644
--- a/drivers/staging/media/imx/imx-media-capture.c
+++ b/drivers/staging/media/imx/imx-media-capture.c
@@ -141,7 +141,8 @@ static int capture_enum_frameintervals(struct file *file, 
void *fh,
 
fie.code = cc->codes[0];
 
-   ret = v4l2_subdev_call(priv->src_sd, pad, enum_frame_interval, NULL, 
);
+   ret = v4l2_subdev_call(priv->src_sd, pad, enum_frame_interval,
+  NULL, );
if (ret)
return ret;
 
-- 
2.14.3