Re: [PATCH v3] [media] mtk-vcodec: Show mtk driver error without DEBUG definition

[Hirokazu Honda]

Fixing whitespace in the previous patch.

On Wed, Jul 5, 2017 at 2:33 PM, Hirokazu Honda  wrote:
> A driver error message is shown without DEBUG definition
> to find an error and debug easily.
>
> Signed-off-by: Hirokazu Honda 
> ---
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 20 +---
>  1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h 
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> index 237e144c194f..c1378c1b402c 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> @@ -32,6 +32,15 @@ extern int mtk_v4l2_dbg_level;
>  extern bool mtk_vcodec_dbg;
>
>
> +#define mtk_v4l2_err(fmt, args...) \
> +   pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
> +  ##args)
> +
> +#define mtk_vcodec_err(h, fmt, args...)  
>   \
> +   pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
> +  ((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
> +
> +
>  #if defined(DEBUG)
>
>  #define mtk_v4l2_debug(level, fmt, args...) \
> @@ -41,11 +50,6 @@ extern bool mtk_vcodec_dbg;
> level, __func__, __LINE__, ##args);  \
> } while (0)
>
> -#define mtk_v4l2_err(fmt, args...)\
> -   pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
> -  ##args)
> -
> -
>  #define mtk_v4l2_debug_enter()  mtk_v4l2_debug(3, "+")
>  #define mtk_v4l2_debug_leave()  mtk_v4l2_debug(3, "-")
>
> @@ -57,22 +61,16 @@ extern bool mtk_vcodec_dbg;
> __func__, ##args);  \
> } while (0)
>
> -#define mtk_vcodec_err(h, fmt, args...)  
>   \
> -   pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
> -  ((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
> -
>  #define mtk_vcodec_debug_enter(h)  mtk_vcodec_debug(h, "+")
>  #define mtk_vcodec_debug_leave(h)  mtk_vcodec_debug(h, "-")
>
>  #else
>
>  #define mtk_v4l2_debug(level, fmt, args...) {}
> -#define mtk_v4l2_err(fmt, args...) {}
>  #define mtk_v4l2_debug_enter() {}
>  #define mtk_v4l2_debug_leave() {}
>
>  #define mtk_vcodec_debug(h, fmt, args...) {}
> -#define mtk_vcodec_err(h, fmt, args...) {}
>  #define mtk_vcodec_debug_enter(h) {}
>  #define mtk_vcodec_debug_leave(h) {}
>
> --
> 2.13.2.725.g09c95d1e9-goog
>

[PATCH v3] [media] mtk-vcodec: Show mtk driver error without DEBUG definition

[Hirokazu Honda]

A driver error message is shown without DEBUG definition
to find an error and debug easily.

Signed-off-by: Hirokazu Honda 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
index 237e144c194f..c1378c1b402c 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
@@ -32,6 +32,15 @@ extern int mtk_v4l2_dbg_level;
 extern bool mtk_vcodec_dbg;
 
 
+#define mtk_v4l2_err(fmt, args...) \
+   pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
+  ##args)
+
+#define mtk_vcodec_err(h, fmt, args...)
\
+   pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
+  ((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
+
+
 #if defined(DEBUG)
 
 #define mtk_v4l2_debug(level, fmt, args...) \
@@ -41,11 +50,6 @@ extern bool mtk_vcodec_dbg;
level, __func__, __LINE__, ##args);  \
} while (0)
 
-#define mtk_v4l2_err(fmt, args...)\
-   pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
-  ##args)
-
-
 #define mtk_v4l2_debug_enter()  mtk_v4l2_debug(3, "+")
 #define mtk_v4l2_debug_leave()  mtk_v4l2_debug(3, "-")
 
@@ -57,22 +61,16 @@ extern bool mtk_vcodec_dbg;
__func__, ##args);  \
} while (0)
 
-#define mtk_vcodec_err(h, fmt, args...)
\
-   pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
-  ((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
-
 #define mtk_vcodec_debug_enter(h)  mtk_vcodec_debug(h, "+")
 #define mtk_vcodec_debug_leave(h)  mtk_vcodec_debug(h, "-")
 
 #else
 
 #define mtk_v4l2_debug(level, fmt, args...) {}
-#define mtk_v4l2_err(fmt, args...) {}
 #define mtk_v4l2_debug_enter() {}
 #define mtk_v4l2_debug_leave() {}
 
 #define mtk_vcodec_debug(h, fmt, args...) {}
-#define mtk_vcodec_err(h, fmt, args...) {}
 #define mtk_vcodec_debug_enter(h) {}
 #define mtk_vcodec_debug_leave(h) {}
 
-- 
2.13.2.725.g09c95d1e9-goog

[PATCH] drivers/staging/media/atomisp/i2c/gc2235: fix sparse warning: missing static

[Guillermo O. Freschi]

Several local use structs were missing declarations. Added static
qualifier to clean up Sparse warning.

Signed-off-by: Guillermo O. Freschi 
---
 drivers/staging/media/atomisp/i2c/gc2235.c | 2 +-
 drivers/staging/media/atomisp/i2c/gc2235.h | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/gc2235.c 
b/drivers/staging/media/atomisp/i2c/gc2235.c
index 50f431729b6c..04e69dd5fdb1 100644
--- a/drivers/staging/media/atomisp/i2c/gc2235.c
+++ b/drivers/staging/media/atomisp/i2c/gc2235.c
@@ -480,7 +480,7 @@ static const struct v4l2_ctrl_ops ctrl_ops = {
.g_volatile_ctrl = gc2235_g_volatile_ctrl
 };
 
-struct v4l2_ctrl_config gc2235_controls[] = {
+static struct v4l2_ctrl_config gc2235_controls[] = {
{
 .ops = _ops,
 .id = V4L2_CID_EXPOSURE_ABSOLUTE,
diff --git a/drivers/staging/media/atomisp/i2c/gc2235.h 
b/drivers/staging/media/atomisp/i2c/gc2235.h
index ccbc757045a5..ae8f09dbe5c7 100644
--- a/drivers/staging/media/atomisp/i2c/gc2235.h
+++ b/drivers/staging/media/atomisp/i2c/gc2235.h
@@ -530,7 +530,7 @@ static struct gc2235_reg const gc2235_1616_1216_30fps[] = {
{ GC2235_TOK_TERM, 0, 0 }
 };
 
-struct gc2235_resolution gc2235_res_preview[] = {
+static struct gc2235_resolution gc2235_res_preview[] = {
 
{
.desc = "gc2235_1600_900_30fps",
@@ -582,7 +582,7 @@ struct gc2235_resolution gc2235_res_preview[] = {
 };
 #define N_RES_PREVIEW (ARRAY_SIZE(gc2235_res_preview))
 
-struct gc2235_resolution gc2235_res_still[] = {
+static struct gc2235_resolution gc2235_res_still[] = {
{
.desc = "gc2235_1600_900_30fps",
.width = 1600,
@@ -632,7 +632,7 @@ struct gc2235_resolution gc2235_res_still[] = {
 };
 #define N_RES_STILL (ARRAY_SIZE(gc2235_res_still))
 
-struct gc2235_resolution gc2235_res_video[] = {
+static struct gc2235_resolution gc2235_res_video[] = {
{
.desc = "gc2235_1296_736_30fps",
.width = 1296,
-- 
2.11.0

Re: [PATCH RFC 1/2] media: V3s: Add support for Allwinner CSI.

[Maxime Ripard]

On Tue, Jul 04, 2017 at 03:25:45PM +0800, Yong wrote:
> On Mon, 3 Jul 2017 13:25:21 +0200
> Maxime Ripard  wrote:
> 
> > Hi,
> > 
> > On Mon, Jul 03, 2017 at 06:59:52PM +0800, Yong wrote:
> > > > > + select VIDEOBUF2_DMA_CONTIG
> > > > > + select REGMAP_MMIO
> > > > > + ---help---
> > > > > +Support for the Allwinner Camera Sensor Interface Controller.
> > > > 
> > > > This controller is the same for all Allwinner SoC models?
> > > 
> > > No.
> > > I will change the Kconfig and Makefile.
> > 
> > This is basically a design that has been introduced in the A31 (sun6i
> > family). I guess we should just call the driver and Kconfig symbols
> > sun6i_csi (even though we don't support it yet). It also used on the
> > A23, A33, A80, A83T, H3, and probably the H5 and A64.
> 
> Thanks for the advice. That's good.
> My purpose is to make the code reusable. People working on other
> Allwinner SoC could easily make their CSI working by just filling the
> SoC specific code. But I'm not familiar with other Allwinner SoCs 
> except V3s. I hope to get more advice.

Right, of course we don't expect you to do all that work, and we
should definitely focus on the V3s that you have for now. My comment
was only about the driver name and Kconfig option.

For the rest of the code, see the other comments :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

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?
> 
> I also pushed the rebased ccp2 branch there:
> 
> 
> 
> It's now right on the top of media-tree master.

Is ccp2 branch expected to go into 4.13, too?

Best regards,
Pavel

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

[PATCH] cec: clear all cec_log_addrs fields

[Hans Verkuil]

The CEC version, vendor ID and OSD name were not cleared when clearing the
current set of logical addresses. This was unexpected and somewhat confusing,
so reset all these fields to their default values. Also document this since
the documentation wasn't quite clear either.

Signed-off-by: Hans Verkuil 
--
diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst 
b/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst
index fcf863ab6f43..91cecc4d69cb 100644
--- a/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst
@@ -48,7 +48,9 @@ can only be called by a file descriptor in initiator mode 
(see :ref:`CEC_S_MODE`
 the ``EBUSY`` error code will be returned.

 To clear existing logical addresses set ``num_log_addrs`` to 0. All other 
fields
-will be ignored in that case. The adapter will go to the unconfigured state.
+will be ignored in that case. The adapter will go to the unconfigured state 
and the
+``cec_version``, ``vendor_id`` and ``osd_name`` fields are all reset to their 
default
+values (CEC version 2.0, no vendor ID and an empty OSD name).

 If the physical address is valid (see :ref:`ioctl CEC_ADAP_S_PHYS_ADDR 
`),
 then this ioctl will block until all requested logical
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index bf45977b2823..5a2363cbaeb1 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -1471,8 +1471,13 @@ int __cec_s_log_addrs(struct cec_adapter *adap,
return -ENODEV;

if (!log_addrs || log_addrs->num_log_addrs == 0) {
-   adap->log_addrs.num_log_addrs = 0;
cec_adap_unconfigure(adap);
+   adap->log_addrs.num_log_addrs = 0;
+   for (i = 0; i < CEC_MAX_LOG_ADDRS; i++)
+   adap->log_addrs.log_addr[i] = CEC_LOG_ADDR_INVALID;
+   adap->log_addrs.osd_name[0] = '\0';
+   adap->log_addrs.vendor_id = CEC_VENDOR_ID_NONE;
+   adap->log_addrs.cec_version = CEC_OP_CEC_VERSION_2_0;
return 0;
}

[PATCH v6 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).

Version 6 addresses review comments from Hans Verkuil regarding CEC, HDCP 1.4
and adds the s_dv_timings() callback, as well as the 
V4L2_CID_DV_RX_POWER_PRESENT
ctrl.

This series depends on the patch at [1].

This series was tested in a FPGA platform using an embedded platform called
ARC AXS101.

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 
Cc: Mark Rutland 
Cc: Sylwester Nawrocki 

[1] https://patchwork.linuxtv.org/patch/41834/

 .../devicetree/bindings/media/snps,dw-hdmi-rx.txt  |   70 +
 MAINTAINERS|7 +
 drivers/media/platform/Kconfig |2 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/dwc/Kconfig |   23 +
 drivers/media/platform/dwc/Makefile|2 +
 drivers/media/platform/dwc/dw-hdmi-phy-e405.c  |  844 +
 drivers/media/platform/dwc/dw-hdmi-phy-e405.h  |   63 +
 drivers/media/platform/dwc/dw-hdmi-rx.c| 1809 
 drivers/media/platform/dwc/dw-hdmi-rx.h|  441 +
 include/media/dwc/dw-hdmi-phy-pdata.h  |  128 ++
 include/media/dwc/dw-hdmi-rx-pdata.h   |   70 +
 12 files changed, 3461 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 v6 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 
Cc: Sylwester Nawrocki 

Changes from v4:
- Use usleep_range (Sylwester)
- Remove some comments (Sylwester)
- Parse phy version from of_device_id (Sylwester)
- Use "cfg" instead of "cfg-clk" (Sylwester, Rob)
- Change some messages to dev_dbg (Sylwester)
Changes from v3:
- Use v4l2 async API (Sylwester)
- Use clock API (Sylwester)
- Add compatible string (Sylwester)
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 | 844 ++
 drivers/media/platform/dwc/dw-hdmi-phy-e405.h |  63 ++
 include/media/dwc/dw-hdmi-phy-pdata.h | 128 
 7 files changed, 1048 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 1313cd5..47d4a50 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 9beadc7..e6a55fb 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -86,3 +86,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_MDP)  += mtk-mdp/
 obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
 
 obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
+
+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..26d70ca
--- /dev/null
+++ b/drivers/media/platform/dwc/dw-hdmi-phy-e405.c
@@ -0,0 +1,844 @@
+/*
+ * 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 

[PATCH v6 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: Carlos Palminha 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Mauro Carvalho Chehab 
Cc: Hans Verkuil 
Cc: Sylwester Nawrocki 
Cc: devicet...@vger.kernel.org

Changes from v4:
- Use "cfg" instead of "cfg-clk" (Rob)
- Change node names (Rob)
Changes from v3:
- Document the new DT bindings suggested by Sylwester
Changes from v2:
- Document edid-phandle property
---
 .../devicetree/bindings/media/snps,dw-hdmi-rx.txt  | 70 ++
 1 file changed, 70 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..449b8a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
@@ -0,0 +1,70 @@
+Synopsys DesignWare HDMI RX Decoder
+===
+
+This document defines device tree properties for the Synopsys DesignWare HDMI
+RX Decoder (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.
+
+- compatible: Shall be "snps,dw-hdmi-rx".
+
+- 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.
+
+- clocks: Phandle to the config clock block.
+
+- clock-names: Shall be "cfg".
+
+- edid-phandle: phandle to the EDID handler block.
+
+- #address-cells: Shall be 1.
+
+- #size-cells: Shall be 0.
+
+You also have to create a subnode for phy driver. Phy properties are as 
follows.
+
+- compatible: Shall be "snps,dw-hdmi-phy-e405".
+
+- reg: Shall be JTAG address of phy.
+
+- clocks: Phandle for cfg clock.
+
+- clock-names:Shall be "cfg".
+
+A sample binding is now provided. The compatible string is for a SoC which has
+has a Synopsys DesignWare HDMI RX decoder inside.
+
+Example:
+
+dw_hdmi_soc: dw-hdmi-soc@0 {
+   compatible = "snps,dw-hdmi-soc";
+   reg = <0x11c00 0x1000>; /* EDIDs */
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   hdmi-rx@0 {
+   compatible = "snps,dw-hdmi-rx";
+   reg = <0x0 0x1>;
+   interrupts = <1 2>;
+   edid-phandle = <_hdmi_soc>;
+
+   clocks = <_hdmi_refclk>;
+   clock-names = "cfg";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   hdmi-phy@fc {
+   compatible = "snps,dw-hdmi-phy-e405";
+   reg = <0xfc>;
+
+   clocks = <_hdmi_refclk>;
+   clock-names = "cfg";
+   };
+   };
+};
-- 
1.9.1

[PATCH v6 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 
Cc: Sylwester Nawrocki 

Changes from v5:
- Removed HDCP 1.4 support (Hans)
- Removed some CEC debug messages (Hans)
- Add s_dv_timings callback (Hans)
- Add V4L2_CID_DV_RX_POWER_PRESENT ctrl (Hans)
Changes from v4:
- Add flag V4L2_SUBDEV_FL_HAS_DEVNODE (Sylwester)
- Remove some comments and change some messages to dev_dbg (Sylwester)
- Use v4l2_async_subnotifier_register() (Sylwester)
Changes from v3:
- Use v4l2 async API (Sylwester)
- Do not block waiting for phy
- Do not use busy waiting delays (Sylwester)
- Simplify dw_hdmi_power_on (Sylwester)
- Use clock API (Sylwester)
- Use compatible string (Sylwester)
- Minor fixes (Sylwester)
Changes from v2:
- Address review comments from Hans regarding CEC
- Use CEC notifier
- Enable SCDC
Changes from v1:
- Add support for CEC
- Correct typo errors
- Correctly detect interlaced video modes
- Correct VIC parsing
Changes from RFC:
- Add support for HDCP 1.4
- Fixup HDMI_VIC not being parsed (Hans)
- Send source change signal when powering off (Hans)
- Add 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  |   15 +
 drivers/media/platform/dwc/Makefile |1 +
 drivers/media/platform/dwc/dw-hdmi-rx.c | 1809 +++
 drivers/media/platform/dwc/dw-hdmi-rx.h |  441 
 include/media/dwc/dw-hdmi-rx-pdata.h|   70 ++
 5 files changed, 2336 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..3ddccde 100644
--- a/drivers/media/platform/dwc/Kconfig
+++ b/drivers/media/platform/dwc/Kconfig
@@ -6,3 +6,18 @@ 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.
+
+config VIDEO_DWC_HDMI_RX_CEC
+   bool
+   depends on VIDEO_DWC_HDMI_RX
+   select CEC_CORE
+   select CEC_NOTIFIER
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..a7ae5a3
--- /dev/null
+++ b/drivers/media/platform/dwc/dw-hdmi-rx.c
@@ -0,0 +1,1809 @@
+/*
+ * 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 

[PATCH v6 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 
Cc: Carlos Palminha 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c4be6d4..7ebc6dd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11354,6 +11354,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

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

[Hans Verkuil]

On 07/04/17 15:50, Jose Abreu wrote:
> 
> 
> On 04-07-2017 14:02, Hans Verkuil wrote:
>> On 07/04/17 14:33, Jose Abreu wrote:
>>>
>>> On 04-07-2017 10:39, Hans Verkuil wrote:
> +static const struct v4l2_subdev_video_ops
> dw_hdmi_sd_video_ops = {
> +.s_routing = dw_hdmi_s_routing,
> +.g_input_status = dw_hdmi_g_input_status,
> +.g_parm = dw_hdmi_g_parm,
> +.g_dv_timings = dw_hdmi_g_dv_timings,
> +.query_dv_timings = dw_hdmi_query_dv_timings,
 No s_dv_timings???
>>> Hmm, yeah, I didn't implement it because the callchain and the
>>> player I use just use {get/set}_fmt. s_dv_timings can just
>>> populate the fields and replace them with the detected dv_timings
>>> ? Just like set_fmt does? Because the controller has no scaler.
>> No, s_dv_timings is the function that actually sets
>> dw_dev->timings.
>> After you check that it is valid of course (call
>> v4l2_valid_dv_timings).
>>
>> set_fmt calls get_fmt which returns the information from
>> dw_dev->timings.
>>
>> But it is s_dv_timings that has to set dw_dev->timings.
>>
>> With the current code you can only capture 640x480 (the default
>> timings).
>> Have you ever tested this with any other timings? I don't quite
>> understand
>> how you test.
> I use mpv to test with a wrapper driver that just calls the
> subdev ops and sets up a video dma.
>
> Ah, I see now. I failed to port the correct callbacks and in the
> upstream version I'm using I only tested with 640x480 ...
>
> But apart from that this is a capture device without scaling so I
> can not set timings, I can only return them so that applications
> know which format I'm receiving, right? So my s_dv_timings will
> return the same as query_dv_timings ...
 Well, to be precise: s_dv_timings just accepts what the application
 gives it (as long as it is within the dv_timings capabilities). But
 those timings come in practice from a query_dv_timings call from the
 application.

 The core rule is that receivers cannot randomly change timings since
 timings are related to buffer sizes. You do not want the application
 to allocate buffers for 640x480 and when the source changes to 1920x1080
 have those buffers suddenly overflow.

 Instead the app queries the timings, allocates the buffers, start
 streaming and when the timings change it will get an event so it can
 stop streaming, reallocate buffers, and start the process again.

 In other words, the application is in control here.

>>> ... But this is not true for mpv/mplayer. They first try to set a
>>> default format (by using s_fmt) and then query the format again
>>> (by using g_fmt) ... So dv_timings are never used. Are these apps
>>> broken? Im only using them because of performance, do you
>>> recommend others?
>> I don't believe those have ever been adapted to the DV_TIMINGS API. Only
>> SDTV (G/S/QUERYSTD). I believe gstreamer can handle this, though. But I
>> don't have any experience with gstreamer.
>>
>> qv4l2 works fine, though. If you can build that on your system, then that's
>> by far the easiest utility to use.
> 
> I will give it a try in my PCIe setup. But for my embedded setup
> (the one I'm using for testing this controller) it won't do. To
> handle this I modified my wrapper driver to "simulate" the
> dv_timings calls.
> 
>>
>> The reason why so few applications have been adapted to the DV_TIMINGS API
>> is that it is so hard to get hardware with working HDMI input. There are
>> PCIe cards, but since the datasheets for the used HDMI receivers are closed
>> we can't make a driver. And there are no cheap SoC devkits that have HDMI 
>> input.
>> Output, yes. Input, no.
>>
>> So there is no easy way to add support for this to applications.
>>
>> Regards,
>>
>>  Hans
> 
> Yeah, and even for SDTV the support is limited in mpv/mplayer :/
> I was told that v4l2 code in these apps is more or less unmaintained.

For the average PC user video capture is simply not all that interesting
or relevant anymore. Video capture moved to embedded systems (phones,
tablets, but of course also video conferencing equipment) and professional
video processing.

> BTW, do you have any pending comments for the other patches in
> this series? Because I've addressed all your comments regarding
> this patch and I'm ready to send a new version.

No, I didn't have any comments for the other patches.

Regards,

Hans

Re: [PATCH 2/2] rc-main: remove input events for repeat messages

[David Härdeman]

On Sat, Jul 01, 2017 at 01:20:50PM +0100, Sean Young wrote:
>On Thu, Jun 22, 2017 at 09:24:00PM +0200, David Härdeman wrote:
>> Protocols like NEC generate around 10 repeat events per second.
>> 
>> The input events are not very useful for userspace but still waste power
>> by waking up every listener. So let's remove them (MSC_SCAN events
>> are still generated for the initial keypress).
>> 
>> Signed-off-by: David Härdeman 
>> ---
>>  drivers/media/rc/rc-main.c |   13 -
>>  1 file changed, 4 insertions(+), 9 deletions(-)
>> 
>> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
>> index 7387bd4d75b0..9f490aa11bc4 100644
>> --- a/drivers/media/rc/rc-main.c
>> +++ b/drivers/media/rc/rc-main.c
>> @@ -616,16 +616,11 @@ void rc_repeat(struct rc_dev *dev)
>>  
>>  spin_lock_irqsave(>keylock, flags);
>>  
>> -if (!dev->keypressed)
>> -goto out;
>> -
>> -input_event(dev->input_dev, EV_MSC, MSC_SCAN, dev->last_scancode);
>> -input_sync(dev->input_dev);
>
>I don't agree with this. It's good to see something in user space when
>a repeat received. This is useful for debugging purposes.

Not going to press the issue, but dev_dbg might be another option if
debugging is the intended use-case?

-- 
David Härdeman

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

[Jose Abreu]

On 04-07-2017 14:02, Hans Verkuil wrote:
> On 07/04/17 14:33, Jose Abreu wrote:
>>
>> On 04-07-2017 10:39, Hans Verkuil wrote:
 +static const struct v4l2_subdev_video_ops
 dw_hdmi_sd_video_ops = {
 +.s_routing = dw_hdmi_s_routing,
 +.g_input_status = dw_hdmi_g_input_status,
 +.g_parm = dw_hdmi_g_parm,
 +.g_dv_timings = dw_hdmi_g_dv_timings,
 +.query_dv_timings = dw_hdmi_query_dv_timings,
>>> No s_dv_timings???
>> Hmm, yeah, I didn't implement it because the callchain and the
>> player I use just use {get/set}_fmt. s_dv_timings can just
>> populate the fields and replace them with the detected dv_timings
>> ? Just like set_fmt does? Because the controller has no scaler.
> No, s_dv_timings is the function that actually sets
> dw_dev->timings.
> After you check that it is valid of course (call
> v4l2_valid_dv_timings).
>
> set_fmt calls get_fmt which returns the information from
> dw_dev->timings.
>
> But it is s_dv_timings that has to set dw_dev->timings.
>
> With the current code you can only capture 640x480 (the default
> timings).
> Have you ever tested this with any other timings? I don't quite
> understand
> how you test.
 I use mpv to test with a wrapper driver that just calls the
 subdev ops and sets up a video dma.

 Ah, I see now. I failed to port the correct callbacks and in the
 upstream version I'm using I only tested with 640x480 ...

 But apart from that this is a capture device without scaling so I
 can not set timings, I can only return them so that applications
 know which format I'm receiving, right? So my s_dv_timings will
 return the same as query_dv_timings ...
>>> Well, to be precise: s_dv_timings just accepts what the application
>>> gives it (as long as it is within the dv_timings capabilities). But
>>> those timings come in practice from a query_dv_timings call from the
>>> application.
>>>
>>> The core rule is that receivers cannot randomly change timings since
>>> timings are related to buffer sizes. You do not want the application
>>> to allocate buffers for 640x480 and when the source changes to 1920x1080
>>> have those buffers suddenly overflow.
>>>
>>> Instead the app queries the timings, allocates the buffers, start
>>> streaming and when the timings change it will get an event so it can
>>> stop streaming, reallocate buffers, and start the process again.
>>>
>>> In other words, the application is in control here.
>>>
>> ... But this is not true for mpv/mplayer. They first try to set a
>> default format (by using s_fmt) and then query the format again
>> (by using g_fmt) ... So dv_timings are never used. Are these apps
>> broken? Im only using them because of performance, do you
>> recommend others?
> I don't believe those have ever been adapted to the DV_TIMINGS API. Only
> SDTV (G/S/QUERYSTD). I believe gstreamer can handle this, though. But I
> don't have any experience with gstreamer.
>
> qv4l2 works fine, though. If you can build that on your system, then that's
> by far the easiest utility to use.

I will give it a try in my PCIe setup. But for my embedded setup
(the one I'm using for testing this controller) it won't do. To
handle this I modified my wrapper driver to "simulate" the
dv_timings calls.

>
> The reason why so few applications have been adapted to the DV_TIMINGS API
> is that it is so hard to get hardware with working HDMI input. There are
> PCIe cards, but since the datasheets for the used HDMI receivers are closed
> we can't make a driver. And there are no cheap SoC devkits that have HDMI 
> input.
> Output, yes. Input, no.
>
> So there is no easy way to add support for this to applications.
>
> Regards,
>
>   Hans

Yeah, and even for SDTV the support is limited in mpv/mplayer :/
I was told that v4l2 code in these apps is more or less unmaintained.

BTW, do you have any pending comments for the other patches in
this series? Because I've addressed all your comments regarding
this patch and I'm ready to send a new version.

Best regards,
Jose Miguel Abreu

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

[Hans Verkuil]

On 07/04/17 14:33, Jose Abreu wrote:
> 
> 
> On 04-07-2017 10:39, Hans Verkuil wrote:
>>
>>> +static const struct v4l2_subdev_video_ops
>>> dw_hdmi_sd_video_ops = {
>>> +.s_routing = dw_hdmi_s_routing,
>>> +.g_input_status = dw_hdmi_g_input_status,
>>> +.g_parm = dw_hdmi_g_parm,
>>> +.g_dv_timings = dw_hdmi_g_dv_timings,
>>> +.query_dv_timings = dw_hdmi_query_dv_timings,
>> No s_dv_timings???
> Hmm, yeah, I didn't implement it because the callchain and the
> player I use just use {get/set}_fmt. s_dv_timings can just
> populate the fields and replace them with the detected dv_timings
> ? Just like set_fmt does? Because the controller has no scaler.
 No, s_dv_timings is the function that actually sets
 dw_dev->timings.
 After you check that it is valid of course (call
 v4l2_valid_dv_timings).

 set_fmt calls get_fmt which returns the information from
 dw_dev->timings.

 But it is s_dv_timings that has to set dw_dev->timings.

 With the current code you can only capture 640x480 (the default
 timings).
 Have you ever tested this with any other timings? I don't quite
 understand
 how you test.
>>> I use mpv to test with a wrapper driver that just calls the
>>> subdev ops and sets up a video dma.
>>>
>>> Ah, I see now. I failed to port the correct callbacks and in the
>>> upstream version I'm using I only tested with 640x480 ...
>>>
>>> But apart from that this is a capture device without scaling so I
>>> can not set timings, I can only return them so that applications
>>> know which format I'm receiving, right? So my s_dv_timings will
>>> return the same as query_dv_timings ...
>> Well, to be precise: s_dv_timings just accepts what the application
>> gives it (as long as it is within the dv_timings capabilities). But
>> those timings come in practice from a query_dv_timings call from the
>> application.
>>
>> The core rule is that receivers cannot randomly change timings since
>> timings are related to buffer sizes. You do not want the application
>> to allocate buffers for 640x480 and when the source changes to 1920x1080
>> have those buffers suddenly overflow.
>>
>> Instead the app queries the timings, allocates the buffers, start
>> streaming and when the timings change it will get an event so it can
>> stop streaming, reallocate buffers, and start the process again.
>>
>> In other words, the application is in control here.
>>
> 
> ... But this is not true for mpv/mplayer. They first try to set a
> default format (by using s_fmt) and then query the format again
> (by using g_fmt) ... So dv_timings are never used. Are these apps
> broken? Im only using them because of performance, do you
> recommend others?

I don't believe those have ever been adapted to the DV_TIMINGS API. Only
SDTV (G/S/QUERYSTD). I believe gstreamer can handle this, though. But I
don't have any experience with gstreamer.

qv4l2 works fine, though. If you can build that on your system, then that's
by far the easiest utility to use.

The reason why so few applications have been adapted to the DV_TIMINGS API
is that it is so hard to get hardware with working HDMI input. There are
PCIe cards, but since the datasheets for the used HDMI receivers are closed
we can't make a driver. And there are no cheap SoC devkits that have HDMI input.
Output, yes. Input, no.

So there is no easy way to add support for this to applications.

Regards,

Hans

Atualize sua conta de webmail

[Administração]

Sua caixa de correio excedeu o limite de armazenamento definido pela
administração e não pode enviar ou receber novas mensagens até você validar
seu webmail. o email



Clique no link a seguir para confirmar seu email



http://corriewebdd.tripod.com/





Obrigado

Administração do Webmail.





---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: [PATCH 4/4] [media] rc: pwm-ir-tx: add new driver

[Sean Young]

On Sun, Jul 02, 2017 at 12:06:13PM +0100, Sean Young wrote:
> This is new driver which uses pwm, so it is more power-efficient
> than the bit banging gpio-ir-tx driver.
> 
> Signed-off-by: Sean Young 
> ---
>  .../devicetree/bindings/leds/irled/pwm-ir-tx.txt   |  13 ++
>  drivers/media/rc/Kconfig   |  12 ++
>  drivers/media/rc/Makefile  |   1 +
>  drivers/media/rc/pwm-ir-tx.c   | 165 
> +
>  4 files changed, 191 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/leds/irled/pwm-ir-tx.txt
>  create mode 100644 drivers/media/rc/pwm-ir-tx.c
> 
> diff --git a/Documentation/devicetree/bindings/leds/irled/pwm-ir-tx.txt 
> b/Documentation/devicetree/bindings/leds/irled/pwm-ir-tx.txt
> new file mode 100644
> index 000..6887a71
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/irled/pwm-ir-tx.txt
> @@ -0,0 +1,13 @@
> +Device tree bindings for IR LED connected through pwm pin which is used as
> +IR transmitter.
> +
> +Required properties:
> +- compatible: should be "pwm-ir-tx".
> +- pwms : PWM property to point to the PWM device (phandle)/port (id) and to
> +  specify the period time to be used: < id period_ns>;
> +
> +Example:
> + irled {
> + compatible = "pwm-ir-tx";
> + pwms = < 0 1000>;
> + };
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index ad54011..c5338e3 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -399,6 +399,18 @@ config IR_GPIO_TX
>  To compile this driver as a module, choose M here: the module will
>  be called gpio-ir-tx.
>  
> +config IR_PWM_TX
> + tristate "PWM IR transmitter"
> + depends on RC_CORE
> + depends on LIRC
> + depends on PWM
> + ---help---
> +Say Y if you want to use a PWM based IR transmitter. This is
> +more power efficient than the bit banging gpio driver.
> +
> +To compile this driver as a module, choose M here: the module will
> +be called pwm-ir-tx.
> +
>  config RC_ST
>   tristate "ST remote control receiver"
>   depends on RC_CORE
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index 3e64a4e..466c402 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
>  obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
>  obj-$(CONFIG_IR_GPIO_CIR) += gpio-ir-recv.o
>  obj-$(CONFIG_IR_GPIO_TX) += gpio-ir-tx.o
> +obj-$(CONFIG_IR_PWM_TX) += pwm-ir-tx.o
>  obj-$(CONFIG_IR_IGORPLUGUSB) += igorplugusb.o
>  obj-$(CONFIG_IR_IGUANA) += iguanair.o
>  obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
> diff --git a/drivers/media/rc/pwm-ir-tx.c b/drivers/media/rc/pwm-ir-tx.c
> new file mode 100644
> index 000..1ab10b4
> --- /dev/null
> +++ b/drivers/media/rc/pwm-ir-tx.c
> @@ -0,0 +1,165 @@
> +/*
> + * Copyright (C) 2017 Sean Young 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2, 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 
> +#include 
> +
> +#define DRIVER_NAME  "pwm-ir-tx"
> +#define DEVICE_NAME  "PWM IR Transmitter"
> +
> +struct pwm_ir {
> + struct pwm_device *pwm;
> + unsigned int carrier;
> + unsigned int duty_cycle;
> + /* One transmission at a time */
> + struct mutex lock;
> +};
> +
> +static const struct of_device_id pwm_ir_of_match[] = {
> + { .compatible = "pwm-ir-tx", },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, pwm_ir_of_match);
> +
> +static int pwm_ir_set_duty_cycle(struct rc_dev *dev, u32 duty_cycle)
> +{
> + struct pwm_ir *pwm_ir = dev->priv;
> +
> + pwm_ir->duty_cycle = duty_cycle;
> +
> + return 0;
> +}
> +
> +static int pwm_ir_set_carrier(struct rc_dev *dev, u32 carrier)
> +{
> + struct pwm_ir *pwm_ir = dev->priv;
> +
> + if (!carrier)
> + return -EINVAL;
> +
> + pwm_ir->carrier = carrier;
> +
> + return 0;
> +}
> +
> +static int pwm_ir_tx(struct rc_dev *dev, unsigned int *txbuf,
> +  unsigned int count)
> +{
> + struct pwm_ir *pwm_ir = dev->priv;
> + struct pwm_device *pwm = pwm_ir->pwm;
> + int i, duty, period;
> + ktime_t edge;
> + s64 delta;
> +
> + if (mutex_lock_interruptible(_ir->lock))
> + return -ERESTARTSYS;
> +
> + period = DIV_ROUND_CLOSEST(NSEC_PER_SEC, pwm_ir->carrier);
> + duty = DIV_ROUND_CLOSEST(pwm_ir->duty_cycle * period, 100);
> +
> + pwm_config(pwm, duty, period);

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

[Jose Abreu]

On 04-07-2017 10:39, Hans Verkuil wrote:
>
>> +static const struct v4l2_subdev_video_ops
>> dw_hdmi_sd_video_ops = {
>> +.s_routing = dw_hdmi_s_routing,
>> +.g_input_status = dw_hdmi_g_input_status,
>> +.g_parm = dw_hdmi_g_parm,
>> +.g_dv_timings = dw_hdmi_g_dv_timings,
>> +.query_dv_timings = dw_hdmi_query_dv_timings,
> No s_dv_timings???
 Hmm, yeah, I didn't implement it because the callchain and the
 player I use just use {get/set}_fmt. s_dv_timings can just
 populate the fields and replace them with the detected dv_timings
 ? Just like set_fmt does? Because the controller has no scaler.
>>> No, s_dv_timings is the function that actually sets
>>> dw_dev->timings.
>>> After you check that it is valid of course (call
>>> v4l2_valid_dv_timings).
>>>
>>> set_fmt calls get_fmt which returns the information from
>>> dw_dev->timings.
>>>
>>> But it is s_dv_timings that has to set dw_dev->timings.
>>>
>>> With the current code you can only capture 640x480 (the default
>>> timings).
>>> Have you ever tested this with any other timings? I don't quite
>>> understand
>>> how you test.
>> I use mpv to test with a wrapper driver that just calls the
>> subdev ops and sets up a video dma.
>>
>> Ah, I see now. I failed to port the correct callbacks and in the
>> upstream version I'm using I only tested with 640x480 ...
>>
>> But apart from that this is a capture device without scaling so I
>> can not set timings, I can only return them so that applications
>> know which format I'm receiving, right? So my s_dv_timings will
>> return the same as query_dv_timings ...
> Well, to be precise: s_dv_timings just accepts what the application
> gives it (as long as it is within the dv_timings capabilities). But
> those timings come in practice from a query_dv_timings call from the
> application.
>
> The core rule is that receivers cannot randomly change timings since
> timings are related to buffer sizes. You do not want the application
> to allocate buffers for 640x480 and when the source changes to 1920x1080
> have those buffers suddenly overflow.
>
> Instead the app queries the timings, allocates the buffers, start
> streaming and when the timings change it will get an event so it can
> stop streaming, reallocate buffers, and start the process again.
>
> In other words, the application is in control here.
>

... But this is not true for mpv/mplayer. They first try to set a
default format (by using s_fmt) and then query the format again
(by using g_fmt) ... So dv_timings are never used. Are these apps
broken? Im only using them because of performance, do you
recommend others?

Best regards,
Jose Miguel Abreu

Re: [PATCH v1 0/4] media: rc: add support for IR receiver on MT7622 SoC

[Andi Shyti]

Hi Sean,

> This patchset introduces Consumer IR (CIR) support for MT7622 SoC
> implements raw mode for more compatibility with different protocols
> as previously SoC did. Before adding support to MT7622 SoC, extra
> code refactor is done since there're major differences in register and
> field definition from the previous SoC.
> 
> Sean Wang (4):
>   dt-bindings: media: mtk-cir: Add support for MT7622 SoC
>   media: rc: mtk-cir: add platform data to adapt into various hardware
>   media: rc: mtk-cir: add support for MediaTek MT7622 SoC
>   MAINTAINERS: add entry for MediaTek CIR driver

for the whole patchset:

Reviewed-by: Andi Shyti 

Andi

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

[Hans Verkuil]

On 07/04/17 11:28, Jose Abreu wrote:
> Hi Hans,
> 
> 
> On 03-07-2017 11:33, Hans Verkuil wrote:
>> On 07/03/2017 11:53 AM, Jose Abreu wrote:
>>> Hi Hans,
>>>
>>>
>>> On 03-07-2017 10:27, Hans Verkuil wrote:
 On 06/29/2017 12:46 PM, Jose Abreu wrote:
> 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 
> Cc: Sylwester Nawrocki 
>
> Changes from v4:
>  - Add flag V4L2_SUBDEV_FL_HAS_DEVNODE (Sylwester)
>  - Remove some comments and change some messages to dev_dbg
> (Sylwester)
>  - Use v4l2_async_subnotifier_register() (Sylwester)
> Changes from v3:
>  - Use v4l2 async API (Sylwester)
>  - Do not block waiting for phy
>  - Do not use busy waiting delays (Sylwester)
>  - Simplify dw_hdmi_power_on (Sylwester)
>  - Use clock API (Sylwester)
>  - Use compatible string (Sylwester)
>  - Minor fixes (Sylwester)
> Changes from v2:
>  - Address review comments from Hans regarding CEC
>  - Use CEC notifier
>  - Enable SCDC
> Changes from v1:
>  - Add support for CEC
>  - Correct typo errors
>  - Correctly detect interlaced video modes
>  - Correct VIC parsing
> Changes from RFC:
>  - Add support for HDCP 1.4
>  - Fixup HDMI_VIC not being parsed (Hans)
>  - Send source change signal when powering off (Hans)
>  - Add 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  |   15 +
>drivers/media/platform/dwc/Makefile |1 +
>drivers/media/platform/dwc/dw-hdmi-rx.c | 1824
> +++
>drivers/media/platform/dwc/dw-hdmi-rx.h |  441 
>include/media/dwc/dw-hdmi-rx-pdata.h|   97 ++
>5 files changed, 2378 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..3ddccde 100644
> --- a/drivers/media/platform/dwc/Kconfig
> +++ b/drivers/media/platform/dwc/Kconfig
> @@ -6,3 +6,18 @@ 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.
> +
> +config VIDEO_DWC_HDMI_RX_CEC
> +bool
> +depends on VIDEO_DWC_HDMI_RX
> +select CEC_CORE
> +select CEC_NOTIFIER
> diff --git a/drivers/media/platform/dwc/Makefile
> b/drivers/media/platform/dwc/Makefile
> index fc3b62c..cd04ca9 100644
> --- a/drivers/media/platform/dwc/Makefile
> +++ 

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

[Jose Abreu]

Hi Hans,


On 03-07-2017 11:33, Hans Verkuil wrote:
> On 07/03/2017 11:53 AM, Jose Abreu wrote:
>> Hi Hans,
>>
>>
>> On 03-07-2017 10:27, Hans Verkuil wrote:
>>> On 06/29/2017 12:46 PM, Jose Abreu wrote:
 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 
 Cc: Sylwester Nawrocki 

 Changes from v4:
  - Add flag V4L2_SUBDEV_FL_HAS_DEVNODE (Sylwester)
  - Remove some comments and change some messages to dev_dbg
 (Sylwester)
  - Use v4l2_async_subnotifier_register() (Sylwester)
 Changes from v3:
  - Use v4l2 async API (Sylwester)
  - Do not block waiting for phy
  - Do not use busy waiting delays (Sylwester)
  - Simplify dw_hdmi_power_on (Sylwester)
  - Use clock API (Sylwester)
  - Use compatible string (Sylwester)
  - Minor fixes (Sylwester)
 Changes from v2:
  - Address review comments from Hans regarding CEC
  - Use CEC notifier
  - Enable SCDC
 Changes from v1:
  - Add support for CEC
  - Correct typo errors
  - Correctly detect interlaced video modes
  - Correct VIC parsing
 Changes from RFC:
  - Add support for HDCP 1.4
  - Fixup HDMI_VIC not being parsed (Hans)
  - Send source change signal when powering off (Hans)
  - Add 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  |   15 +
drivers/media/platform/dwc/Makefile |1 +
drivers/media/platform/dwc/dw-hdmi-rx.c | 1824
 +++
drivers/media/platform/dwc/dw-hdmi-rx.h |  441 
include/media/dwc/dw-hdmi-rx-pdata.h|   97 ++
5 files changed, 2378 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..3ddccde 100644
 --- a/drivers/media/platform/dwc/Kconfig
 +++ b/drivers/media/platform/dwc/Kconfig
 @@ -6,3 +6,18 @@ 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.
 +
 +config VIDEO_DWC_HDMI_RX_CEC
 +bool
 +depends on VIDEO_DWC_HDMI_RX
 +select CEC_CORE
 +select CEC_NOTIFIER
 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 

Re: [PATCH v6 1/3] [media] v4l: add parsed MPEG-2 support

[Hugues FRUCHET]

Hi Randy,
Thanks for review, and sorry for late reply, answers inline.
BR,
Hugues.

On 06/11/2017 01:41 PM, ayaka wrote:
> 
> 
> On 04/28/2017 09:25 PM, Hugues Fruchet wrote:
>> Add "parsed MPEG-2" pixel format & related controls
>> needed by stateless video decoders.
>> In order to decode the video bitstream chunk provided
>> by user on output queue, stateless decoders require
>> also some extra data resulting from this video bitstream
>> chunk parsing.
>> Those parsed extra data have to be set by user through
>> control framework using the dedicated mpeg video extended
>> controls introduced in this patchset.
> 
> I have compared those v4l2 controls with the registers of the rockchip 
> video IP.
> 
> Most of them are met, but only lacks of sw_init_qp.

In case of MPEG-1/2, this register seems forced to 1, please double 
check the on2 headers parsing library related to MPEG2. Nevertheless, I 
see this hardware register used with VP8/H264.

Hence, no need to put this field on MPEG-2 interface, but should come 
with VP8/H264.

> 
> 
> Here is the full translation table of the registers of the rockchip 
> video IP.
> 
> q_scale_type   
> sw_qscale_type
> concealment_motion_vectorssw_con_mv_e
> intra_dc_precision  sw_intra_dc_prec
> intra_vlc_format 
> sw_intra_vlc_tab
> frame_pred_frame_dct  sw_frame_pred_dct
> 
> alternate_scan   
> sw_alt_scan_flag_e
> 
> f_code
> sw_fcode_bwd_ver
> 
> sw_fcode_bwd_hor
> 
> sw_fcode_fwd_ver
> 
> sw_fcode_fwd_hor
> full_pel_forward_vector  sw_mv_accuracy_fwd
> full_pel_backward_vector   sw_mv_accuracy_bwd
> 
> 
> I also saw you add two format for parsed MPEG-2/MPEG-1 format, I would 
> not recommand to do that.

We need to differentiate MPEG-1/MPEG-2, not all the fields are 
applicable depending on version.

> 
> That is what google does, because for a few video format and some 
> hardware, they just request a offsets from the original video byte stream.

I don't understand your comment, perhaps have you some as a basis of
discussion ?
Offset from the beginning of original video bitstream is supported 
within proposed interface, see v4l2_mpeg_video_mpeg2_pic_hd->offset field.

> 
>> Signed-off-by: Hugues Fruchet
>> ---
>>   Documentation/media/uapi/v4l/extended-controls.rst | 363 
>> +
>>   Documentation/media/uapi/v4l/pixfmt-013.rst|  10 +
>>   Documentation/media/uapi/v4l/vidioc-queryctrl.rst  |  38 ++-
>>   Documentation/media/videodev2.h.rst.exceptions |   6 +
>>   drivers/media/v4l2-core/v4l2-ctrls.c   |  53 +++
>>   drivers/media/v4l2-core/v4l2-ioctl.c   |   2 +
>>   include/uapi/linux/v4l2-controls.h |  94 ++
>>   include/uapi/linux/videodev2.h |   8 +
>>   8 files changed, 572 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
>> b/Documentation/media/uapi/v4l/extended-controls.rst
>> index abb1057..b48eac9 100644
>> --- a/Documentation/media/uapi/v4l/extended-controls.rst
>> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
>> @@ -1827,6 +1827,369 @@ enum v4l2_mpeg_cx2341x_video_median_filter_type -
>>   not insert, 1 = insert packets.
>>   
>>   
>> +MPEG-2 Parsed Control Reference
>> +-
>> +
>> +The MPEG-2 parsed decoding controls are needed by stateless video decoders.
>> +Those decoders expose :ref:`Compressed formats ` 
>> :ref:`V4L2_PIX_FMT_MPEG1_PARSED` or 
>> :ref:`V4L2_PIX_FMT_MPEG2_PARSED`.
>> +In order to decode the video bitstream chunk provided by user on output 
>> queue,
>> +stateless decoders require also some extra data resulting from this video
>> +bitstream chunk parsing. Those parsed extra data have to be set by user
>> +through control framework using the mpeg video extended controls defined
>> +in this section. Those controls have been defined based on MPEG-2 standard
>> +ISO/IEC 13818-2, and so derive directly from the MPEG-2 video bitstream 
>> syntax
>> +including how it is coded inside bitstream (enumeration values for ex.).
>> +
>> +MPEG-2 Parsed Control IDs
>> +^^^
>> +
>> +.. _mpeg2-parsed-control-id:
>> +
>> +.. c:type:: V4L2_CID_MPEG_VIDEO_MPEG2_SEQ_HDR
>> +(enum)
>> +
>> +.. tabularcolumns:: |p{4.0cm}|p{2.5cm}|p{11.0cm}|
>> +
>> +.. c:type:: v4l2_mpeg_video_mpeg2_seq_hdr
>> +
>> +.. cssclass:: longtable
>> +
>> +.. flat-table:: struct 

Re: [PATCH RFC 1/2] media: V3s: Add support for Allwinner CSI.

[Yong]

On Mon, 3 Jul 2017 13:25:21 +0200
Maxime Ripard  wrote:

> Hi,
> 
> On Mon, Jul 03, 2017 at 06:59:52PM +0800, Yong wrote:
> > > > +   select VIDEOBUF2_DMA_CONTIG
> > > > +   select REGMAP_MMIO
> > > > +   ---help---
> > > > +  Support for the Allwinner Camera Sensor Interface Controller.
> > > 
> > > This controller is the same for all Allwinner SoC models?
> > 
> > No.
> > I will change the Kconfig and Makefile.
> 
> This is basically a design that has been introduced in the A31 (sun6i
> family). I guess we should just call the driver and Kconfig symbols
> sun6i_csi (even though we don't support it yet). It also used on the
> A23, A33, A80, A83T, H3, and probably the H5 and A64.
> 
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Thanks for the advice. That's good.
My purpose is to make the code reusable. People working on other
Allwinner SoC could easily make their CSI working by just filling the
SoC specific code. But I'm not familiar with other Allwinner SoCs 
except V3s. I hope to get more advice.

Re: [PATCH 01/12] [media] vb2: add explicit fence user API

[Alexandre Courbot]

On Tue, Jul 4, 2017 at 2:57 PM, Tomasz Figa  wrote:
> Hi Gustavo,
>
> On Tue, Jun 27, 2017 at 12:39 AM, Gustavo Padovan  wrote:
>> 2017-06-18 kbuild test robot :
>>
>>> Hi Gustavo,
>>>
>>> [auto build test ERROR on linuxtv-media/master]
>>> [also build test ERROR on v4.12-rc5 next-20170616]
>>> [if your patch is applied to the wrong git tree, please drop us a note to 
>>> help improve the system]
>>>
>>> url:
>>> https://github.com/0day-ci/linux/commits/Gustavo-Padovan/vb2-add-explicit-fence-user-API/20170618-210740
>>> base:   git://linuxtv.org/media_tree.git master
>>> config: x86_64-allmodconfig (attached as .config)
>>> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
>>> reproduce:
>>> # save the attached .config to linux build tree
>>> make ARCH=x86_64
>>>
>>> All error/warnings (new ones prefixed by >>):
>>>
>>>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c: In function 
>>> 'atomisp_qbuf':
>>> >> drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:1297:10: 
>>> >> error: 'struct v4l2_buffer' has no member named 'reserved2'; did you 
>>> >> mean 'reserved'?
>>>  (buf->reserved2 & ATOMISP_BUFFER_HAS_PER_FRAME_SETTING)) {
>>>  ^~
>>>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:1299:50: 
>>> error: 'struct v4l2_buffer' has no member named 'reserved2'; did you mean 
>>> 'reserved'?
>>>   pipe->frame_request_config_id[buf->index] = buf->reserved2 &
>>>  ^~
>>>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c: In function 
>>> 'atomisp_dqbuf':
>>>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:1483:5: 
>>> error: 'struct v4l2_buffer' has no member named 'reserved2'; did you mean 
>>> 'reserved'?
>>>  buf->reserved2 = pipe->frame_config_id[buf->index];
>>> ^~
>>>In file included from include/linux/printk.h:329:0,
>>> from include/linux/kernel.h:13,
>>> from include/linux/delay.h:21,
>>> from 
>>> drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:24:
>>>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:1488:6: 
>>> error: 'struct v4l2_buffer' has no member named 'reserved2'; did you mean 
>>> 'reserved'?
>>>   buf->reserved2);
>>>  ^
>>
>> Ouch! Seems the reserved2 was burned down by 2 drivers accessing it
>> without any care for the uAPI. I'll change my patches to use the
>> 'reserved' field instead.
>
> Given that a reserved field has a clear meaning of being reserved and
> the driver in question is in staging. I'd rather vote for fixing the
> driver.

Same here. It seems like this use of reserved2 should not have been
merged in the first place, thankfully it's only in staging.