[PATCH v2] [media] v4l2: add V4L2_CAP_IO_MC

[Helen Koike]

Add V4L2_CAP_IO_MC to be used in struct v4l2_capability to indicate that
input and output are controlled by the Media Controller instead of V4L2
API.
When this flag is set, ioctls for get, set and enum input and outputs
are automatically enabled and programmed to call helper function.

Signed-off-by: Helen Koike 

---

Changes in v2::
- replace the type by capability
- erase V4L2_INPUT_TYPE_DEFAULT
- also consider output
- plug helpers in the ops automatically so drivers doesn't need
to set it by hand
- update docs
- commit message and title
---
 Documentation/media/uapi/v4l/vidioc-querycap.rst |  3 +
 Documentation/media/videodev2.h.rst.exceptions   |  1 +
 drivers/media/v4l2-core/v4l2-dev.c   | 35 +++--
 drivers/media/v4l2-core/v4l2-ioctl.c | 91 ++--
 include/uapi/linux/videodev2.h   |  2 +
 5 files changed, 120 insertions(+), 12 deletions(-)

diff --git a/Documentation/media/uapi/v4l/vidioc-querycap.rst 
b/Documentation/media/uapi/v4l/vidioc-querycap.rst
index 12e0d9a..2bd1223 100644
--- a/Documentation/media/uapi/v4l/vidioc-querycap.rst
+++ b/Documentation/media/uapi/v4l/vidioc-querycap.rst
@@ -252,6 +252,9 @@ specification the ioctl returns an ``EINVAL`` error code.
 * - ``V4L2_CAP_TOUCH``
   - 0x1000
   - This is a touch device.
+* - ``V4L2_CAP_IO_MC``
+  - 0x2000
+  - This device has its inputs and outputs controller by the Media 
Controller
 * - ``V4L2_CAP_DEVICE_CAPS``
   - 0x8000
   - The driver fills the ``device_caps`` field. This capability can
diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index a5cb0a8..0b48cd0 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -159,6 +159,7 @@ replace define V4L2_CAP_ASYNCIO device-capabilities
 replace define V4L2_CAP_STREAMING device-capabilities
 replace define V4L2_CAP_DEVICE_CAPS device-capabilities
 replace define V4L2_CAP_TOUCH device-capabilities
+replace define V4L2_CAP_IO_MC device-capabilities
 
 # V4L2 pix flags
 replace define V4L2_PIX_FMT_PRIV_MAGIC :c:type:`v4l2_pix_format`
diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
b/drivers/media/v4l2-core/v4l2-dev.c
index c647ba6..0f272fe 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -688,22 +688,34 @@ static void determine_valid_ioctls(struct video_device 
*vdev)
SET_VALID_IOCTL(ops, VIDIOC_G_STD, vidioc_g_std);
if (is_rx) {
SET_VALID_IOCTL(ops, VIDIOC_QUERYSTD, vidioc_querystd);
-   SET_VALID_IOCTL(ops, VIDIOC_ENUMINPUT, 
vidioc_enum_input);
-   SET_VALID_IOCTL(ops, VIDIOC_G_INPUT, vidioc_g_input);
-   SET_VALID_IOCTL(ops, VIDIOC_S_INPUT, vidioc_s_input);
SET_VALID_IOCTL(ops, VIDIOC_ENUMAUDIO, 
vidioc_enumaudio);
SET_VALID_IOCTL(ops, VIDIOC_G_AUDIO, vidioc_g_audio);
SET_VALID_IOCTL(ops, VIDIOC_S_AUDIO, vidioc_s_audio);
SET_VALID_IOCTL(ops, VIDIOC_QUERY_DV_TIMINGS, 
vidioc_query_dv_timings);
SET_VALID_IOCTL(ops, VIDIOC_S_EDID, vidioc_s_edid);
+   if (vdev->device_caps & V4L2_CAP_IO_MC) {
+   set_bit(_IOC_NR(VIDIOC_ENUMINPUT), 
valid_ioctls);
+   set_bit(_IOC_NR(VIDIOC_G_INPUT), valid_ioctls);
+   set_bit(_IOC_NR(VIDIOC_S_INPUT), valid_ioctls);
+   } else {
+   SET_VALID_IOCTL(ops, VIDIOC_ENUMINPUT, 
vidioc_enum_input);
+   SET_VALID_IOCTL(ops, VIDIOC_G_INPUT, 
vidioc_g_input);
+   SET_VALID_IOCTL(ops, VIDIOC_S_INPUT, 
vidioc_s_input);
+   }
}
if (is_tx) {
-   SET_VALID_IOCTL(ops, VIDIOC_ENUMOUTPUT, 
vidioc_enum_output);
-   SET_VALID_IOCTL(ops, VIDIOC_G_OUTPUT, vidioc_g_output);
-   SET_VALID_IOCTL(ops, VIDIOC_S_OUTPUT, vidioc_s_output);
SET_VALID_IOCTL(ops, VIDIOC_ENUMAUDOUT, 
vidioc_enumaudout);
SET_VALID_IOCTL(ops, VIDIOC_G_AUDOUT, vidioc_g_audout);
SET_VALID_IOCTL(ops, VIDIOC_S_AUDOUT, vidioc_s_audout);
+   if (vdev->device_caps & V4L2_CAP_IO_MC) {
+   set_bit(_IOC_NR(VIDIOC_ENUMOUTPUT), 
valid_ioctls);
+   set_bit(_IOC_NR(VIDIOC_G_OUTPUT), valid_ioctls);
+   set_bit(_IOC_NR(VIDIOC_S_OUTPUT), valid_ioctls);
+   } else {
+   SET_VALID_IOCTL(ops, VIDIOC_ENUMOUTPUT, 

Re: [PATCH v2 0/15] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator

[Takiguchi, Yasunari]

Dear Mauro

Thanks for your kind review during your busy schedule.

I will confirm with your findings and discuss about them
(how to change our codes) in our team.

Regards & Thanks
Takiguchi

On 2017/06/13 23:38, Mauro Carvalho Chehab wrote:
> Hi Takiguchi-san,
> 
> Em Thu, 25 May 2017 15:15:39 +0900
> "Takiguchi, Yasunari"  escreveu:
> 
>> Hi, all
>>
>> I sent the patch series of Sony CXD2880 DVB-T2/T tuner + demodulator driver 
>> on Apr/14.
>> Are there any comments, advices and review results for them?
> 
> Usually, reviewing drivers takes more time, as one needs to reserve a
> long period of time for reviewing. Sorry for the delay.
> 
>> I'd like to get better understanding of current review status for our codes.
> 
> Just sent today a review. There are some things that need to be
> changed in order to get it into a better shape and make it easier
> to review. In particular, it should be using some Kernel internal APIs,
> instead of coming with re-implementation of existing core code. That's fine. 
> It is very unusual that the first contributions from a new Kernel
> developer to gets everything the way as it is expected mainstream ;-)
> 
> One thing that come into my mind, besides what was already commented,
> is that it seems you added an abstraction layer. We don't like such
> layers very much, as it makes harder to understand the driver, usually
> for very little benefit.
> 
> On this first review, I didn't actually try to understand what's
> going on there. As the driver doesn't contain any comments inside,
> it makes harder to understand why some things were coded using
> such approach.
> 
> Thanks,
> Mauro

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

[Tomasz Figa]

On Wed, Jun 14, 2017 at 11:32 AM, Zhi, Yong  wrote:
> Hi, Tomasz,
>
> Thanks for your code review, still need more time to study and test the 
> solution for the rest of comments, going forward, I will respond to your 
> review first before submitting new version.

Just to clarify, my note was not about addressing all the comments
instantly, but rather about not leaving any unaddressed comments in
newer patch sets (unless agreed with the reviewers to do that). The
default assumption is that next patch set has all comments from
previous one addressed. If that's not true, it's going to confuse the
reviewers and make them put additional effort into comparing the code
manually.

I'd say it's just better to reply on the list that you need a bit more
time to address the comments, rather than sending a half-done next
patch set. That's just my opinion, though.

Best regards,
Tomasz

>
> Thanks,
>
> Yong
>
>> -Original Message-
>> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
>> ow...@vger.kernel.org] On Behalf Of Tomasz Figa
>> Sent: Tuesday, June 13, 2017 5:01 PM
>> To: Zhi, Yong 
>> Cc: linux-media@vger.kernel.org; Sakari Ailus ;
>> Zheng, Jian Xu ; Mani, Rajmohan
>> ; Toivonen, Tuukka
>> ; Yang, Hyungwoo
>> ; Mohandass, Divagar
>> 
>> Subject: Re: [PATCH 3/3] intel-ipu3: cio2: Add new MIPI-CSI2 driver
>>
>> Hi Yong,
>>
>> On Wed, Jun 14, 2017 at 5:17 AM, Yong Zhi  wrote:
>> > This patch adds CIO2 CSI-2 device driver for Intel's IPU3 camera
>> > sub-system support.
>> >
>> > Signed-off-by: Yong Zhi 
>> > ---
>> >  drivers/media/pci/Kconfig|2 +
>> >  drivers/media/pci/Makefile   |3 +-
>> >  drivers/media/pci/intel/Makefile |5 +
>> >  drivers/media/pci/intel/ipu3/Kconfig |   17 +
>> >  drivers/media/pci/intel/ipu3/Makefile|1 +
>> >  drivers/media/pci/intel/ipu3/ipu3-cio2.c | 1779
>> > ++
>> > drivers/media/pci/intel/ipu3/ipu3-cio2.h |  434 
>> >  7 files changed, 2240 insertions(+), 1 deletion(-)  create mode
>> > 100644 drivers/media/pci/intel/Makefile  create mode 100644
>> > drivers/media/pci/intel/ipu3/Kconfig
>> >  create mode 100644 drivers/media/pci/intel/ipu3/Makefile
>> >  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.c
>> >  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.h
>> >
>>
>> I quickly checked the code and it doesn't seem to have most of my comments
>> from v2 addressed. It's not a very good practice to send new version without
>> addressing or at least replying to all the comments - it's the best way to 
>> lose
>> track of necessary changes. Please make sure that all the comments are
>> taken care of.
>>
>> Best regards,
>> Tomasz

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

[Zhi, Yong]

Hi, Tomasz,

Thanks for your code review, still need more time to study and test the 
solution for the rest of comments, going forward, I will respond to your review 
first before submitting new version.

Thanks,

Yong  

> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Tomasz Figa
> Sent: Tuesday, June 13, 2017 5:01 PM
> To: Zhi, Yong 
> Cc: linux-media@vger.kernel.org; Sakari Ailus ;
> Zheng, Jian Xu ; Mani, Rajmohan
> ; Toivonen, Tuukka
> ; Yang, Hyungwoo
> ; Mohandass, Divagar
> 
> Subject: Re: [PATCH 3/3] intel-ipu3: cio2: Add new MIPI-CSI2 driver
> 
> Hi Yong,
> 
> On Wed, Jun 14, 2017 at 5:17 AM, Yong Zhi  wrote:
> > This patch adds CIO2 CSI-2 device driver for Intel's IPU3 camera
> > sub-system support.
> >
> > Signed-off-by: Yong Zhi 
> > ---
> >  drivers/media/pci/Kconfig|2 +
> >  drivers/media/pci/Makefile   |3 +-
> >  drivers/media/pci/intel/Makefile |5 +
> >  drivers/media/pci/intel/ipu3/Kconfig |   17 +
> >  drivers/media/pci/intel/ipu3/Makefile|1 +
> >  drivers/media/pci/intel/ipu3/ipu3-cio2.c | 1779
> > ++
> > drivers/media/pci/intel/ipu3/ipu3-cio2.h |  434 
> >  7 files changed, 2240 insertions(+), 1 deletion(-)  create mode
> > 100644 drivers/media/pci/intel/Makefile  create mode 100644
> > drivers/media/pci/intel/ipu3/Kconfig
> >  create mode 100644 drivers/media/pci/intel/ipu3/Makefile
> >  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.c
> >  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.h
> >
> 
> I quickly checked the code and it doesn't seem to have most of my comments
> from v2 addressed. It's not a very good practice to send new version without
> addressing or at least replying to all the comments - it's the best way to 
> lose
> track of necessary changes. Please make sure that all the comments are
> taken care of.
> 
> Best regards,
> Tomasz

[PATCH v3 1/1] i2c: Add Omnivision OV5670 5M sensor support

[chiranjeevi . rapolu]

From: Chiranjeevi Rapolu 

Provides single source pad with up to 2592x1944 pixels at 10-bit raw
bayer format over MIPI CSI2 two lanes at 640Mbps/lane.
The driver supports following features:
- up to  30fps at 5M pixels
- manual exposure
- digital/analog gain
- V-blank/H-blank
- test pattern
- media controller
- runtime pm

Signed-off-by: Chiranjeevi Rapolu 
---
 drivers/media/i2c/Kconfig  |   12 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov5670.c | 2591 
 3 files changed, 2604 insertions(+)
 create mode 100644 drivers/media/i2c/ov5670.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index c380e24..55e1877 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -573,6 +573,18 @@ config VIDEO_OV5647
  To compile this driver as a module, choose M here: the
  module will be called ov5647.
 
+config VIDEO_OV5670
+   tristate "OmniVision OV5670 sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   select V4L2_FWNODE
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV5670 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov5670.
+
 config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 62323ec..de95651 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
 obj-$(CONFIG_VIDEO_OV2640) += ov2640.o
 obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
 obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
+obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
diff --git a/drivers/media/i2c/ov5670.c b/drivers/media/i2c/ov5670.c
new file mode 100644
index 000..64bb858
--- /dev/null
+++ b/drivers/media/i2c/ov5670.c
@@ -0,0 +1,2591 @@
+/*
+ * Copyright (c) 2017 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define OV5670_REG_CHIP_ID 0x300a
+#define OV5670_CHIP_ID 0x005670
+
+#define OV5670_REG_MODE_SELECT 0x0100
+#define OV5670_MODE_STANDBY0x00
+#define OV5670_MODE_STREAMING  0x01
+
+#define OV5670_REG_SOFTWARE_RST0x0103
+#define OV5670_SOFTWARE_RST0x01
+
+/* vertical-timings from sensor */
+#define OV5670_REG_VTS 0x380e
+#define OV5670_VTS_30FPS   0x0808 /* default for 30 fps */
+#define OV5670_VTS_MAX 0x7fff
+#define OV5670_VBLANK_MIN  56
+
+/* horizontal-timings from sensor */
+#define OV5670_MAX_PPL 3408/* Maximum pixels per line */
+
+/* Exposure controls from sensor */
+#define OV5670_REG_EXPOSURE0x3500
+#defineOV5670_EXPOSURE_MIN 0
+#defineOV5670_EXPOSURE_MAX 1048575
+#defineOV5670_EXPOSURE_STEP1
+#defineOV5670_EXPOSURE_DEFAULT 31872
+
+/* Analog gain controls from sensor */
+#define OV5670_REG_ANALOG_GAIN 0x3508
+#defineANALOG_GAIN_MIN 0
+#defineANALOG_GAIN_MAX 8191
+#defineANALOG_GAIN_STEP1
+#defineANALOG_GAIN_DEFAULT 128
+
+/* Digital gain controls from sensor */
+#define OV5670_REG_R_DGTL_GAIN 0x5032
+#define OV5670_REG_G_DGTL_GAIN 0x5034
+#define OV5670_REG_B_DGTL_GAIN 0x5036
+#define OV5670_DGTL_GAIN_MIN   0
+#define OV5670_DGTL_GAIN_MAX   4095
+#define OV5670_DGTL_GAIN_STEP  1
+#define OV5670_DGTL_GAIN_DEFAULT   1024
+
+/* Test Pattern Control */
+#define OV5670_REG_TEST_PATTERN0x4303
+#define OV5670_TEST_PATTERN_ENABLE BIT(3)
+#define OV5670_REG_TEST_PATTERN_CTRL   0x4320
+
+#define OV5670_REG_VALUE_08BIT 1
+#define OV5670_REG_VALUE_16BIT 2
+#define OV5670_REG_VALUE_24BIT 3
+
+struct ov5670_reg {
+   u16 address;
+   u8 val;
+};
+
+struct ov5670_reg_list {
+   u32 num_of_regs;
+   const struct ov5670_reg *regs;
+};
+
+struct ov5670_link_freq_config {
+   u32 pixel_rate;
+   const struct ov5670_reg_list reg_list;
+};
+
+struct ov5670_mode {
+ 

Re: [GIT PULL FOR v4.13] Add video-mux, ov5640 and i.MX media staging driver

[Steve Longerbeam]

On 06/13/2017 12:55 PM, Hans Verkuil wrote:
It's been a long road, but the i.MX6 platform now has a proper driver. 
There

are a few relatively minor issues remaining (see the TODO file) before it
can be moved out of staging.

I want to thank Steve and Philipp for their hard work!


Your welcome! :)

But the Freescale ARM DTS patches are still pending, this driver is not
operational until those patches are merged. What is holding that up?
They implement the associated bindings docs which have been Acked.

Steve




Regards,

 Hans

The following changes since commit 
47f910f0e0deb880c2114811f7ea1ec115a19ee4:


   [media] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev 
(2017-06-08 16:55:25 -0300)


are available in the git repository at:

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

for you to fetch changes up to 5f19bcc69f4e351ab6700214e4f8f3d71807d4e2:

   MAINTAINERS: add entry for Freescale i.MX media driver (2017-06-13 
21:48:28 +0200)



Marek Vasut (1):
   media: imx: Drop warning upon multiple S_STREAM disable calls

Philipp Zabel (7):
   dt-bindings: Add bindings for video-multiplexer device
   add mux and video interface bridge entity functions
   platform: add video-multiplexer subdevice driver
   MAINTAINERS: add maintainer entry for video multiplexer v4l2 
subdevice driver

   media: imx: csi: increase burst size for YUV formats
   media: imx: csi: add frame skipping support
   media: imx: csi: add sink selection rectangles

Russell King (3):
   media: imx: csi: add support for bayer formats
   media: imx: csi: add frame size/interval enumeration
   media: imx: capture: add frame sizes/interval enumeration

Steve Longerbeam (14):
   dt/bindings: Add bindings for OV5640
   add Omnivision OV5640 sensor driver
   MAINTAINERS: add entry for OV5640 sensor driver
   dt-bindings: Add bindings for i.MX media driver
   media: Add userspace header file for i.MX
   media: Add i.MX media core driver
   media: imx: Add a TODO file
   media: imx: Add Capture Device Interface
   media: imx: Add CSI subdev driver
   media: imx: Add VDIC subdev driver
   media: imx: Add IC subdev drivers
   media: imx: Add MIPI CSI-2 Receiver subdev driver
   media: imx: set and propagate default field, colorimetry
   MAINTAINERS: add entry for Freescale i.MX media driver

  Documentation/devicetree/bindings/media/i2c/ov5640.txt |   45 +
  Documentation/devicetree/bindings/media/imx.txt|   53 +
  Documentation/devicetree/bindings/media/video-mux.txt  |   60 ++
  Documentation/media/uapi/mediactl/media-types.rst  |   21 +
  Documentation/media/v4l-drivers/imx.rst|  614 


  MAINTAINERS|   25 +
  drivers/media/i2c/Kconfig  |   10 +
  drivers/media/i2c/Makefile |1 +
  drivers/media/i2c/ov5640.c | 2344 


  drivers/media/platform/Kconfig |7 +
  drivers/media/platform/Makefile|2 +
  drivers/media/platform/video-mux.c |  334 +++
  drivers/staging/media/Kconfig  |2 +
  drivers/staging/media/Makefile |1 +
  drivers/staging/media/imx/Kconfig  |   21 +
  drivers/staging/media/imx/Makefile |   12 +
  drivers/staging/media/imx/TODO |   23 +
  drivers/staging/media/imx/imx-ic-common.c  |  113 +++
  drivers/staging/media/imx/imx-ic-prp.c |  518 ++
  drivers/staging/media/imx/imx-ic-prpencvf.c| 1309 
+

  drivers/staging/media/imx/imx-ic.h |   38 +
  drivers/staging/media/imx/imx-media-capture.c  |  775 
+++
  drivers/staging/media/imx/imx-media-csi.c  | 1817 
++
  drivers/staging/media/imx/imx-media-dev.c  |  667 
+

  drivers/staging/media/imx/imx-media-fim.c  |  494 ++
  drivers/staging/media/imx/imx-media-internal-sd.c  |  349 +++
  drivers/staging/media/imx/imx-media-of.c   |  270 +
  drivers/staging/media/imx/imx-media-utils.c|  896 
+
  drivers/staging/media/imx/imx-media-vdic.c | 1009 
+++

  drivers/staging/media/imx/imx-media.h  |  325 ++
  drivers/staging/media/imx/imx6-mipi-csi2.c |  698 
+

  include/linux/imx-media.h  |   29 +
  include/media/imx.h|   15 +
  include/uapi/linux/media.h |6 +
  

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

[Tomasz Figa]

Hi Yong,

On Wed, Jun 14, 2017 at 5:17 AM, Yong Zhi  wrote:
> This patch adds CIO2 CSI-2 device driver for
> Intel's IPU3 camera sub-system support.
>
> Signed-off-by: Yong Zhi 
> ---
>  drivers/media/pci/Kconfig|2 +
>  drivers/media/pci/Makefile   |3 +-
>  drivers/media/pci/intel/Makefile |5 +
>  drivers/media/pci/intel/ipu3/Kconfig |   17 +
>  drivers/media/pci/intel/ipu3/Makefile|1 +
>  drivers/media/pci/intel/ipu3/ipu3-cio2.c | 1779 
> ++
>  drivers/media/pci/intel/ipu3/ipu3-cio2.h |  434 
>  7 files changed, 2240 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/pci/intel/Makefile
>  create mode 100644 drivers/media/pci/intel/ipu3/Kconfig
>  create mode 100644 drivers/media/pci/intel/ipu3/Makefile
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.c
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.h
>

I quickly checked the code and it doesn't seem to have most of my
comments from v2 addressed. It's not a very good practice to send new
version without addressing or at least replying to all the comments -
it's the best way to lose track of necessary changes. Please make sure
that all the comments are taken care of.

Best regards,
Tomasz

RE: [PATCH v10 1/1] [media] i2c: add support for OV13858 sensor

[Yang, Hyungwoo]

Hi Sakari,

I reverted v10 and just added a comparison to see if clock-frequency is 19.2Mhz
https://patchwork.kernel.org/patch/9784827/ 

-Hyungwoo
 
-Original Message-
> From: Sakari Ailus [mailto:sakari.ai...@iki.fi] 
> Sent: Tuesday, June 13, 2017 8:29 AM
> To: Yang, Hyungwoo 
> Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com; Zheng, Jian Xu 
> ; tf...@chromium.org; Hsu, Cedric 
> 
> Subject: Re: [PATCH v10 1/1] [media] i2c: add support for OV13858 sensor
> 
> Hi Hyungwoo,
> 
> On Tue, Jun 13, 2017 at 02:29:25PM +, Yang, Hyungwoo wrote:
> > 
> > 
> > Here is the _DSD for 19.2Mhz
> 
> If you attached it, the list server most likely removed the attachment.
> Could you send it again in-line?
> 
> > 
> > 
> > 
> > 
> > 
> > i've inlined my comments.
> > 
> > 
> > 
> > -Original Message-
> > > From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
> > > Sent: Tuesday, June 13, 2017 3:18 AM
> > > To: Yang, Hyungwoo 
> > > Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com; 
> > > Zheng, Jian Xu ; tf...@chromium.org; Hsu, 
> > > Cedric 
> > > Subject: Re: [PATCH v10 1/1] [media] i2c: add support for OV13858 
> > > sensor
> > > 
> > > Hi Hyungwoo,
> > > 
> > > On Mon, Jun 12, 2017 at 05:56:00PM -0700, Hyungwoo Yang wrote:
> ...
> > > > +   if (ret)
> > > > +   return ret;
> > > > +   ov13858->num_of_skip_frames = val;
> > > > +
> > > > +   device_for_each_child_node(dev, child) {
> > > > +   if (!fwnode_property_present(child, "link"))
> > > > +   continue;
> > > 
> > > You shouldn't need these here.
> > > 
> > 
> > ?? just get child and see if the expected property is found ?
> > Acked
> 
> Your child nodes shouldn't look like that, nor an individual driver should 
> need to be directly interested in them.
> 
> Please see Documentation/acpi/dsd/graph.txt .
> 
> > > > +   if (ret) {
> > > > +   dev_err(dev, "link-rate error : %d\n",  ret);
> > > > +   goto error;
> > > > +   }
> > > > +   link_freq_menu_items[freq_id] = val;
> > > > +
> > > > +   freq_cfg = _freq_configs[freq_id];
> > > > +   ret = fwnode_property_read_u32(fwn_freq, "pixel-rate", 
> > > > );
> > > 
> > > This is something a sensor driver needs to know. It may not be present in 
> > > device firmware.
> > > 
> > 
> > Real frequency of the link can be different from input clock frequency 
> > so pixel reate which is dependent on link frequency should be here.
> 
> The pixel rate does depend on the link frequency, but you can either 
> calculate it in the driver OR make it specific your sensor configuration.
> 
> > 
> > > > +   if (ret) {
> > > > +   dev_err(dev, "pixel-rate error : %d\n",  ret);
> > > > +   goto error;
> > > > +   }
> > > > +   freq_cfg->pixel_rate = val;
> > > > +
> > > > +   num_of_values = fwnode_property_read_u32_array(fwn_freq,
> > > > +  
> > > > "pll-regs",
> > > 
> > > This is something that could go to device firmware but I don't really see 
> > > a reason for that at the moment. Can this continue to be a part of the 
> > > driver for now?
> > > 
> > > Could you also check that the external clock frequency matches with what 
> > > your register lists assume? The property should be called 
> > > "clock-frequency"
> > > and it's a u32.
> > 
> > Are you saying, for now, let's remove pll reg/value pairs from _DSD  
> > and just support only one input clock frequency ?
> 
> That would help getting the driver merged during this merge window. It's 
> always possible to add support for different configurations later on.
> 
> --
> Kind regards,
> 
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi   XMPP: sai...@retiisi.org.uk
>

[PATCH RESEND v11 1/1] [media] i2c: add support for OV13858 sensor

[Hyungwoo Yang]

This patch adds driver for Omnivision's ov13858
sensor, the driver supports following features:

- manual exposure/gain(analog and digital) control support
- two link frequencies
- VBLANK/HBLANK support
- test pattern support
- media controller support
- runtime pm support
- supported resolutions
  + 4224x3136 at 30FPS
  + 2112x1568 at 30FPS(default) and 60FPS
  + 2112x1188 at 30FPS(default) and 60FPS
  + 1056x784 at 30FPS(default) and 60FPS

Signed-off-by: Hyungwoo Yang 
---
 drivers/media/i2c/Kconfig   |8 +
 drivers/media/i2c/Makefile  |1 +
 drivers/media/i2c/ov13858.c | 1816 +++
 3 files changed, 1825 insertions(+)
 create mode 100644 drivers/media/i2c/ov13858.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index c380e24..26a9a3c 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -600,6 +600,14 @@ config VIDEO_OV9650
  This is a V4L2 sensor-level driver for the Omnivision
  OV9650 and OV9652 camera sensors.
 
+config VIDEO_OV13858
+   tristate "OmniVision OV13858 sensor support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV13858 camera.
+
 config VIDEO_VS6624
tristate "ST VS6624 sensor support"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 62323ec..3f4dc02 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
+obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
 obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
 obj-$(CONFIG_VIDEO_MT9M111) += mt9m111.o
 obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c
new file mode 100644
index 000..c826644
--- /dev/null
+++ b/drivers/media/i2c/ov13858.c
@@ -0,0 +1,1816 @@
+/*
+ * Copyright (c) 2017 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define OV13858_REG_VALUE_08BIT1
+#define OV13858_REG_VALUE_16BIT2
+#define OV13858_REG_VALUE_24BIT3
+
+#define OV13858_REG_MODE_SELECT0x0100
+#define OV13858_MODE_STANDBY   0x00
+#define OV13858_MODE_STREAMING 0x01
+
+#define OV13858_REG_SOFTWARE_RST   0x0103
+#define OV13858_SOFTWARE_RST   0x01
+
+/* PLL1 generates PCLK and MIPI_PHY_CLK */
+#define OV13858_REG_PLL1_CTRL_00x0300
+#define OV13858_REG_PLL1_CTRL_10x0301
+#define OV13858_REG_PLL1_CTRL_20x0302
+#define OV13858_REG_PLL1_CTRL_30x0303
+#define OV13858_REG_PLL1_CTRL_40x0304
+#define OV13858_REG_PLL1_CTRL_50x0305
+
+/* PLL2 generates DAC_CLK, SCLK and SRAM_CLK */
+#define OV13858_REG_PLL2_CTRL_B0x030b
+#define OV13858_REG_PLL2_CTRL_C0x030c
+#define OV13858_REG_PLL2_CTRL_D0x030d
+#define OV13858_REG_PLL2_CTRL_E0x030e
+#define OV13858_REG_PLL2_CTRL_F0x030f
+#define OV13858_REG_PLL2_CTRL_12   0x0312
+#define OV13858_REG_MIPI_SC_CTRL0  0x3016
+#define OV13858_REG_MIPI_SC_CTRL1  0x3022
+
+/* Chip ID */
+#define OV13858_REG_CHIP_ID0x300a
+#define OV13858_CHIP_ID0x00d855
+
+/* V_TIMING internal */
+#define OV13858_REG_VTS0x380e
+#define OV13858_VTS_30FPS  0x0c8e /* 30 fps */
+#define OV13858_VTS_60FPS  0x0648 /* 60 fps */
+#define OV13858_VTS_MAX0x7fff
+#define OV13858_VBLANK_MIN 56
+
+/* HBLANK control - read only */
+#define OV13858_PPL_540MHZ 2244
+#define OV13858_PPL_1080MHZ4488
+
+/* Exposure control */
+#define OV13858_REG_EXPOSURE   0x3500
+#define OV13858_EXPOSURE_MIN   4
+#define OV13858_EXPOSURE_MAX   (OV13858_VTS_MAX - 8)
+#define OV13858_EXPOSURE_STEP  1
+#define OV13858_EXPOSURE_DEFAULT   0x640
+
+/* Analog gain control */
+#define OV13858_REG_ANALOG_GAIN0x3508
+#define OV13858_ANA_GAIN_MIN   0
+#define OV13858_ANA_GAIN_MAX   0x1fff
+#define OV13858_ANA_GAIN_STEP  1
+#define 

[PATCH v11 0/1] [media] i2c: add support for OV13858 sensor

[Hyungwoo Yang]

v11 : removed v10 and added checking if input clock frequency is 19.2Mhz
v10 : moved data dependent on module input clock frequency into fwnode.
v9 : added HBLANK and CID_GAIN(for digital gain).
v8 : enabled ov13858 with basic functionalities.

Hyungwoo Yang (1):
  [media] i2c: add support for OV13858 sensor

 drivers/media/i2c/Kconfig   |8 +
 drivers/media/i2c/Makefile  |1 +
 drivers/media/i2c/ov13858.c | 1816 +++
 3 files changed, 1825 insertions(+)
 create mode 100644 drivers/media/i2c/ov13858.c

-- 
1.9.1

[PATCH v11 1/1] [media] i2c: add support for OV13858 sensor

[Hyungwoo Yang]

This patch adds driver for Omnivision's ov13858
sensor, the driver supports following features:

- manual exposure/gain(analog and digital) control support
- two link frequencies
- VBLANK/HBLANK support
- test pattern support
- media controller support
- runtime pm support
- supported resolutions
  + 4224x3136 at 30FPS
  + 2112x1568 at 30FPS(default) and 60FPS
  + 2112x1188 at 30FPS(default) and 60FPS
  + 1056x784 at 30FPS(default) and 60FPS

Signed-off-by: Hyungwoo Yang 
---
 drivers/media/i2c/Kconfig   |8 +
 drivers/media/i2c/Makefile  |1 +
 drivers/media/i2c/ov13858.c | 1816 +++
 3 files changed, 1825 insertions(+)
 create mode 100644 drivers/media/i2c/ov13858.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index c380e24..26a9a3c 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -600,6 +600,14 @@ config VIDEO_OV9650
  This is a V4L2 sensor-level driver for the Omnivision
  OV9650 and OV9652 camera sensors.
 
+config VIDEO_OV13858
+   tristate "OmniVision OV13858 sensor support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV13858 camera.
+
 config VIDEO_VS6624
tristate "ST VS6624 sensor support"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 62323ec..3f4dc02 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
+obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
 obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
 obj-$(CONFIG_VIDEO_MT9M111) += mt9m111.o
 obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c
new file mode 100644
index 000..73d00e0
--- /dev/null
+++ b/drivers/media/i2c/ov13858.c
@@ -0,0 +1,1816 @@
+/*
+ * Copyright (c) 2017 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define OV13858_REG_VALUE_08BIT1
+#define OV13858_REG_VALUE_16BIT2
+#define OV13858_REG_VALUE_24BIT3
+
+#define OV13858_REG_MODE_SELECT0x0100
+#define OV13858_MODE_STANDBY   0x00
+#define OV13858_MODE_STREAMING 0x01
+
+#define OV13858_REG_SOFTWARE_RST   0x0103
+#define OV13858_SOFTWARE_RST   0x01
+
+/* PLL1 generates PCLK and MIPI_PHY_CLK */
+#define OV13858_REG_PLL1_CTRL_00x0300
+#define OV13858_REG_PLL1_CTRL_10x0301
+#define OV13858_REG_PLL1_CTRL_20x0302
+#define OV13858_REG_PLL1_CTRL_30x0303
+#define OV13858_REG_PLL1_CTRL_40x0304
+#define OV13858_REG_PLL1_CTRL_50x0305
+
+/* PLL2 generates DAC_CLK, SCLK and SRAM_CLK */
+#define OV13858_REG_PLL2_CTRL_B0x030b
+#define OV13858_REG_PLL2_CTRL_C0x030c
+#define OV13858_REG_PLL2_CTRL_D0x030d
+#define OV13858_REG_PLL2_CTRL_E0x030e
+#define OV13858_REG_PLL2_CTRL_F0x030f
+#define OV13858_REG_PLL2_CTRL_12   0x0312
+#define OV13858_REG_MIPI_SC_CTRL0  0x3016
+#define OV13858_REG_MIPI_SC_CTRL1  0x3022
+
+/* Chip ID */
+#define OV13858_REG_CHIP_ID0x300a
+#define OV13858_CHIP_ID0x00d855
+
+/* V_TIMING internal */
+#define OV13858_REG_VTS0x380e
+#define OV13858_VTS_30FPS  0x0c8e /* 30 fps */
+#define OV13858_VTS_60FPS  0x0648 /* 60 fps */
+#define OV13858_VTS_MAX0x7fff
+#define OV13858_VBLANK_MIN 56
+
+/* HBLANK control - read only */
+#define OV13858_PPL_540MHZ 2244
+#define OV13858_PPL_1080MHZ4488
+
+/* Exposure control */
+#define OV13858_REG_EXPOSURE   0x3500
+#define OV13858_EXPOSURE_MIN   4
+#define OV13858_EXPOSURE_MAX   (OV13858_VTS_MAX - 8)
+#define OV13858_EXPOSURE_STEP  1
+#define OV13858_EXPOSURE_DEFAULT   0x640
+
+/* Analog gain control */
+#define OV13858_REG_ANALOG_GAIN0x3508
+#define OV13858_ANA_GAIN_MIN   0
+#define OV13858_ANA_GAIN_MAX   0x1fff
+#define OV13858_ANA_GAIN_STEP  1
+#define 

Re: v4l2-fwnode: status, plans for merge, any branch to merge against?

[Pavel Machek]

Hi!

> > Are there any news about the fwnode branch?
> > 
> > I have quite usable camera, but it is still based on
> > 982e8e40390d26430ef106fede41594139a4111c (that's v4.10). It would be
> > good to see fwnode stuff upstream... are there any plans for that?
> > 
> > Is there stable branch to which I could move the stuff?
> 
> What's relevant for most V4L2 drivers is in linux-media right now.
> 
> There are new features that will take some time to get in. The trouble has
> been, and continue to be, that the patches need to go through various trees
> so it'll take some time for them to be merged.
> 
> I expect to have most of them in during the next merge window.

So git://linuxtv.org/media_tree.git branch master is the right one to
work one?

Thanks,
Pavel


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


signature.asc
Description: Digital signature

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

[Yong Zhi]

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

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

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

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

[Yong Zhi]

The formats added by this patch are:

V4L2_PIX_FMT_IPU3_SBGGR10
V4L2_PIX_FMT_IPU3_SGBRG10
V4L2_PIX_FMT_IPU3_SGRBG10
V4L2_PIX_FMT_IPU3_SRGGB10

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

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

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

[Yong Zhi]

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

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

===
= history =
===

More soon for next version.

version 3:
- remove cio2_set_power().
- replace dma_alloc_noncoherent() with dma_alloc_coherent().
- apply ffs tricks at possible places.
- change sensor_vc to local variable.
- move ktime_get_ns() a little earlier in the calling order.
- fix multiple assignments(I.e a = b =c)
- define CIO2_PAGE_SIZE for CIO2 PAGE_SIZE, SENSOR_VIR_CH_DFLT
for default sensor virtual ch.
- rework cio2_csi2_calc_timing().
- update v4l2 async subdev field name from match.fwnode.fwn
  to match.fwnode.fwnode.
- cherry-pick internal fix for triggering different irq on SOF and EOF.
- return -ENOMEM for vb2_dma_sg_plane_desc() in cio2_vb2_buf_init().
- add cio2_link_validate() placeholder for vdev.

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

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

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

-- 
2.7.4

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

[Yong Zhi]

Add IPU3 specific formats:

V4L2_PIX_FMT_IPU3_SBGGR10
V4L2_PIX_FMT_IPU3_SGBRG10
V4L2_PIX_FMT_IPU3_SGRBG10
V4L2_PIX_FMT_IPU3_SRGGB10

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

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

[GIT PULL FOR v4.13] Add video-mux, ov5640 and i.MX media staging driver

[Hans Verkuil]

It's been a long road, but the i.MX6 platform now has a proper driver. There
are a few relatively minor issues remaining (see the TODO file) before it
can be moved out of staging.

I want to thank Steve and Philipp for their hard work!

Regards,

Hans

The following changes since commit 47f910f0e0deb880c2114811f7ea1ec115a19ee4:

  [media] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev (2017-06-08 
16:55:25 -0300)

are available in the git repository at:

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

for you to fetch changes up to 5f19bcc69f4e351ab6700214e4f8f3d71807d4e2:

  MAINTAINERS: add entry for Freescale i.MX media driver (2017-06-13 21:48:28 
+0200)


Marek Vasut (1):
  media: imx: Drop warning upon multiple S_STREAM disable calls

Philipp Zabel (7):
  dt-bindings: Add bindings for video-multiplexer device
  add mux and video interface bridge entity functions
  platform: add video-multiplexer subdevice driver
  MAINTAINERS: add maintainer entry for video multiplexer v4l2 subdevice 
driver
  media: imx: csi: increase burst size for YUV formats
  media: imx: csi: add frame skipping support
  media: imx: csi: add sink selection rectangles

Russell King (3):
  media: imx: csi: add support for bayer formats
  media: imx: csi: add frame size/interval enumeration
  media: imx: capture: add frame sizes/interval enumeration

Steve Longerbeam (14):
  dt/bindings: Add bindings for OV5640
  add Omnivision OV5640 sensor driver
  MAINTAINERS: add entry for OV5640 sensor driver
  dt-bindings: Add bindings for i.MX media driver
  media: Add userspace header file for i.MX
  media: Add i.MX media core driver
  media: imx: Add a TODO file
  media: imx: Add Capture Device Interface
  media: imx: Add CSI subdev driver
  media: imx: Add VDIC subdev driver
  media: imx: Add IC subdev drivers
  media: imx: Add MIPI CSI-2 Receiver subdev driver
  media: imx: set and propagate default field, colorimetry
  MAINTAINERS: add entry for Freescale i.MX media driver

 Documentation/devicetree/bindings/media/i2c/ov5640.txt |   45 +
 Documentation/devicetree/bindings/media/imx.txt|   53 +
 Documentation/devicetree/bindings/media/video-mux.txt  |   60 ++
 Documentation/media/uapi/mediactl/media-types.rst  |   21 +
 Documentation/media/v4l-drivers/imx.rst|  614 
 MAINTAINERS|   25 +
 drivers/media/i2c/Kconfig  |   10 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov5640.c | 2344 

 drivers/media/platform/Kconfig |7 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/video-mux.c |  334 +++
 drivers/staging/media/Kconfig  |2 +
 drivers/staging/media/Makefile |1 +
 drivers/staging/media/imx/Kconfig  |   21 +
 drivers/staging/media/imx/Makefile |   12 +
 drivers/staging/media/imx/TODO |   23 +
 drivers/staging/media/imx/imx-ic-common.c  |  113 +++
 drivers/staging/media/imx/imx-ic-prp.c |  518 ++
 drivers/staging/media/imx/imx-ic-prpencvf.c| 1309 
+
 drivers/staging/media/imx/imx-ic.h |   38 +
 drivers/staging/media/imx/imx-media-capture.c  |  775 +++
 drivers/staging/media/imx/imx-media-csi.c  | 1817 
++
 drivers/staging/media/imx/imx-media-dev.c  |  667 +
 drivers/staging/media/imx/imx-media-fim.c  |  494 ++
 drivers/staging/media/imx/imx-media-internal-sd.c  |  349 +++
 drivers/staging/media/imx/imx-media-of.c   |  270 +
 drivers/staging/media/imx/imx-media-utils.c|  896 +
 drivers/staging/media/imx/imx-media-vdic.c | 1009 
+++
 drivers/staging/media/imx/imx-media.h  |  325 ++
 drivers/staging/media/imx/imx6-mipi-csi2.c |  698 +
 include/linux/imx-media.h  |   29 +
 include/media/imx.h|   15 +
 include/uapi/linux/media.h |6 +
 include/uapi/linux/v4l2-controls.h |4 +
 35 files changed, 12907 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
 create mode 100644 Documentation/devicetree/bindings/media/imx.txt
 create mode 100644 Documentation/devicetree/bindings/media/video-mux.txt
 create mode 100644 Documentation/media/v4l-drivers/imx.rst
 create mode 

[PATCH v4 01/11] [media] vimc: sen: Integrate the tpg on the sensor

[Helen Koike]

Initialize the test pattern generator on the sensor
Generate a colored bar image instead of a grey one

Signed-off-by: Helen Koike 

---

Changes in v4: None
Changes in v3:
[media] vimc: sen: Integrate the tpg on the sensor
- Declare frame_size as a local variable
- Set tpg frame format before starting kthread
- s_stream(sd, 1): return 0 if stream is already enabled
- s_stream(sd, 0): return 0 if stream is already disabled
- s_stream: propagate error from kthread_stop
- coding style when calling tpg_s_bytesperline
- s/vimc_thread_sen/vimc_sen_tpg_thread
- fix multiline comment
- remove V4L2_FIELD_ALTERNATE from tpg_s_field
- remove V4L2_STD_PAL from tpg_fill_plane_buffer

Changes in v2:
[media] vimc: sen: Integrate the tpg on the sensor
- Fix include location
- Select V4L2_TPG in Kconfig
- configure tpg on streamon only
- rm BUG_ON
- coding style


---
 drivers/media/platform/vimc/Kconfig   |  1 +
 drivers/media/platform/vimc/vimc-sensor.c | 64 ---
 2 files changed, 52 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/vimc/Kconfig 
b/drivers/media/platform/vimc/Kconfig
index a18f635..71c9fe7 100644
--- a/drivers/media/platform/vimc/Kconfig
+++ b/drivers/media/platform/vimc/Kconfig
@@ -2,6 +2,7 @@ config VIDEO_VIMC
tristate "Virtual Media Controller Driver (VIMC)"
depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_VMALLOC
+   select VIDEO_V4L2_TPG
default n
---help---
  Skeleton driver for Virtual Media Controller
diff --git a/drivers/media/platform/vimc/vimc-sensor.c 
b/drivers/media/platform/vimc/vimc-sensor.c
index 591f6a4..2e83487 100644
--- a/drivers/media/platform/vimc/vimc-sensor.c
+++ b/drivers/media/platform/vimc/vimc-sensor.c
@@ -20,17 +20,20 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "vimc-sensor.h"
 
+#define VIMC_SEN_FRAME_MAX_WIDTH 4096
+
 struct vimc_sen_device {
struct vimc_ent_device ved;
struct v4l2_subdev sd;
+   struct tpg_data tpg;
struct task_struct *kthread_sen;
u8 *frame;
/* The active format */
struct v4l2_mbus_framefmt mbus_format;
-   int frame_size;
 };
 
 static int vimc_sen_enum_mbus_code(struct v4l2_subdev *sd,
@@ -84,6 +87,24 @@ static int vimc_sen_get_fmt(struct v4l2_subdev *sd,
return 0;
 }
 
+static void vimc_sen_tpg_s_format(struct vimc_sen_device *vsen)
+{
+   const struct vimc_pix_map *vpix =
+   vimc_pix_map_by_code(vsen->mbus_format.code);
+
+   tpg_reset_source(>tpg, vsen->mbus_format.width,
+vsen->mbus_format.height, vsen->mbus_format.field);
+   tpg_s_bytesperline(>tpg, 0, vsen->mbus_format.width * vpix->bpp);
+   tpg_s_buf_height(>tpg, vsen->mbus_format.height);
+   tpg_s_fourcc(>tpg, vpix->pixelformat);
+   /* TODO: add support for V4L2_FIELD_ALTERNATE */
+   tpg_s_field(>tpg, vsen->mbus_format.field, false);
+   tpg_s_colorspace(>tpg, vsen->mbus_format.colorspace);
+   tpg_s_ycbcr_enc(>tpg, vsen->mbus_format.ycbcr_enc);
+   tpg_s_quantization(>tpg, vsen->mbus_format.quantization);
+   tpg_s_xfer_func(>tpg, vsen->mbus_format.xfer_func);
+}
+
 static const struct v4l2_subdev_pad_ops vimc_sen_pad_ops = {
.enum_mbus_code = vimc_sen_enum_mbus_code,
.enum_frame_size= vimc_sen_enum_frame_size,
@@ -97,7 +118,7 @@ static const struct media_entity_operations vimc_sen_mops = {
.link_validate = v4l2_subdev_link_validate,
 };
 
-static int vimc_thread_sen(void *data)
+static int vimc_sen_tpg_thread(void *data)
 {
struct vimc_sen_device *vsen = data;
unsigned int i;
@@ -110,7 +131,7 @@ static int vimc_thread_sen(void *data)
if (kthread_should_stop())
break;
 
-   memset(vsen->frame, 100, vsen->frame_size);
+   tpg_fill_plane_buffer(>tpg, 0, 0, vsen->frame);
 
/* Send the frame to all source pads */
for (i = 0; i < vsen->sd.entity.num_pads; i++)
@@ -132,26 +153,31 @@ static int vimc_sen_s_stream(struct v4l2_subdev *sd, int 
enable)
 
if (enable) {
const struct vimc_pix_map *vpix;
+   unsigned int frame_size;
 
if (vsen->kthread_sen)
-   return -EINVAL;
+   /* tpg is already executing */
+   return 0;
 
/* Calculate the frame size */
vpix = vimc_pix_map_by_code(vsen->mbus_format.code);
-   vsen->frame_size = vsen->mbus_format.width * vpix->bpp *
-  vsen->mbus_format.height;
+   frame_size = vsen->mbus_format.width * vpix->bpp *
+vsen->mbus_format.height;
 
  

[PATCH v4 02/11] [media] vimc: Move common code from the core

[Helen Koike]

Remove helper functions from vimc-core and add it in vimc-common to
clean up the core.

Signed-off-by: Helen Koike 

---

Changes in v4: None
Changes in v3:
[media] vimc: Move common code from the core
- This is a new patch in the series

Changes in v2: None


---
 drivers/media/platform/vimc/Makefile   |   2 +-
 drivers/media/platform/vimc/vimc-capture.h |   2 +-
 drivers/media/platform/vimc/vimc-common.c  | 221 +
 .../platform/vimc/{vimc-core.h => vimc-common.h}   |   7 +-
 drivers/media/platform/vimc/vimc-core.c| 205 +--
 drivers/media/platform/vimc/vimc-sensor.h  |   2 +-
 6 files changed, 229 insertions(+), 210 deletions(-)
 create mode 100644 drivers/media/platform/vimc/vimc-common.c
 rename drivers/media/platform/vimc/{vimc-core.h => vimc-common.h} (96%)

diff --git a/drivers/media/platform/vimc/Makefile 
b/drivers/media/platform/vimc/Makefile
index c45195e..6b6ddf4 100644
--- a/drivers/media/platform/vimc/Makefile
+++ b/drivers/media/platform/vimc/Makefile
@@ -1,3 +1,3 @@
-vimc-objs := vimc-core.o vimc-capture.o vimc-sensor.o
+vimc-objs := vimc-core.o vimc-capture.o vimc-common.o vimc-sensor.o
 
 obj-$(CONFIG_VIDEO_VIMC) += vimc.o
diff --git a/drivers/media/platform/vimc/vimc-capture.h 
b/drivers/media/platform/vimc/vimc-capture.h
index 581a813..7e5c707 100644
--- a/drivers/media/platform/vimc/vimc-capture.h
+++ b/drivers/media/platform/vimc/vimc-capture.h
@@ -18,7 +18,7 @@
 #ifndef _VIMC_CAPTURE_H_
 #define _VIMC_CAPTURE_H_
 
-#include "vimc-core.h"
+#include "vimc-common.h"
 
 struct vimc_ent_device *vimc_cap_create(struct v4l2_device *v4l2_dev,
const char *const name,
diff --git a/drivers/media/platform/vimc/vimc-common.c 
b/drivers/media/platform/vimc/vimc-common.c
new file mode 100644
index 000..42f779a
--- /dev/null
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -0,0 +1,221 @@
+/*
+ * vimc-common.c Virtual Media Controller Driver
+ *
+ * Copyright (C) 2015-2017 Helen Koike 
+ *
+ * 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.
+ *
+ */
+
+#include "vimc-common.h"
+
+static const struct vimc_pix_map vimc_pix_map_list[] = {
+   /* TODO: add all missing formats */
+
+   /* RGB formats */
+   {
+   .code = MEDIA_BUS_FMT_BGR888_1X24,
+   .pixelformat = V4L2_PIX_FMT_BGR24,
+   .bpp = 3,
+   },
+   {
+   .code = MEDIA_BUS_FMT_RGB888_1X24,
+   .pixelformat = V4L2_PIX_FMT_RGB24,
+   .bpp = 3,
+   },
+   {
+   .code = MEDIA_BUS_FMT_ARGB_1X32,
+   .pixelformat = V4L2_PIX_FMT_ARGB32,
+   .bpp = 4,
+   },
+
+   /* Bayer formats */
+   {
+   .code = MEDIA_BUS_FMT_SBGGR8_1X8,
+   .pixelformat = V4L2_PIX_FMT_SBGGR8,
+   .bpp = 1,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SGBRG8_1X8,
+   .pixelformat = V4L2_PIX_FMT_SGBRG8,
+   .bpp = 1,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SGRBG8_1X8,
+   .pixelformat = V4L2_PIX_FMT_SGRBG8,
+   .bpp = 1,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SRGGB8_1X8,
+   .pixelformat = V4L2_PIX_FMT_SRGGB8,
+   .bpp = 1,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SBGGR10_1X10,
+   .pixelformat = V4L2_PIX_FMT_SBGGR10,
+   .bpp = 2,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SGBRG10_1X10,
+   .pixelformat = V4L2_PIX_FMT_SGBRG10,
+   .bpp = 2,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SGRBG10_1X10,
+   .pixelformat = V4L2_PIX_FMT_SGRBG10,
+   .bpp = 2,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SRGGB10_1X10,
+   .pixelformat = V4L2_PIX_FMT_SRGGB10,
+   .bpp = 2,
+   },
+
+   /* 10bit raw bayer a-law compressed to 8 bits */
+   {
+   .code = MEDIA_BUS_FMT_SBGGR10_ALAW8_1X8,
+   .pixelformat = V4L2_PIX_FMT_SBGGR10ALAW8,
+   .bpp = 1,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SGBRG10_ALAW8_1X8,
+   .pixelformat = V4L2_PIX_FMT_SGBRG10ALAW8,
+   .bpp = 1,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SGRBG10_ALAW8_1X8,
+   .pixelformat = V4L2_PIX_FMT_SGRBG10ALAW8,
+

[PATCH v4 03/11] [media] vimc: common: Add vimc_ent_sd_* helper

[Helen Koike]

As all the subdevices in the topology will be initialized in the same
way, to avoid code repetition the vimc_ent_sd_{register, unregister}
helper functions were created

Signed-off-by: Helen Koike 

---

Changes in v4: None
Changes in v3:
[media] vimc: common: Add vimc_ent_sd_* helper
- add it in vimc-common.c instead in vimc-core.c
- fix vimc_ent_sd_register, use function parameter to assign
sd->entity.function instead of using a fixed value
- rename commit to add the "common" tag

Changes in v2:
[media] vimc: Add vimc_ent_sd_* helper functions
- Comments in vimc_ent_sd_init
- Update vimc_ent_sd_init with upstream code as media_entity_pads_init
(instead of media_entity_init), entity->function intead of entity->type
- Add missing vimc_pads_cleanup in vimc_ent_sd_cleanup
- remove subdevice v4l2_dev and dev fields
- change unregister order in vimc_ent_sd_cleanup
- rename vimc_ent_sd_{init,cleanup} to vimc_ent_sd_{register,unregister}
- remove struct vimc_ent_subdevice, use ved and sd directly
- don't impose struct vimc_sen_device to declare ved and sd struct first
- add kernel docs


---
 drivers/media/platform/vimc/vimc-common.c | 66 +++
 drivers/media/platform/vimc/vimc-common.h | 39 ++
 drivers/media/platform/vimc/vimc-sensor.c | 58 +--
 3 files changed, 114 insertions(+), 49 deletions(-)

diff --git a/drivers/media/platform/vimc/vimc-common.c 
b/drivers/media/platform/vimc/vimc-common.c
index 42f779a..3afbabd 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -219,3 +219,69 @@ struct media_pad *vimc_pads_init(u16 num_pads, const 
unsigned long *pads_flag)
 
return pads;
 }
+
+static const struct media_entity_operations vimc_ent_sd_mops = {
+   .link_validate = v4l2_subdev_link_validate,
+};
+
+int vimc_ent_sd_register(struct vimc_ent_device *ved,
+struct v4l2_subdev *sd,
+struct v4l2_device *v4l2_dev,
+const char *const name,
+u32 function,
+u16 num_pads,
+const unsigned long *pads_flag,
+const struct v4l2_subdev_ops *sd_ops,
+void (*sd_destroy)(struct vimc_ent_device *))
+{
+   int ret;
+
+   /* Allocate the pads */
+   ved->pads = vimc_pads_init(num_pads, pads_flag);
+   if (IS_ERR(ved->pads))
+   return PTR_ERR(ved->pads);
+
+   /* Fill the vimc_ent_device struct */
+   ved->destroy = sd_destroy;
+   ved->ent = >entity;
+
+   /* Initialize the subdev */
+   v4l2_subdev_init(sd, sd_ops);
+   sd->entity.function = function;
+   sd->entity.ops = _ent_sd_mops;
+   sd->owner = THIS_MODULE;
+   strlcpy(sd->name, name, sizeof(sd->name));
+   v4l2_set_subdevdata(sd, ved);
+
+   /* Expose this subdev to user space */
+   sd->flags = V4L2_SUBDEV_FL_HAS_DEVNODE;
+
+   /* Initialize the media entity */
+   ret = media_entity_pads_init(>entity, num_pads, ved->pads);
+   if (ret)
+   goto err_clean_pads;
+
+   /* Register the subdev with the v4l2 and the media framework */
+   ret = v4l2_device_register_subdev(v4l2_dev, sd);
+   if (ret) {
+   dev_err(v4l2_dev->dev,
+   "%s: subdev register failed (err=%d)\n",
+   name, ret);
+   goto err_clean_m_ent;
+   }
+
+   return 0;
+
+err_clean_m_ent:
+   media_entity_cleanup(>entity);
+err_clean_pads:
+   vimc_pads_cleanup(ved->pads);
+   return ret;
+}
+
+void vimc_ent_sd_unregister(struct vimc_ent_device *ved, struct v4l2_subdev 
*sd)
+{
+   v4l2_device_unregister_subdev(sd);
+   media_entity_cleanup(ved->ent);
+   vimc_pads_cleanup(ved->pads);
+}
diff --git a/drivers/media/platform/vimc/vimc-common.h 
b/drivers/media/platform/vimc/vimc-common.h
index 00d3da4..9ec361c 100644
--- a/drivers/media/platform/vimc/vimc-common.h
+++ b/drivers/media/platform/vimc/vimc-common.h
@@ -110,4 +110,43 @@ const struct vimc_pix_map *vimc_pix_map_by_code(u32 code);
  */
 const struct vimc_pix_map *vimc_pix_map_by_pixelformat(u32 pixelformat);
 
+/**
+ * vimc_ent_sd_register - initialize and register a subdev node
+ *
+ * @ved:   the vimc_ent_device struct to be initialize
+ * @sd:the v4l2_subdev struct to be initialize and registered
+ * @v4l2_dev:  the v4l2 device to register the v4l2_subdev
+ * @name:  name of the sub-device. Please notice that the name must be
+ * unique.
+ * @function:  media entity function defined by MEDIA_ENT_F_* macros
+ * @num_pads:  number of pads to initialize
+ * @pads_flag: flags to use in each pad
+ * @sd_ops:pointer to  v4l2_subdev_ops.
+ * @sd_destroy:

[PATCH v4 04/11] [media] vimc: common: Add vimc_pipeline_s_stream helper

[Helen Koike]

Move the vimc_cap_pipeline_s_stream from the vimc-cap.c to vimc-common.c
as this core will be reused by other subdevices to activate the stream
in their directly connected nodes

Signed-off-by: Helen Koike 

---

Changes in v4: None
Changes in v3:
[media] vimc: Add vimc_pipeline_s_stream in the core
- add it in vimc-common instead of vimc-core
- rename commit with "common" tag

Changes in v2:
[media] vimc: Add vimc_pipeline_s_stream in the core
- Use is_media_entity_v4l2_subdev instead of comparing with the old
entity->type
- Fix comments style
- add kernel-docs
- call s_stream across all sink pads


---
 drivers/media/platform/vimc/vimc-capture.c | 29 ++-
 drivers/media/platform/vimc/vimc-common.c  | 32 ++
 drivers/media/platform/vimc/vimc-common.h  | 11 ++
 3 files changed, 45 insertions(+), 27 deletions(-)

diff --git a/drivers/media/platform/vimc/vimc-capture.c 
b/drivers/media/platform/vimc/vimc-capture.c
index 9adb06d..93f6a09 100644
--- a/drivers/media/platform/vimc/vimc-capture.c
+++ b/drivers/media/platform/vimc/vimc-capture.c
@@ -132,31 +132,6 @@ static void vimc_cap_return_all_buffers(struct 
vimc_cap_device *vcap,
spin_unlock(>qlock);
 }
 
-static int vimc_cap_pipeline_s_stream(struct vimc_cap_device *vcap, int enable)
-{
-   struct v4l2_subdev *sd;
-   struct media_pad *pad;
-   int ret;
-
-   /* Start the stream in the subdevice direct connected */
-   pad = media_entity_remote_pad(>vdev.entity.pads[0]);
-
-   /*
-* if it is a raw node from vimc-core, there is nothing to activate
-* TODO: remove this when there are no more raw nodes in the
-* core and return error instead
-*/
-   if (pad->entity->obj_type == MEDIA_ENTITY_TYPE_BASE)
-   return 0;
-
-   sd = media_entity_to_v4l2_subdev(pad->entity);
-   ret = v4l2_subdev_call(sd, video, s_stream, enable);
-   if (ret && ret != -ENOIOCTLCMD)
-   return ret;
-
-   return 0;
-}
-
 static int vimc_cap_start_streaming(struct vb2_queue *vq, unsigned int count)
 {
struct vimc_cap_device *vcap = vb2_get_drv_priv(vq);
@@ -173,7 +148,7 @@ static int vimc_cap_start_streaming(struct vb2_queue *vq, 
unsigned int count)
}
 
/* Enable streaming from the pipe */
-   ret = vimc_cap_pipeline_s_stream(vcap, 1);
+   ret = vimc_pipeline_s_stream(>vdev.entity, 1);
if (ret) {
media_pipeline_stop(entity);
vimc_cap_return_all_buffers(vcap, VB2_BUF_STATE_QUEUED);
@@ -192,7 +167,7 @@ static void vimc_cap_stop_streaming(struct vb2_queue *vq)
struct vimc_cap_device *vcap = vb2_get_drv_priv(vq);
 
/* Disable streaming from the pipe */
-   vimc_cap_pipeline_s_stream(vcap, 0);
+   vimc_pipeline_s_stream(>vdev.entity, 0);
 
/* Stop the media pipeline */
media_pipeline_stop(>vdev.entity);
diff --git a/drivers/media/platform/vimc/vimc-common.c 
b/drivers/media/platform/vimc/vimc-common.c
index 3afbabd..f809a9d 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -220,6 +220,38 @@ struct media_pad *vimc_pads_init(u16 num_pads, const 
unsigned long *pads_flag)
return pads;
 }
 
+int vimc_pipeline_s_stream(struct media_entity *ent, int enable)
+{
+   struct v4l2_subdev *sd;
+   struct media_pad *pad;
+   unsigned int i;
+   int ret;
+
+   for (i = 0; i < ent->num_pads; i++) {
+   if (ent->pads[i].flags & MEDIA_PAD_FL_SOURCE)
+   continue;
+
+   /* Start the stream in the subdevice direct connected */
+   pad = media_entity_remote_pad(>pads[i]);
+
+   /*
+* if this is a raw node from vimc-core, then there is
+* nothing to activate
+* TODO: remove this when there are no more raw nodes in the
+* core and return error instead
+*/
+   if (pad->entity->obj_type == MEDIA_ENTITY_TYPE_BASE)
+   continue;
+
+   sd = media_entity_to_v4l2_subdev(pad->entity);
+   ret = v4l2_subdev_call(sd, video, s_stream, enable);
+   if (ret && ret != -ENOIOCTLCMD)
+   return ret;
+   }
+
+   return 0;
+}
+
 static const struct media_entity_operations vimc_ent_sd_mops = {
.link_validate = v4l2_subdev_link_validate,
 };
diff --git a/drivers/media/platform/vimc/vimc-common.h 
b/drivers/media/platform/vimc/vimc-common.h
index 9ec361c..73e7e94 100644
--- a/drivers/media/platform/vimc/vimc-common.h
+++ b/drivers/media/platform/vimc/vimc-common.h
@@ -97,6 +97,17 @@ static inline void vimc_pads_cleanup(struct media_pad *pads)
 }
 
 /**
+ * vimc_pipeline_s_stream - start stream through the pipeline
+ *
+ * @ent:   the 

[PATCH v4 05/11] [media] vimc: common: Add vimc_link_validate

[Helen Koike]

All links will be checked in the same way. Adding a helper function for
that

Signed-off-by: Helen Koike 

---

Changes in v4:
[media] vimc: common: Add vimc_link_validate
- remove vimc_fmt_pix_to_mbus(), replaced by
v4l2_fill_mbus_format()
- remove EXPORT_SYMBOL(vimc_link_validate), not necessary in
this patch, moved to submodules patch
- Fix multi-line comment style
- If colorspace is set to DEFAULT, then assume all the other
colorimetry parameters are also DEFAULT

Changes in v3:
[media] vimc: common: Add vimc_link_validate
- this is a new patch in the series

Changes in v2: None


---
 drivers/media/platform/vimc/vimc-capture.c |  78 +++
 drivers/media/platform/vimc/vimc-common.c  | 121 -
 drivers/media/platform/vimc/vimc-common.h  |  14 
 3 files changed, 145 insertions(+), 68 deletions(-)

diff --git a/drivers/media/platform/vimc/vimc-capture.c 
b/drivers/media/platform/vimc/vimc-capture.c
index 93f6a09..5bdecd1 100644
--- a/drivers/media/platform/vimc/vimc-capture.c
+++ b/drivers/media/platform/vimc/vimc-capture.c
@@ -64,6 +64,15 @@ static int vimc_cap_querycap(struct file *file, void *priv,
return 0;
 }
 
+static void vimc_cap_get_format(struct vimc_ent_device *ved,
+   struct v4l2_pix_format *fmt)
+{
+   struct vimc_cap_device *vcap = container_of(ved, struct vimc_cap_device,
+   ved);
+
+   *fmt = vcap->format;
+}
+
 static int vimc_cap_fmt_vid_cap(struct file *file, void *priv,
  struct v4l2_format *f)
 {
@@ -231,74 +240,8 @@ static const struct vb2_ops vimc_cap_qops = {
.wait_finish= vb2_ops_wait_finish,
 };
 
-/*
- * NOTE: this function is a copy of v4l2_subdev_link_validate_get_format
- * maybe the v4l2 function should be public
- */
-static int vimc_cap_v4l2_subdev_link_validate_get_format(struct media_pad *pad,
-   struct v4l2_subdev_format *fmt)
-{
-   struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(pad->entity);
-
-   fmt->which = V4L2_SUBDEV_FORMAT_ACTIVE;
-   fmt->pad = pad->index;
-
-   return v4l2_subdev_call(sd, pad, get_fmt, NULL, fmt);
-}
-
-static int vimc_cap_link_validate(struct media_link *link)
-{
-   struct v4l2_subdev_format source_fmt;
-   const struct vimc_pix_map *vpix;
-   struct vimc_cap_device *vcap = container_of(link->sink->entity,
-   struct vimc_cap_device,
-   vdev.entity);
-   struct v4l2_pix_format *sink_fmt = >format;
-   int ret;
-
-   /*
-* if it is a raw node from vimc-core, ignore the link for now
-* TODO: remove this when there are no more raw nodes in the
-* core and return error instead
-*/
-   if (link->source->entity->obj_type == MEDIA_ENTITY_TYPE_BASE)
-   return 0;
-
-   /* Get the the format of the subdev */
-   ret = vimc_cap_v4l2_subdev_link_validate_get_format(link->source,
-   _fmt);
-   if (ret)
-   return ret;
-
-   dev_dbg(vcap->vdev.v4l2_dev->dev,
-   "%s: link validate formats src:%dx%d %d sink:%dx%d %d\n",
-   vcap->vdev.name,
-   source_fmt.format.width, source_fmt.format.height,
-   source_fmt.format.code,
-   sink_fmt->width, sink_fmt->height,
-   sink_fmt->pixelformat);
-
-   /* The width, height and code must match. */
-   vpix = vimc_pix_map_by_pixelformat(sink_fmt->pixelformat);
-   if (source_fmt.format.width != sink_fmt->width
-   || source_fmt.format.height != sink_fmt->height
-   || vpix->code != source_fmt.format.code)
-   return -EPIPE;
-
-   /*
-* The field order must match, or the sink field order must be NONE
-* to support interlaced hardware connected to bridges that support
-* progressive formats only.
-*/
-   if (source_fmt.format.field != sink_fmt->field &&
-   sink_fmt->field != V4L2_FIELD_NONE)
-   return -EPIPE;
-
-   return 0;
-}
-
 static const struct media_entity_operations vimc_cap_mops = {
-   .link_validate  = vimc_cap_link_validate,
+   .link_validate  = vimc_link_validate,
 };
 
 static void vimc_cap_destroy(struct vimc_ent_device *ved)
@@ -434,6 +377,7 @@ struct vimc_ent_device *vimc_cap_create(struct v4l2_device 
*v4l2_dev,
vcap->ved.destroy = vimc_cap_destroy;
vcap->ved.ent = >vdev.entity;
vcap->ved.process_frame = vimc_cap_process_frame;
+   vcap->ved.vdev_get_format = vimc_cap_get_format;
 
/* Initialize the video_device struct */
vdev = >vdev;
diff --git 

[PATCH v4 10/11] [media] vimc: deb: Add debayer filter

[Helen Koike]

Implement the debayer filter and integrate it with the core

Signed-off-by: Helen Koike 

---

Changes in v4:
[media] vimc: deb: Add debayer filter
- Rebase without [media] vimc: Optimize frame generation through
pipe
- use vimc_colorimetry_clamp
- replace V4L2_COLORSPACE_SRGB by V4L2_COLORSPACE_DEFAULT in the
default format struct
- use struct vimc_platform_data to retrieve the entity's name

Changes in v3:
[media] vimc: deb: Add debayer filter
- Declare frame_size as a local variable
- s_stream(sd, 1): return 0 if stream is already enabled
- s_stream(sd, 0): return 0 if stream is already disabled
- s_stream: add ret variable to propagate return errors
- structure code to be a module, use platform_driver and component 
system
- fix multiline comment
- s/thought/through
- s/RGB/RGB888
- clamp height and width of the image by an even value
- if user try to set colorspace to an invalid format, set all
colorimetry parameters to _DEFAULT
- uset _DEFAULT for colorimetry in the default format

Changes in v2:
[media] vimc: deb: Add debayer filter
- Using MEDIA_ENT_F_ATV_DECODER in function
- remove v4l2_dev and dev from vimc_deb_device struct
- src fmt propagates from the sink
- coding style
- remove redundant else if statements
- check end of enum and remove BUG_ON
- enum frame size with min and max values
- set/try fmt
- remove unecessary include freezer.h
- check pad types on create
- return EBUSY when trying to set the format while stream is on
- remove vsd struct
- add IS_SRC and IS_SINK macros
- add deb_mean_win_size as a parameter of the module
- check set_fmt default parameters for quantization, colorspace ...
- add more dev_dbg


---
 drivers/media/platform/vimc/Makefile   |   4 +-
 drivers/media/platform/vimc/vimc-common.h  |   2 +
 drivers/media/platform/vimc/vimc-debayer.c | 601 +
 3 files changed, 606 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/vimc/vimc-debayer.c

diff --git a/drivers/media/platform/vimc/Makefile 
b/drivers/media/platform/vimc/Makefile
index 0e5d5ce..4fba8ef 100644
--- a/drivers/media/platform/vimc/Makefile
+++ b/drivers/media/platform/vimc/Makefile
@@ -1,6 +1,8 @@
 vimc-objs := vimc-core.o
 vimc_capture-objs := vimc-capture.o
 vimc_common-objs := vimc-common.o
+vimc_debayer-objs := vimc-debayer.o
 vimc_sensor-objs := vimc-sensor.o
 
-obj-$(CONFIG_VIDEO_VIMC) += vimc.o vimc_capture.o vimc_common.o vimc_sensor.o
+obj-$(CONFIG_VIDEO_VIMC) += vimc.o vimc_capture.o vimc_common.o vimc-debayer.o 
\
+   vimc_sensor.o
diff --git a/drivers/media/platform/vimc/vimc-common.h 
b/drivers/media/platform/vimc/vimc-common.h
index a9c1cfd..25ba752 100644
--- a/drivers/media/platform/vimc/vimc-common.h
+++ b/drivers/media/platform/vimc/vimc-common.h
@@ -27,6 +27,8 @@
 #define VIMC_FRAME_MIN_WIDTH 16
 #define VIMC_FRAME_MIN_HEIGHT 16
 
+#define VIMC_FRAME_INDEX(lin, col, width, bpp) ((lin * width + col) * bpp)
+
 /**
  * struct vimc_colorimetry_clamp - Adjust colorimetry parameters
  *
diff --git a/drivers/media/platform/vimc/vimc-debayer.c 
b/drivers/media/platform/vimc/vimc-debayer.c
new file mode 100644
index 000..e23a5b9
--- /dev/null
+++ b/drivers/media/platform/vimc/vimc-debayer.c
@@ -0,0 +1,601 @@
+/*
+ * vimc-debayer.c Virtual Media Controller Driver
+ *
+ * Copyright (C) 2015-2017 Helen Koike 
+ *
+ * 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vimc-common.h"
+
+#define VIMC_DEB_DRV_NAME "vimc-debayer"
+
+static unsigned int deb_mean_win_size = 3;
+module_param(deb_mean_win_size, uint, );
+MODULE_PARM_DESC(deb_mean_win_size, " the window size to calculate the mean.\n"
+   "NOTE: the window size need to be an odd number, as the main pixel "
+   "stays in the center of the window, otherwise the next odd number "
+   "is considered");
+
+#define IS_SINK(pad) (!pad)
+#define IS_SRC(pad)  (pad)
+
+enum vimc_deb_rgb_colors {
+   VIMC_DEB_RED = 0,
+   VIMC_DEB_GREEN = 1,
+   VIMC_DEB_BLUE = 2,
+};
+
+struct vimc_deb_pix_map {
+   u32 code;
+   enum vimc_deb_rgb_colors order[2][2];
+};
+
+struct 

[PATCH v4 11/11] [media] vimc: sca: Add scaler

[Helen Koike]

Implement scaler and integrated with the core

Signed-off-by: Helen Koike 

---

Changes in v4:
[media] vimc: sca: Add scaler
- use vimc_colorimetry_clamp
- replace V4L2_COLORSPACE_SRGB by V4L2_COLORSPACE_DEFAULT in the
default format struct
- use struct vimc_platform_data to retrieve the entity's name

Changes in v3:
[media] vimc: sca: Add scaler
- Declare frame_size as a local variable
- s_stream(sd, 1): return 0 if stream is already enabled
- s_stream(sd, 0): return 0 if stream is already disabled
- s_stream: add ret variable to propagate return errors
- structure code to be a module, use platform_driver and component 
system
- s/thought/through
- clamp height and width of the image by an even value
- if user try to set colorspace to an invalid format, set all
colorimetry parameters to _DEFAULT
- uset _DEFAULT for colorimetry in the default format

Changes in v2:
[media] vimc: sca: Add scaler
- Add function MEDIA_ENT_F_IO_V4L
- remove v4l2_dev and dev
- s/sink_mbus_fmt/sink_fmt
- remove BUG_ON, remove redundant if else, rewrite TODO, check end of 
enum
- rm src_width/height, enum fsize with min and max values
- set/try fmt
- remove unecessary include freezer.h
- core: add bayer boolean in pixel table
- coding style
- fix bug in enum frame size
- check pad types on create
- return EBUSY when trying to set the format while stream is on
- remove vsd struct
- add IS_SRC and IS_SINK macros
- add sca_mult as a parameter of the module
- check set_fmt default parameters for quantization, colorspace ...
- add more dev_dbg


---
 drivers/media/platform/vimc/Makefile  |   3 +-
 drivers/media/platform/vimc/vimc-common.c |  27 ++
 drivers/media/platform/vimc/vimc-common.h |   1 +
 drivers/media/platform/vimc/vimc-scaler.c | 455 ++
 4 files changed, 485 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/vimc/vimc-scaler.c

diff --git a/drivers/media/platform/vimc/Makefile 
b/drivers/media/platform/vimc/Makefile
index 4fba8ef..68c5d98 100644
--- a/drivers/media/platform/vimc/Makefile
+++ b/drivers/media/platform/vimc/Makefile
@@ -2,7 +2,8 @@ vimc-objs := vimc-core.o
 vimc_capture-objs := vimc-capture.o
 vimc_common-objs := vimc-common.o
 vimc_debayer-objs := vimc-debayer.o
+vimc_scaler-objs := vimc-scaler.o
 vimc_sensor-objs := vimc-sensor.o
 
 obj-$(CONFIG_VIDEO_VIMC) += vimc.o vimc_capture.o vimc_common.o vimc-debayer.o 
\
-   vimc_sensor.o
+   vimc_scaler.o vimc_sensor.o
diff --git a/drivers/media/platform/vimc/vimc-common.c 
b/drivers/media/platform/vimc/vimc-common.c
index da7f2b7..9d63c84 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -20,6 +20,10 @@
 
 #include "vimc-common.h"
 
+/*
+ * NOTE: non-bayer formats need to come first (necessary for enum_mbus_code
+ * in the scaler)
+ */
 static const struct vimc_pix_map vimc_pix_map_list[] = {
/* TODO: add all missing formats */
 
@@ -28,16 +32,19 @@ static const struct vimc_pix_map vimc_pix_map_list[] = {
.code = MEDIA_BUS_FMT_BGR888_1X24,
.pixelformat = V4L2_PIX_FMT_BGR24,
.bpp = 3,
+   .bayer = false,
},
{
.code = MEDIA_BUS_FMT_RGB888_1X24,
.pixelformat = V4L2_PIX_FMT_RGB24,
.bpp = 3,
+   .bayer = false,
},
{
.code = MEDIA_BUS_FMT_ARGB_1X32,
.pixelformat = V4L2_PIX_FMT_ARGB32,
.bpp = 4,
+   .bayer = false,
},
 
/* Bayer formats */
@@ -45,41 +52,49 @@ static const struct vimc_pix_map vimc_pix_map_list[] = {
.code = MEDIA_BUS_FMT_SBGGR8_1X8,
.pixelformat = V4L2_PIX_FMT_SBGGR8,
.bpp = 1,
+   .bayer = true,
},
{
.code = MEDIA_BUS_FMT_SGBRG8_1X8,
.pixelformat = V4L2_PIX_FMT_SGBRG8,
.bpp = 1,
+   .bayer = true,
},
{
.code = MEDIA_BUS_FMT_SGRBG8_1X8,
.pixelformat = V4L2_PIX_FMT_SGRBG8,
.bpp = 1,
+   .bayer = true,
},
{
.code = MEDIA_BUS_FMT_SRGGB8_1X8,
.pixelformat = V4L2_PIX_FMT_SRGGB8,
.bpp = 1,
+   .bayer = true,
},
{
.code = MEDIA_BUS_FMT_SBGGR10_1X10,
.pixelformat = V4L2_PIX_FMT_SBGGR10,
.bpp = 2,
+   .bayer = true,
},
{
.code = MEDIA_BUS_FMT_SGBRG10_1X10,
.pixelformat = 

[PATCH v4 06/11] [media] vimc: common: Add vimc_colorimetry_clamp

[Helen Koike]

Colorimetry value will always be checked in the same way. Adding a
helper macro for that

Signed-off-by: Helen Koike 

---

Changes in v4:
[media] vimc: common: Add vimc_colorimetry_clamp
- this is a new patch in the series

Changes in v3: None
Changes in v2: None


---
 drivers/media/platform/vimc/vimc-common.h | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/media/platform/vimc/vimc-common.h 
b/drivers/media/platform/vimc/vimc-common.h
index 60ebde2..43483ee 100644
--- a/drivers/media/platform/vimc/vimc-common.h
+++ b/drivers/media/platform/vimc/vimc-common.h
@@ -23,6 +23,32 @@
 #include 
 
 /**
+ * struct vimc_colorimetry_clamp - Adjust colorimetry parameters
+ *
+ * @fmt:   the pointer to struct v4l2_pix_format or
+ * struct v4l2_mbus_framefmt
+ *
+ * Entities must check if colorimetry given by the userspace is valid, if not
+ * then set them as DEFAULT
+ */
+#define vimc_colorimetry_clamp(fmt)\
+do {   \
+   if ((fmt)->colorspace == V4L2_COLORSPACE_DEFAULT\
+   || (fmt)->colorspace > V4L2_COLORSPACE_DCI_P3) {\
+   (fmt)->colorspace = V4L2_COLORSPACE_DEFAULT;\
+   (fmt)->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;  \
+   (fmt)->quantization = V4L2_QUANTIZATION_DEFAULT;\
+   (fmt)->xfer_func = V4L2_XFER_FUNC_DEFAULT;  \
+   }   \
+   if ((fmt)->ycbcr_enc > V4L2_YCBCR_ENC_SMPTE240M)\
+   (fmt)->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;  \
+   if ((fmt)->quantization > V4L2_QUANTIZATION_LIM_RANGE)  \
+   (fmt)->quantization = V4L2_QUANTIZATION_DEFAULT;\
+   if ((fmt)->xfer_func > V4L2_XFER_FUNC_SMPTE2084)\
+   (fmt)->xfer_func = V4L2_XFER_FUNC_DEFAULT;  \
+} while (0)
+
+/**
  * struct vimc_pix_map - maps media bus code with v4l2 pixel format
  *
  * @code:  media bus format code defined by MEDIA_BUS_FMT_* macros
-- 
2.7.4

[PATCH v4 08/11] [media] vimc: cap: Support several image formats

[Helen Koike]

Allow user space to change the image format as the frame size, the
pixel format, colorspace, quantization, field YCbCr encoding
and the transfer function

Signed-off-by: Helen Koike 

---

Changes in v4:
[media] vimc: cap: Support several image formats
- add vimc_colorimetry_clamp macro
- replace V4L2_COLORSPACE_SRGB by V4L2_COLORSPACE_DEFAULT in the
default format struct

Changes in v3:
[media] vimc: cap: Support several image formats
- use *_DEFAULT macros for colorimetry in the default format
- clamp height and width of the image by an even value
- is user try to set colorspace to an invalid format, set all
colorimetry parameters to _DEFAULT
- remove V4L2_FMT_FLAG_COMPRESSED from vimc_cap_enum_fmt_vid_cap
- remove V4L2_BUF_TYPE_VIDEO_CAPTURE from vimc_cap_enum_fmt_vid_cap
- increase step_width and step_height to 2 instead of 1
- remove link validate function, use the one in vimc-common.c

Changes in v2:
[media] vimc: cap: Support several image formats
- this is a new commit in the serie (the old one was splitted in two)
- allow user space to change all fields from struct v4l2_pix_format
  (e.g. colospace, quantization, field, xfer_func, ycbcr_enc)
- link_validate and try_fmt: also checks colospace, quantization, 
field, xfer_func, ycbcr_enc
- add struct v4l2_pix_format fmt_default
- add enum_framesizes
- enum_fmt_vid_cap: enumerate all formats from vimc_pix_map_table
- add mode dev_dbg


---
 drivers/media/platform/vimc/vimc-capture.c | 117 +
 1 file changed, 101 insertions(+), 16 deletions(-)

diff --git a/drivers/media/platform/vimc/vimc-capture.c 
b/drivers/media/platform/vimc/vimc-capture.c
index 5bdecd1..359f59e 100644
--- a/drivers/media/platform/vimc/vimc-capture.c
+++ b/drivers/media/platform/vimc/vimc-capture.c
@@ -40,6 +40,14 @@ struct vimc_cap_device {
struct media_pipeline pipe;
 };
 
+static const struct v4l2_pix_format fmt_default = {
+   .width = 640,
+   .height = 480,
+   .pixelformat = V4L2_PIX_FMT_RGB24,
+   .field = V4L2_FIELD_NONE,
+   .colorspace = V4L2_COLORSPACE_DEFAULT,
+};
+
 struct vimc_cap_buffer {
/*
 * struct vb2_v4l2_buffer must be the first element
@@ -73,7 +81,7 @@ static void vimc_cap_get_format(struct vimc_ent_device *ved,
*fmt = vcap->format;
 }
 
-static int vimc_cap_fmt_vid_cap(struct file *file, void *priv,
+static int vimc_cap_g_fmt_vid_cap(struct file *file, void *priv,
  struct v4l2_format *f)
 {
struct vimc_cap_device *vcap = video_drvdata(file);
@@ -83,16 +91,98 @@ static int vimc_cap_fmt_vid_cap(struct file *file, void 
*priv,
return 0;
 }
 
+static int vimc_cap_try_fmt_vid_cap(struct file *file, void *priv,
+   struct v4l2_format *f)
+{
+   struct v4l2_pix_format *format = >fmt.pix;
+   const struct vimc_pix_map *vpix;
+
+   format->width = clamp_t(u32, format->width, VIMC_FRAME_MIN_WIDTH,
+   VIMC_FRAME_MAX_WIDTH) & ~1;
+   format->height = clamp_t(u32, format->height, VIMC_FRAME_MIN_HEIGHT,
+VIMC_FRAME_MAX_HEIGHT) & ~1;
+
+   /* Don't accept a pixelformat that is not on the table */
+   vpix = vimc_pix_map_by_pixelformat(format->pixelformat);
+   if (!vpix) {
+   format->pixelformat = fmt_default.pixelformat;
+   vpix = vimc_pix_map_by_pixelformat(format->pixelformat);
+   }
+   /* TODO: Add support for custom bytesperline values */
+   format->bytesperline = format->width * vpix->bpp;
+   format->sizeimage = format->bytesperline * format->height;
+
+   if (format->field == V4L2_FIELD_ANY)
+   format->field = fmt_default.field;
+
+   vimc_colorimetry_clamp(format);
+
+   return 0;
+}
+
+static int vimc_cap_s_fmt_vid_cap(struct file *file, void *priv,
+ struct v4l2_format *f)
+{
+   struct vimc_cap_device *vcap = video_drvdata(file);
+
+   /* Do not change the format while stream is on */
+   if (vb2_is_busy(>queue))
+   return -EBUSY;
+
+   vimc_cap_try_fmt_vid_cap(file, priv, f);
+
+   dev_dbg(vcap->vdev.v4l2_dev->dev, "%s: format update: "
+   "old:%dx%d (0x%x, %d, %d, %d, %d) "
+   "new:%dx%d (0x%x, %d, %d, %d, %d)\n", vcap->vdev.name,
+   /* old */
+   vcap->format.width, vcap->format.height,
+   vcap->format.pixelformat, vcap->format.colorspace,
+   vcap->format.quantization, vcap->format.xfer_func,
+   vcap->format.ycbcr_enc,
+   /* new */
+   f->fmt.pix.width, f->fmt.pix.height,
+   f->fmt.pix.pixelformat, f->fmt.pix.colorspace,
+   f->fmt.pix.quantization, 

[PATCH v4 09/11] [media] vimc: Subdevices as modules

[Helen Koike]

Change the core structure for adding subdevices in the topology.
Instead of calling the specific create function for each subdevice,
inject a child platform_device with the driver's name.
Each type of node in the topology (sensor, capture, debayer, scaler)
will register a platform_driver with the corresponding name through the
component subsystem.
Implementing a new subdevice type doesn't require vimc-core to be altered.

This facilitates future implementation of dynamic entities, where
hotpluging an entity in the topology is just a matter of
registering/unregistering a platform_device in the system.
It also facilitates other implementations of different nodes without
touching the core code and remove the need of a header file for each
type of node.

Signed-off-by: Helen Koike 

---

Changes in v4:
[media] vimc: Subdevices as modules
- Rebase without [media] vimc: Optimize frame generation the through
pipe
- s/EXPORT_SYMBOL/EXPORT_SYMBOL_GPL
- add struct vimc_platform_data to pass the entity's name to the
sudmodule
- Fix comment about vimc-input (remove vimc-output comment)

Changes in v3:
[media] vimc: Subdevices as modules
- This is a new patch in the series

Changes in v2: None


---
 drivers/media/platform/vimc/Makefile   |   7 +-
 drivers/media/platform/vimc/vimc-capture.c |  99 ---
 drivers/media/platform/vimc/vimc-capture.h |  28 --
 drivers/media/platform/vimc/vimc-common.c  |  38 +--
 drivers/media/platform/vimc/vimc-common.h  |  29 ++-
 drivers/media/platform/vimc/vimc-core.c| 405 +++--
 drivers/media/platform/vimc/vimc-sensor.c  |  93 +--
 drivers/media/platform/vimc/vimc-sensor.h  |  28 --
 8 files changed, 339 insertions(+), 388 deletions(-)
 delete mode 100644 drivers/media/platform/vimc/vimc-capture.h
 delete mode 100644 drivers/media/platform/vimc/vimc-sensor.h

diff --git a/drivers/media/platform/vimc/Makefile 
b/drivers/media/platform/vimc/Makefile
index 6b6ddf4..0e5d5ce 100644
--- a/drivers/media/platform/vimc/Makefile
+++ b/drivers/media/platform/vimc/Makefile
@@ -1,3 +1,6 @@
-vimc-objs := vimc-core.o vimc-capture.o vimc-common.o vimc-sensor.o
+vimc-objs := vimc-core.o
+vimc_capture-objs := vimc-capture.o
+vimc_common-objs := vimc-common.o
+vimc_sensor-objs := vimc-sensor.o
 
-obj-$(CONFIG_VIDEO_VIMC) += vimc.o
+obj-$(CONFIG_VIDEO_VIMC) += vimc.o vimc_capture.o vimc_common.o vimc_sensor.o
diff --git a/drivers/media/platform/vimc/vimc-capture.c 
b/drivers/media/platform/vimc/vimc-capture.c
index 359f59e..14cb32e 100644
--- a/drivers/media/platform/vimc/vimc-capture.c
+++ b/drivers/media/platform/vimc/vimc-capture.c
@@ -15,15 +15,21 @@
  *
  */
 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 
-#include "vimc-capture.h"
+#include "vimc-common.h"
+
+#define VIMC_CAP_DRV_NAME "vimc-capture"
 
 struct vimc_cap_device {
struct vimc_ent_device ved;
struct video_device vdev;
+   struct device *dev;
struct v4l2_pix_format format;
struct vb2_queue queue;
struct list_head buf_list;
@@ -131,7 +137,7 @@ static int vimc_cap_s_fmt_vid_cap(struct file *file, void 
*priv,
 
vimc_cap_try_fmt_vid_cap(file, priv, f);
 
-   dev_dbg(vcap->vdev.v4l2_dev->dev, "%s: format update: "
+   dev_dbg(vcap->dev, "%s: format update: "
"old:%dx%d (0x%x, %d, %d, %d, %d) "
"new:%dx%d (0x%x, %d, %d, %d, %d)\n", vcap->vdev.name,
/* old */
@@ -309,8 +315,7 @@ static int vimc_cap_buffer_prepare(struct vb2_buffer *vb)
unsigned long size = vcap->format.sizeimage;
 
if (vb2_plane_size(vb, 0) < size) {
-   dev_err(vcap->vdev.v4l2_dev->dev,
-   "%s: buffer too small (%lu < %lu)\n",
+   dev_err(vcap->dev, "%s: buffer too small (%lu < %lu)\n",
vcap->vdev.name, vb2_plane_size(vb, 0), size);
return -EINVAL;
}
@@ -335,8 +340,10 @@ static const struct media_entity_operations vimc_cap_mops 
= {
.link_validate  = vimc_link_validate,
 };
 
-static void vimc_cap_destroy(struct vimc_ent_device *ved)
+static void vimc_cap_comp_unbind(struct device *comp, struct device *master,
+void *master_data)
 {
+   struct vimc_ent_device *ved = dev_get_drvdata(comp);
struct vimc_cap_device *vcap = container_of(ved, struct vimc_cap_device,
ved);
 
@@ -385,42 +392,35 @@ static void vimc_cap_process_frame(struct vimc_ent_device 
*ved,
vb2_buffer_done(_buf->vb2.vb2_buf, VB2_BUF_STATE_DONE);
 }
 
-struct vimc_ent_device *vimc_cap_create(struct v4l2_device *v4l2_dev,
-   const char *const name,
-   u16 num_pads,
-   const unsigned long *pads_flag)
+static int 

[PATCH v4 07/11] [media] vimc: sen: Support several image formats

[Helen Koike]

Allow user space to change the image format as the frame size, the
media bus pixel format, colorspace, quantization, field YCbCr encoding
and the transfer function

Signed-off-by: Helen Koike 

---

Changes in v4:
[media] vimc: sen: Support several image formats
- use vimc_colorimetry_clamp macro
- replace V4L2_COLORSPACE_SRGB by V4L2_COLORSPACE_DEFAULT in the
default format struct

Changes in v3:
[media] vimc: sen: Support several image formats
- remove support for V4L2_FIELD_ALTERNATE (left as TODO for now)
- clamp image size to an even dimension for height and width
- set default values for colorimetry using _DEFAULT macro
- reset all values of colorimetry to _DEFAULT if user tries to
set an invalid colorspace

Changes in v2:
[media] vimc: sen: Support several image formats
- this is a new commit in the serie (the old one was splitted in two)
- add init_cfg to initialize try_fmt
- reorder code in vimc_sen_set_fmt
- allow user space to change all fields from struct v4l2_mbus_framefmt
  (e.g. colospace, quantization, field, xfer_func, ycbcr_enc)
- merge with patch for the enum_mbus_code and enum_frame_size
- change commit message
- add vimc_pix_map_by_index
- rename MIN/MAX macros
- check set_fmt default parameters for quantization, colorspace 
...media] vimc: sen: Support several image formats


---
 drivers/media/platform/vimc/vimc-common.c |   8 ++
 drivers/media/platform/vimc/vimc-common.h |  12 +++
 drivers/media/platform/vimc/vimc-sensor.c | 130 +++---
 3 files changed, 121 insertions(+), 29 deletions(-)

diff --git a/drivers/media/platform/vimc/vimc-common.c 
b/drivers/media/platform/vimc/vimc-common.c
index 6ad77fd..b698055 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -144,6 +144,14 @@ static const struct vimc_pix_map vimc_pix_map_list[] = {
},
 };
 
+const struct vimc_pix_map *vimc_pix_map_by_index(unsigned int i)
+{
+   if (i >= ARRAY_SIZE(vimc_pix_map_list))
+   return NULL;
+
+   return _pix_map_list[i];
+}
+
 const struct vimc_pix_map *vimc_pix_map_by_code(u32 code)
 {
unsigned int i;
diff --git a/drivers/media/platform/vimc/vimc-common.h 
b/drivers/media/platform/vimc/vimc-common.h
index 43483ee..fb3463c 100644
--- a/drivers/media/platform/vimc/vimc-common.h
+++ b/drivers/media/platform/vimc/vimc-common.h
@@ -22,6 +22,11 @@
 #include 
 #include 
 
+#define VIMC_FRAME_MAX_WIDTH 4096
+#define VIMC_FRAME_MAX_HEIGHT 2160
+#define VIMC_FRAME_MIN_WIDTH 16
+#define VIMC_FRAME_MIN_HEIGHT 16
+
 /**
  * struct vimc_colorimetry_clamp - Adjust colorimetry parameters
  *
@@ -139,6 +144,13 @@ static inline void vimc_pads_cleanup(struct media_pad 
*pads)
 int vimc_pipeline_s_stream(struct media_entity *ent, int enable);
 
 /**
+ * vimc_pix_map_by_index - get vimc_pix_map struct by its index
+ *
+ * @i: index of the vimc_pix_map struct in vimc_pix_map_list
+ */
+const struct vimc_pix_map *vimc_pix_map_by_index(unsigned int i);
+
+/**
  * vimc_pix_map_by_code - get vimc_pix_map struct by media bus code
  *
  * @code:  media bus format code defined by MEDIA_BUS_FMT_* macros
diff --git a/drivers/media/platform/vimc/vimc-sensor.c 
b/drivers/media/platform/vimc/vimc-sensor.c
index 6386ac1..d4f9705 100644
--- a/drivers/media/platform/vimc/vimc-sensor.c
+++ b/drivers/media/platform/vimc/vimc-sensor.c
@@ -24,8 +24,6 @@
 
 #include "vimc-sensor.h"
 
-#define VIMC_SEN_FRAME_MAX_WIDTH 4096
-
 struct vimc_sen_device {
struct vimc_ent_device ved;
struct v4l2_subdev sd;
@@ -36,18 +34,39 @@ struct vimc_sen_device {
struct v4l2_mbus_framefmt mbus_format;
 };
 
+static const struct v4l2_mbus_framefmt fmt_default = {
+   .width = 640,
+   .height = 480,
+   .code = MEDIA_BUS_FMT_RGB888_1X24,
+   .field = V4L2_FIELD_NONE,
+   .colorspace = V4L2_COLORSPACE_DEFAULT,
+};
+
+static int vimc_sen_init_cfg(struct v4l2_subdev *sd,
+struct v4l2_subdev_pad_config *cfg)
+{
+   unsigned int i;
+
+   for (i = 0; i < sd->entity.num_pads; i++) {
+   struct v4l2_mbus_framefmt *mf;
+
+   mf = v4l2_subdev_get_try_format(sd, cfg, i);
+   *mf = fmt_default;
+   }
+
+   return 0;
+}
+
 static int vimc_sen_enum_mbus_code(struct v4l2_subdev *sd,
   struct v4l2_subdev_pad_config *cfg,
   struct v4l2_subdev_mbus_code_enum *code)
 {
-   struct vimc_sen_device *vsen =
-   container_of(sd, struct vimc_sen_device, sd);
+   const struct vimc_pix_map *vpix = vimc_pix_map_by_index(code->index);
 
-   /* TODO: Add support for other codes */
-   if (code->index)
+   if (!vpix)
return -EINVAL;
 
-  

[PATCH v4 00/11] [media]: vimc: Virtual Media Control VPU's

[Helen Koike]

This patch series improves the current video processing units in vimc
(by adding more controls to the sensor and capture node, allowing the
user to configure different frame formats) and also adds a debayer
and a scaler node.
The debayer transforms the bayer format image received in its sink pad
to a bayer format by averaging the pixels within a mean window.
The scaler only scales up the image for now.

This patch series is based on media/master and it is available at:
https://github.com/helen-fornazier/opw-staging/tree/z/sent/vimc/vpu/v4

In this version I removed the commit
[media] vimc: Optimize frame generation through the pipe
There was a bug when multiple links going to the same sink was enabled,
I'll rework on it and re-send it in a different patch series

Changes in v4:
[media] vimc: common: Add vimc_link_validate
- remove vimc_fmt_pix_to_mbus(), replaced by
v4l2_fill_mbus_format()
- remove EXPORT_SYMBOL(vimc_link_validate), not necessary in
this patch, moved to submodules patch
- Fix multi-line comment style
- If colorspace is set to DEFAULT, then assume all the other
colorimetry parameters are also DEFAULT
[media] vimc: common: Add vimc_colorimetry_clamp
- this is a new patch in the series
[media] vimc: sen: Support several image formats
- use vimc_colorimetry_clamp macro
- replace V4L2_COLORSPACE_SRGB by V4L2_COLORSPACE_DEFAULT in the
default format struct
[media] vimc: cap: Support several image formats
- add vimc_colorimetry_clamp macro
- replace V4L2_COLORSPACE_SRGB by V4L2_COLORSPACE_DEFAULT in the
default format struct
[media] vimc: Subdevices as modules
- Rebase without [media] vimc: Optimize frame generation the through
pipe
- s/EXPORT_SYMBOL/EXPORT_SYMBOL_GPL
- add struct vimc_platform_data to pass the entity's name to the
sudmodule
- Fix comment about vimc-input (remove vimc-output comment)
[media] vimc: deb: Add debayer filter
- Rebase without [media] vimc: Optimize frame generation through
pipe
- use vimc_colorimetry_clamp
- replace V4L2_COLORSPACE_SRGB by V4L2_COLORSPACE_DEFAULT in the
default format struct
- use struct vimc_platform_data to retrieve the entity's name
[media] vimc: sca: Add scaler
- use vimc_colorimetry_clamp
- replace V4L2_COLORSPACE_SRGB by V4L2_COLORSPACE_DEFAULT in the
default format struct
- use struct vimc_platform_data to retrieve the entity's name

Changes in v3:
[media] vimc: sen: Integrate the tpg on the sensor
- Declare frame_size as a local variable
- Set tpg frame format before starting kthread
- s_stream(sd, 1): return 0 if stream is already enabled
- s_stream(sd, 0): return 0 if stream is already disabled
- s_stream: propagate error from kthread_stop
- coding style when calling tpg_s_bytesperline
- s/vimc_thread_sen/vimc_sen_tpg_thread
- fix multiline comment
- remove V4L2_FIELD_ALTERNATE from tpg_s_field
- remove V4L2_STD_PAL from tpg_fill_plane_buffer
[media] vimc: Move common code from the core
- This is a new patch in the series
[media] vimc: common: Add vimc_ent_sd_* helper
- add it in vimc-common.c instead in vimc-core.c
- fix vimc_ent_sd_register, use function parameter to assign
sd->entity.function instead of using a fixed value
- rename commit to add the "common" tag
[media] vimc: Add vimc_pipeline_s_stream in the core
- add it in vimc-common instead of vimc-core
- rename commit with "common" tag
[media] vimc: common: Add vimc_link_validate
- this is a new patch in the series
[media] vimc: sen: Support several image formats
- remove support for V4L2_FIELD_ALTERNATE (left as TODO for now)
- clamp image size to an even dimension for height and width
- set default values for colorimetry using _DEFAULT macro
- reset all values of colorimetry to _DEFAULT if user tries to
set an invalid colorspace
[media] vimc: cap: Support several image formats
- use *_DEFAULT macros for colorimetry in the default format
- clamp height and width of the image by an even value
- is user try to set colorspace to an invalid format, set all
colorimetry parameters to _DEFAULT
- remove V4L2_FMT_FLAG_COMPRESSED from vimc_cap_enum_fmt_vid_cap
- remove V4L2_BUF_TYPE_VIDEO_CAPTURE from vimc_cap_enum_fmt_vid_cap
- increase step_width and step_height to 2 instead of 1
- remove link validate function, use the one in vimc-common.c
[media] vimc: Subdevices as modules
- This is a new patch in the series
[media] vimc: deb: Add debayer filter
- Declare frame_size as a local variable
- s_stream(sd, 1): return 0 if stream is already enabled
- s_stream(sd, 0): 

Re: [PATCH 1/9] [media] s5p-jpeg: Reset the Codec before doing a soft reset

[Jacek Anaszewski]

Hi Thierry,

On 06/07/2017 02:34 PM, Thierry Escande wrote:
> Hi Jacek,
> 
> On 02/06/2017 21:50, Jacek Anaszewski wrote:
>> Hi Thierry,
>>
>> On 06/02/2017 06:02 PM, Thierry Escande wrote:
>>> From: Abhilash Kesavan 
>>>
>>> This patch resets the encoding and decoding register bits before doing a
>>> soft reset.
>>>
>>> Signed-off-by: Tony K Nadackal 
>>> Signed-off-by: Thierry Escande 
>>> ---
>>>   drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 4 
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
>>> b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
>>> index a1d823a..9ad8f6d 100644
>>> --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
>>> +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
>>> @@ -21,6 +21,10 @@ void exynos4_jpeg_sw_reset(void __iomem *base)
>>>   unsigned int reg;
>>> reg = readl(base + EXYNOS4_JPEG_CNTL_REG);
>>> +writel(reg & ~(EXYNOS4_DEC_MODE | EXYNOS4_ENC_MODE),
>>> +   base + EXYNOS4_JPEG_CNTL_REG);
>>
>> Why is it required? It would be nice if commit message explained that.
> 
> Unfortunately the bug entry in the ChromeOS issue tracker does not
> mention more information about that and the patch author is no more
> reachable on that email address.
> 
> So unless someone else knows the answer I won't be able to give more
> explanation in the commit message...

Unfortunately I don't have longer access to the hardware and
can't test these changes. Have you tested them, or just cherry-picked
from the bug tracker?

-- 
Best regards,
Jacek Anaszewski

Re: [PATCH v7 1/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation

[Niklas Söderlund]

Hi Sakari,

Thanks for your feedback.

On 2017-05-29 14:16:25 +0300, Sakari Ailus wrote:
> Hi Niklas,
> 
> On Wed, May 24, 2017 at 02:13:52AM +0200, Niklas Söderlund wrote:
> > From: Niklas Söderlund 
> > 
> > Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
> > are located between the video sources (CSI-2 transmitters) and the video
> > grabbers (VIN) on Gen3 of Renesas R-Car SoC.
> > 
> > Each CSI-2 device is connected to more then one VIN device which
> > simultaneously can receive video from the same CSI-2 device. Each VIN
> > device can also be connected to more then one CSI-2 device. The routing
> > of which link are used are controlled by the VIN devices. There are only
> > a few possible routes which are set by hardware limitations, which are
> > different for each SoC in the Gen3 family.
> > 
> > To work with the limitations of routing possibilities it is necessary
> > for the DT bindings to describe which VIN device is connected to which
> > CSI-2 device. This is why port 1 needs to to assign reg numbers for each
> > VIN device that be connected to it. To setup and to know which links are
> > valid for each SoC is the responsibility of the VIN driver since the
> > register to configure it belongs to the VIN hardware.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  .../devicetree/bindings/media/rcar-csi2.txt| 116 
> > +
> >  1 file changed, 116 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/rcar-csi2.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/media/rcar-csi2.txt 
> > b/Documentation/devicetree/bindings/media/rcar-csi2.txt
> > new file mode 100644
> > index ..f6e2027ee92b171a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/rcar-csi2.txt
> > @@ -0,0 +1,116 @@
> > +Renesas R-Car MIPI CSI-2
> > +
> > +
> > +The rcar-csi2 device provides MIPI CSI-2 capabilities for the Renesas R-Car
> > +family of devices. It is to be used in conjunction with the R-Car VIN 
> > module,
> > +which provides the video capture capabilities.
> > +
> > + - compatible: Must be one or more of the following
> > +   - "renesas,r8a7795-csi2" for the R8A7795 device.
> > +   - "renesas,r8a7796-csi2" for the R8A7796 device.
> > +   - "renesas,rcar-gen3-csi2" for a generic R-Car Gen3 compatible device.
> > +
> > +   When compatible with a generic version nodes must list the
> > +   SoC-specific version corresponding to the platform first
> > +   followed by the generic version.
> > +
> > + - reg: the register base and size for the device registers
> > + - interrupts: the interrupt for the device
> > + - clocks: Reference to the parent clock
> > +
> > +The device node should contain two 'port' child nodes according to the
> > +bindings defined in Documentation/devicetree/bindings/media/
> > +video-interfaces.txt. Port 0 should connect the node that is the video
> > +source for to the CSI-2. Port 1 should connect all the R-Car VIN
> > +modules, which can make use of the CSI-2 module.
> 
> Should or shall?
> 
> I guess you could add that it is possible to leave them unconnected, too.

Which ports/endpoints are you talking about? In my mind it's not allowed 
to leave them unconnected.

If there ever is a system with only 4 VIN instances (I'm not aware of 
any such system) then yes the endpoints for those VIN not present in the 
system in port 1 should be left unconnected but other then that they 
should all be mandatory right? Or am I missing something?

> 
> > +
> > +- Port 0 - Video source
> > +   - Reg 0 - sub-node describing the endpoint that is the video source
> 
> Which endpoint properties are mandatory for the receiver? Which ones are
> optional? (I.e. it shouldn't be necessary to read driver code to write board
> description.)

I will add a note that all endpoints in port 0 are mandatory and that 
all endpoints that represents a connection to a VIN instance in the 
system is mandatory for next version. Thanks I did not think about this 
possibility.

> 
> > +
> > +- Port 1 - VIN instances
> > +   - Reg 0 - sub-node describing the endpoint that is VIN0
> > +   - Reg 1 - sub-node describing the endpoint that is VIN1
> > +   - Reg 2 - sub-node describing the endpoint that is VIN2
> > +   - Reg 3 - sub-node describing the endpoint that is VIN3
> > +   - Reg 4 - sub-node describing the endpoint that is VIN4
> > +   - Reg 5 - sub-node describing the endpoint that is VIN5
> > +   - Reg 6 - sub-node describing the endpoint that is VIN6
> > +   - Reg 7 - sub-node describing the endpoint that is VIN7
> > +
> > +Example:
> > +
> > +/* SoC properties */
> > +
> > +csi20: csi2@fea8 {
> > +compatible = "renesas,r8a7796-csi2";
> > +reg = <0 0xfea8 0 0x1>;
> > +interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
> > +clocks = < CPG_MOD 714>;
> > +

Re: [PATCH v10 1/1] [media] i2c: add support for OV13858 sensor

[Sakari Ailus]

Hi Hyungwoo,

On Tue, Jun 13, 2017 at 02:29:25PM +, Yang, Hyungwoo wrote:
> 
> 
> Here is the _DSD for 19.2Mhz

If you attached it, the list server most likely removed the attachment.
Could you send it again in-line?

> 
> 
> 
> 
> 
> i've inlined my comments.
> 
> 
> 
> -Original Message-
> > From: Sakari Ailus [mailto:sakari.ai...@iki.fi] 
> > Sent: Tuesday, June 13, 2017 3:18 AM
> > To: Yang, Hyungwoo 
> > Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com; Zheng, Jian 
> > Xu ; tf...@chromium.org; Hsu, Cedric 
> > 
> > Subject: Re: [PATCH v10 1/1] [media] i2c: add support for OV13858 sensor
> > 
> > Hi Hyungwoo,
> > 
> > On Mon, Jun 12, 2017 at 05:56:00PM -0700, Hyungwoo Yang wrote:
...
> > > + if (ret)
> > > + return ret;
> > > + ov13858->num_of_skip_frames = val;
> > > +
> > > + device_for_each_child_node(dev, child) {
> > > + if (!fwnode_property_present(child, "link"))
> > > + continue;
> > 
> > You shouldn't need these here.
> > 
> 
> ?? just get child and see if the expected property is found ?
> Acked

Your child nodes shouldn't look like that, nor an individual driver should
need to be directly interested in them.

Please see Documentation/acpi/dsd/graph.txt .

> > > + if (ret) {
> > > + dev_err(dev, "link-rate error : %d\n",  ret);
> > > + goto error;
> > > + }
> > > + link_freq_menu_items[freq_id] = val;
> > > +
> > > + freq_cfg = _freq_configs[freq_id];
> > > + ret = fwnode_property_read_u32(fwn_freq, "pixel-rate", );
> > 
> > This is something a sensor driver needs to know. It may not be present in 
> > device firmware.
> > 
> 
> Real frequency of the link can be different from input clock frequency so
> pixel reate which is dependent on link frequency should be here.

The pixel rate does depend on the link frequency, but you can either
calculate it in the driver OR make it specific your sensor configuration.

> 
> > > + if (ret) {
> > > + dev_err(dev, "pixel-rate error : %d\n",  ret);
> > > + goto error;
> > > + }
> > > + freq_cfg->pixel_rate = val;
> > > +
> > > + num_of_values = fwnode_property_read_u32_array(fwn_freq,
> > > +"pll-regs",
> > 
> > This is something that could go to device firmware but I don't really see a 
> > reason for that at the moment. Can this continue to be a part of the driver 
> > for now?
> > 
> > Could you also check that the external clock frequency matches with what 
> > your register lists assume? The property should be called "clock-frequency"
> > and it's a u32.
> 
> Are you saying, for now, let's remove pll reg/value pairs from _DSD  and
> just support only one input clock frequency ?

That would help getting the driver merged during this merge window. It's
always possible to add support for different configurations later on.

-- 
Kind regards,

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

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

[Mauro Carvalho Chehab]

Hi Linus,

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

For:

  - some build dependency issues at CEC core with randconfigs;
  - fix an off by one error at vb2;
  - a race fix at cec core;
  - driver fixes at tc358743, sir_ir and rainshadow-cec.

Regards,
Mauro

-

The following changes since commit 963761a0b2e85663ee4a5630f72930885a06598a:

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

are available in the git repository at:

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

for you to fetch changes up to f9f314f323951a33d8b4a4f63f7d04b7f3bc0603:

  [media] media/cec.h: use IS_REACHABLE instead of IS_ENABLED (2017-06-08 
16:52:28 -0300)


media fixes for v4.12-rc6


Arnd Bergmann (2):
  [media] cec: improve MEDIA_CEC_RC dependencies
  [media] cec-notifier.h: handle unreachable CONFIG_CEC_CORE

Christophe JAILLET (1):
  [media] vb2: Fix an off by one error in 'vb2_plane_vaddr'

Hans Verkuil (2):
  [media] cec: race fix: don't return -ENONET in cec_receive()
  [media] media/cec.h: use IS_REACHABLE instead of IS_ENABLED

Philipp Zabel (1):
  [media] tc358743: fix register i2c_rd/wr function fix

Sean Young (1):
  [media] sir_ir: infinite loop in interrupt handler

Wei Yongjun (1):
  [media] rainshadow-cec: Fix missing spin_lock_init()

 drivers/media/cec/Kconfig |  1 +
 drivers/media/cec/cec-api.c   |  8 +---
 drivers/media/i2c/tc358743.c  |  2 +-
 drivers/media/rc/sir_ir.c |  6 ++
 drivers/media/usb/rainshadow-cec/rainshadow-cec.c |  1 +
 drivers/media/v4l2-core/videobuf2-core.c  |  2 +-
 include/media/cec-notifier.h  | 10 ++
 include/media/cec.h   |  2 +-
 8 files changed, 22 insertions(+), 10 deletions(-)

Re: [PATCH v2 0/15] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator

[Mauro Carvalho Chehab]

Hi Takiguchi-san,

Em Thu, 25 May 2017 15:15:39 +0900
"Takiguchi, Yasunari"  escreveu:

> Hi, all
> 
> I sent the patch series of Sony CXD2880 DVB-T2/T tuner + demodulator driver 
> on Apr/14.
> Are there any comments, advices and review results for them?

Usually, reviewing drivers takes more time, as one needs to reserve a
long period of time for reviewing. Sorry for the delay.

> I'd like to get better understanding of current review status for our codes.

Just sent today a review. There are some things that need to be
changed in order to get it into a better shape and make it easier
to review. In particular, it should be using some Kernel internal APIs,
instead of coming with re-implementation of existing core code. That's fine. 
It is very unusual that the first contributions from a new Kernel
developer to gets everything the way as it is expected mainstream ;-)

One thing that come into my mind, besides what was already commented,
is that it seems you added an abstraction layer. We don't like such
layers very much, as it makes harder to understand the driver, usually
for very little benefit.

On this first review, I didn't actually try to understand what's
going on there. As the driver doesn't contain any comments inside,
it makes harder to understand why some things were coded using
such approach.

Thanks,
Mauro

[PATCH v3 0/2] v4l2-async: add subnotifier registration for subdevices

[Niklas Söderlund]

Hi,

This series enables incremental async find and bind of subdevices,
please se patch 2/2 for a more detailed description.

This is tested on Renesas H3 and M3-W together with the Renesas CSI-2
and VIN Gen3 driver (posted separately). It is based on top of the media-tree.

* Changes since v2
- Fixed lots of spelling mistakes, thanks Hans!
- Used a goto instead if state variable when restarting iteration over 
  subdev list as suggested by Sakari. Thank you it's much easier read 
  now.
- Added Acked-by from Sakari and Hans, thanks!
- Rebased to latest media-tree.

* Changes since v1:
- Added a pre-patch which adds an error check which was previously in
  the new incremental async code but is more useful on its own.
- Added documentation to Documentation/media/kapi/v4l2-subdev.rst.
- Fixed data type of bool variable.
- Added call to lockdep_assert_held(), thanks Sakari.
- Fixed commit messages typo, thanks Sakari.


Niklas Söderlund (2):
  v4l: async: check for v4l2_dev in v4l2_async_notifier_register()
  v4l: async: add subnotifier registration for subdevices

 Documentation/media/kapi/v4l2-subdev.rst | 20 ++
 drivers/media/v4l2-core/v4l2-async.c | 68 +++-
 include/media/v4l2-async.h   | 22 +++
 3 files changed, 100 insertions(+), 10 deletions(-)

-- 
2.13.1

[PATCH v3 1/2] v4l: async: check for v4l2_dev in v4l2_async_notifier_register()

[Niklas Söderlund]

Add a check for v4l2_dev to v4l2_async_notifier_register() as to fail as
early as possible since this will fail later in v4l2_async_test_notify().

Signed-off-by: Niklas Söderlund 
Acked-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/v4l2-async.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index cbd919d4edd27e17..c16200c88417b151 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -148,7 +148,8 @@ int v4l2_async_notifier_register(struct v4l2_device 
*v4l2_dev,
struct v4l2_async_subdev *asd;
int i;
 
-   if (!notifier->num_subdevs || notifier->num_subdevs > V4L2_MAX_SUBDEVS)
+   if (!v4l2_dev || !notifier->num_subdevs ||
+   notifier->num_subdevs > V4L2_MAX_SUBDEVS)
return -EINVAL;
 
notifier->v4l2_dev = v4l2_dev;
-- 
2.13.1

[PATCH v3 2/2] media: entity: Add media_entity_get_fwnode_pad() function

[Niklas Söderlund]

This is a wrapper around the media entity get_fwnode_pad operation.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/media-entity.c | 35 +++
 include/media/media-entity.h | 23 +++
 2 files changed, 58 insertions(+)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index bc44193efa4798b4..35a15263793f71e1 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -18,6 +18,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -386,6 +387,40 @@ struct media_entity *media_graph_walk_next(struct 
media_graph *graph)
 }
 EXPORT_SYMBOL_GPL(media_graph_walk_next);
 
+int media_entity_get_fwnode_pad(struct media_entity *entity,
+   struct fwnode_handle *fwnode,
+   unsigned int direction)
+{
+   struct fwnode_endpoint endpoint;
+   int i, ret;
+
+   if (!entity->ops || !entity->ops->get_fwnode_pad) {
+   for (i = 0; i < entity->num_pads; i++) {
+   if (entity->pads[i].flags & direction)
+   return i;
+   }
+
+   return -ENXIO;
+   }
+
+   ret = fwnode_graph_parse_endpoint(fwnode, );
+   if (ret)
+   return ret;
+
+   ret = entity->ops->get_fwnode_pad();
+   if (ret < 0)
+   return ret;
+
+   if (ret >= entity->num_pads)
+   return -ENXIO;
+
+   if (!(entity->pads[ret].flags & direction))
+   return -ENXIO;
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(media_entity_get_fwnode_pad);
+
 /* 
-
  * Pipeline management
  */
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index 46eeb036aa330534..4114e06964824ec9 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -821,6 +821,29 @@ struct media_pad *media_entity_remote_pad(struct media_pad 
*pad);
 struct media_entity *media_entity_get(struct media_entity *entity);
 
 /**
+ * media_entity_get_fwnode_pad - Get pad number from fwnode
+ *
+ * @entity: The entity
+ * @fwnode: Pointer to the fwnode_handle which should be used to find the pad
+ * @direction: Expected direction of the pad, as defined in
+ *:ref:`include/uapi/linux/media.h `
+ *(seek for ``MEDIA_PAD_FL_*``)
+ *
+ * This function can be used to resolve the media pad number from
+ * a fwnode. This is useful for devices which use more complex
+ * mappings of media pads.
+ *
+ * If the entity dose not implement the get_fwnode_pad() operation
+ * then this function searches the entity for the first pad that
+ * matches the @direction.
+ *
+ * Return: returns the pad number on success or a negative error code.
+ */
+int media_entity_get_fwnode_pad(struct media_entity *entity,
+   struct fwnode_handle *fwnode,
+   unsigned int direction);
+
+/**
  * media_graph_walk_init - Allocate resources used by graph walk.
  *
  * @graph: Media graph structure that will be used to walk the graph
-- 
2.13.1

[PATCH v3 0/2] media: entity: add operation to help map DT node to media pad

[Niklas Söderlund]

Hi,

This series add a new entity operation which will aid capture
drivers to map a port/endpoint in DT to a media graph pad.

This series is implemented support for the ongoing ADV748x work by
Kieran Bingham. In his work he have a driver which registers more then
one subdevice. So when a driver finds this subdevice it must be able to
ask the subdevice itself which pad number correspond to the DT endpoint
the driver used to bind subdevice in the first place.

This is tested on Renesas H3 and M3-W together with the Renesas CSI-2
and VIN Gen3 driver (posted separately). It is based on top media-tree.

* Changes since v2
- Renamed pad_from_fwnode to get_fwnode_pad as suggested by Sakari.
- Return pad number instead of passing it as a pointer to both 
  get_fwnode_pad() and media_entity_pad_from_fwnode().
- Document possible flags of the direction argument to 
  media_entity_pad_from_fwnode().
- Use unsigned int instead of int for bitmask.
- Fix numerous spelling mistakes, thanks Hans!
- Rebased to latest media-tree.

* Changes since v1
- Rebased work ontop of Sakaris fwnode branch and make use of the fwnode 
  instead of the raw DT port/reg numbers.
- Do not assume DT port is equal to pad number if the driver do not 
  implement the lookup function. Instead search for the first pad with
  the correct direction and use that. Thanks Sakari for the suggestion!
- Use ENXIO instead of EINVAL to signal lookup error.

Niklas Söderlund (2):
  media: entity: Add get_fwnode_pad entity operation
  media: entity: Add media_entity_get_fwnode_pad() function

 drivers/media/media-entity.c | 35 +++
 include/media/media-entity.h | 28 
 2 files changed, 63 insertions(+)

-- 
2.13.1

[PATCH v3 1/2] media: entity: Add get_fwnode_pad entity operation

[Niklas Söderlund]

The optional operation can be used by entities to report how it maps its
fwnode endpoints to media pad numbers. This is useful for devices which
require advanced mappings of pads.

Signed-off-by: Niklas Söderlund 
---
 include/media/media-entity.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index c7c254c5bca1761b..46eeb036aa330534 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -21,6 +21,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -171,6 +172,9 @@ struct media_pad {
 
 /**
  * struct media_entity_operations - Media entity operations
+ * @get_fwnode_pad:Return the pad number based on a fwnode endpoint or
+ * a negative value on error. This operation can be used
+ * to map a fwnode to a media pad number. Optional.
  * @link_setup:Notify the entity of link changes. The 
operation can
  * return an error, in which case link setup will be
  * cancelled. Optional.
@@ -184,6 +188,7 @@ struct media_pad {
  *mutex held.
  */
 struct media_entity_operations {
+   int (*get_fwnode_pad)(struct fwnode_endpoint *endpoint);
int (*link_setup)(struct media_entity *entity,
  const struct media_pad *local,
  const struct media_pad *remote, u32 flags);
-- 
2.13.1

[PATCH v3 2/2] v4l: async: add subnotifier registration for subdevices

[Niklas Söderlund]

When the registered() callback of v4l2_subdev_internal_ops is called the
subdevice has access to the master devices v4l2_dev and it's called with
the async frameworks list_lock held. In this context the subdevice can
register its own notifiers to allow for incremental discovery of
subdevices.

The master device registers the subdevices closest to itself in its
notifier while the subdevice(s) register notifiers for their closest
neighboring devices when they are registered. Using this incremental
approach two problems can be solved:

1. The master device no longer has to care how many devices exist in
   the pipeline. It only needs to care about its closest subdevice and
   arbitrary long pipelines can be created without having to adapt the
   master device for each case.

2. Subdevices which are represented as a single DT node but register
   more than one subdevice can use this to improve the pipeline
   discovery, since the subdevice driver is the only one who knows which
   of its subdevices is linked with which subdevice of a neighboring DT
   node.

To enable subdevices to register/unregister notifiers from the
registered()/unregistered() callback v4l2_async_subnotifier_register()
and v4l2_async_subnotifier_unregister() are added. These new notifier
register functions are similar to the master device equivalent functions
but run without taking the v4l2-async list_lock which already is held
when the registered()/unregistered() callbacks are called.

Signed-off-by: Niklas Söderlund 
Acked-by: Hans Verkuil 
Acked-by: Sakari Ailus 
---
 Documentation/media/kapi/v4l2-subdev.rst | 20 ++
 drivers/media/v4l2-core/v4l2-async.c | 65 +++-
 include/media/v4l2-async.h   | 22 +++
 3 files changed, 98 insertions(+), 9 deletions(-)

diff --git a/Documentation/media/kapi/v4l2-subdev.rst 
b/Documentation/media/kapi/v4l2-subdev.rst
index e1f0b726e438f963..e308f30887a8f1b5 100644
--- a/Documentation/media/kapi/v4l2-subdev.rst
+++ b/Documentation/media/kapi/v4l2-subdev.rst
@@ -262,6 +262,26 @@ is called. After all subdevices have been located the 
.complete() callback is
 called. When a subdevice is removed from the system the .unbind() method is
 called. All three callbacks are optional.
 
+Subdevice drivers might in turn register subnotifier objects with an
+array of other subdevice descriptors that the subdevice needs for its
+own operation. Subnotifiers are an extension of the bridge drivers
+notifier to allow for a incremental registering and matching of
+subdevices. This is useful when a driver only has information about
+which subdevice is closest to itself and would require knowledge from the
+driver of that subdevice to know which other subdevice(s) lie beyond.
+By registering subnotifiers drivers can incrementally move the subdevice
+matching down the chain of drivers. This is performed using the
+:c:func:`v4l2_async_subnotifier_register` call. To unregister the
+subnotifier the driver has to call
+:c:func:`v4l2_async_subnotifier_unregister`. These functions and their
+arguments behave almost the same as the bridge driver notifiers
+described above and are treated equally by the V4L2 core when matching
+asynchronously registered subdevices. The differences are that the
+subnotifier functions act on :c:type:`v4l2_subdev` instead of
+:c:type:`v4l2_device` and that they should be called from the subdevice's
+``.registered()`` and ``.unregistered()``
+:c:type:`v4l2_subdev_internal_ops` callbacks instead of at probe time.
+
 V4L2 sub-device userspace API
 -
 
diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index c16200c88417b151..0b8135bf55af6b09 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -141,8 +141,9 @@ static void v4l2_async_cleanup(struct v4l2_subdev *sd)
sd->dev = NULL;
 }
 
-int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
-struct v4l2_async_notifier *notifier)
+static int v4l2_async_do_notifier_register(struct v4l2_device *v4l2_dev,
+  struct v4l2_async_notifier *notifier,
+  bool subnotifier)
 {
struct v4l2_subdev *sd, *tmp;
struct v4l2_async_subdev *asd;
@@ -174,8 +175,17 @@ int v4l2_async_notifier_register(struct v4l2_device 
*v4l2_dev,
list_add_tail(>list, >waiting);
}
 
-   mutex_lock(_lock);
+   if (subnotifier)
+   lockdep_assert_held(_lock);
+   else
+   mutex_lock(_lock);
 
+   /*
+* This function can be called recursively so the list
+* might be modified in a recursive call. Start from the
+* top of the list each iteration.
+*/
+again:
list_for_each_entry_safe(sd, tmp, _list, 

RE: [PATCH v10 1/1] [media] i2c: add support for OV13858 sensor

[Yang, Hyungwoo]

Here is the _DSD for 19.2Mhz





i've inlined my comments.



-Original Message-
> From: Sakari Ailus [mailto:sakari.ai...@iki.fi] 
> Sent: Tuesday, June 13, 2017 3:18 AM
> To: Yang, Hyungwoo 
> Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com; Zheng, Jian Xu 
> ; tf...@chromium.org; Hsu, Cedric 
> 
> Subject: Re: [PATCH v10 1/1] [media] i2c: add support for OV13858 sensor
> 
> Hi Hyungwoo,
> 
> On Mon, Jun 12, 2017 at 05:56:00PM -0700, Hyungwoo Yang wrote:
> > This patch adds driver for Omnivision's ov13858 sensor, the driver 
> > supports following features:
> > 
> > - manual exposure/gain(analog and digital) control support
> > - two link frequencies
> > - VBLANK/HBLANK support
> > - test pattern support
> > - media controller support
> > - runtime pm support
> > - supported resolutions
> >   + 4224x3136 at 30FPS
> >   + 2112x1568 at 30FPS(default) and 60FPS
> >   + 2112x1188 at 30FPS(default) and 60FPS
> >   + 1056x784 at 30FPS(default) and 60FPS
> > 
> > Signed-off-by: Hyungwoo Yang 
> > ---
> >  drivers/media/i2c/Kconfig   |8 +
> >  drivers/media/i2c/Makefile  |1 +
> >  drivers/media/i2c/ov13858.c | 1920 
> > +++
> >  3 files changed, 1929 insertions(+)
> >  create mode 100644 drivers/media/i2c/ov13858.c
> > 
> > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig 
> > index c380e24..26a9a3c 100644
> > --- a/drivers/media/i2c/Kconfig
> > +++ b/drivers/media/i2c/Kconfig
> > @@ -600,6 +600,14 @@ config VIDEO_OV9650
> >   This is a V4L2 sensor-level driver for the Omnivision
> >   OV9650 and OV9652 camera sensors.
> >  
> > +config VIDEO_OV13858
> > +   tristate "OmniVision OV13858 sensor support"
> > +   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> > +   depends on MEDIA_CAMERA_SUPPORT
> 
> select V4L2_FWNODE
> 
> > +   ---help---
> > + This is a Video4Linux2 sensor-level driver for the OmniVision
> > + OV13858 camera.
> > +
> >  config VIDEO_VS6624
> > tristate "ST VS6624 sensor support"
> > depends on VIDEO_V4L2 && I2C
> > diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile 
> > index 62323ec..3f4dc02 100644
> > --- a/drivers/media/i2c/Makefile
> > +++ b/drivers/media/i2c/Makefile
> > @@ -63,6 +63,7 @@ obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
> >  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
> >  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
> >  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
> > +obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
> >  obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
> >  obj-$(CONFIG_VIDEO_MT9M111) += mt9m111.o
> >  obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o diff --git 
> > a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c new file 
> > mode 100644 index 000..0334cee
> > --- /dev/null
> > +++ b/drivers/media/i2c/ov13858.c
> 
> ...
> 
> > +static int ov13858_read_platform_data(struct device *dev,
> > + struct ov13858 *ov13858)
> > +{
> > +   struct fwnode_handle *child, *fwn_freq;
> > +   struct ov13858_link_freq_config *freq_cfg;
> > +   struct ov13858_reg *pll_regs;
> > +   int i, freq_id = 0, ret, num_of_values, num_of_pairs;
> > +   u32 val, *val_array;
> > +
> > +   /* For now, platform data is only available from fwnode */
> > +   if (!dev_fwnode(dev)) {
> > +   dev_err(dev, "no platform data\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   ret = device_property_read_u32(dev, "skip-frames", );
> 
> This is a property of the sensor (or its configuration), not the hardware 
> platform. Please use a constant if the value does not depend on configuration.
> 
> > +   if (ret)
> > +   return ret;
> > +   ov13858->num_of_skip_frames = val;
> > +
> > +   device_for_each_child_node(dev, child) {
> > +   if (!fwnode_property_present(child, "link"))
> > +   continue;
> 
> You shouldn't need these here.
> 

?? just get child and see if the expected property is found ?
Acked

> > +
> > +   /* Limited number of link frequencies are allowed */
> > +   if (freq_id == OV13858_NUM_OF_LINK_FREQS) {
> > +   dev_err(dev, "no more than two freqs\n");
> > +   ret = -EINVAL;
> > +   goto error;
> > +   }
> > +
> > +   fwn_freq = fwnode_get_next_child_node(child, NULL);
> > +   if (!fwn_freq) {
> > +   ret = -EINVAL;
> > +   goto error;
> > +   }
> > +
> > +   /* Get link freq menu item for LINK_FREQ control */
> > +   ret = fwnode_property_read_u32(fwn_freq, "link-rate", );
> 
> If you need to know the valid link frequencies (among other things), please 
> use v4l2_fwnode_endpoint_alloc_parse() instead. It parses the firmware tables 
> for you.
> 

Acked.

> > +   if (ret) {
> > +   dev_err(dev, "link-rate error : %d\n",  ret);
> > + 

[GIT PULL FOR v4.13] (v2) Added max2175 and rcar_drif drivers

[Hans Verkuil]

Changes since the previous pull request:

- made i2s control private
- add maintainers entries
- fix sparse/smatch errors
- slightly modified the code so we don't hit a regmap_read_poll_timeout macro
  bug (patches to fix that were posted separately, out of scope for media).

Regards,

Hans

The following changes since commit 47f910f0e0deb880c2114811f7ea1ec115a19ee4:

  [media] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev (2017-06-08 
16:55:25 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git rcar-drif

for you to fetch changes up to 1c226f355783196a85cfe4446b2817ea15fff2ea:

  MAINTAINERS: Add entry for R-Car DRIF & MAX2175 drivers (2017-06-13 15:52:39 
+0200)


Ramesh Shanmugasundaram (8):
  media: v4l2-ctrls: Reserve controls for MAX217X
  dt-bindings: media: Add MAX2175 binding description
  media: i2c: max2175: Add MAX2175 support
  media: Add new SDR formats PC16, PC18 & PC20
  doc_rst: media: New SDR formats PC16, PC18 & PC20
  dt-bindings: media: Add Renesas R-Car DRIF binding
  media: platform: rcar_drif: Add DRIF support
  MAINTAINERS: Add entry for R-Car DRIF & MAX2175 drivers

 Documentation/devicetree/bindings/media/i2c/max2175.txt  |   59 
 Documentation/devicetree/bindings/media/renesas,drif.txt |  176 ++
 Documentation/devicetree/bindings/property-units.txt |1 +
 Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst  |   55 
 Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst  |   55 
 Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst  |   54 +++
 Documentation/media/uapi/v4l/sdr-formats.rst |3 +
 Documentation/media/v4l-drivers/index.rst|1 +
 Documentation/media/v4l-drivers/max2175.rst  |   62 
 MAINTAINERS  |   19 ++
 drivers/media/i2c/Kconfig|   12 +
 drivers/media/i2c/Makefile   |2 +
 drivers/media/i2c/max2175.c  | 1453 
+
 drivers/media/i2c/max2175.h  |  109 +++
 drivers/media/platform/Kconfig   |   25 ++
 drivers/media/platform/Makefile  |1 +
 drivers/media/platform/rcar_drif.c   | 1498 

 drivers/media/v4l2-core/v4l2-ioctl.c |3 +
 include/uapi/linux/max2175.h |   28 ++
 include/uapi/linux/v4l2-controls.h   |5 +
 include/uapi/linux/videodev2.h   |3 +
 21 files changed, 3624 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/max2175.txt
 create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
 create mode 100644 Documentation/media/v4l-drivers/max2175.rst
 create mode 100644 drivers/media/i2c/max2175.c
 create mode 100644 drivers/media/i2c/max2175.h
 create mode 100644 drivers/media/platform/rcar_drif.c
 create mode 100644 include/uapi/linux/max2175.h

Re: [PATCH v2 1/2] iopoll: Avoid namespace collision within macros & tidyup

[Geert Uytterhoeven]

Hi Ramesh,

On Tue, Jun 13, 2017 at 3:33 PM, Ramesh Shanmugasundaram
 wrote:
> Renamed variable "timeout" to "__timeout" to avoid namespace collision.
> Tidy up macro arguments with paranthesis.
>
> Signed-off-by: Ramesh Shanmugasundaram 
> 

Thanks for your patches!

> --- a/include/linux/iopoll.h
> +++ b/include/linux/iopoll.h
> @@ -42,18 +42,19 @@
>   */
>  #define readx_poll_timeout(op, addr, val, cond, sleep_us, timeout_us)  \
>  ({ \
> -   ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
> +   ktime_t __timeout = ktime_add_us(ktime_get(), timeout_us); \

I think timeout_us should be within parentheses, too.

> might_sleep_if(sleep_us); \
> for (;;) { \
> (val) = op(addr); \
> if (cond) \
> break; \
> -   if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
> +   if ((timeout_us) && \
> +   ktime_compare(ktime_get(), __timeout) > 0) { \
> (val) = op(addr); \
> break; \
> } \
> if (sleep_us) \
> -   usleep_range((sleep_us >> 2) + 1, sleep_us); \
> +   usleep_range(((sleep_us) >> 2) + 1, sleep_us); \

Same for sleep_us.

Also in readx_poll_timeout_atomic(), and in your second patch.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [RFC PATCH v3 09/11] [media] vimc: Subdevices as modules

[Hans Verkuil]

On 06/13/17 15:23, Helen Koike wrote:
> Hi Hans,
> 
> On 2017-06-13 03:49 AM, Hans Verkuil wrote:
>> On 06/12/2017 10:35 PM, Helen Koike wrote:
>>> Hi Hans,
>>>
>>> Thank you for your review. Please check my comments below
>>>
>>> On 2017-06-12 07:37 AM, Hans Verkuil wrote:
 On 06/03/2017 04:58 AM, Helen Koike wrote:
> +static struct component_match *vimc_add_subdevs(struct vimc_device
> *vimc)
> +{
> +struct component_match *match = NULL;
> +unsigned int i;
> +
> +for (i = 0; i < vimc->pipe_cfg->num_ents; i++) {
> +dev_dbg(>pdev.dev, "new pdev for %s\n",
> +vimc->pipe_cfg->ents[i].drv);
> +
> +/*
> + * TODO: check if using platform_data is indeed the best
> way to
> + * pass the name to the driver or if we should add the drv
> name
> + * in the platform_device_id table
> + */

 Didn't you set the drv name in the platform_device_id table already?
>>>
>>> I refer to the name of the entity, there is the name that identifies the
>>> driver as "vimc-sensor" that is set in the platform_device_id table but
>>> there is also the custom name of the entity e.g. "My Sensor A" that I
>>> need to inform to the vimc-sensor driver.
>>
>> Ah, so in the TODO you mean:
>>
>> "the best way to pass the entity name to the driver"
> 
> Yes
> 
>>
>> I got confused there.
> 
> Sorry about that, I'll improve this comment (if we don't decide to 
> remove it)
> 
>>
>> But in that case I still don't get what you mean with "add the drv name
>> in the platform_device_id table". Do you mean "entity name" there as
>> well?
> 
> Yes, it is because there is a member of the platform_device_id table 
> called driver_data and I was wondering if this would be more 
> appropriated then using the platform_data.
> 
> Under Documentation/driver-model/platform.txt it is written:
> "In many cases, the memory and IRQ resources associated with the 
> platform device are not enough to let the device's driver work.  Board 
> setup code
> will often provide additional information using the device's platform_data
> field to hold additional information."
> 
> So I thought that using platform_data to pass the entity's name to the 
> driver would be acceptable as it seems to be a "Board setup code" for vimc

OK, now I understand. I am OK with this, but I would prefer if you made a
proper struct for this:

struct vimc_platform_data {
char entity_name[32];
};

Then point platform_data to that. Also comment clearly why you do it.

Part of the confusion comes from the fact that this is unusual for MC
devices: they all use the device tree instead of platform_data, so seeing
platform_data being used in something like this is unexpected.

> 
>>
>>>

 Using platform_data feels like an abuse to be honest.
>>>
>>> Another option would be to make the vimc-sensor driver to populate the
>>> entity name automatically as "Sensor x", where x could be the entity
>>> number, but I don't think this is a good option.
>>
>> Why not? Well, probably not the entity number, but a simple instance
>> counter would do fine (i.e. Sensor 1, 2, 3...).
> 
> Because I usually use tests scripts that configure the right pad image 
> format to a specific entity's name using media-ctl, I would like an 
> assurance that what identifies the entity doesn't change (that doesn't 
> depend on the order they are inserted), and I thought that applications 
> in userspace might want the same.

Good point!

> 
>>
>> It can be made fancier later with dynamic reconfiguration where you
>> might want to use the first unused instance number.
> 
> We could use configfs for that, but I was wondering what the names of 
> the folders that represent an entity would mean, if the user do
> $ mkdir vimc-sensor-foo
> $ mkdir vimc-sensor-bar
> Then foo and bar would unused names as the entities would be first 
> created under the names "Sensor 1" and "Sensor 2", I think it would be 
> nice if they were created as "Sensor foo" and "Sensor bar".
> 
>>
>>>

 Creating these components here makes sense. Wouldn't it also make sense
 to use
 v4l2_async to wait until they have all been bound? It would more closely
 emulate
 standard drivers. Apologies if I misunderstand what is happening here.
>>>
>>> I am using linux/component.h for that, when all devices are present and
>>> all modules are loaded, the component.h system brings up the core by
>>> calling vimc_comp_bind() function, which calls component_bind_all() to
>>> call the binding function of each module, then it finishes registering
>>> the topology.
>>> If any one of the components or module is unload, the component system
>>> takes down the entire topology calling component_unbind_all which calls
>>> the unbind functions from each module.
>>> This makes sure that the media device, subdevices and video device are
>>> only registered in the v4l2 system if all the modules are 

[PATCH v2 0/2] Avoid namespace collision within macros & tidyup

[Ramesh Shanmugasundaram]

Hi All,

The readx_poll_timeout & similar macros defines local variable that can
cause name space collision with the caller. Fixed this issue by prefixing
them with underscores. Also tidied couple of instances where the macro
arguments are used in expressions without paranthesis.

This patchset is based on top of today's linux-next repo.
commit bc4c75f41a1c ("Add linux-next specific files for 20170613")

Change history:

v2:
 - iopoll.h:
- Enclosed timeout_us & sleep_us arguments with paranthesis
 - regmap.h:
- Enclosed timeout_us & sleep_us arguments with paranthesis
- Renamed pollret to __ret

Note: timeout_us cause spare check warning as identified here [1].

[1] https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg15138.html

Thanks,
Ramesh

Ramesh Shanmugasundaram (2):
  iopoll: Avoid namespace collision within macros & tidyup
  regmap: Avoid namespace collision within macro & tidyup

 include/linux/iopoll.h | 12 +++-
 include/linux/regmap.h | 17 +
 2 files changed, 16 insertions(+), 13 deletions(-)

-- 
2.12.2

[PATCH v2 1/2] iopoll: Avoid namespace collision within macros & tidyup

[Ramesh Shanmugasundaram]

Renamed variable "timeout" to "__timeout" to avoid namespace collision.
Tidy up macro arguments with paranthesis.

Signed-off-by: Ramesh Shanmugasundaram 
---
 include/linux/iopoll.h | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/include/linux/iopoll.h b/include/linux/iopoll.h
index d29e1e21bf3f..e000172bee54 100644
--- a/include/linux/iopoll.h
+++ b/include/linux/iopoll.h
@@ -42,18 +42,19 @@
  */
 #define readx_poll_timeout(op, addr, val, cond, sleep_us, timeout_us)  \
 ({ \
-   ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
+   ktime_t __timeout = ktime_add_us(ktime_get(), timeout_us); \
might_sleep_if(sleep_us); \
for (;;) { \
(val) = op(addr); \
if (cond) \
break; \
-   if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
+   if ((timeout_us) && \
+   ktime_compare(ktime_get(), __timeout) > 0) { \
(val) = op(addr); \
break; \
} \
if (sleep_us) \
-   usleep_range((sleep_us >> 2) + 1, sleep_us); \
+   usleep_range(((sleep_us) >> 2) + 1, sleep_us); \
} \
(cond) ? 0 : -ETIMEDOUT; \
 })
@@ -77,12 +78,13 @@
  */
 #define readx_poll_timeout_atomic(op, addr, val, cond, delay_us, timeout_us) \
 ({ \
-   ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
+   ktime_t __timeout = ktime_add_us(ktime_get(), timeout_us); \
for (;;) { \
(val) = op(addr); \
if (cond) \
break; \
-   if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
+   if ((timeout_us) && \
+   ktime_compare(ktime_get(), __timeout) > 0) { \
(val) = op(addr); \
break; \
} \
-- 
2.12.2

[PATCH v2 2/2] regmap: Avoid namespace collision within macro & tidyup

[Ramesh Shanmugasundaram]

Renamed variable "timeout" to "__timeout" & "pollret" to "__ret" to
avoid namespace collision. Tidy up macro arguments with paranthesis.

Signed-off-by: Ramesh Shanmugasundaram 
---
 include/linux/regmap.h | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 86eeacc1425a..ebc7282abc80 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -120,23 +120,24 @@ struct reg_sequence {
  */
 #define regmap_read_poll_timeout(map, addr, val, cond, sleep_us, timeout_us) \
 ({ \
-   ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
-   int pollret; \
+   ktime_t __timeout = ktime_add_us(ktime_get(), timeout_us); \
+   int __ret; \
might_sleep_if(sleep_us); \
for (;;) { \
-   pollret = regmap_read((map), (addr), &(val)); \
-   if (pollret) \
+   __ret = regmap_read((map), (addr), &(val)); \
+   if (__ret) \
break; \
if (cond) \
break; \
-   if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
-   pollret = regmap_read((map), (addr), &(val)); \
+   if ((timeout_us) && \
+   ktime_compare(ktime_get(), __timeout) > 0) { \
+   __ret = regmap_read((map), (addr), &(val)); \
break; \
} \
if (sleep_us) \
-   usleep_range((sleep_us >> 2) + 1, sleep_us); \
+   usleep_range(((sleep_us) >> 2) + 1, sleep_us); \
} \
-   pollret ?: ((cond) ? 0 : -ETIMEDOUT); \
+   __ret ?: ((cond) ? 0 : -ETIMEDOUT); \
 })
 
 #ifdef CONFIG_REGMAP
-- 
2.12.2

[PATCHv2] ARM: dts: exynos: add needs-hpd to for Odroid-U3

[Hans Verkuil]

The Odroid-U3 board has an IP4791CZ12 level shifter that is
disabled if the HPD is low, which means that the CEC pin is
disabled as well.

Signed-off-by: Hans Verkuil 
---
Changes since v1: moved  to after  to keep it somewhat
alphabetical.
---
 arch/arm/boot/dts/exynos4412-odroidu3.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts 
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 7504a5aa538e..44a4de08466b 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -78,6 +78,10 @@
regulator-max-microvolt = <330>;
 };

+ {
+   needs-hpd;
+};
+
 /* VDDQ for MSHC (eMMC card) */
 _reg {
regulator-name = "LDO22_VDDQ_MMC4_2.8V";
-- 
2.11.0

[GIT PULL FOR v4.13] CEC helper functions and CEC_CAP_NEEDS_HPD capability

[Hans Verkuil]

This patch series adds various useful helper functions (esp. for
upcoming CEC support in drm drivers).

The other addition is support for the new CEC_CAP_NEEDS_HPD capability: it
turns out there is a lot of hardware out there that cannot use the CEC pin
when there is no HPD. The CEC specification allows this in order to wake up
displays that pull the HPD low when in standby, but CEC still works.

But hardware like the Odroid U3 that hooks the HPD to a level-shifter and
that powers it off when the HPD goes low will also block the CEC signal from
reaching the SoC. So even though the SoC can handle this, the board design
prevents it from working.

There are more upcoming drivers (e.g. DisplayPort CEC-over-AUX tunneling)
that have the same limitation, so this capability is needed for 4.13.

The final two patches generalizes the CEC DT bindings at the request of Rob
Herring.

Regards,

Hans

The following changes since commit 47f910f0e0deb880c2114811f7ea1ec115a19ee4:

  [media] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev (2017-06-08 
16:55:25 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git cec-hpd

for you to fetch changes up to a1aba50d302888f607a2e50f9240dd64b9a2bea5:

  dt-bindings: media/s5p-cec.txt, media/stih-cec.txt: refer to cec.txt 
(2017-06-13 15:00:22 +0200)


Hans Verkuil (10):
  cec: add cec_s_phys_addr_from_edid helper function
  cec: add cec_phys_addr_invalidate() helper function
  cec: add cec_transmit_attempt_done helper function
  stih-cec/vivid/pulse8/rainshadow: use cec_transmit_attempt_done
  cec: add CEC_CAP_NEEDS_HPD
  cec-ioc-adap-g-caps.rst: document CEC_CAP_NEEDS_HPD
  dt-bindings: media/s5p-cec.txt: document needs-hpd property
  s5p_cec: set the CEC_CAP_NEEDS_HPD flag if needed
  dt-bindings: add media/cec.txt
  dt-bindings: media/s5p-cec.txt, media/stih-cec.txt: refer to cec.txt

 Documentation/devicetree/bindings/media/cec.txt  |  8 
 Documentation/devicetree/bindings/media/s5p-cec.txt  |  6 +-
 Documentation/devicetree/bindings/media/stih-cec.txt |  2 +-
 Documentation/media/kapi/cec-core.rst| 18 ++
 Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst |  8 
 MAINTAINERS  |  1 +
 drivers/media/cec/cec-adap.c | 60 
++--
 drivers/media/cec/cec-api.c  |  5 -
 drivers/media/cec/cec-core.c |  1 +
 drivers/media/platform/s5p-cec/s5p_cec.c |  4 +++-
 drivers/media/platform/sti/cec/stih-cec.c|  9 -
 drivers/media/platform/vivid/vivid-cec.c |  6 +++---
 drivers/media/usb/pulse8-cec/pulse8-cec.c|  9 +++--
 drivers/media/usb/rainshadow-cec/rainshadow-cec.c|  9 +++--
 include/media/cec.h  | 29 
+
 include/uapi/linux/cec.h |  2 ++
 16 files changed, 147 insertions(+), 30 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/cec.txt

Re: [PATCH v2 08/15] [media] cxd2880: Add top level of the driver

[Mauro Carvalho Chehab]

Em Fri, 14 Apr 2017 11:31:50 +0900
 escreveu:

> From: Yasunari Takiguchi 
> 
> This provides the main dvb frontend operation functions
> for the Sony CXD2880 DVB-T2/T tuner + demodulator driver.

For now, I'll do only a quick review on patches 6-15, as there are several
things to be ajusted on the code, from my past comments.

I'll do a better review on the next version. So, I'll focus only on
a few random issues I see on the code below.

> 
> Signed-off-by: Yasunari Takiguchi 
> Signed-off-by: Masayuki Yamamoto 
> Signed-off-by: Hideki Nozawa 
> Signed-off-by: Kota Yonezawa 
> Signed-off-by: Toshihiko Matsumoto 
> Signed-off-by: Satoshi Watanabe 
> ---
>  drivers/media/dvb-frontends/cxd2880/cxd2880_top.c | 1550 
> +
>  1 file changed, 1550 insertions(+)
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_top.c
> 
> diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_top.c 
> b/drivers/media/dvb-frontends/cxd2880/cxd2880_top.c
> new file mode 100644
> index ..66d78fb93a13
> --- /dev/null
> +++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_top.c
> @@ -0,0 +1,1550 @@
> +/*
> + * cxd2880_top.c
> + * Sony CXD2880 DVB-T2/T tuner + demodulator driver
> + *
> + * Copyright (C) 2016, 2017 Sony Semiconductor Solutions Corporation
> + *
> + * 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; version 2 of the License.
> + *
> + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
> + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
> + * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
> + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
> + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
> + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
> + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see .
> + */
> +
> +#include 
> +
> +#include "dvb_frontend.h"
> +
> +#include "cxd2880.h"
> +#include "cxd2880_tnrdmd_mon.h"
> +#include "cxd2880_tnrdmd_dvbt2_mon.h"
> +#include "cxd2880_tnrdmd_dvbt_mon.h"
> +#include "cxd2880_integ_dvbt2.h"
> +#include "cxd2880_integ_dvbt.h"
> +#include "cxd2880_devio_spi.h"
> +#include "cxd2880_spi_device.h"
> +#include "cxd2880_tnrdmd_driver_version.h"
> +
> +struct cxd2880_priv {
> + struct cxd2880_tnrdmd tnrdmd;
> + struct spi_device *spi;
> + struct cxd2880_io regio;
> + struct cxd2880_spi_device spi_device;
> + struct cxd2880_spi cxd2880_spi;
> + struct cxd2880_dvbt_tune_param dvbt_tune_param;
> + struct cxd2880_dvbt2_tune_param dvbt2_tune_param;
> + struct mutex *spi_mutex; /* For SPI access exclusive control */
> +};
> +
> +/*
> + * return value conversion table
> + */
> +static int return_tbl[] = {
> + 0, /* CXD2880_RESULT_OK */
> + -EINVAL,   /* CXD2880_RESULT_ERROR_ARG*/
> + -EIO,  /* CXD2880_RESULT_ERROR_IO */
> + -EPERM,/* CXD2880_RESULT_ERROR_SW_STATE */
> + -EBUSY,/* CXD2880_RESULT_ERROR_HW_STATE */
> + -ETIME,/* CXD2880_RESULT_ERROR_TIMEOUT */
> + -EAGAIN,   /* CXD2880_RESULT_ERROR_UNLOCK */
> + -ERANGE,   /* CXD2880_RESULT_ERROR_RANGE */
> + -EOPNOTSUPP,   /* CXD2880_RESULT_ERROR_NOSUPPORT */
> + -ECANCELED,/* CXD2880_RESULT_ERROR_CANCEL */
> + -EPERM,/* CXD2880_RESULT_ERROR_OTHER */
> + -EOVERFLOW,/* CXD2880_RESULT_ERROR_OVERFLOW */
> + 0, /* CXD2880_RESULT_OK_CONFIRM */
> +};

Please, don't use a conversion table. That makes the driver more
complex to be understood without any good reason. Instead, just 
replace the values at the original enum.

> +
> +static enum cxd2880_ret cxd2880_pre_bit_err_t(
> + struct cxd2880_tnrdmd *tnrdmd, u32 *pre_bit_err,
> + u32 *pre_bit_count)
> +{
> + u8 rdata[2];
> +
> + if ((!tnrdmd) || (!pre_bit_err) || (!pre_bit_count))
> + return CXD2880_RESULT_ERROR_ARG;
> +
> + if (tnrdmd->diver_mode == CXD2880_TNRDMD_DIVERMODE_SUB)
> + return CXD2880_RESULT_ERROR_ARG;
> +
> + if (tnrdmd->state != CXD2880_TNRDMD_STATE_ACTIVE)
> + return CXD2880_RESULT_ERROR_SW_STATE;
> +
> + if (tnrdmd->sys != 

Re: [RFC PATCH v3 09/11] [media] vimc: Subdevices as modules

[Helen Koike]

Hi Hans,

On 2017-06-13 03:49 AM, Hans Verkuil wrote:

On 06/12/2017 10:35 PM, Helen Koike wrote:

Hi Hans,

Thank you for your review. Please check my comments below

On 2017-06-12 07:37 AM, Hans Verkuil wrote:

On 06/03/2017 04:58 AM, Helen Koike wrote:

+static struct component_match *vimc_add_subdevs(struct vimc_device
*vimc)
+{
+struct component_match *match = NULL;
+unsigned int i;
+
+for (i = 0; i < vimc->pipe_cfg->num_ents; i++) {
+dev_dbg(>pdev.dev, "new pdev for %s\n",
+vimc->pipe_cfg->ents[i].drv);
+
+/*
+ * TODO: check if using platform_data is indeed the best
way to
+ * pass the name to the driver or if we should add the drv
name
+ * in the platform_device_id table
+ */


Didn't you set the drv name in the platform_device_id table already?


I refer to the name of the entity, there is the name that identifies the
driver as "vimc-sensor" that is set in the platform_device_id table but
there is also the custom name of the entity e.g. "My Sensor A" that I
need to inform to the vimc-sensor driver.


Ah, so in the TODO you mean:

"the best way to pass the entity name to the driver"


Yes



I got confused there.


Sorry about that, I'll improve this comment (if we don't decide to 
remove it)




But in that case I still don't get what you mean with "add the drv name
in the platform_device_id table". Do you mean "entity name" there as
well?


Yes, it is because there is a member of the platform_device_id table 
called driver_data and I was wondering if this would be more 
appropriated then using the platform_data.


Under Documentation/driver-model/platform.txt it is written:
"In many cases, the memory and IRQ resources associated with the 
platform device are not enough to let the device's driver work.  Board 
setup code

will often provide additional information using the device's platform_data
field to hold additional information."

So I thought that using platform_data to pass the entity's name to the 
driver would be acceptable as it seems to be a "Board setup code" for vimc








Using platform_data feels like an abuse to be honest.


Another option would be to make the vimc-sensor driver to populate the
entity name automatically as "Sensor x", where x could be the entity
number, but I don't think this is a good option.


Why not? Well, probably not the entity number, but a simple instance
counter would do fine (i.e. Sensor 1, 2, 3...).


Because I usually use tests scripts that configure the right pad image 
format to a specific entity's name using media-ctl, I would like an 
assurance that what identifies the entity doesn't change (that doesn't 
depend on the order they are inserted), and I thought that applications 
in userspace might want the same.




It can be made fancier later with dynamic reconfiguration where you
might want to use the first unused instance number.


We could use configfs for that, but I was wondering what the names of 
the folders that represent an entity would mean, if the user do

$ mkdir vimc-sensor-foo
$ mkdir vimc-sensor-bar
Then foo and bar would unused names as the entities would be first 
created under the names "Sensor 1" and "Sensor 2", I think it would be 
nice if they were created as "Sensor foo" and "Sensor bar".








Creating these components here makes sense. Wouldn't it also make sense
to use
v4l2_async to wait until they have all been bound? It would more closely
emulate
standard drivers. Apologies if I misunderstand what is happening here.


I am using linux/component.h for that, when all devices are present and
all modules are loaded, the component.h system brings up the core by
calling vimc_comp_bind() function, which calls component_bind_all() to
call the binding function of each module, then it finishes registering
the topology.
If any one of the components or module is unload, the component system
takes down the entire topology calling component_unbind_all which calls
the unbind functions from each module.
This makes sure that the media device, subdevices and video device are
only registered in the v4l2 system if all the modules are loaded.

I wans't familiar with v4l2-async.h, but from a quick look it seems that
it only works with struct v4l2_subdev, but I'll also need for struct
video_device (for the capture node for example).
And also, if a module is missing we would have vimc partially
registered, e.g. the debayer could be registered at /dev/subdevX but the
sensor not yet and the media wouldn't be ready, I am not sure if this is
a problem though.

Maybe we can use component.h for now, then I can implement
v4l2_async_{un}register_video_device and migrate to v4l2-sync.h latter.
What do you think?


That's OK. The v4l2-async mechanism precedes the component API. We should
probably investigate moving over to the component API. I seem to remember
that it didn't have all the features we needed, but it's a long time ago
since someone looked at that and whatever the 

Re: [PATCH v2 06/15] [media] cxd2880: Add tuner part of the driver

[Mauro Carvalho Chehab]

Em Fri, 14 Apr 2017 11:26:56 +0900
 escreveu:

> From: Yasunari Takiguchi 
> 
> This part of the driver has the main routines to handle
> the tuner and demodulator functionality.  The tnrdmd_mon.* files
> have monitor functions for the driver.
> This is part of the Sony CXD2880 DVB-T2/T tuner + demodulator driver.
> 
> Signed-off-by: Yasunari Takiguchi 
> Signed-off-by: Masayuki Yamamoto 
> Signed-off-by: Hideki Nozawa 
> Signed-off-by: Kota Yonezawa 
> Signed-off-by: Toshihiko Matsumoto 
> Signed-off-by: Satoshi Watanabe 
> ---
>  drivers/media/dvb-frontends/cxd2880/cxd2880_dtv.h  |   50 +
>  .../media/dvb-frontends/cxd2880/cxd2880_tnrdmd.c   | 3925 
> 
>  .../media/dvb-frontends/cxd2880/cxd2880_tnrdmd.h   |  395 ++
>  .../cxd2880/cxd2880_tnrdmd_driver_version.h|   29 +
>  .../dvb-frontends/cxd2880/cxd2880_tnrdmd_mon.c |  207 ++
>  .../dvb-frontends/cxd2880/cxd2880_tnrdmd_mon.h |   52 +
>  6 files changed, 4658 insertions(+)
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_dtv.h
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd.c
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd.h
>  create mode 100644 
> drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_driver_version.h
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_mon.c
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_mon.h
> 
> diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_dtv.h 
> b/drivers/media/dvb-frontends/cxd2880/cxd2880_dtv.h
> new file mode 100644
> index ..7de098d556fe
> --- /dev/null
> +++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_dtv.h
> @@ -0,0 +1,50 @@
> +/*
> + * cxd2880_dtv.h
> + * Sony CXD2880 DVB-T2/T tuner + demodulator driver
> + * DTV related definitions
> + *
> + * Copyright (C) 2016, 2017 Sony Semiconductor Solutions Corporation
> + *
> + * 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; version 2 of the License.
> + *
> + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
> + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
> + * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
> + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
> + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
> + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
> + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see .
> + */
> +
> +#ifndef CXD2880_DTV_H
> +#define CXD2880_DTV_H
> +
> +enum cxd2880_dtv_sys {
> + CXD2880_DTV_SYS_UNKNOWN,
> + CXD2880_DTV_SYS_DVBT,
> + CXD2880_DTV_SYS_DVBT2,
> + CXD2880_DTV_SYS_ISDBT,
> + CXD2880_DTV_SYS_ISDBTSB,
> + CXD2880_DTV_SYS_ISDBTMM_A,
> + CXD2880_DTV_SYS_ISDBTMM_B,
> + CXD2880_DTV_SYS_ANY
> +};
> +
> +enum cxd2880_dtv_bandwidth {
> + CXD2880_DTV_BW_UNKNOWN = 0,
> + CXD2880_DTV_BW_1_7_MHZ = 1,
> + CXD2880_DTV_BW_5_MHZ = 5,
> + CXD2880_DTV_BW_6_MHZ = 6,
> + CXD2880_DTV_BW_7_MHZ = 7,
> + CXD2880_DTV_BW_8_MHZ = 8
> +};
> +
> +#endif
> diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd.c 
> b/drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd.c
> new file mode 100644
> index ..286384ae0124
> --- /dev/null
> +++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd.c
> @@ -0,0 +1,3925 @@
> +/*
> + * cxd2880_tnrdmd.c
> + * Sony CXD2880 DVB-T2/T tuner + demodulator driver
> + * common control functions
> + *
> + * Copyright (C) 2016, 2017 Sony Semiconductor Solutions Corporation
> + *
> + * 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; version 2 of the License.
> + *
> + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
> + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
> + * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
> + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 

[PATCH v10] media: i2c: max2175: Add MAX2175 support

[Ramesh Shanmugasundaram]

This patch adds driver support for the MAX2175 chip. This is Maxim
Integrated's RF to Bits tuner front end chip designed for software-defined
radio solutions. This driver exposes the tuner as a sub-device instance
with standard and custom controls to configure the device.

Signed-off-by: Ramesh Shanmugasundaram 
---
Hi Hans,

   As discussed in #v4l, here is the v10 of this patch alone.

Hi Geert,

   I changed the timeout interval to usecs and removed the work
   around comment. I will also be posting a patch fixing the
   regmap header.

Thanks,
Ramesh.

v10:
 - On second thought, converted the msec timeout interval to usecs
   to avoid the comment & macro limitations. Refer #v4l (Hans)
v9:
 - Work around to avoid a sparse warning generated because of
   regmap_read_poll_timeout macro implementation.
v8:
 - Fixed smatch warnings in max2175_load_from_rom().
v7:
 - Made I2S enable/disable control as private (Mauro).
v6:
 - Addressed Sakari's comments. They are:
- Added uapi header file.
- Added newline at the end of the function before return.
- Cleaned up header file inclusion.
- Used fwnode_ apis whereever applicable.
- Cleaned up debug statements.
- Removed separate dir for max2175.
v5:
 - sck -> Sample clock is clarified in driver documentation (Hans)
 - "refout-load-pF" is renamed to "refout-load" as per updated bindings.
---
 Documentation/media/v4l-drivers/index.rst   |1 +
 Documentation/media/v4l-drivers/max2175.rst |   62 ++
 drivers/media/i2c/Kconfig   |   12 +
 drivers/media/i2c/Makefile  |2 +
 drivers/media/i2c/max2175.c | 1453 +++
 drivers/media/i2c/max2175.h |  109 ++
 include/uapi/linux/max2175.h|   28 +
 7 files changed, 1667 insertions(+)
 create mode 100644 Documentation/media/v4l-drivers/max2175.rst
 create mode 100644 drivers/media/i2c/max2175.c
 create mode 100644 drivers/media/i2c/max2175.h
 create mode 100644 include/uapi/linux/max2175.h

diff --git a/Documentation/media/v4l-drivers/index.rst 
b/Documentation/media/v4l-drivers/index.rst
index 90fe22a6414a..2e24d6806052 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -42,6 +42,7 @@ For more details see the file COPYING in the source 
distribution of Linux.
davinci-vpbe
fimc
ivtv
+   max2175
meye
omap3isp
omap4_camera
diff --git a/Documentation/media/v4l-drivers/max2175.rst 
b/Documentation/media/v4l-drivers/max2175.rst
new file mode 100644
index ..04478c25d57a
--- /dev/null
+++ b/Documentation/media/v4l-drivers/max2175.rst
@@ -0,0 +1,62 @@
+Maxim Integrated MAX2175 RF to bits tuner driver
+
+
+The MAX2175 driver implements the following driver-specific controls:
+
+``V4L2_CID_MAX2175_I2S_ENABLE``
+---
+Enable/Disable I2S output of the tuner. This is a private control
+that can be accessed only using the subdev interface.
+Refer to Documentation/media/kapi/v4l2-controls for more details.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``(0)``
+  - I2S output is disabled.
+* - ``(1)``
+  - I2S output is enabled.
+
+``V4L2_CID_MAX2175_HSLS``
+-
+The high-side/low-side (HSLS) control of the tuner for a given band.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``(0)``
+  - The LO frequency position is below the desired frequency.
+* - ``(1)``
+  - The LO frequency position is above the desired frequency.
+
+``V4L2_CID_MAX2175_RX_MODE (menu)``
+---
+The Rx mode controls a number of preset parameters of the tuner like
+sample clock (sck), sampling rate etc. These multiple settings are
+provided under one single label called Rx mode in the datasheet. The
+list below shows the supported modes with a brief description.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``"Europe modes"``
+* - ``"FM 1.2" (0)``
+  - This configures FM band with a sample rate of 0.512 million
+samples/sec with a 10.24 MHz sck.
+* - ``"DAB 1.2" (1)``
+  - This configures VHF band with a sample rate of 2.048 million
+samples/sec with a 32.768 MHz sck.
+
+* - ``"North America modes"``
+* - ``"FM 1.0" (0)``
+  - This configures FM band with a sample rate of 0.7441875 million
+samples/sec with a 14.88375 MHz sck.
+* - ``"DAB 1.2" (1)``
+  - This configures FM band with a sample rate of 0.372 million
+samples/sec with a 7.441875 MHz sck.
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index c380e2475c82..c0e6e78883b0 100644
--- 

Re: v4l2-fwnode: status, plans for merge, any branch to merge against?

[Sakari Ailus]

Hi Pavel,

On Tue, Jun 13, 2017 at 02:22:40PM +0200, Pavel Machek wrote:
> Hi!
> 
> Are there any news about the fwnode branch?
> 
> I have quite usable camera, but it is still based on
> 982e8e40390d26430ef106fede41594139a4111c (that's v4.10). It would be
> good to see fwnode stuff upstream... are there any plans for that?
> 
> Is there stable branch to which I could move the stuff?

What's relevant for most V4L2 drivers is in linux-media right now.

There are new features that will take some time to get in. The trouble has
been, and continue to be, that the patches need to go through various trees
so it'll take some time for them to be merged.

I expect to have most of them in during the next merge window.

-- 
Kind regards,

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

Re: [PATCH 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver

[Jose Abreu]

On 13-06-2017 11:54, Hans Verkuil wrote:
> On 06/13/17 12:31, Hans Verkuil wrote:
>> On 06/13/17 12:06, Jose Abreu wrote:
>>> Hi Hans,
>>>
>>>
>>> On 13-06-2017 11:01, Jose Abreu wrote:
>>>
>>> [snip]
 Changes from RFC:
- Added support for HDCP 1.4
>>> [snip]
 +
 +/* HDCP 1.4 */
 +#define DW_HDMI_HDCP14_BKSV_SIZE  2
 +#define DW_HDMI_HDCP14_KEYS_SIZE  (2 * 40)
 +
 +struct dw_hdmi_hdcp14_key {
 +  u32 seed;
 +  u32 bksv[DW_HDMI_HDCP14_BKSV_SIZE];
 +  u32 keys[DW_HDMI_HDCP14_KEYS_SIZE];
 +  bool keys_valid;
 +};
 +
 +struct dw_hdmi_rx_pdata {
 +  /* Controller configuration */
 +  unsigned int iref_clk; /* MHz */
 +  struct dw_hdmi_hdcp14_key hdcp14_keys;
 +  /* 5V sense interface */
 +  bool (*dw_5v_status)(void __iomem *regs, int input);
 +  void (*dw_5v_clear)(void __iomem *regs);
 +  void __iomem *dw_5v_arg;
 +  /* Zcal interface */
 +  void (*dw_zcal_reset)(void __iomem *regs);
 +  bool (*dw_zcal_done)(void __iomem *regs);
 +  void __iomem *dw_zcal_arg;
 +};
 +
 +#endif /* __DW_HDMI_RX_PDATA_H__ */
>>> I now have support for HDCP 1.4 in this driver. Can you send me
>>> the patches about HDCP that you mentioned a while ago?
>> This is what I have:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.linuxtv.org_hverkuil_media-5Ftree.git_log_-3Fh-3Dhdcp=DwICaQ=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=89GFcWI869VtRcbl-8t_R_cPeWiZlxloSapfdhTf4vg=MUyGTv9NeittcGKYdkUd6gfL55UKG3aR6vqx9MDJ-Bw=
>>  
>>
>> This is very old and somewhat messy.
>>
>> It uses ioctls for the bksv's, but I wonder if array/compound controls
>> wouldn't be more appropriate (those didn't exist when this was written
>> originally).
>>
>> It also needs to be checked against HDCP 2 so it can support that as well
> That's HDCP 2.2, of course.
>
>> (or at least be easily extended for that).
> Just a follow-up: I would really appreciated it if someone (you?) could get
> this finalized. The code in the branch above worked for us, but was never
> actually used in any product. It was internal test code only. It also is
> HDCP 1.4 only.

I saw the code. I can send a RFC but I'm very limited now in
terms of what I can test with this. The only available setup I
have is a receiver so I can't test transmitters neither
repeaters. As for HDCP 2.2 my implementation is *very* custom.

So, as I only have a receiver we are not very reactive. I mean I
can send events to userspace saying that auth
started/finished/failed but thats it because the transmitter
takes the lead for HDCP 1.4 and 2.2.

Also, as for what I submitted, I think I have to find another way
to do this because I'm using a "flavor" of the controller where
HDCP 1.4 keys must be programmed by SW. Right now they are passed
by pdata but these are secret keys so it doesn't make any sense
because manufacturers will not share their keys and they are
mostly embedded directly in the HW. Short story: my hdcp 1.4 code
does not make much sense.

>
> For a proper API we should think about HDCP 1.4 and 2.2 support, and also
> look at how this works for DisplayPort. Hmm, looks like DP supports HDCP 1.3
> and 2.2. I'm not sure what the differences are (if any) between 1.3 and 1.4.

Never used DP so I don't know if there are differences.

>
> Regards,
>
>   Hans

Best regards,
Jose Miguel Abreu

Re: [PATCH v2 05/15] [media] cxd2880: Add spi device IO routines

[Mauro Carvalho Chehab]

Em Fri, 14 Apr 2017 11:25:23 +0900
 escreveu:

> From: Yasunari Takiguchi 
> 
> Add functions for initializing, reading and writing to the SPI
> device for the Sony CXD2880 DVB-T2/T tuner + demodulator.
> 
> Signed-off-by: Yasunari Takiguchi 
> Signed-off-by: Masayuki Yamamoto 
> Signed-off-by: Hideki Nozawa 
> Signed-off-by: Kota Yonezawa 
> Signed-off-by: Toshihiko Matsumoto 
> Signed-off-by: Satoshi Watanabe 
> ---
>  .../dvb-frontends/cxd2880/cxd2880_devio_spi.c  | 147 
> +
>  .../dvb-frontends/cxd2880/cxd2880_devio_spi.h  |  40 ++
>  drivers/media/dvb-frontends/cxd2880/cxd2880_spi.h  |  51 +++
>  .../dvb-frontends/cxd2880/cxd2880_spi_device.c | 130 ++
>  .../dvb-frontends/cxd2880/cxd2880_spi_device.h |  45 +++
>  5 files changed, 413 insertions(+)
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_devio_spi.c
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_devio_spi.h
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_spi.h
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_spi_device.c
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_spi_device.h
> 
> diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_devio_spi.c 
> b/drivers/media/dvb-frontends/cxd2880/cxd2880_devio_spi.c
> new file mode 100644
> index ..516efade6bf5
> --- /dev/null
> +++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_devio_spi.c
> @@ -0,0 +1,147 @@
> +/*
> + * cxd2880_devio_spi.c
> + * Sony CXD2880 DVB-T2/T tuner + demodulator driver
> + * I/O interface via SPI
> + *
> + * Copyright (C) 2016, 2017 Sony Semiconductor Solutions Corporation
> + *
> + * 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; version 2 of the License.
> + *
> + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
> + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
> + * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
> + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
> + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
> + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
> + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see .
> + */
> +
> +#include "cxd2880_devio_spi.h"
> +#include "cxd2880_stdlib.h"
> +
> +#define BURST_WRITE_MAX 128
> +
> +static enum cxd2880_ret cxd2880_io_spi_read_reg(struct cxd2880_io *io,
> + enum cxd2880_io_tgt tgt,
> + u8 sub_address, u8 *data,
> + u32 size)

Return argument should be integer, as it is an error code or zero.

> +{
> + enum cxd2880_ret ret = CXD2880_RESULT_OK;
> + struct cxd2880_spi *spi = NULL;
> + u8 send_data[6];
> + u8 *read_data_top = data;
> +
> + if ((!io) || (!io->if_object) || (!data))
> + return CXD2880_RESULT_ERROR_ARG;
> +
> + if (sub_address + size > 0x100)
> + return CXD2880_RESULT_ERROR_RANGE;

Please use standard return error codes. In this specific case, likely
-EINVAL and -ERANGE.

Same apply to other functions below.

> +
> + spi = (struct cxd2880_spi *)(io->if_object);
> +
> + if (tgt == CXD2880_IO_TGT_SYS)
> + send_data[0] = 0x0B;
> + else
> + send_data[0] = 0x0A;
> +
> + send_data[3] = 0;
> + send_data[4] = 0;
> + send_data[5] = 0;
> +
> + while (size > 0) {
> + send_data[1] = sub_address;
> + if (size > 255)
> + send_data[2] = 255;
> + else
> + send_data[2] = (u8)size;

No need to cast.

> +
> + ret =
> + spi->write_read(spi, send_data, sizeof(send_data),
> + read_data_top, send_data[2]);
> + if (ret != CXD2880_RESULT_OK)
> + return ret;

Please keep it simple, e. g.:

if (ret)
return ret;

> +
> + sub_address += send_data[2];
> + read_data_top += send_data[2];
> + size -= send_data[2];
> + }
> +
> + return ret;
> +}

v4l2-fwnode: status, plans for merge, any branch to merge against?

[Pavel Machek]

Hi!

Are there any news about the fwnode branch?

I have quite usable camera, but it is still based on
982e8e40390d26430ef106fede41594139a4111c (that's v4.10). It would be
good to see fwnode stuff upstream... are there any plans for that?

Is there stable branch to which I could move the stuff?

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


signature.asc
Description: Digital signature

Re: [PATCH v4 1/2] media: i2c: adv748x: add adv748x driver

[Kieran Bingham]

Hi Niklas

On 13/06/17 08:33, Niklas Söderlund wrote:
> Hi Kieran,
> 
> Thanks for your patch, and great work!

Thanks for taking a look.

> On 2017-06-13 01:35:07 +0100, Kieran Bingham wrote:
>> From: Kieran Bingham 
>>
>> Provide support for the ADV7481 and ADV7482.
>>
>> The driver is modelled with 4 subdevices to allow simultaneous streaming
>> from the AFE (Analog front end) and HDMI inputs though two CSI TX
>> entities.
>>
>> The HDMI entity is linked to the TXA CSI bus, whilst the AFE is linked
>> to the TXB CSI bus.
>>
>> The driver is based on a prototype by Koji Matsuoka in the Renesas BSP,
>> and an earlier rework by Niklas Söderlund.
>>
>> Signed-off-by: Kieran Bingham 
>>



>> +static int adv748x_afe_get_format(struct v4l2_subdev *sd,
>> +  struct v4l2_subdev_pad_config *cfg,
>> +  struct v4l2_subdev_format *sdformat)
>> +{
>> +struct adv748x_afe *afe = adv748x_sd_to_afe(sd);
>> +struct v4l2_mbus_framefmt *mbusformat;
>> +
>> +/* The format of the analog sink pads is nonsensical */
>> +if (sdformat->pad != ADV748X_AFE_SOURCE)
>> +return -EINVAL;
>> +
>> +if (sdformat->which == V4L2_SUBDEV_FORMAT_TRY) {
>> +mbusformat = v4l2_subdev_get_try_format(sd, cfg, sdformat->pad);
>> +sdformat->format = *mbusformat;
>> +} else {
>> +adv748x_afe_fill_format(afe, >format);
>> +adv748x_afe_set_pixelrate(afe);
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static int adv748x_afe_set_format(struct v4l2_subdev *sd,
>> +  struct v4l2_subdev_pad_config *cfg,
>> +  struct v4l2_subdev_format *sdformat)
>> +{
>> +struct v4l2_mbus_framefmt *mbusformat;
>> +
>> +/* The format of the analog sink pads is nonsensical */
>> +if (sdformat->pad != ADV748X_AFE_SOURCE)
>> +return -EINVAL;
>> +
>> +if (sdformat->which == V4L2_SUBDEV_FORMAT_ACTIVE)
>> +return adv748x_afe_get_format(sd, cfg, sdformat);
>> +
>> +mbusformat = v4l2_subdev_get_try_format(sd, cfg, sdformat->pad);
>> +*mbusformat = sdformat->format;
> 
> Hum, for the V4L2_SUBDEV_FORMAT_TRY case will this not accept any format 
> provided to the function? Should you not limit this to the device 
> capabilities before assigning it to mbusformat ?

Hrmmm maybe it got too late last night :)

I was trying to remove the effect of the active setting on the TRY format, and
I've gone too far :)

> 
>> +
>> +return 0;
>> +}




>> +
>> +static int adv748x_setup_links(struct adv748x_state *state)
>> +{
>> +int ret;
>> +int enabled = MEDIA_LNK_FL_ENABLED;
>> +
>> +/*
>> + * HACK/Workaround:
>> + *
>> + * Currently non-immutable link resets go through the RVin
>> + * driver, and cause the links to fail, due to not being part of RVIN.
>> + * As a temporary workaround until the RVIN driver knows better than to 
>> parse
>> + * links that do not belong to it, use static immutable links for our 
>> internal
>> + * media paths.
>> + */
> 
> The problem is a bigger then just the VIN ignoring the links not 
> belonging to it self I think. The ADV7482 driver must have a link 
> notification handler to deal with the links that belong to it.
> 
> Else if all links of the media device is reset there is no way to setup 
> the links between the different ADV7482 subdevices, or am I missing 
> something?

Ahhh -- this function shouldn't even be in here ! It's not meant to be used -
Links are now created in adv748x_csi2_register_link() so now I'm concerned why I
didn't get an unused function compiler warning :)

However - your point still stands.

> 
>> +#define ADV748x_DEV_STATIC_LINKS
>> +#ifdef ADV748x_DEV_STATIC_LINKS
>> +enabled |= MEDIA_LNK_FL_IMMUTABLE;
>> +#endif
>> +
>> +/* TXA - Default link is with HDMI */
>> +ret = media_create_pad_link(>hdmi.sd.entity, 1,
>> +>txa.sd.entity, 0, enabled);
>> +if (ret) {
>> +adv_err(state, "Failed to create HDMI-TXA pad link");
>> +return ret;
>> +}
>> +
>> +#ifndef ADV748x_DEV_STATIC_LINKS
>> +ret = media_create_pad_link(>afe.sd.entity, ADV748X_AFE_SOURCE,
>> +>txa.sd.entity, 0, 0);
>> +if (ret) {
>> +adv_err(state, "Failed to create AFE-TXA pad link");
>> +return ret;
>> +}
>> +#endif
>> +
>> +/* TXB - Can only output from the AFE */
>> +ret = media_create_pad_link(>afe.sd.entity, ADV748X_AFE_SOURCE,
>> +>txb.sd.entity, 0, enabled);
>> +if (ret) {
>> +adv_err(state, "Failed to create AFE-TXB pad link");
>> +return ret;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +int adv748x_register_subdevs(struct adv748x_state *state,
>> + struct v4l2_device *v4l2_dev)

And 

Re: [PATCH v2 04/15] [media] cxd2880: Add math functions for the driver

[Mauro Carvalho Chehab]

Em Fri, 14 Apr 2017 11:22:37 +0900
 escreveu:

> From: Yasunari Takiguchi 
> 
> Provide some math support functions (fixed-point log functions)
> for the Sony CXD2880 DVB-T2/T tuner + demodulator driver.

No need. The Kernel already provide log functions. You should use the
existing ones, instead of reinventing the wheel. The log2 functions
are at:
include/linux/log2.h

We also have both log2 and log10 functions at:
drivers/media/dvb-core/dvb_math.h

That should likely what you want.


> 
> Signed-off-by: Yasunari Takiguchi 
> Signed-off-by: Masayuki Yamamoto 
> Signed-off-by: Hideki Nozawa 
> Signed-off-by: Kota Yonezawa 
> Signed-off-by: Toshihiko Matsumoto 
> Signed-off-by: Satoshi Watanabe 
> ---
>  drivers/media/dvb-frontends/cxd2880/cxd2880_math.c | 89 
> ++
>  drivers/media/dvb-frontends/cxd2880/cxd2880_math.h | 40 ++
>  2 files changed, 129 insertions(+)
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_math.c
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_math.h
> 
> diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_math.c 
> b/drivers/media/dvb-frontends/cxd2880/cxd2880_math.c
> new file mode 100644
> index ..434c827898ff
> --- /dev/null
> +++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_math.c
> @@ -0,0 +1,89 @@
> +/*
> + * cxd2880_math.c
> + * Sony CXD2880 DVB-T2/T tuner + demodulator driver
> + * mathmatics functions
> + *
> + * Copyright (C) 2016, 2017 Sony Semiconductor Solutions Corporation
> + *
> + * 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; version 2 of the License.
> + *
> + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
> + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
> + * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
> + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
> + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
> + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
> + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see .
> + */
> +
> +#include "cxd2880_math.h"
> +
> +#define MAX_BIT_PRECISION  5
> +#define FRAC_BITMASK 0x1F
> +#define LOG2_10_100X  332
> +#define LOG2_E_100X144
> +
> +static const u8 log2_look_up[] = {
> + 0, 4,
> + 9, 13,
> + 17, 21,
> + 25, 29,
> + 32, 36,
> + 39, 43,
> + 46, 49,
> + 52, 55,
> + 58, 61,
> + 64, 67,
> + 70, 73,
> + 75, 78,
> + 81, 83,
> + 86, 88,
> + 91, 93,
> + 95, 98
> +};
> +
> +u32 cxd2880_math_log2(u32 x)
> +{
> + u8 count = 0;
> + u8 index = 0;
> + u32 xval = x;
> +
> + for (x >>= 1; x > 0; x >>= 1)
> + count++;
> +
> + x = count * 100;
> +
> + if (count > 0) {
> + if (count <= MAX_BIT_PRECISION) {
> + index =
> + (u8)(xval << (MAX_BIT_PRECISION - count)) &
> + FRAC_BITMASK;
> + x += log2_look_up[index];
> + } else {
> + index =
> + (u8)(xval >> (count - MAX_BIT_PRECISION)) &
> + FRAC_BITMASK;
> + x += log2_look_up[index];
> + }
> + }
> +
> + return x;
> +}
> +
> +u32 cxd2880_math_log10(u32 x)
> +{
> + return ((100 * cxd2880_math_log2(x) + LOG2_10_100X / 2) / LOG2_10_100X);
> +}
> +
> +u32 cxd2880_math_log(u32 x)
> +{
> + return ((100 * cxd2880_math_log2(x) + LOG2_E_100X / 2) / LOG2_E_100X);
> +}
> diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_math.h 
> b/drivers/media/dvb-frontends/cxd2880/cxd2880_math.h
> new file mode 100644
> index ..94211835a4ad
> --- /dev/null
> +++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_math.h
> @@ -0,0 +1,40 @@
> +/*
> + * cxd2880_math.h
> + * Sony CXD2880 DVB-T2/T tuner + demodulator driver
> + * mathmatics definitions
> + *
> + * Copyright (C) 2016, 2017 Sony Semiconductor Solutions Corporation
> + *
> + * 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 

Re: [PATCH v2 03/15] [media] cxd2880: Add common files for the driver

[Mauro Carvalho Chehab]

Em Fri, 14 Apr 2017 11:17:01 +0900
 escreveu:

> From: Yasunari Takiguchi 
> 
> These are common files for the driver for the
> Sony CXD2880 DVB-T2/T tuner + demodulator.
> These contains helper functions for the driver.
> 
> Signed-off-by: Yasunari Takiguchi 
> Signed-off-by: Masayuki Yamamoto 
> Signed-off-by: Hideki Nozawa 
> Signed-off-by: Kota Yonezawa 
> Signed-off-by: Toshihiko Matsumoto 
> Signed-off-by: Satoshi Watanabe 
> ---
>  drivers/media/dvb-frontends/cxd2880/cxd2880.h  | 46 
>  .../media/dvb-frontends/cxd2880/cxd2880_common.c   | 84 +
>  .../media/dvb-frontends/cxd2880/cxd2880_common.h   | 86 
> ++
>  drivers/media/dvb-frontends/cxd2880/cxd2880_io.c   | 68 +
>  drivers/media/dvb-frontends/cxd2880/cxd2880_io.h   | 62 
>  .../media/dvb-frontends/cxd2880/cxd2880_stdlib.h   | 35 +
>  .../dvb-frontends/cxd2880/cxd2880_stopwatch_port.c | 71 ++
>  7 files changed, 452 insertions(+)
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880.h
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_common.c
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_common.h
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_io.c
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_io.h
>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_stdlib.h
>  create mode 100644 
> drivers/media/dvb-frontends/cxd2880/cxd2880_stopwatch_port.c
> 
> diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880.h 
> b/drivers/media/dvb-frontends/cxd2880/cxd2880.h
> new file mode 100644
> index ..281f9a784eb5
> --- /dev/null
> +++ b/drivers/media/dvb-frontends/cxd2880/cxd2880.h
> @@ -0,0 +1,46 @@
> +/*
> + * cxd2880.h
> + * Sony CXD2880 DVB-T2/T tuner + demodulator driver public definitions
> + *
> + * Copyright (C) 2016, 2017 Sony Semiconductor Solutions Corporation
> + *
> + * 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; version 2 of the License.
> + *
> + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
> + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
> + * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
> + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
> + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
> + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
> + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see .
> + */
> +
> +#ifndef CXD2880_H
> +#define CXD2880_H
> +
> +struct cxd2880_config {
> + struct spi_device *spi;
> + struct mutex *spi_mutex; /* For SPI access exclusive control */
> +};
> +
> +#if IS_REACHABLE(CONFIG_DVB_CXD2880)
> +extern struct dvb_frontend *cxd2880_attach(struct dvb_frontend *fe,
> + struct cxd2880_config *cfg);
> +#else
> +static inline struct dvb_frontend *cxd2880_attach(struct dvb_frontend *fe,
> + struct cxd2880_config *cfg)
> +{
> + pr_warn("%s: driver disabled by Kconfig\n", __func__);
> + return NULL;
> +}
> +#endif /* CONFIG_DVB_CXD2880 */
> +
> +#endif /* CXD2880_H */
> diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_common.c 
> b/drivers/media/dvb-frontends/cxd2880/cxd2880_common.c
> new file mode 100644
> index ..850f3a76b2c7
> --- /dev/null
> +++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_common.c
> @@ -0,0 +1,84 @@
> +/*
> + * cxd2880_common.c
> + * Sony CXD2880 DVB-T2/T tuner + demodulator driver
> + * common functions
> + *
> + * Copyright (C) 2016, 2017 Sony Semiconductor Solutions Corporation
> + *
> + * 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; version 2 of the License.
> + *
> + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
> + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
> + * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
> + * 

Re: [PATCH v2 02/15] [media] cxd2880-spi: Add support for CXD2008 SPI interface

[Mauro Carvalho Chehab]

Em Fri, 14 Apr 2017 11:08:23 +0900
 escreveu:

> From: Yasunari Takiguchi 
> 
> This is the SPI adapter part of the driver for the
> Sony CXD2880 DVB-T2/T tuner + demodulator.
> 
> Signed-off-by: Yasunari Takiguchi 
> Signed-off-by: Masayuki Yamamoto 
> Signed-off-by: Hideki Nozawa 
> Signed-off-by: Kota Yonezawa 
> Signed-off-by: Toshihiko Matsumoto 
> Signed-off-by: Satoshi Watanabe 
> ---
>  drivers/media/spi/cxd2880-spi.c | 728 
> 
>  1 file changed, 728 insertions(+)
>  create mode 100644 drivers/media/spi/cxd2880-spi.c
> 
> diff --git a/drivers/media/spi/cxd2880-spi.c b/drivers/media/spi/cxd2880-spi.c
> new file mode 100644
> index ..82e122349055
> --- /dev/null
> +++ b/drivers/media/spi/cxd2880-spi.c
> @@ -0,0 +1,728 @@
> +/*
> + * cxd2880-spi.c
> + * Sony CXD2880 DVB-T2/T tuner + demodulator driver
> + * SPI adapter
> + *
> + * Copyright (C) 2016, 2017 Sony Semiconductor Solutions Corporation
> + *
> + * 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; version 2 of the License.
> + *
> + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
> + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
> + * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
> + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
> + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
> + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
> + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see .
> + */
> +
> +#include 
> +
> +#include "dvb_demux.h"
> +#include "dmxdev.h"
> +#include "dvb_frontend.h"
> +#include "cxd2880.h"
> +
> +#define CXD2880_MAX_FILTER_SIZE 32
> +#define BURST_WRITE_MAX 128
> +#define MAX_TRANS_PACKET 300
> +
> +struct cxd2880_ts_buf_info {
> + u8 read_ready;
> + u8 almost_full;
> + u8 almost_empty;
> + u8 overflow;
> + u8 underflow;
> + u16 packet_num;
> +};
> +
> +struct cxd2880_pid_config {
> + u8 is_enable;
> + u16 pid;
> +};
> +
> +struct cxd2880_pid_filter_config {
> + u8 is_negative;
> + struct cxd2880_pid_config pid_config[CXD2880_MAX_FILTER_SIZE];
> +};
> +
> +struct cxd2880_dvb_spi {
> + struct dvb_frontend dvb_fe;
> + struct dvb_adapter adapter;
> + struct dvb_demux demux;
> + struct dmxdev dmxdev;
> + struct dmx_frontend dmx_fe;
> + struct task_struct *cxd2880_ts_read_thread;
> + struct spi_device *spi;
> + struct mutex spi_mutex; /* For SPI access exclusive control */
> + int feed_count;
> + int all_pid_feed_count;
> + u8 *ts_buf;
> + struct cxd2880_pid_filter_config filter_config;
> +};
> +
> +DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
> +
> +static int cxd2880_write_spi(struct spi_device *spi, u8 *data, u32 size)
> +{
> + struct spi_message msg;
> + struct spi_transfer tx;
> + int ret = 0;
> +
> + if ((!spi) || (!data)) {
> + pr_err("%s: invalid arg\n", __func__);

The best would be to se dev_err() & friends for printing messages, as
they print the device's name as filled at struct device. If you don't use, 
please add a define that will print the name at the logs, like:

#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

either at the begining of the driver or at some header file.

Btw, I'm noticing that you're also using dev_err() on other places
of the code. Please standardize. OK, on a few places, you may still
need to use pr_err(), if you need to print a message before
initializing struct device, but I suspect that you can initialize
it before reading/writing to SPI.

> + return -EINVAL;
> + }
> +
> + memset(, 0, sizeof(tx));
> + tx.tx_buf = data;
> + tx.len = size;
> +
> + spi_message_init();
> + spi_message_add_tail(, );
> + ret = spi_sync(spi, );
> +
> + return ret;
> +}
> +
> +static int cxd2880_write_reg(struct spi_device *spi,
> + u8 subAddress, const u8 *data, u32 size)
> +{
> + u8 send_data[BURST_WRITE_MAX + 4];
> + const u8 *write_data_top = NULL;
> + int ret = 0;
> +
> + if ((!spi) || (!data)) {
> + pr_err("%s: invalid arg\n", __func__);
> + return 

Re: [PATCH 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver

[Hans Verkuil]

On 06/13/17 12:31, Hans Verkuil wrote:
> On 06/13/17 12:06, Jose Abreu wrote:
>> Hi Hans,
>>
>>
>> On 13-06-2017 11:01, Jose Abreu wrote:
>>
>> [snip]
>>> Changes from RFC:
>>> - Added support for HDCP 1.4
>>
>> [snip]
>>> +
>>> +/* HDCP 1.4 */
>>> +#define DW_HDMI_HDCP14_BKSV_SIZE   2
>>> +#define DW_HDMI_HDCP14_KEYS_SIZE   (2 * 40)
>>> +
>>> +struct dw_hdmi_hdcp14_key {
>>> +   u32 seed;
>>> +   u32 bksv[DW_HDMI_HDCP14_BKSV_SIZE];
>>> +   u32 keys[DW_HDMI_HDCP14_KEYS_SIZE];
>>> +   bool keys_valid;
>>> +};
>>> +
>>> +struct dw_hdmi_rx_pdata {
>>> +   /* Controller configuration */
>>> +   unsigned int iref_clk; /* MHz */
>>> +   struct dw_hdmi_hdcp14_key hdcp14_keys;
>>> +   /* 5V sense interface */
>>> +   bool (*dw_5v_status)(void __iomem *regs, int input);
>>> +   void (*dw_5v_clear)(void __iomem *regs);
>>> +   void __iomem *dw_5v_arg;
>>> +   /* Zcal interface */
>>> +   void (*dw_zcal_reset)(void __iomem *regs);
>>> +   bool (*dw_zcal_done)(void __iomem *regs);
>>> +   void __iomem *dw_zcal_arg;
>>> +};
>>> +
>>> +#endif /* __DW_HDMI_RX_PDATA_H__ */
>>
>> I now have support for HDCP 1.4 in this driver. Can you send me
>> the patches about HDCP that you mentioned a while ago?
> 
> This is what I have:
> 
> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=hdcp
> 
> This is very old and somewhat messy.
> 
> It uses ioctls for the bksv's, but I wonder if array/compound controls
> wouldn't be more appropriate (those didn't exist when this was written
> originally).
> 
> It also needs to be checked against HDCP 2 so it can support that as well

That's HDCP 2.2, of course.

> (or at least be easily extended for that).

Just a follow-up: I would really appreciated it if someone (you?) could get
this finalized. The code in the branch above worked for us, but was never
actually used in any product. It was internal test code only. It also is
HDCP 1.4 only.

For a proper API we should think about HDCP 1.4 and 2.2 support, and also
look at how this works for DisplayPort. Hmm, looks like DP supports HDCP 1.3
and 2.2. I'm not sure what the differences are (if any) between 1.3 and 1.4.

Regards,

Hans

Re: [PATCH 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver

[Hans Verkuil]

On 06/13/17 12:06, Jose Abreu wrote:
> Hi Hans,
> 
> 
> On 13-06-2017 11:01, Jose Abreu wrote:
> 
> [snip]
>> Changes from RFC:
>>  - Added support for HDCP 1.4
> 
> [snip]
>> +
>> +/* HDCP 1.4 */
>> +#define DW_HDMI_HDCP14_BKSV_SIZE2
>> +#define DW_HDMI_HDCP14_KEYS_SIZE(2 * 40)
>> +
>> +struct dw_hdmi_hdcp14_key {
>> +u32 seed;
>> +u32 bksv[DW_HDMI_HDCP14_BKSV_SIZE];
>> +u32 keys[DW_HDMI_HDCP14_KEYS_SIZE];
>> +bool keys_valid;
>> +};
>> +
>> +struct dw_hdmi_rx_pdata {
>> +/* Controller configuration */
>> +unsigned int iref_clk; /* MHz */
>> +struct dw_hdmi_hdcp14_key hdcp14_keys;
>> +/* 5V sense interface */
>> +bool (*dw_5v_status)(void __iomem *regs, int input);
>> +void (*dw_5v_clear)(void __iomem *regs);
>> +void __iomem *dw_5v_arg;
>> +/* Zcal interface */
>> +void (*dw_zcal_reset)(void __iomem *regs);
>> +bool (*dw_zcal_done)(void __iomem *regs);
>> +void __iomem *dw_zcal_arg;
>> +};
>> +
>> +#endif /* __DW_HDMI_RX_PDATA_H__ */
> 
> I now have support for HDCP 1.4 in this driver. Can you send me
> the patches about HDCP that you mentioned a while ago?

This is what I have:

https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=hdcp

This is very old and somewhat messy.

It uses ioctls for the bksv's, but I wonder if array/compound controls
wouldn't be more appropriate (those didn't exist when this was written
originally).

It also needs to be checked against HDCP 2 so it can support that as well
(or at least be easily extended for that).

Regards,

Hans

Re: [PATCH v2 0/3] ngene: Replace semaphores with mutexes

[Binoy Jayan]

Hi Arnd,

On 13 June 2017 at 15:19, Arnd Bergmann  wrote:
> On Tue, Jun 13, 2017 at 10:58 AM, Binoy Jayan  wrote:
>> These are a set of patches [v2] which removes semaphores from ngene.
>> These are part of a bigger effort to eliminate unwanted semaphores
>> from the linux kernel.
>
> All three
>
> Acked-by: Arnd Bergmann 
>
> I already gave an Ack for one or two of the patches in the first round, but
> you seem to have dropped that. When you resend a patch with an Ack,
> please include that above your Signed-off-by line. (No need to resend
> for an Ack otherwise, this normally gets picked up when the patch
> gets applied from the list.

Sorry I dropped it as there were changes in two of the patches.
But there were obvious ones anyway.

Thanks,
Binoy

Re: [PATCH v10 1/1] [media] i2c: add support for OV13858 sensor

[Sakari Ailus]

Hi Hyungwoo,

On Mon, Jun 12, 2017 at 05:56:00PM -0700, Hyungwoo Yang wrote:
> This patch adds driver for Omnivision's ov13858
> sensor, the driver supports following features:
> 
> - manual exposure/gain(analog and digital) control support
> - two link frequencies
> - VBLANK/HBLANK support
> - test pattern support
> - media controller support
> - runtime pm support
> - supported resolutions
>   + 4224x3136 at 30FPS
>   + 2112x1568 at 30FPS(default) and 60FPS
>   + 2112x1188 at 30FPS(default) and 60FPS
>   + 1056x784 at 30FPS(default) and 60FPS
> 
> Signed-off-by: Hyungwoo Yang 
> ---
>  drivers/media/i2c/Kconfig   |8 +
>  drivers/media/i2c/Makefile  |1 +
>  drivers/media/i2c/ov13858.c | 1920 
> +++
>  3 files changed, 1929 insertions(+)
>  create mode 100644 drivers/media/i2c/ov13858.c
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index c380e24..26a9a3c 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -600,6 +600,14 @@ config VIDEO_OV9650
> This is a V4L2 sensor-level driver for the Omnivision
> OV9650 and OV9652 camera sensors.
>  
> +config VIDEO_OV13858
> + tristate "OmniVision OV13858 sensor support"
> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + depends on MEDIA_CAMERA_SUPPORT

select V4L2_FWNODE

> + ---help---
> +   This is a Video4Linux2 sensor-level driver for the OmniVision
> +   OV13858 camera.
> +
>  config VIDEO_VS6624
>   tristate "ST VS6624 sensor support"
>   depends on VIDEO_V4L2 && I2C
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 62323ec..3f4dc02 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -63,6 +63,7 @@ obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
>  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
>  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
>  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
> +obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
>  obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
>  obj-$(CONFIG_VIDEO_MT9M111) += mt9m111.o
>  obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
> diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c
> new file mode 100644
> index 000..0334cee
> --- /dev/null
> +++ b/drivers/media/i2c/ov13858.c

...

> +static int ov13858_read_platform_data(struct device *dev,
> +   struct ov13858 *ov13858)
> +{
> + struct fwnode_handle *child, *fwn_freq;
> + struct ov13858_link_freq_config *freq_cfg;
> + struct ov13858_reg *pll_regs;
> + int i, freq_id = 0, ret, num_of_values, num_of_pairs;
> + u32 val, *val_array;
> +
> + /* For now, platform data is only available from fwnode */
> + if (!dev_fwnode(dev)) {
> + dev_err(dev, "no platform data\n");
> + return -EINVAL;
> + }
> +
> + ret = device_property_read_u32(dev, "skip-frames", );

This is a property of the sensor (or its configuration), not the hardware
platform. Please use a constant if the value does not depend on
configuration.

> + if (ret)
> + return ret;
> + ov13858->num_of_skip_frames = val;
> +
> + device_for_each_child_node(dev, child) {
> + if (!fwnode_property_present(child, "link"))
> + continue;

You shouldn't need these here.

> +
> + /* Limited number of link frequencies are allowed */
> + if (freq_id == OV13858_NUM_OF_LINK_FREQS) {
> + dev_err(dev, "no more than two freqs\n");
> + ret = -EINVAL;
> + goto error;
> + }
> +
> + fwn_freq = fwnode_get_next_child_node(child, NULL);
> + if (!fwn_freq) {
> + ret = -EINVAL;
> + goto error;
> + }
> +
> + /* Get link freq menu item for LINK_FREQ control */
> + ret = fwnode_property_read_u32(fwn_freq, "link-rate", );

If you need to know the valid link frequencies (among other things), please
use v4l2_fwnode_endpoint_alloc_parse() instead. It parses the firmware
tables for you.

> + if (ret) {
> + dev_err(dev, "link-rate error : %d\n",  ret);
> + goto error;
> + }
> + link_freq_menu_items[freq_id] = val;
> +
> + freq_cfg = _freq_configs[freq_id];
> + ret = fwnode_property_read_u32(fwn_freq, "pixel-rate", );

This is something a sensor driver needs to know. It may not be present in
device firmware.

> + if (ret) {
> + dev_err(dev, "pixel-rate error : %d\n",  ret);
> + goto error;
> + }
> + freq_cfg->pixel_rate = val;
> +
> + num_of_values = fwnode_property_read_u32_array(fwn_freq,
> +"pll-regs",

This is something that could go to device 

Re: [PATCH 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver

[Jose Abreu]

Hi Hans,


On 13-06-2017 11:01, Jose Abreu wrote:

[snip]
> Changes from RFC:
>   - Added support for HDCP 1.4

[snip]
> +
> +/* HDCP 1.4 */
> +#define DW_HDMI_HDCP14_BKSV_SIZE 2
> +#define DW_HDMI_HDCP14_KEYS_SIZE (2 * 40)
> +
> +struct dw_hdmi_hdcp14_key {
> + u32 seed;
> + u32 bksv[DW_HDMI_HDCP14_BKSV_SIZE];
> + u32 keys[DW_HDMI_HDCP14_KEYS_SIZE];
> + bool keys_valid;
> +};
> +
> +struct dw_hdmi_rx_pdata {
> + /* Controller configuration */
> + unsigned int iref_clk; /* MHz */
> + struct dw_hdmi_hdcp14_key hdcp14_keys;
> + /* 5V sense interface */
> + bool (*dw_5v_status)(void __iomem *regs, int input);
> + void (*dw_5v_clear)(void __iomem *regs);
> + void __iomem *dw_5v_arg;
> + /* Zcal interface */
> + void (*dw_zcal_reset)(void __iomem *regs);
> + bool (*dw_zcal_done)(void __iomem *regs);
> + void __iomem *dw_zcal_arg;
> +};
> +
> +#endif /* __DW_HDMI_RX_PDATA_H__ */

I now have support for HDCP 1.4 in this driver. Can you send me
the patches about HDCP that you mentioned a while ago?

Best regards,
Jose Miguel Abreu

[PATCH 0/4] Synopsys Designware HDMI Video Capture Controller + PHY

[Jose Abreu]

The Synopsys Designware HDMI RX controller is an HDMI receiver controller that
is responsible to process digital data that comes from a phy. The final result
is a stream of raw video data that can then be connected to a video DMA, for
example, and transfered into RAM so that it can be displayed.

The controller + phy available in this series natively support all HDMI 1.4 and
HDMI 2.0 modes, including deep color. Although, the driver is quite in its
initial stage and unfortunatelly only non deep color modes are supported. Also,
audio is not yet supported in the driver (the controller has several audio
output interfaces).

Jose Abreu (4):
  [media] platform: Add Synopsys Designware HDMI RX PHY e405 Driver
  [media] platform: Add Synopsys Designware HDMI RX Controller Driver
  MAINTAINERS: Add entry for Synopsys Designware HDMI drivers
  dt-bindings: media: Document Synopsys Designware HDMI RX

Cc: Carlos Palminha 
Cc: Mauro Carvalho Chehab 
Cc: Hans Verkuil 
Cc: Rob Herring 

 .../devicetree/bindings/media/snps,dw-hdmi-rx.txt  |   41 +
 MAINTAINERS|7 +
 drivers/media/platform/Kconfig |2 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/dwc/Kconfig |   17 +
 drivers/media/platform/dwc/Makefile|2 +
 drivers/media/platform/dwc/dw-hdmi-phy-e405.c  |  783 ++
 drivers/media/platform/dwc/dw-hdmi-phy-e405.h  |   63 +
 drivers/media/platform/dwc/dw-hdmi-rx.c| 1496 
 drivers/media/platform/dwc/dw-hdmi-rx.h|  376 +
 include/media/dwc/dw-hdmi-phy-pdata.h  |  131 ++
 include/media/dwc/dw-hdmi-rx-pdata.h   |   63 +
 12 files changed, 2983 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
 create mode 100644 drivers/media/platform/dwc/Kconfig
 create mode 100644 drivers/media/platform/dwc/Makefile
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.c
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.h
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h
 create mode 100644 include/media/dwc/dw-hdmi-phy-pdata.h
 create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h

-- 
1.9.1

[PATCH 4/4] dt-bindings: media: Document Synopsys Designware HDMI RX

[Jose Abreu]

Document the bindings for the Synopsys Designware HDMI RX.

Signed-off-by: Jose Abreu 
Cc: Rob Herring 
---
 .../devicetree/bindings/media/snps,dw-hdmi-rx.txt  | 41 ++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt

diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt 
b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
new file mode 100644
index 000..9e877de
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
@@ -0,0 +1,41 @@
+Synopsys DesignWare HDMI RX Decoder
+===
+
+This document defines device tree properties for the Synopsys DesignWare HDMI
+RX Descoder (DWC HDMI RX). It doesn't constitute a device tree binding
+specification by itself but is meant to be referenced by platform-specific
+device tree bindings.
+
+When referenced from platform device tree bindings the properties defined in
+this document are defined as follows.
+
+- reg: Memory mapped base address and length of the DWC HDMI RX registers.
+
+- interrupts: Reference to the DWC HDMI RX interrupt and 5v sense interrupt.
+
+- snps,hdmi-phy-jtag-addr: JTAG address of the phy to be used.
+
+- snps,hdmi-phy-version: Version of the phy to be used.
+
+- snps,hdmi-phy-cfg-clk: Value of the cfg clk that is delivered to phy.
+
+- snps,hdmi-phy-driver: *Exact* name of the phy driver to be used.
+
+- snps,hdmi-ctl-cfg-clk: Value of the cfg clk that is delivered to the
+controller.
+
+A sample binding is now provided. The compatible string is for a wrapper driver
+which then instantiates the Synopsys Designware HDMI RX decoder driver.
+
+Example:
+
+dw_hdmi_wrapper: dw-hdmi-wrapper@0 {
+   compatible = "snps,dw-hdmi-rx-wrapper";
+   reg = <0x0 0x1>; /* controller regbank */
+   interrupts = <1 3>; /* controller interrupt + 5v sense interrupt */
+   snps,hdmi-phy-driver = "dw-hdmi-phy-e405";
+   snps,hdmi-phy-version = <405>;
+   snps,hdmi-phy-cfg-clk = <25>; /* MHz */
+   snps,hdmi-ctl-cfg-clk = <25>; /* MHz */
+   snps,hdmi-phy-jtag-addr = /bits/ 8 <0xfc>;
+};
-- 
1.9.1

[PATCH 1/4] [media] platform: Add Synopsys Designware HDMI RX PHY e405 Driver

[Jose Abreu]

This adds support for the Synopsys Designware HDMI RX PHY e405. This
phy receives and decodes HDMI video that is delivered to a controller.

Main features included in this driver are:
- Equalizer algorithm that chooses the phy best settings
according to the detected HDMI cable characteristics.
- Support for scrambling
- Support for HDMI 2.0 modes up to 6G (HDMI 4k@60Hz).

The driver was implemented as a standalone V4L2 subdevice and the
phy interface with the controller was implemented using V4L2 ioctls. I
do not know if this is the best option but it is not possible to use the
existing API functions directly as we need specific functions that will
be called by the controller at specific configuration stages.

There is also a bidirectional communication between controller and phy:
The phy must provide functions that the controller will call (i.e.
configuration functions) and the controller must provide read/write
callbacks, as well as other specific functions.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mauro Carvalho Chehab 
Cc: Hans Verkuil 

Changes from RFC:
- Remove a bunch of functions that can be collapsed into
a single config() function
- Add comments for the callbacks and structures (Hans)
---
 drivers/media/platform/Kconfig|   2 +
 drivers/media/platform/Makefile   |   2 +
 drivers/media/platform/dwc/Kconfig|   8 +
 drivers/media/platform/dwc/Makefile   |   1 +
 drivers/media/platform/dwc/dw-hdmi-phy-e405.c | 783 ++
 drivers/media/platform/dwc/dw-hdmi-phy-e405.h |  63 +++
 include/media/dwc/dw-hdmi-phy-pdata.h | 131 +
 7 files changed, 990 insertions(+)
 create mode 100644 drivers/media/platform/dwc/Kconfig
 create mode 100644 drivers/media/platform/dwc/Makefile
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.c
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.h
 create mode 100644 include/media/dwc/dw-hdmi-phy-pdata.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 288d3b0..8d83803 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -33,6 +33,8 @@ source "drivers/media/platform/omap/Kconfig"
 
 source "drivers/media/platform/blackfin/Kconfig"
 
+source "drivers/media/platform/dwc/Kconfig"
+
 config VIDEO_SH_VOU
tristate "SuperH VOU video output driver"
depends on MEDIA_CAMERA_SUPPORT
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index c3588d5..4910241 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -79,3 +79,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)   += mtk-vcodec/
 obj-$(CONFIG_VIDEO_MEDIATEK_MDP)   += mtk-mdp/
 
 obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
+
+obj-y  += dwc/
diff --git a/drivers/media/platform/dwc/Kconfig 
b/drivers/media/platform/dwc/Kconfig
new file mode 100644
index 000..361d38d
--- /dev/null
+++ b/drivers/media/platform/dwc/Kconfig
@@ -0,0 +1,8 @@
+config VIDEO_DWC_HDMI_PHY_E405
+   tristate "Synopsys Designware HDMI RX PHY e405 driver"
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   help
+ Support for Synopsys Designware HDMI RX PHY. Version is e405.
+
+ To compile this driver as a module, choose M here. The module
+ will be called dw-hdmi-phy-e405.
diff --git a/drivers/media/platform/dwc/Makefile 
b/drivers/media/platform/dwc/Makefile
new file mode 100644
index 000..fc3b62c
--- /dev/null
+++ b/drivers/media/platform/dwc/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o
diff --git a/drivers/media/platform/dwc/dw-hdmi-phy-e405.c 
b/drivers/media/platform/dwc/dw-hdmi-phy-e405.c
new file mode 100644
index 000..b6a5b4b
--- /dev/null
+++ b/drivers/media/platform/dwc/dw-hdmi-phy-e405.c
@@ -0,0 +1,783 @@
+/*
+ * Synopsys Designware HDMI PHY E405 driver
+ *
+ * This Synopsys dw-phy-e405 software and associated documentation
+ * (hereinafter the "Software") is an unsupported proprietary work of
+ * Synopsys, Inc. unless otherwise expressly agreed to in writing between
+ * Synopsys and you. The Software IS NOT an item of Licensed Software or a
+ * Licensed Product under any End User Software License Agreement or
+ * Agreement for Licensed Products with Synopsys or any supplement thereto.
+ * Synopsys is a registered trademark of Synopsys, Inc. Other names included
+ * in the SOFTWARE may be the trademarks of their respective owners.
+ *
+ * The contents of this file are dual-licensed; you may select either version 2
+ * of the GNU General Public License (“GPL”) or the MIT license (“MIT”).
+ *
+ * Copyright (c) 2017 Synopsys, Inc. and/or its affiliates.
+ *
+ * THIS SOFTWARE IS PROVIDED "AS IS"  WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING, BUT NOT 

[PATCH 3/4] MAINTAINERS: Add entry for Synopsys Designware HDMI drivers

[Jose Abreu]

Add a entry for Synopsys Designware HDMI Receivers drivers
and phys.

Signed-off-by: Jose Abreu 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 053c3bd..e798040 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11294,6 +11294,13 @@ L: net...@vger.kernel.org
 S: Supported
 F: drivers/net/ethernet/synopsys/
 
+SYNOPSYS DESIGNWARE HDMI RECEIVERS AND PHY DRIVERS
+M: Jose Abreu 
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/platform/dwc/*
+F: include/media/dwc/*
+
 SYNOPSYS DESIGNWARE I2C DRIVER
 M: Jarkko Nikula 
 R: Andy Shevchenko 
-- 
1.9.1

[PATCH 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver

[Jose Abreu]

This is an initial submission for the Synopsys Designware HDMI RX
Controller Driver. This driver interacts with a phy driver so that
a communication between them is created and a video pipeline is
configured.

The controller + phy pipeline can then be integrated into a fully
featured system that can be able to receive video up to 4k@60Hz
with deep color 48bit RGB, depending on the platform. Although,
this initial version does not yet handle deep color modes.

This driver was implemented as a standard V4L2 subdevice and its
main features are:
- Internal state machine that reconfigures phy until the
video is not stable
- JTAG communication with phy
- Inter-module communication with phy driver
- Debug write/read ioctls

Some notes:
- RX sense controller (cable connection/disconnection) must
be handled by the platform wrapper as this is not integrated
into the controller RTL
- The same goes for EDID ROM's
- ZCAL calibration is needed only in FPGA platforms, in ASIC
this is not needed
- The state machine is not an ideal solution as it creates a
kthread but it is needed because some sources might not be
very stable at sending the video (i.e. we must react
accordingly).

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mauro Carvalho Chehab 
Cc: Hans Verkuil 

Changes from RFC:
- Added support for HDCP 1.4
- Fixup HDMI_VIC not being parsed (Hans)
- Send source change signal when powering off (Hans)
- Added a "wait stable delay"
- Detect interlaced video modes (Hans)
- Restrain g/s_register from reading/writing to HDCP regs (Hans)
---
 drivers/media/platform/dwc/Kconfig  |9 +
 drivers/media/platform/dwc/Makefile |1 +
 drivers/media/platform/dwc/dw-hdmi-rx.c | 1496 +++
 drivers/media/platform/dwc/dw-hdmi-rx.h |  376 
 include/media/dwc/dw-hdmi-rx-pdata.h|   63 ++
 5 files changed, 1945 insertions(+)
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h
 create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h

diff --git a/drivers/media/platform/dwc/Kconfig 
b/drivers/media/platform/dwc/Kconfig
index 361d38d..11efa23 100644
--- a/drivers/media/platform/dwc/Kconfig
+++ b/drivers/media/platform/dwc/Kconfig
@@ -6,3 +6,12 @@ config VIDEO_DWC_HDMI_PHY_E405
 
  To compile this driver as a module, choose M here. The module
  will be called dw-hdmi-phy-e405.
+
+config VIDEO_DWC_HDMI_RX
+   tristate "Synopsys Designware HDMI Receiver driver"
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   help
+ Support for Synopsys Designware HDMI RX controller.
+
+ To compile this driver as a module, choose M here. The module
+ will be called dw-hdmi-rx.
diff --git a/drivers/media/platform/dwc/Makefile 
b/drivers/media/platform/dwc/Makefile
index fc3b62c..cd04ca9 100644
--- a/drivers/media/platform/dwc/Makefile
+++ b/drivers/media/platform/dwc/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o
+obj-$(CONFIG_VIDEO_DWC_HDMI_RX) += dw-hdmi-rx.o
diff --git a/drivers/media/platform/dwc/dw-hdmi-rx.c 
b/drivers/media/platform/dwc/dw-hdmi-rx.c
new file mode 100644
index 000..27ba3c3
--- /dev/null
+++ b/drivers/media/platform/dwc/dw-hdmi-rx.c
@@ -0,0 +1,1496 @@
+/*
+ * Synopsys Designware HDMI Receiver controller driver
+ *
+ * This Synopsys dw-hdmi-rx software and associated documentation
+ * (hereinafter the "Software") is an unsupported proprietary work of
+ * Synopsys, Inc. unless otherwise expressly agreed to in writing between
+ * Synopsys and you. The Software IS NOT an item of Licensed Software or a
+ * Licensed Product under any End User Software License Agreement or
+ * Agreement for Licensed Products with Synopsys or any supplement thereto.
+ * Synopsys is a registered trademark of Synopsys, Inc. Other names included
+ * in the SOFTWARE may be the trademarks of their respective owners.
+ *
+ * The contents of this file are dual-licensed; you may select either version 2
+ * of the GNU General Public License (“GPL”) or the MIT license (“MIT”).
+ *
+ * Copyright (c) 2017 Synopsys, Inc. and/or its affiliates.
+ *
+ * THIS SOFTWARE IS PROVIDED "AS IS"  WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING, BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE
+ * ARISING FROM, OUT OF, OR IN CONNECTION WITH THE SOFTWARE THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 

Re: [PATCH v2 0/3] ngene: Replace semaphores with mutexes

[Arnd Bergmann]

On Tue, Jun 13, 2017 at 10:58 AM, Binoy Jayan  wrote:
> These are a set of patches [v2] which removes semaphores from ngene.
> These are part of a bigger effort to eliminate unwanted semaphores
> from the linux kernel.

All three

Acked-by: Arnd Bergmann 

I already gave an Ack for one or two of the patches in the first round, but
you seem to have dropped that. When you resend a patch with an Ack,
please include that above your Signed-off-by line. (No need to resend
for an Ack otherwise, this normally gets picked up when the patch
gets applied from the list.

   Arnd

Re: [PATCH v4 1/2] media: i2c: adv748x: add adv748x driver

[Geert Uytterhoeven]

Hi Kieran,

On Tue, Jun 13, 2017 at 11:32 AM, Kieran Bingham
 wrote:
> On 13/06/17 10:24, Geert Uytterhoeven wrote:
>> On Tue, Jun 13, 2017 at 2:35 AM, Kieran Bingham  wrote:
>>> From: Kieran Bingham 
>>>
>>> Provide support for the ADV7481 and ADV7482.
>>>
>>> The driver is modelled with 4 subdevices to allow simultaneous streaming
>>> from the AFE (Analog front end) and HDMI inputs though two CSI TX
>>> entities.
>>>
>>> The HDMI entity is linked to the TXA CSI bus, whilst the AFE is linked
>>> to the TXB CSI bus.
>>>
>>> The driver is based on a prototype by Koji Matsuoka in the Renesas BSP,
>>> and an earlier rework by Niklas Söderlund.
>>>
>>> Signed-off-by: Kieran Bingham 
>>
>>> --- /dev/null
>>> +++ b/drivers/media/i2c/adv748x/adv748x-hdmi.c
>>
>>> +static int adv748x_hdmi_set_pixelrate(struct adv748x_hdmi *hdmi)
>>> +{
>>> +   struct v4l2_subdev *tx;
>>> +   struct v4l2_dv_timings timings;
>>> +   struct v4l2_bt_timings *bt = 
>>> +   unsigned int fps;
>>> +
>>> +   tx = adv748x_get_remote_sd(>pads[ADV748X_HDMI_SOURCE]);
>>> +   if (!tx)
>>> +   return -ENOLINK;
>>> +
>>> +   adv748x_hdmi_query_dv_timings(>sd, );
>>> +
>>> +   fps = DIV_ROUND_CLOSEST(bt->pixelclock,
>>> +   V4L2_DV_BT_FRAME_WIDTH(bt) *
>>> +   V4L2_DV_BT_FRAME_HEIGHT(bt));
>>
>> On arm32:
>>
>> drivers/built-in.o: In function `adv748x_hdmi_set_pixelrate':
>> :(.text+0x1b8b1c): undefined reference to `__aeabi_uldivmod'
>>
>> v4l2_bt_timings.pixelclock is u64, so you should use DIV_ROUND_CLOSEST_ULL()
>> instead.
>
> Aha, thanks.
>
> /me ponders why I didn't get spammed from the bot-builders about this?

-EBUSY?

> Fix applied locally ready for v5.
>
> Would you like the remote updated for renesas-drivers or will you patch 
> locally?

I'll patch it locally just to avoid receiving more spam from the builders soon
(we don't use adv748x on arm32 boards).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v9] media: i2c: max2175: Add MAX2175 support

[Geert Uytterhoeven]

Hi Ramesh,

On Tue, Jun 13, 2017 at 11:10 AM, Ramesh Shanmugasundaram
 wrote:
> This patch adds driver support for the MAX2175 chip. This is Maxim
> Integrated's RF to Bits tuner front end chip designed for software-defined
> radio solutions. This driver exposes the tuner as a sub-device instance
> with standard and custom controls to configure the device.
>
> Signed-off-by: Ramesh Shanmugasundaram 
> 
> ---
> Hi Hans,
>
>As requested, here is the v9 of this patch alone implementing the work
>around to avoid the sparse warning.
>
>
> https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg15138.html
>
>For some reason, I could not reproduce this warning in my setup :-(
>
> Thanks,
> Ramesh.
>
> v9:
>  - Work around to avoid a sparse warning generated because of
>regmap_read_poll_timeout macro implementation.

> +/* Checks expected pattern every msec until timeout */
> +static int max2175_poll_timeout(struct max2175 *ctx, u8 idx, u8 msb, u8 lsb,
> +   u8 exp_bitval, u32 timeout_ms)
> +{
> +   unsigned int val;
> +
> +   /*
> +* The brackets around the last parameter is a work around to avoid
> +* the sparse tool warning. The ideal fix is to use brackets for the
> +* last parameter of regmap_read_poll_timeout macro.
> +*/
> +   return regmap_read_poll_timeout(ctx->regmap, idx, val,
> +   (max2175_get_bitval(val, msb, lsb) == exp_bitval),
> +   1000, (timeout_ms * 1000));

I don't think that issue should be fixed here, so I prefer v8.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v4 1/2] media: i2c: adv748x: add adv748x driver

[Kieran Bingham]

On 13/06/17 10:24, Geert Uytterhoeven wrote:
> Hi Kieran,
> 
> On Tue, Jun 13, 2017 at 2:35 AM, Kieran Bingham  wrote:
>> From: Kieran Bingham 
>>
>> Provide support for the ADV7481 and ADV7482.
>>
>> The driver is modelled with 4 subdevices to allow simultaneous streaming
>> from the AFE (Analog front end) and HDMI inputs though two CSI TX
>> entities.
>>
>> The HDMI entity is linked to the TXA CSI bus, whilst the AFE is linked
>> to the TXB CSI bus.
>>
>> The driver is based on a prototype by Koji Matsuoka in the Renesas BSP,
>> and an earlier rework by Niklas Söderlund.
>>
>> Signed-off-by: Kieran Bingham 
> 
>> --- /dev/null
>> +++ b/drivers/media/i2c/adv748x/adv748x-hdmi.c
> 
>> +static int adv748x_hdmi_set_pixelrate(struct adv748x_hdmi *hdmi)
>> +{
>> +   struct v4l2_subdev *tx;
>> +   struct v4l2_dv_timings timings;
>> +   struct v4l2_bt_timings *bt = 
>> +   unsigned int fps;
>> +
>> +   tx = adv748x_get_remote_sd(>pads[ADV748X_HDMI_SOURCE]);
>> +   if (!tx)
>> +   return -ENOLINK;
>> +
>> +   adv748x_hdmi_query_dv_timings(>sd, );
>> +
>> +   fps = DIV_ROUND_CLOSEST(bt->pixelclock,
>> +   V4L2_DV_BT_FRAME_WIDTH(bt) *
>> +   V4L2_DV_BT_FRAME_HEIGHT(bt));
> 
> On arm32:
> 
> drivers/built-in.o: In function `adv748x_hdmi_set_pixelrate':
> :(.text+0x1b8b1c): undefined reference to `__aeabi_uldivmod'
> 
> v4l2_bt_timings.pixelclock is u64, so you should use DIV_ROUND_CLOSEST_ULL()
> instead.

Aha, thanks.

/me ponders why I didn't get spammed from the bot-builders about this?

Fix applied locally ready for v5.

Would you like the remote updated for renesas-drivers or will you patch locally?

--
Kieran

> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> 

[PATCH v9] media: i2c: max2175: Add MAX2175 support

[Ramesh Shanmugasundaram]

This patch adds driver support for the MAX2175 chip. This is Maxim
Integrated's RF to Bits tuner front end chip designed for software-defined
radio solutions. This driver exposes the tuner as a sub-device instance
with standard and custom controls to configure the device.

Signed-off-by: Ramesh Shanmugasundaram 
---
Hi Hans,

   As requested, here is the v9 of this patch alone implementing the work
   around to avoid the sparse warning.

   https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg15138.html

   For some reason, I could not reproduce this warning in my setup :-(

Thanks,
Ramesh.

v9:
 - Work around to avoid a sparse warning generated because of
   regmap_read_poll_timeout macro implementation.
v8:
 - Fixed smatch warnings in max2175_load_from_rom().
v7:
 - Made I2S enable/disable control as private (Mauro).
v6:
 - Addressed Sakari's comments. They are:
- Added uapi header file.
- Added newline at the end of the function before return.
- Cleaned up header file inclusion.
- Used fwnode_ apis whereever applicable.
- Cleaned up debug statements.
- Removed separate dir for max2175.
v5:
 - sck -> Sample clock is clarified in driver documentation (Hans)
 - "refout-load-pF" is renamed to "refout-load" as per updated bindings.
---
 Documentation/media/v4l-drivers/index.rst   |1 +
 Documentation/media/v4l-drivers/max2175.rst |   62 ++
 drivers/media/i2c/Kconfig   |   12 +
 drivers/media/i2c/Makefile  |2 +
 drivers/media/i2c/max2175.c | 1458 +++
 drivers/media/i2c/max2175.h |  109 ++
 include/uapi/linux/max2175.h|   28 +
 7 files changed, 1672 insertions(+)
 create mode 100644 Documentation/media/v4l-drivers/max2175.rst
 create mode 100644 drivers/media/i2c/max2175.c
 create mode 100644 drivers/media/i2c/max2175.h
 create mode 100644 include/uapi/linux/max2175.h

diff --git a/Documentation/media/v4l-drivers/index.rst 
b/Documentation/media/v4l-drivers/index.rst
index 90fe22a6414a..2e24d6806052 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -42,6 +42,7 @@ For more details see the file COPYING in the source 
distribution of Linux.
davinci-vpbe
fimc
ivtv
+   max2175
meye
omap3isp
omap4_camera
diff --git a/Documentation/media/v4l-drivers/max2175.rst 
b/Documentation/media/v4l-drivers/max2175.rst
new file mode 100644
index ..04478c25d57a
--- /dev/null
+++ b/Documentation/media/v4l-drivers/max2175.rst
@@ -0,0 +1,62 @@
+Maxim Integrated MAX2175 RF to bits tuner driver
+
+
+The MAX2175 driver implements the following driver-specific controls:
+
+``V4L2_CID_MAX2175_I2S_ENABLE``
+---
+Enable/Disable I2S output of the tuner. This is a private control
+that can be accessed only using the subdev interface.
+Refer to Documentation/media/kapi/v4l2-controls for more details.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``(0)``
+  - I2S output is disabled.
+* - ``(1)``
+  - I2S output is enabled.
+
+``V4L2_CID_MAX2175_HSLS``
+-
+The high-side/low-side (HSLS) control of the tuner for a given band.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``(0)``
+  - The LO frequency position is below the desired frequency.
+* - ``(1)``
+  - The LO frequency position is above the desired frequency.
+
+``V4L2_CID_MAX2175_RX_MODE (menu)``
+---
+The Rx mode controls a number of preset parameters of the tuner like
+sample clock (sck), sampling rate etc. These multiple settings are
+provided under one single label called Rx mode in the datasheet. The
+list below shows the supported modes with a brief description.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``"Europe modes"``
+* - ``"FM 1.2" (0)``
+  - This configures FM band with a sample rate of 0.512 million
+samples/sec with a 10.24 MHz sck.
+* - ``"DAB 1.2" (1)``
+  - This configures VHF band with a sample rate of 2.048 million
+samples/sec with a 32.768 MHz sck.
+
+* - ``"North America modes"``
+* - ``"FM 1.0" (0)``
+  - This configures FM band with a sample rate of 0.7441875 million
+samples/sec with a 14.88375 MHz sck.
+* - ``"DAB 1.2" (1)``
+  - This configures FM band with a sample rate of 0.372 million
+samples/sec with a 7.441875 MHz sck.
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index c380e2475c82..c0e6e78883b0 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -796,6 +796,18 @@ config 

Re: [PATCH v4 1/2] media: i2c: adv748x: add adv748x driver

[Geert Uytterhoeven]

Hi Kieran,

On Tue, Jun 13, 2017 at 2:35 AM, Kieran Bingham  wrote:
> From: Kieran Bingham 
>
> Provide support for the ADV7481 and ADV7482.
>
> The driver is modelled with 4 subdevices to allow simultaneous streaming
> from the AFE (Analog front end) and HDMI inputs though two CSI TX
> entities.
>
> The HDMI entity is linked to the TXA CSI bus, whilst the AFE is linked
> to the TXB CSI bus.
>
> The driver is based on a prototype by Koji Matsuoka in the Renesas BSP,
> and an earlier rework by Niklas Söderlund.
>
> Signed-off-by: Kieran Bingham 

> --- /dev/null
> +++ b/drivers/media/i2c/adv748x/adv748x-hdmi.c

> +static int adv748x_hdmi_set_pixelrate(struct adv748x_hdmi *hdmi)
> +{
> +   struct v4l2_subdev *tx;
> +   struct v4l2_dv_timings timings;
> +   struct v4l2_bt_timings *bt = 
> +   unsigned int fps;
> +
> +   tx = adv748x_get_remote_sd(>pads[ADV748X_HDMI_SOURCE]);
> +   if (!tx)
> +   return -ENOLINK;
> +
> +   adv748x_hdmi_query_dv_timings(>sd, );
> +
> +   fps = DIV_ROUND_CLOSEST(bt->pixelclock,
> +   V4L2_DV_BT_FRAME_WIDTH(bt) *
> +   V4L2_DV_BT_FRAME_HEIGHT(bt));

On arm32:

drivers/built-in.o: In function `adv748x_hdmi_set_pixelrate':
:(.text+0x1b8b1c): undefined reference to `__aeabi_uldivmod'

v4l2_bt_timings.pixelclock is u64, so you should use DIV_ROUND_CLOSEST_ULL()
instead.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[Tomasz Figa]

Hi Tuukka,

Thanks for your replies. Please see mine inline.

On Tue, Jun 13, 2017 at 5:58 PM, Tuukka Toivonen
 wrote:
> Hi Tomasz,
>
> On Monday, June 12, 2017 18:59:18 Tomasz Figa wrote:
>> By any chance, doesn't the hardware provide some simple mode for
>> contiguous buffers? Since we have an MMU anyway, we could use
>> vb2_dma_contig and simplify the code significantly.
>
> In IPU3 the CIO2 (CSI-2 receiver) and the IMGU (image processing system)
> are entirely separate PCI devices. The MMU is only in the IMGU device;
> the CIO2 doesn't have MMU but has the FBPT (frame buffer pointer tables)
> to handle discontinuous buffers.
>
> [...]
>
>>
>> > +   pixelformat = V4L2_PIX_FMT_IPU3_SRGGB10;
>> > +
>> > +   alloc_devs[0] = >pci_dev->dev;
>>
>> Hmm, so it doesn't go through the IPU MMU in the end?
>
> No, it doesn't.

Aha. I was confused by the fact that the driver calls
dma_alloc_(non)coherent() with sizes likely greater than PAGE_SIZE.

So, given the above, I believe we need to fix the LOP allocation to
allocate one page at a time and stop relying on bus address
contiguity.

>> > +/* Called after each buffer is allocated */
>> > +static int cio2_vb2_buf_init(struct vb2_buffer *vb)
>> > +{
>> > +   struct cio2_device *cio2 = vb2_get_drv_priv(vb->vb2_queue);
>> > +   struct device *dev = >pci_dev->dev;
>> > +   struct cio2_buffer *b =
>> > +   container_of(vb, struct cio2_buffer, vbb.vb2_buf);
>> > +   unsigned int length = vb->planes[0].length;
>> > +   int lops  = DIV_ROUND_UP(DIV_ROUND_UP(length, PAGE_SIZE) +
> 1,
>> > +PAGE_SIZE / sizeof(u32));
>> > +   u32 *lop;
>> > +   struct sg_table *sg;
>> > +   struct sg_page_iter sg_iter;
>> > +
>> > +   if (lops <= 0 || lops > CIO2_MAX_LOPS) {
>> > +   dev_err(dev, "%s: bad buffer size (%i)\n", __func__,
> length);
>> > +   return -ENOSPC; /* Should never happen */
>> > +   }
>> > +
>> > +   /* Allocate LOP table */
>> > +   b->lop = lop = dma_alloc_noncoherent(dev, lops * PAGE_SIZE,
>> > +   >lop_bus_addr,
> GFP_KERNEL);

^^ Here is the offending allocation.

>>
>> > +   u32 fbpt_rp =
>> > +   (readl(cio2->base +
> CIO2_REG_CDMARI(CIO2_DMA_CHAN))
>> > +>> CIO2_CDMARI_FBPT_RP_SHIFT)
>> > +   & CIO2_CDMARI_FBPT_RP_MASK;
>> > +
>> > +   /*
>> > +* fbpt_rp is the fbpt entry that the dma is
> currently working
>> > +* on, but since it could jump to next entry at any
> time,
>> > +* assume that we might already be there.
>> > +*/
>> > +   fbpt_rp = (fbpt_rp + 1) % CIO2_MAX_BUFFERS;
>>
>> Hmm, this is really racy. This code can be pre-empted and not execute
>> for quite long time, depending on system load, resuming after the
>> hardware goes even further. Technically you could prevent this using
>> *_irq_save()/_irq_restore(), but I'd try to find a way that doesn't
>> rely on the timing, if possible.
>
> That is true, if the driver doesn't get executed in more than one frame
> time. I don't think that's very common, but should be handled.
>
> Hmm. Actually the buffer has VALID bit which is set by driver to indicate
> that the HW can fill the buffer and cleared by HW to indicate that the
> buffer is filled. Probably the HW can not actually jump to the next
> buffer as suggested by the comment, because I think the VALID bit
> would be clear in that case. That should be checked.

I think the problem here is that we keep all the entries valid and
only point to dummy buffers if there are no buffers queued by
userspace.

>
>>
>> > +
>> > +   if (bufs_queued <= 1)
>> > +   next = fbpt_rp + 1; /* Buffers were
> drained */
>> > +   else if (fbpt_rp == next)
>> > +   next++;
>> > +   next %= CIO2_MAX_BUFFERS;
>> > +   }
>> > +
>> > +   while (q->bufs[next]) {
>> > +   /* If the entry is used, get the next one,
>> > +* We can not break here if all are filled,
>> > +* Will wait for one free, otherwise it will crash
>> > +*/
>
> That comment should be fixed. "otherwise it will crash" doesn't
> tell much useful. Why would it crash?
>
>> > +   dev_dbg(>pci_dev->dev,
>> > +   "entry %i was already full!\n", next);
>> > +   next = (next + 1) % CIO2_MAX_BUFFERS;
>>
>> A busy waiting, possibly infinite, loop. Hmm.
>
> It's not really busy waiting. We have allocated CIO2_MAX_BUFFERS
> buffers (or actually just buffer entries in HW table) circularly for the
> hardware, and then the user has requested N buffer queue. The driver
> ensures N <= CIO2_MAX_BUFFERS and this guarantees that whenever user
> queues a buffer, there necessarily is a 

[PATCH v2 3/3] media: ngene: Replace semaphore i2c_switch_mutex with mutex

[Binoy Jayan]

The semaphore 'i2c_switch_mutex' is used as a simple mutex, so
it should be written as one. Semaphores are going away in the future.

Signed-off-by: Binoy Jayan 
---
 drivers/media/pci/ngene/ngene-core.c | 2 +-
 drivers/media/pci/ngene/ngene-i2c.c  | 6 +++---
 drivers/media/pci/ngene/ngene.h  | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/media/pci/ngene/ngene-core.c 
b/drivers/media/pci/ngene/ngene-core.c
index ea64901..8c92cb7 100644
--- a/drivers/media/pci/ngene/ngene-core.c
+++ b/drivers/media/pci/ngene/ngene-core.c
@@ -1345,7 +1345,7 @@ static int ngene_start(struct ngene *dev)
mutex_init(>cmd_mutex);
mutex_init(>stream_mutex);
sema_init(>pll_mutex, 1);
-   sema_init(>i2c_switch_mutex, 1);
+   mutex_init(>i2c_switch_mutex);
spin_lock_init(>cmd_lock);
for (i = 0; i < MAX_STREAM; i++)
spin_lock_init(>channel[i].state_lock);
diff --git a/drivers/media/pci/ngene/ngene-i2c.c 
b/drivers/media/pci/ngene/ngene-i2c.c
index cf39fcf..fbf3635 100644
--- a/drivers/media/pci/ngene/ngene-i2c.c
+++ b/drivers/media/pci/ngene/ngene-i2c.c
@@ -118,7 +118,7 @@ static int ngene_i2c_master_xfer(struct i2c_adapter 
*adapter,
(struct ngene_channel *)i2c_get_adapdata(adapter);
struct ngene *dev = chan->dev;
 
-   down(>i2c_switch_mutex);
+   mutex_lock(>i2c_switch_mutex);
ngene_i2c_set_bus(dev, chan->number);
 
if (num == 2 && msg[1].flags & I2C_M_RD && !(msg[0].flags & I2C_M_RD))
@@ -136,11 +136,11 @@ static int ngene_i2c_master_xfer(struct i2c_adapter 
*adapter,
msg[0].buf, msg[0].len, 0))
goto done;
 
-   up(>i2c_switch_mutex);
+   mutex_unlock(>i2c_switch_mutex);
return -EIO;
 
 done:
-   up(>i2c_switch_mutex);
+   mutex_unlock(>i2c_switch_mutex);
return num;
 }
 
diff --git a/drivers/media/pci/ngene/ngene.h b/drivers/media/pci/ngene/ngene.h
index 0dd15d6..7c7cd21 100644
--- a/drivers/media/pci/ngene/ngene.h
+++ b/drivers/media/pci/ngene/ngene.h
@@ -765,7 +765,7 @@ struct ngene {
struct mutex  cmd_mutex;
struct mutex  stream_mutex;
struct semaphore  pll_mutex;
-   struct semaphore  i2c_switch_mutex;
+   struct mutex  i2c_switch_mutex;
int   i2c_current_channel;
int   i2c_current_bus;
spinlock_tcmd_lock;
-- 
Binoy Jayan

[PATCH v2 1/3] media: ngene: Replace semaphore cmd_mutex with mutex

[Binoy Jayan]

The semaphore 'cmd_mutex' is used as a simple mutex, so
it should be written as one. Also, replace down with
mutex_destroy to ensure sane state when ngene_stop is
called.

Signed-off-by: Binoy Jayan 
---
 drivers/media/pci/ngene/ngene-core.c | 12 ++--
 drivers/media/pci/ngene/ngene.h  |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/media/pci/ngene/ngene-core.c 
b/drivers/media/pci/ngene/ngene-core.c
index ce69e64..eeb61eb 100644
--- a/drivers/media/pci/ngene/ngene-core.c
+++ b/drivers/media/pci/ngene/ngene-core.c
@@ -336,9 +336,9 @@ int ngene_command(struct ngene *dev, struct ngene_command 
*com)
 {
int result;
 
-   down(>cmd_mutex);
+   mutex_lock(>cmd_mutex);
result = ngene_command_mutex(dev, com);
-   up(>cmd_mutex);
+   mutex_unlock(>cmd_mutex);
return result;
 }
 
@@ -1283,7 +1283,7 @@ static int ngene_load_firm(struct ngene *dev)
 
 static void ngene_stop(struct ngene *dev)
 {
-   down(>cmd_mutex);
+   mutex_destroy(>cmd_mutex);
i2c_del_adapter(&(dev->channel[0].i2c_adapter));
i2c_del_adapter(&(dev->channel[1].i2c_adapter));
ngwritel(0, NGENE_INT_ENABLE);
@@ -1346,7 +1346,7 @@ static int ngene_start(struct ngene *dev)
init_waitqueue_head(>cmd_wq);
init_waitqueue_head(>tx_wq);
init_waitqueue_head(>rx_wq);
-   sema_init(>cmd_mutex, 1);
+   mutex_init(>cmd_mutex);
sema_init(>stream_mutex, 1);
sema_init(>pll_mutex, 1);
sema_init(>i2c_switch_mutex, 1);
@@ -1606,10 +1606,10 @@ static void ngene_unlink(struct ngene *dev)
com.in_len = 3;
com.out_len = 1;
 
-   down(>cmd_mutex);
+   mutex_lock(>cmd_mutex);
ngwritel(0, NGENE_INT_ENABLE);
ngene_command_mutex(dev, );
-   up(>cmd_mutex);
+   mutex_unlock(>cmd_mutex);
 }
 
 void ngene_shutdown(struct pci_dev *pdev)
diff --git a/drivers/media/pci/ngene/ngene.h b/drivers/media/pci/ngene/ngene.h
index 10d8f74..e600b70 100644
--- a/drivers/media/pci/ngene/ngene.h
+++ b/drivers/media/pci/ngene/ngene.h
@@ -762,7 +762,7 @@ struct ngene {
 
wait_queue_head_t cmd_wq;
int   cmd_done;
-   struct semaphore  cmd_mutex;
+   struct mutex  cmd_mutex;
struct semaphore  stream_mutex;
struct semaphore  pll_mutex;
struct semaphore  i2c_switch_mutex;
-- 
Binoy Jayan

[PATCH v2 2/3] media: ngene: Replace semaphore stream_mutex with mutex

[Binoy Jayan]

The semaphore 'stream_mutex' is used as a simple mutex, so
it should be written as one. Also moving the mutex_[lock/unlock]
to the caller as it is anyway locked at the beginning of the
callee thus avoiding repetition.

Signed-off-by: Binoy Jayan 
---
 drivers/media/pci/ngene/ngene-core.c | 18 +++---
 drivers/media/pci/ngene/ngene.h  |  2 +-
 2 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/media/pci/ngene/ngene-core.c 
b/drivers/media/pci/ngene/ngene-core.c
index eeb61eb..ea64901 100644
--- a/drivers/media/pci/ngene/ngene-core.c
+++ b/drivers/media/pci/ngene/ngene-core.c
@@ -560,7 +560,6 @@ static int ngene_command_stream_control(struct ngene *dev, 
u8 stream,
u16 BsSPI = ((stream & 1) ? 0x9800 : 0x9700);
u16 BsSDO = 0x9B00;
 
-   down(>stream_mutex);
memset(, 0, sizeof(com));
com.cmd.hdr.Opcode = CMD_CONTROL;
com.cmd.hdr.Length = sizeof(struct FW_STREAM_CONTROL) - 2;
@@ -586,17 +585,13 @@ static int ngene_command_stream_control(struct ngene 
*dev, u8 stream,
chan->State = KSSTATE_ACQUIRE;
chan->HWState = HWSTATE_STOP;
spin_unlock_irq(>state_lock);
-   if (ngene_command(dev, ) < 0) {
-   up(>stream_mutex);
+   if (ngene_command(dev, ) < 0)
return -1;
-   }
/* clear_buffers(chan); */
flush_buffers(chan);
-   up(>stream_mutex);
return 0;
}
spin_unlock_irq(>state_lock);
-   up(>stream_mutex);
return 0;
}
 
@@ -692,11 +687,9 @@ static int ngene_command_stream_control(struct ngene *dev, 
u8 stream,
chan->HWState = HWSTATE_STARTUP;
spin_unlock_irq(>state_lock);
 
-   if (ngene_command(dev, ) < 0) {
-   up(>stream_mutex);
+   if (ngene_command(dev, ) < 0)
return -1;
-   }
-   up(>stream_mutex);
+
return 0;
 }
 
@@ -750,8 +743,11 @@ void set_transfer(struct ngene_channel *chan, int state)
/* else printk(KERN_INFO DEVICE_NAME ": lock=%08x\n",
   ngreadl(0x9310)); */
 
+   mutex_lock(>stream_mutex);
ret = ngene_command_stream_control(dev, chan->number,
   control, mode, flags);
+   mutex_unlock(>stream_mutex);
+
if (!ret)
chan->running = state;
else
@@ -1347,7 +1343,7 @@ static int ngene_start(struct ngene *dev)
init_waitqueue_head(>tx_wq);
init_waitqueue_head(>rx_wq);
mutex_init(>cmd_mutex);
-   sema_init(>stream_mutex, 1);
+   mutex_init(>stream_mutex);
sema_init(>pll_mutex, 1);
sema_init(>i2c_switch_mutex, 1);
spin_lock_init(>cmd_lock);
diff --git a/drivers/media/pci/ngene/ngene.h b/drivers/media/pci/ngene/ngene.h
index e600b70..0dd15d6 100644
--- a/drivers/media/pci/ngene/ngene.h
+++ b/drivers/media/pci/ngene/ngene.h
@@ -763,7 +763,7 @@ struct ngene {
wait_queue_head_t cmd_wq;
int   cmd_done;
struct mutex  cmd_mutex;
-   struct semaphore  stream_mutex;
+   struct mutex  stream_mutex;
struct semaphore  pll_mutex;
struct semaphore  i2c_switch_mutex;
int   i2c_current_channel;
-- 
Binoy Jayan

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

[Tuukka Toivonen]

Hi Tomasz,

On Monday, June 12, 2017 18:59:18 Tomasz Figa wrote:
> By any chance, doesn't the hardware provide some simple mode for
> contiguous buffers? Since we have an MMU anyway, we could use
> vb2_dma_contig and simplify the code significantly.

In IPU3 the CIO2 (CSI-2 receiver) and the IMGU (image processing system) 
are entirely separate PCI devices. The MMU is only in the IMGU device; 
the CIO2 doesn't have MMU but has the FBPT (frame buffer pointer tables) 
to handle discontinuous buffers.

[...]

> 
> > +   pixelformat = V4L2_PIX_FMT_IPU3_SRGGB10;
> > +
> > +   alloc_devs[0] = >pci_dev->dev;
> 
> Hmm, so it doesn't go through the IPU MMU in the end?

No, it doesn't.

> 
> > +   szimage = cio2_bytesperline(width) * height;
> > +
> > +   if (*num_planes) {
> > +   /*
> > +* Only single plane is supported
> > +*/
> > +   if (*num_planes != 1 || sizes[0] < szimage)
> > +   return -EINVAL;
> 
> S_FMT should validate this and then queue_setup should never get an
> invalid value.
> 
> > +   }
> > +
> > +   *num_planes = 1;
> > +   sizes[0] = szimage;
> > +
> > +   *num_buffers = clamp_val(*num_buffers, 1, CIO2_MAX_BUFFERS);
> > +
> > +   /* Initialize buffer queue */
> > +   for (i = 0; i < CIO2_MAX_BUFFERS; i++) {
> > +   q->bufs[i] = NULL;
> > +   cio2_fbpt_entry_init_dummy(cio2, >fbpt[i * 
CIO2_MAX_LOPS]);
> > +   }
> > +   atomic_set(>bufs_queued, 0);
> > +   q->bufs_first = 0;
> > +   q->bufs_next = 0;
> > +
> > +   return r;
> > +}
> > +
> > +/* Called after each buffer is allocated */
> > +static int cio2_vb2_buf_init(struct vb2_buffer *vb)
> > +{
> > +   struct cio2_device *cio2 = vb2_get_drv_priv(vb->vb2_queue);
> > +   struct device *dev = >pci_dev->dev;
> > +   struct cio2_buffer *b =
> > +   container_of(vb, struct cio2_buffer, vbb.vb2_buf);
> > +   unsigned int length = vb->planes[0].length;
> > +   int lops  = DIV_ROUND_UP(DIV_ROUND_UP(length, PAGE_SIZE) + 
1,
> > +PAGE_SIZE / sizeof(u32));
> > +   u32 *lop;
> > +   struct sg_table *sg;
> > +   struct sg_page_iter sg_iter;
> > +
> > +   if (lops <= 0 || lops > CIO2_MAX_LOPS) {
> > +   dev_err(dev, "%s: bad buffer size (%i)\n", __func__, 
length);
> > +   return -ENOSPC; /* Should never happen */
> > +   }
> > +
> > +   /* Allocate LOP table */
> > +   b->lop = lop = dma_alloc_noncoherent(dev, lops * PAGE_SIZE,
> > +   >lop_bus_addr, 
GFP_KERNEL);
> 
> _coherent?
> 
> > +   if (!lop)
> > +   return -ENOMEM;
> > +
> > +   /* Fill LOP */
> > +   sg = vb2_dma_sg_plane_desc(vb, 0);
> > +   if (!sg)
> > +   return -EFAULT;
> 
> I'd say -ENOMEM is better here. (But actually it should be impossible,
> if allocation succeeded previously.)
> 
> > +
> > +   for_each_sg_page(sg->sgl, _iter, sg->nents, 0)
> > +   *lop++ = sg_page_iter_dma_address(_iter) >> 
PAGE_SHIFT;
> > +   *lop++ = cio2->dummy_page_bus_addr >> PAGE_SHIFT;
> > +
> > +   return 0;
> > +}
> > +
> > +/* Transfer buffer ownership to cio2 */
> > +static void cio2_vb2_buf_queue(struct vb2_buffer *vb)
> > +{
> > +   struct cio2_device *cio2 = vb2_get_drv_priv(vb->vb2_queue);
> > +   struct cio2_queue *q =
> > +   container_of(vb->vb2_queue, struct cio2_queue, vbq);
> > +   struct cio2_buffer *b =
> > +   container_of(vb, struct cio2_buffer, vbb.vb2_buf);
> > +   struct cio2_fbpt_entry *entry;
> > +   unsigned int next = q->bufs_next;
> > +   int bufs_queued = atomic_inc_return(>bufs_queued);
> > +
> > +   if (vb2_start_streaming_called(>vbq)) {
> 
> Shouldn't it be vb2_is_streaming()? (There is not much difference,
> though, except that vb2_start_streaming_called() returns true, even
> before .start_streaming finished, while vb2_is_streaming() does so
> only after it returns successfully.)
> 
> > +   u32 fbpt_rp =
> > +   (readl(cio2->base + 
CIO2_REG_CDMARI(CIO2_DMA_CHAN))
> > +>> CIO2_CDMARI_FBPT_RP_SHIFT)
> > +   & CIO2_CDMARI_FBPT_RP_MASK;
> > +
> > +   /*
> > +* fbpt_rp is the fbpt entry that the dma is 
currently working
> > +* on, but since it could jump to next entry at any 
time,
> > +* assume that we might already be there.
> > +*/
> > +   fbpt_rp = (fbpt_rp + 1) % CIO2_MAX_BUFFERS;
> 
> Hmm, this is really racy. This code can be pre-empted and not execute
> for quite long time, depending on system load, resuming after the
> hardware goes even further. Technically you could prevent this using
> *_irq_save()/_irq_restore(), but I'd try to find a way that doesn't
> rely on the timing, 

[PATCH v2 0/3] ngene: Replace semaphores with mutexes

[Binoy Jayan]

These are a set of patches [v2] which removes semaphores from ngene.
These are part of a bigger effort to eliminate unwanted semaphores
from the linux kernel.

v1 --> v2
-

Moved mutex_[lock/unlock] outside caller for stream_mutex
mutex_lock converted to mutex_destroy in cmd_mutex

Binoy Jayan (3):
  media: ngene: Replace semaphore cmd_mutex with mutex
  media: ngene: Replace semaphore stream_mutex with mutex
  media: ngene: Replace semaphore i2c_switch_mutex with mutex

 drivers/media/pci/ngene/ngene-core.c | 32 ++--
 drivers/media/pci/ngene/ngene-i2c.c  |  6 +++---
 drivers/media/pci/ngene/ngene.h  |  6 +++---
 3 files changed, 20 insertions(+), 24 deletions(-)

-- 
Binoy Jayan

Re: [PATCH 1/3] media: ngene: Replace semaphore cmd_mutex with mutex

[Binoy Jayan]

Hi Arnd,

On 9 June 2017 at 16:06, Arnd Bergmann  wrote:

>> Thank you for pointing out that. I'll check the
>> concurrency part. By the way why do we need mutex_destoy?
>> To debug an aberrate condition?
>
> At first I suspected the down() here was added for the same
> purpose as a mutex_destroy: to ensure that we are in a sane
> state before we free the device structure, but the way they
> achieve that is completely different.
>
> However, if there is any way that a command may still be in
> progress by the time we get to ngene_stop(), we may also
> be lacking reference counting on the ngene structure here.
> So far I haven't found any of those, and think the mutex_destroy()
> is sufficient here as a debugging help.

I've made the necessary changes. Thank you for reviewing all the patches.

Regards,
Binoy

Re: [PATCH v8 2/3] [media] add mux and video interface bridge entity functions

[Pavel Machek]

On Wed 2017-06-07 11:33:44, Philipp Zabel wrote:
> Add two new media entity function definitions for video multiplexers
> and video interface bridges.
> 
> Signed-off-by: Philipp Zabel 

Acked-by: Pavel Machek 

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


signature.asc
Description: Digital signature

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:   Tue Jun 13 05:00:15 CEST 2017
media-tree git hash:47f910f0e0deb880c2114811f7ea1ec115a19ee4
media_build git hash:   170d3ce439eed9f2f43c5e02fc8d3ca201ca78e8
v4l-utils git hash: ce237eefc1f6dafafc0e1fe3a5fd9f075d3fd066
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

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

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH v4 1/2] media: i2c: adv748x: add adv748x driver

[Niklas Söderlund]

Hi Kieran,

Thanks for your patch, and great work!

On 2017-06-13 01:35:07 +0100, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> Provide support for the ADV7481 and ADV7482.
> 
> The driver is modelled with 4 subdevices to allow simultaneous streaming
> from the AFE (Analog front end) and HDMI inputs though two CSI TX
> entities.
> 
> The HDMI entity is linked to the TXA CSI bus, whilst the AFE is linked
> to the TXB CSI bus.
> 
> The driver is based on a prototype by Koji Matsuoka in the Renesas BSP,
> and an earlier rework by Niklas Söderlund.
> 
> Signed-off-by: Kieran Bingham 
> 
> ---
> 
> v2:
>  - Implement DT parsing
>  - adv748x: Add CSI2 entity
>  - adv748x: Rework pad allocations and fmts
>  - Give AFE 8 input pads and move pad defines
>  - Use the enums to ensure pads are referenced correctly.
>  - adv748x: Rename AFE/HDMI entities
>Now they are 'just afe' and 'just hdmi'
>  - Reorder the entity enum and structures
>  - Added pad-format for the CSI2 entities
>  - CSI2 s_stream pass through
>  - CSI2 control pass through (with link following)
> 
> v3:
>  - dt: Extend DT documentation to specify interrupt mappings
>  - simplify adv748x_parse_dt
>  - core: Add banner to header file describing ADV748x variants
>  - Use entity structure pointers rather than global state pointers where
>possible
>  - afe: Reduce indent on afe_status
>  - hdmi: Add error checking to the bt->pixelclock values.
>  - Remove all unnecessary pad checks: handled by core
>  - Fix all probe cleanup paths
>  - adv748x_csi2_probe() now fails if it has no endpoint
>  - csi2: Fix small oneliners for is_txa and get_remote_sd()
>  - csi2: Fix checkpatch warnings
>  - csi2: Fix up s_stream pass-through
>  - csi2: Fix up Pixel Rate passthrough
>  - csi2: simplify adv748x_csi2_get_pad_format()
>  - Remove 'async notifiers' from AFE/HDMI
>Using async notifiers was overkill, when we have access to the
>subdevices internally and can register them directly.
>  - Use state lock in control handlers and clean up s_ctrls
>  - remove _interruptible mutex locks
> 
> v4:
>  - all: Convert hex 0xXX to lowercase
>  - all: Use defines instead of hardcoded register values
>  - all: Use regmap
>  - afe, csi2, hdmi: _probe -> _init
>  - afe, csi2, hdmi: _remove -> _cleanup
>  - afe, hdmi: Convert pattern generator to a control
>  - afe, hdmi: get/set-fmt refactor
>  - afe, hdmi, csi2: Convert to internal calls for pixelrate
>  - afe: Allow the AFE to configure the Input Select from DT
>  - afe: Reduce indent on adv748x_afe_status switch
>  - afe: Remove ununsed macro definitions AIN0-7
>  - afe: Remove extraneous control checks handled by core
>  - afe: Comment fixups
>  - afe: Rename error label
>  - afe: Correct control names on the SDP
>  - afe: Use AIN0-7 rather than AIN1-8 to match ports and MC pads
>  - core: adv748x_parse_dt references to nodes, and catch multiple
>endpoints in a port.
>  - core: adv748x_dt_cleanup to simplify releasing DT nodes
>  - core: adv748x_print_info renamed to adv748x_identify_chip
>  - core: reorganise ordering of probe sequence
>  - core: No need for of_match_ptr
>  - core: Fix up i2c read/writes (regmap still on todo list)
>  - core: Set specific functions from the entities on subdev-init
>  - core: Use kzalloc for state instead of devm
>  - core: Improve probe error reporting
>  - core: Track unknown BIT(6) in tx{a,b}_power
>  - csi2: Improve adv748x_csi2_get_remote_sd as adv748x_csi2_get_source_sd
>  - csi2: -EPIPE instead of -ENODEV
>  - csi2: adv_dbg, instead of adv_info
>  - csi2: adv748x_csi2_set_format fix
>  - csi2: remove async notifier and sd member variables
>  - csi2: register links from the CSI2
>  - csi2: create virtual channel helper function
>  - dt: Remove numbering from endpoints
>  - dt: describe ports and interrupts as optional
>  - dt: Re-tab
>  - hdmi: adv748x_hdmi_have_signal -> adv748x_hdmi_has_signal
>  - hdmi: fix adv748x_hdmi_read_pixelclock return checks
>  - hdmi: improve adv748x_hdmi_set_video_timings
>  - hdmi: Fix tmp variable as polarity
>  - hdmi: Improve adv748x_hdmi_s_stream
>  - hdmi: Clean up adv748x_hdmi_s_ctrl register definitions and usage
>  - hdmi: Fix up adv748x_hdmi_s_dv_timings with macro names for register
>  - hdmi: Add locking to adv748x_hdmi_g_dv_timings
>writes and locking
>  - hdmi: adv748x_hdmi_set_de_timings function added to clarify DE writes
>  - hdmi: Use CP in control register naming to match component processor
>  - hdmi: clean up adv748x_hdmi_query_dv_timings()
>  - KConfig: Fix up dependency and capitalisation
> 
> 
>  Documentation/devicetree/bindings/media/i2c/adv748x.txt |  96 +-
>  MAINTAINERS |   6 +-
>  drivers/media/i2c/Kconfig   |  11 +-
>  drivers/media/i2c/Makefile  |   1 +-
>  drivers/media/i2c/adv748x/Makefile  |   7 

Re: [RFC PATCH v3 09/11] [media] vimc: Subdevices as modules

[Hans Verkuil]

On 06/12/2017 10:35 PM, Helen Koike wrote:

Hi Hans,

Thank you for your review. Please check my comments below

On 2017-06-12 07:37 AM, Hans Verkuil wrote:

On 06/03/2017 04:58 AM, Helen Koike wrote:

+static struct component_match *vimc_add_subdevs(struct vimc_device
*vimc)
+{
+struct component_match *match = NULL;
+unsigned int i;
+
+for (i = 0; i < vimc->pipe_cfg->num_ents; i++) {
+dev_dbg(>pdev.dev, "new pdev for %s\n",
+vimc->pipe_cfg->ents[i].drv);
+
+/*
+ * TODO: check if using platform_data is indeed the best way to
+ * pass the name to the driver or if we should add the drv name
+ * in the platform_device_id table
+ */


Didn't you set the drv name in the platform_device_id table already?


I refer to the name of the entity, there is the name that identifies the
driver as "vimc-sensor" that is set in the platform_device_id table but
there is also the custom name of the entity e.g. "My Sensor A" that I
need to inform to the vimc-sensor driver.


Ah, so in the TODO you mean:

"the best way to pass the entity name to the driver"

I got confused there.

But in that case I still don't get what you mean with "add the drv name
in the platform_device_id table". Do you mean "entity name" there as
well?





Using platform_data feels like an abuse to be honest.


Another option would be to make the vimc-sensor driver to populate the
entity name automatically as "Sensor x", where x could be the entity
number, but I don't think this is a good option.


Why not? Well, probably not the entity number, but a simple instance
counter would do fine (i.e. Sensor 1, 2, 3...).

It can be made fancier later with dynamic reconfiguration where you
might want to use the first unused instance number.





Creating these components here makes sense. Wouldn't it also make sense
to use
v4l2_async to wait until they have all been bound? It would more closely
emulate
standard drivers. Apologies if I misunderstand what is happening here.


I am using linux/component.h for that, when all devices are present and
all modules are loaded, the component.h system brings up the core by
calling vimc_comp_bind() function, which calls component_bind_all() to
call the binding function of each module, then it finishes registering
the topology.
If any one of the components or module is unload, the component system
takes down the entire topology calling component_unbind_all which calls
the unbind functions from each module.
This makes sure that the media device, subdevices and video device are
only registered in the v4l2 system if all the modules are loaded.

I wans't familiar with v4l2-async.h, but from a quick look it seems that
it only works with struct v4l2_subdev, but I'll also need for struct
video_device (for the capture node for example).
And also, if a module is missing we would have vimc partially
registered, e.g. the debayer could be registered at /dev/subdevX but the
sensor not yet and the media wouldn't be ready, I am not sure if this is
a problem though.

Maybe we can use component.h for now, then I can implement
v4l2_async_{un}register_video_device and migrate to v4l2-sync.h latter.
What do you think?


That's OK. The v4l2-async mechanism precedes the component API. We should
probably investigate moving over to the component API. I seem to remember
that it didn't have all the features we needed, but it's a long time ago
since someone looked at that and whatever the objections were, they may
no longer be true.

Regards,

Hans

Re: [RFC PATCH v3 05/11] [media] vimc: common: Add vimc_link_validate

[Hans Verkuil]

On 06/12/2017 07:20 PM, Helen Koike wrote:

Hi Hans,

Thanks for your review, just a question below

On 2017-06-12 06:50 AM, Hans Verkuil wrote:

On 06/03/2017 04:58 AM, Helen Koike wrote:

+/* The width, height, code and colorspace must match. */
+if (source_fmt.format.width != sink_fmt.format.width
+|| source_fmt.format.height != sink_fmt.format.height
+|| source_fmt.format.code != sink_fmt.format.code
+|| source_fmt.format.colorspace != sink_fmt.format.colorspace)


Source and/or Sink may be COLORSPACE_DEFAULT. If that's the case, then
you should skip comparing ycbcr_enc, quantization or xfer_func. If
colorspace
is DEFAULT, then that implies that the other fields are DEFAULT as well.
Nothing
else makes sense in that case.


I thought that the colorspace couldn't be COLORSPACE_DEFAULT, in the
documentation it is written "The default colorspace. This can be used by
applications to let the driver fill in the colorspace.", so the
colorspace is always set to something different from default no ?
I thought that the COLORSPACE_DEFAULT was only used by the userspace in
VIDIOC_{SUBDEV}_S_FMT so say "driver, use wherever colorspace you want",
but if usespace calls VIDIOC_{SUBDEV}_G_FMT, it would return which exact
colorspace the driver is using, no?


I don't think this rule works for the MC. For regular v4l2 devices the
bridge driver knows what colorspace it receives so it can replace the
colorspace DEFAULT with the real one.

But a e.g. scaler subdev does not actually touch on the colorspace. And
it doesn't know what colorspace it will receive or transmit.

I don't feel it makes sense to require userspace to set and propagate the
colorspace information throughout the pipeline. Allowing it to be set to
DEFAULT (i.e. 'don't care') makes sense to me.

I might change my mind later on this. The simple fact is that the spec isn't
clear what to do with MC devices. That's also where this vimc driver comes
in, so we can try this out without requiring specialized hardware.

Regards,

Hans

[PATCH RESEND v10 1/1] [media] i2c: add support for OV13858 sensor

[Hyungwoo Yang]

This patch adds driver for Omnivision's ov13858
sensor, the driver supports following features:

- manual exposure/gain(analog and digital) control support
- two link frequencies
- VBLANK/HBLANK support
- test pattern support
- media controller support
- runtime pm support
- supported resolutions
  + 4224x3136 at 30FPS
  + 2112x1568 at 30FPS(default) and 60FPS
  + 2112x1188 at 30FPS(default) and 60FPS
  + 1056x784 at 30FPS(default) and 60FPS

Signed-off-by: Hyungwoo Yang 
---
 drivers/media/i2c/Kconfig   |8 +
 drivers/media/i2c/Makefile  |1 +
 drivers/media/i2c/ov13858.c | 1860 +++
 3 files changed, 1869 insertions(+)
 create mode 100644 drivers/media/i2c/ov13858.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index c380e24..26a9a3c 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -600,6 +600,14 @@ config VIDEO_OV9650
  This is a V4L2 sensor-level driver for the Omnivision
  OV9650 and OV9652 camera sensors.
 
+config VIDEO_OV13858
+   tristate "OmniVision OV13858 sensor support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV13858 camera.
+
 config VIDEO_VS6624
tristate "ST VS6624 sensor support"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 62323ec..3f4dc02 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
+obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
 obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
 obj-$(CONFIG_VIDEO_MT9M111) += mt9m111.o
 obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c
new file mode 100644
index 000..6e1c280
--- /dev/null
+++ b/drivers/media/i2c/ov13858.c
@@ -0,0 +1,1860 @@
+/*
+ * Copyright (c) 2017 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define OV13858_REG_VALUE_08BIT1
+#define OV13858_REG_VALUE_16BIT2
+#define OV13858_REG_VALUE_24BIT3
+
+#define OV13858_REG_MODE_SELECT0x0100
+#define OV13858_MODE_STANDBY   0x00
+#define OV13858_MODE_STREAMING 0x01
+
+#define OV13858_REG_SOFTWARE_RST   0x0103
+#define OV13858_SOFTWARE_RST   0x01
+
+/* PLL1 generates PCLK and MIPI_PHY_CLK */
+#define OV13858_REG_PLL1_CTRL_00x0300
+#define OV13858_REG_PLL1_CTRL_10x0301
+#define OV13858_REG_PLL1_CTRL_20x0302
+#define OV13858_REG_PLL1_CTRL_30x0303
+#define OV13858_REG_PLL1_CTRL_40x0304
+#define OV13858_REG_PLL1_CTRL_50x0305
+
+/* PLL2 generates DAC_CLK, SCLK and SRAM_CLK */
+#define OV13858_REG_PLL2_CTRL_B0x030b
+#define OV13858_REG_PLL2_CTRL_C0x030c
+#define OV13858_REG_PLL2_CTRL_D0x030d
+#define OV13858_REG_PLL2_CTRL_E0x030e
+#define OV13858_REG_PLL2_CTRL_F0x030f
+#define OV13858_REG_PLL2_CTRL_12   0x0312
+#define OV13858_REG_MIPI_SC_CTRL0  0x3016
+#define OV13858_REG_MIPI_SC_CTRL1  0x3022
+
+/* Chip ID */
+#define OV13858_REG_CHIP_ID0x300a
+#define OV13858_CHIP_ID0x00d855
+
+/* V_TIMING internal */
+#define OV13858_REG_VTS0x380e
+#define OV13858_VTS_30FPS  0x0c8e /* 30 fps */
+#define OV13858_VTS_60FPS  0x0648 /* 60 fps */
+#define OV13858_VTS_MAX0x7fff
+#define OV13858_VBLANK_MIN 56
+
+/* HBLANK control - read only */
+#define OV13858_PPL_540MHZ 2244
+#define OV13858_PPL_1080MHZ4488
+
+/* Exposure control */
+#define OV13858_REG_EXPOSURE   0x3500
+#define OV13858_EXPOSURE_MIN   4
+#define OV13858_EXPOSURE_MAX   (OV13858_VTS_MAX - 8)
+#define OV13858_EXPOSURE_STEP  1
+#define OV13858_EXPOSURE_DEFAULT   0x640
+
+/* Analog gain control */
+#define OV13858_REG_ANALOG_GAIN0x3508
+#define OV13858_ANA_GAIN_MIN   0
+#define OV13858_ANA_GAIN_MAX   0x1fff
+#define OV13858_ANA_GAIN_STEP  1
+#define