cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Fri Aug 11 05:00:17 CEST 2017
media-tree git hash:ec0c3ec497cabbf3bfa03a9eb5edcc252190a4e0
media_build git hash:   3a2afb881d1efadba33831f9c56321c4bcbe7178
v4l-utils git hash: 7a172d76b5eb606d06f396dc4bce9b71c0b78c03
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.11.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-blackfin-bf561: OK
linux-git-i686: WARNINGS
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: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.4.22-i686: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: WARNINGS
linux-4.9.26-i686: WARNINGS
linux-4.10.14-i686: WARNINGS
linux-4.11-i686: WARNINGS
linux-4.12.1-i686: WARNINGS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.22-x86_64: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.5-x86_64: 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.1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

[PATCH 2/3] media: v4l2-ctrls: prepare the function to be used by compat32 code

[Mauro Carvalho Chehab]

Right now, both v4l2_ctrl_fill() and compat32 code need to know
the type of the control. As new controls are added, this cause
troubles at compat32, as it won't be able to discover what
functions are pointers or not.

Change v4l2_ctrl_fill() function for it to be called with just
one argument: the control type. This way, the compat32 code can
use it internally.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-ctrls.c | 31 +--
 include/media/v4l2-ctrls.h   |  2 ++
 2 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index dd1db678718c..c512b7539077 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -939,8 +939,10 @@ EXPORT_SYMBOL(v4l2_ctrl_get_name);
 void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
s64 *min, s64 *max, u64 *step, s64 *def, u32 *flags)
 {
-   *name = v4l2_ctrl_get_name(id);
-   *flags = 0;
+   if (name) {
+   *name = v4l2_ctrl_get_name(id);
+   *flags = 0;
+   }
 
switch (id) {
case V4L2_CID_AUDIO_MUTE:
@@ -996,11 +998,15 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_RDS_RX_TRAFFIC_PROGRAM:
case V4L2_CID_RDS_RX_MUSIC_SPEECH:
*type = V4L2_CTRL_TYPE_BOOLEAN;
+   if (!name)
+   break;
*min = 0;
*max = *step = 1;
break;
case V4L2_CID_ROTATE:
*type = V4L2_CTRL_TYPE_INTEGER;
+   if (!name)
+   break;
*flags |= V4L2_CTRL_FLAG_MODIFY_LAYOUT;
break;
case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE:
@@ -1015,6 +1021,8 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_AUTO_FOCUS_START:
case V4L2_CID_AUTO_FOCUS_STOP:
*type = V4L2_CTRL_TYPE_BUTTON;
+   if (!name)
+   break;
*flags |= V4L2_CTRL_FLAG_WRITE_ONLY |
  V4L2_CTRL_FLAG_EXECUTE_ON_WRITE;
*min = *max = *step = *def = 0;
@@ -1099,12 +1107,16 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_RF_TUNER_CLASS:
case V4L2_CID_DETECT_CLASS:
*type = V4L2_CTRL_TYPE_CTRL_CLASS;
+   if (!name)
+   break;
/* You can neither read not write these */
*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
*min = *max = *step = *def = 0;
break;
case V4L2_CID_BG_COLOR:
*type = V4L2_CTRL_TYPE_INTEGER;
+   if (!name)
+   break;
*step = 1;
*min = 0;
/* Max is calculated as RGB888 that is 2^24 */
@@ -1123,10 +1135,14 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE:
case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT:
*type = V4L2_CTRL_TYPE_INTEGER;
+   if (!name)
+   break;
*flags |= V4L2_CTRL_FLAG_READ_ONLY;
break;
case V4L2_CID_MPEG_VIDEO_DEC_PTS:
*type = V4L2_CTRL_TYPE_INTEGER64;
+   if (!name)
+   break;
*flags |= V4L2_CTRL_FLAG_VOLATILE | V4L2_CTRL_FLAG_READ_ONLY;
*min = *def = 0;
*max = 0x1LL;
@@ -1134,6 +1150,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
break;
case V4L2_CID_MPEG_VIDEO_DEC_FRAME:
*type = V4L2_CTRL_TYPE_INTEGER64;
+   if (!name)
+   break;
+
*flags |= V4L2_CTRL_FLAG_VOLATILE | V4L2_CTRL_FLAG_READ_ONLY;
*min = *def = 0;
*max = 0x7fffLL;
@@ -1141,6 +1160,8 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
break;
case V4L2_CID_PIXEL_RATE:
*type = V4L2_CTRL_TYPE_INTEGER64;
+   if (!name)
+   break;
*flags |= V4L2_CTRL_FLAG_READ_ONLY;
break;
case V4L2_CID_DETECT_MD_REGION_GRID:
@@ -1156,6 +1177,12 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
*type = V4L2_CTRL_TYPE_INTEGER;
break;
}
+
+   if (!name)
+   return;
+
+   /* Update flags for some controls */
+
switch (id) {
case V4L2_CID_MPEG_AUDIO_ENCODING:
case V4L2_CID_MPEG_AUDIO_MODE:
diff --git a/include/media/v4l2-ctrls.h 

Re: [PATCH] v4l2-compat-ioctl32.c: add capabilities field to, v4l2_input32

[Mauro Carvalho Chehab]

Em Fri, 4 Aug 2017 13:25:06 +0200
Hans Verkuil  escreveu:

> The v4l2_input32 struct wasn't updated when this field was added.
> It didn't cause a failure in the compat code, but it is better to
> keep it in sync with v4l2_input to avoid confusion.
> 
> Signed-off-by: Hans Verkuil 

Looks good to me.

Reviewed-by: Mauro Carvalho Chehab 

> ---
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> index 6f52970f8b54..90827073066f 100644
> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> @@ -627,7 +627,8 @@ struct v4l2_input32 {
>   __u32tuner; /*  Associated tuner */
>   compat_u64   std;
>   __u32status;
> - __u32reserved[4];
> + __u32capabilities;
> + __u32reserved[3];
>  };
> 
>  /* The 64-bit v4l2_input struct has extra padding at the end of the struct.



Thanks,
Mauro

[PATCH RESEND 0/3] v4l2-compat-ioctl32.c: better detect pointer controls

[Mauro Carvalho Chehab]

In the past, only string controls were pointers. That changed when compounded
types got added, but the compat32 code was not updated.

We could just add those controls there, but maintaining it is flaw, as we
often forget about the compat code. So, instead, rely on the control type,
as this is always updated when new controls are added.

As both v4l2-ctrl and compat32 code are at videodev.ko module, we can
move the ctrl_is_pointer() helper function to v4l2-ctrl.c.

---

Re-sending this patch series, as it was c/c to the linux-doc ML by mistake.

Mauro Carvalho Chehab (3):
  media: v4l2-ctrls.h: better document the arguments for v4l2_ctrl_fill
  media: v4l2-ctrls: prepare the function to be used by compat32 code
  media: compat32: reimplement ctrl_is_pointer()

 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 18 +-
 drivers/media/v4l2-core/v4l2-ctrls.c  | 49 +--
 include/media/v4l2-ctrls.h| 28 ++-
 3 files changed, 67 insertions(+), 28 deletions(-)

-- 
2.13.3

[PATCH 1/3] media: v4l2-ctrls.h: better document the arguments for v4l2_ctrl_fill

[Mauro Carvalho Chehab]

The arguments for this function are pointers. Make it clear at
its documentation.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-ctrls.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 2d2aed56922f..6ba30acf06aa 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -339,18 +339,18 @@ struct v4l2_ctrl_config {
 /**
  * v4l2_ctrl_fill - Fill in the control fields based on the control ID.
  *
- * @id: ID of the control
- * @name: name of the control
- * @type: type of the control
- * @min: minimum value for the control
- * @max: maximum value for the control
- * @step: control step
- * @def: default value for the control
- * @flags: flags to be used on the control
+ * @id: pointer for storing the ID of the control
+ * @name: pointer for storing the name of the control
+ * @type: pointer for storing the type of the control
+ * @min: pointer for storing the minimum value for the control
+ * @max: pointer for storing the maximum value for the control
+ * @step: pointer for storing the control step
+ * @def: pointer for storing the default value for the control
+ * @flags: pointer for storing the flags to be used on the control
  *
  * This works for all standard V4L2 controls.
  * For non-standard controls it will only fill in the given arguments
- * and @name will be %NULL.
+ * and @name content will be filled with %NULL.
  *
  * This function will overwrite the contents of @name, @type and @flags.
  * The contents of @min, @max, @step and @def may be modified depending on
-- 
2.13.3

[PATCH 3/3] media: compat32: reimplement ctrl_is_pointer()

[Mauro Carvalho Chehab]

The current way that this function works is subject to problems
as new controls gets added. Move it to v4l2-ctrls and use the
knowledge that v4l2_ctrl_fill() has about controls, in order to
detect if a given control is a pointer.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 18 +-
 drivers/media/v4l2-core/v4l2-ctrls.c  | 18 ++
 include/media/v4l2-ctrls.h|  8 
 3 files changed, 27 insertions(+), 17 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index af8b4c5b0efa..0adcc37280c8 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static long native_ioctl(struct file *file, unsigned int cmd, unsigned long 
arg)
 {
@@ -668,23 +669,6 @@ struct v4l2_ext_control32 {
};
 } __attribute__ ((packed));
 
-/* The following function really belong in v4l2-common, but that causes
-   a circular dependency between modules. We need to think about this, but
-   for now this will do. */
-
-/* Return non-zero if this control is a pointer type. Currently only
-   type STRING is a pointer type. */
-static inline int ctrl_is_pointer(u32 id)
-{
-   switch (id) {
-   case V4L2_CID_RDS_TX_PS_NAME:
-   case V4L2_CID_RDS_TX_RADIO_TEXT:
-   return 1;
-   default:
-   return 0;
-   }
-}
-
 static int get_v4l2_ext_controls32(struct v4l2_ext_controls *kp, struct 
v4l2_ext_controls32 __user *up)
 {
struct v4l2_ext_control32 __user *ucontrols;
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index c512b7539077..0d5dab485723 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1254,6 +1254,24 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
 }
 EXPORT_SYMBOL(v4l2_ctrl_fill);
 
+bool ctrl_is_pointer(u32 id)
+{
+   enum v4l2_ctrl_type type;
+
+   v4l2_ctrl_fill(id, NULL, , NULL, NULL, NULL, NULL, NULL);
+
+   switch (type) {
+   case V4L2_CTRL_TYPE_STRING:
+   case V4L2_CTRL_TYPE_U8:
+   case V4L2_CTRL_TYPE_U16:
+   case V4L2_CTRL_TYPE_U32:
+   return true;
+   default:
+   return false;
+   }
+}
+EXPORT_SYMBOL(ctrl_is_pointer);
+
 static void fill_event(struct v4l2_event *ev, struct v4l2_ctrl *ctrl, u32 
changes)
 {
memset(ev->reserved, 0, sizeof(ev->reserved));
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index e22dea218a4c..bc6772f50956 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -367,6 +367,14 @@ struct v4l2_ctrl_config {
 void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
s64 *min, s64 *max, u64 *step, s64 *def, u32 *flags);
 
+/**
+ * ctrl_is_pointer - Returns non-zero if this control is a pointer type.
+ *
+ * @id: ID of the control
+ *
+ * Currently only STRING and compound types are pointers.
+ */
+bool ctrl_is_pointer(u32 id);
 
 /**
  * v4l2_ctrl_handler_init_class() - Initialize the control handler.
-- 
2.13.3

[PATCH 2/5] [media] cx25840: describe standard for 0b1100 value in AFD_FMT_STAT bits

[Maciej S. Szmigiero]

A 0b1100 value in 4 LSBs of "General Status 1" register (AFD_FMT_STAT) has
known meaning for CX2584x-series chips - it means that a SECAM signal is
currently detected by the chip.

Use this opportunity to also fix wrong binary values that were present
as comments attached to some entries in an array where
chip register -> V4L2 standard mappings are stored.

Signed-off-by: Maciej S. Szmigiero 
---
 drivers/media/i2c/cx25840/cx25840-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/cx25840/cx25840-core.c 
b/drivers/media/i2c/cx25840/cx25840-core.c
index 078b94ae55ac..2fa74c23d619 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.c
+++ b/drivers/media/i2c/cx25840/cx25840-core.c
@@ -2166,9 +2166,9 @@ static int cx25840_g_std(struct v4l2_subdev *sd, 
v4l2_std_id *std)
 
/* 1001 */ V4L2_STD_UNKNOWN,
/* 1010 */ V4L2_STD_UNKNOWN,
-   /* 1001 */ V4L2_STD_UNKNOWN,
-   /* 1010 */ V4L2_STD_UNKNOWN,
/* 1011 */ V4L2_STD_UNKNOWN,
+   /* 1100 */ V4L2_STD_SECAM,
+   /* 1101 */ V4L2_STD_UNKNOWN,
/* 1110 */ V4L2_STD_UNKNOWN,
/*  */ V4L2_STD_UNKNOWN
};

[PATCH 0/5] [media] Add analog mode support for Medion MD95700

[Maciej S. Szmigiero]

This series adds support for analog part of Medion 95700 in the cxusb
driver.

What works:
* Video capture at various sizes with sequential fields,
* Input switching (TV Tuner, Composite, S-Video),
* TV and radio tuning,
* Video standard switching and auto detection,
* Radio mode switching (stereo / mono),
* Unplugging while capturing,
* DVB / analog coexistence,
* Raw BT.656 stream support.

What does not work yet:
* Audio,
* VBI,
* Picture controls.

This series (as an one patch) was submitted for inclusion few years ago,
then waited few months in a patch queue.
Unfortunately, by the time it was supposed to be merged there
were enough changes in media that it was no longer mergable.

I thought at that time that I will be able to rebase and retest it soon
but unfortunately up till now I was never able to find enough time to do
so.
Also, with the passing of time the implementation diverged more and
more from the current kernel code, necessitating even more reworking.

The previous iteration can be found here:
https://patchwork.linuxtv.org/patch/8048/

Since that version there had been the following changes:
* Adaptation to changes in V4L2 / DVB core,

* Radio device was added, with a possibility to tune to a FM radio
station and switch between stereo and mono modes (tested by taping
audio signal directly at tuner output pin),

* DVB / analog coexistence was improved - resolved a few cases where
DVB core would switch off power or reset the tuner when the device
was still being used but in the analog mode,

* Fixed issues reported by v4l2-compliance,

* Switching to raw BT.656 mode is now done by a custom streaming
parameter set via VIDIOC_S_PARM ioctl instead of using a
V4L2_BUF_TYPE_PRIVATE buffer (which was removed from V4L2),

* General small code cleanups (like using BIT() or ARRAY_SIZE() macros
instead of open coding them, code formatting improvements, etc.).

 drivers/media/i2c/cx25840/cx25840-core.c |  422 ++-
 drivers/media/i2c/cx25840/cx25840-core.h |   11 +
 drivers/media/i2c/cx25840/cx25840-vbi.c  |3 +
 drivers/media/pci/ivtv/ivtv-i2c.c|1 +
 drivers/media/tuners/tuner-simple.c  |5 +-
 drivers/media/usb/dvb-usb/Kconfig|8 +-
 drivers/media/usb/dvb-usb/Makefile   |2 +-
 drivers/media/usb/dvb-usb/cxusb-analog.c | 1867 ++
 drivers/media/usb/dvb-usb/cxusb.c|  453 +++-
 drivers/media/usb/dvb-usb/cxusb.h|  137 +++
 drivers/media/usb/dvb-usb/dvb-usb-dvb.c  |   20 +-
 drivers/media/usb/dvb-usb/dvb-usb-init.c |   13 +
 drivers/media/usb/dvb-usb/dvb-usb.h  |8 +
 include/media/drv-intf/cx25840.h |   74 +-
 14 files changed, 2957 insertions(+), 67 deletions(-)
 create mode 100644 drivers/media/usb/dvb-usb/cxusb-analog.c

[PATCH 5/5] [media] cxusb: add analog mode support for Medion MD95700

[Maciej S. Szmigiero]

This patch adds support for analog part of Medion 95700 in the cxusb
driver.

What works:
* Video capture at various sizes with sequential fields,
* Input switching (TV Tuner, Composite, S-Video),
* TV and radio tuning,
* Video standard switching and auto detection,
* Radio mode switching (stereo / mono),
* Unplugging while capturing,
* DVB / analog coexistence,
* Raw BT.656 stream support.

What does not work yet:
* Audio,
* VBI,
* Picture controls.

Signed-off-by: Maciej S. Szmigiero 
---
 drivers/media/usb/dvb-usb/Kconfig|8 +-
 drivers/media/usb/dvb-usb/Makefile   |2 +-
 drivers/media/usb/dvb-usb/cxusb-analog.c | 1867 ++
 drivers/media/usb/dvb-usb/cxusb.c|  453 +++-
 drivers/media/usb/dvb-usb/cxusb.h|  137 +++
 drivers/media/usb/dvb-usb/dvb-usb-dvb.c  |   20 +-
 drivers/media/usb/dvb-usb/dvb-usb-init.c |   13 +
 drivers/media/usb/dvb-usb/dvb-usb.h  |8 +
 8 files changed, 2449 insertions(+), 59 deletions(-)
 create mode 100644 drivers/media/usb/dvb-usb/cxusb-analog.c

diff --git a/drivers/media/usb/dvb-usb/Kconfig 
b/drivers/media/usb/dvb-usb/Kconfig
index 959fa09dfd92..ba941069ae3b 100644
--- a/drivers/media/usb/dvb-usb/Kconfig
+++ b/drivers/media/usb/dvb-usb/Kconfig
@@ -118,7 +118,9 @@ config DVB_USB_UMT_010
 
 config DVB_USB_CXUSB
tristate "Conexant USB2.0 hybrid reference design support"
-   depends on DVB_USB
+   depends on DVB_USB && VIDEO_V4L2
+   select VIDEO_CX25840
+   select VIDEOBUF2_VMALLOC
select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
select DVB_CX22702 if MEDIA_SUBDRV_AUTOSELECT
select DVB_LGDT330X if MEDIA_SUBDRV_AUTOSELECT
@@ -136,8 +138,8 @@ config DVB_USB_CXUSB
select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT
help
  Say Y here to support the Conexant USB2.0 hybrid reference design.
- Currently, only DVB and ATSC modes are supported, analog mode
- shall be added in the future. Devices that require this module:
+ DVB and ATSC modes are supported, with basic analog mode support
+ for Medion MD95700. Devices that require this module:
 
  Medion MD95700 hybrid USB2.0 device.
  DViCO FusionHDTV (Bluebird) USB2.0 devices
diff --git a/drivers/media/usb/dvb-usb/Makefile 
b/drivers/media/usb/dvb-usb/Makefile
index 3b3f32b426d1..24d222e9acc7 100644
--- a/drivers/media/usb/dvb-usb/Makefile
+++ b/drivers/media/usb/dvb-usb/Makefile
@@ -40,7 +40,7 @@ obj-$(CONFIG_DVB_USB_M920X) += dvb-usb-m920x.o
 dvb-usb-digitv-objs := digitv.o
 obj-$(CONFIG_DVB_USB_DIGITV) += dvb-usb-digitv.o
 
-dvb-usb-cxusb-objs := cxusb.o
+dvb-usb-cxusb-objs := cxusb.o cxusb-analog.o
 obj-$(CONFIG_DVB_USB_CXUSB) += dvb-usb-cxusb.o
 
 dvb-usb-ttusb2-objs := ttusb2.o
diff --git a/drivers/media/usb/dvb-usb/cxusb-analog.c 
b/drivers/media/usb/dvb-usb/cxusb-analog.c
new file mode 100644
index ..473d3f06145f
--- /dev/null
+++ b/drivers/media/usb/dvb-usb/cxusb-analog.c
@@ -0,0 +1,1867 @@
+/* DVB USB compliant linux driver for Conexant USB reference design -
+ * (analog part).
+ *
+ * Copyright (C) 2011, 2017 Maciej S. Szmigiero (m...@maciej.szmigiero.name)
+ *
+ * TODO:
+ *  * audio support,
+ *  * finish radio support (requires audio of course),
+ *  * VBI support,
+ *  * controls support
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cxusb.h"
+
+static int cxusb_medion_v_queue_setup(struct vb2_queue *q,
+ unsigned int *num_buffers,
+ unsigned int *num_planes,
+ unsigned int sizes[],
+ struct device *alloc_devs[])
+{
+   struct dvb_usb_device *dvbdev = vb2_get_drv_priv(q);
+   struct cxusb_medion_dev *cxdev = dvbdev->priv;
+   unsigned int size = cxdev->raw_mode ?
+   CXUSB_VIDEO_MAX_FRAME_SIZE :
+   cxdev->width * cxdev->height * 2;
+
+   if (*num_planes > 0) {
+   if (*num_planes != 1)
+   return -EINVAL;
+
+   if (sizes[0] < size)
+   return -EINVAL;
+   } else {
+   *num_planes = 1;
+   sizes[0] = size;
+   }
+
+   if (q->num_buffers + *num_buffers < 6)
+   *num_buffers = 6 - q->num_buffers;
+
+   return 0;
+}
+
+static int cxusb_medion_v_buf_init(struct vb2_buffer *vb)
+{
+   struct dvb_usb_device *dvbdev = vb2_get_drv_priv(vb->vb2_queue);
+   struct cxusb_medion_dev *cxdev = dvbdev->priv;
+
+   cxusb_vprintk(dvbdev, OPS, 

[PATCH 1/5] [media] cx25840: add pin to pad mapping and output format configuration

[Maciej S. Szmigiero]

This commit adds pin to pad mapping and output format configuration support
in CX2584x-series chips to cx25840 driver.

This functionality is then used to allow disabling ivtv-specific hacks
(called a "generic mode"), so cx25840 driver can be used for other devices
not needing them without risking compatibility problems.

Signed-off-by: Maciej S. Szmigiero 
---
 drivers/media/i2c/cx25840/cx25840-core.c | 413 ++-
 drivers/media/i2c/cx25840/cx25840-core.h |  11 +
 drivers/media/i2c/cx25840/cx25840-vbi.c  |   3 +
 drivers/media/pci/ivtv/ivtv-i2c.c|   1 +
 include/media/drv-intf/cx25840.h |  74 +-
 5 files changed, 500 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/cx25840/cx25840-core.c 
b/drivers/media/i2c/cx25840/cx25840-core.c
index 39f51daa7558..078b94ae55ac 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.c
+++ b/drivers/media/i2c/cx25840/cx25840-core.c
@@ -21,6 +21,9 @@
  * CX23888 DIF support for the HVR1850
  * Copyright (C) 2011 Steven Toth 
  *
+ * CX2584x pin to pad mapping and output format configuration support are
+ * Copyright (C) 2011 Maciej S. Szmigiero 
+ *
  * 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
@@ -316,6 +319,279 @@ static int cx23885_s_io_pin_config(struct v4l2_subdev 
*sd, size_t n,
return 0;
 }
 
+static u8 cx25840_function_to_pad(struct i2c_client *client, u8 function)
+{
+   switch (function) {
+   case CX25840_PAD_ACTIVE:
+   return 1;
+
+   case CX25840_PAD_VACTIVE:
+   return 2;
+
+   case CX25840_PAD_CBFLAG:
+   return 3;
+
+   case CX25840_PAD_VID_DATA_EXT0:
+   return 4;
+
+   case CX25840_PAD_VID_DATA_EXT1:
+   return 5;
+
+   case CX25840_PAD_GPO0:
+   return 6;
+
+   case CX25840_PAD_GPO1:
+   return 7;
+
+   case CX25840_PAD_GPO2:
+   return 8;
+
+   case CX25840_PAD_GPO3:
+   return 9;
+
+   case CX25840_PAD_IRQ_N:
+   return 10;
+
+   case CX25840_PAD_AC_SYNC:
+   return 11;
+
+   case CX25840_PAD_AC_SDOUT:
+   return 12;
+
+   case CX25840_PAD_PLL_CLK:
+   return 13;
+
+   case CX25840_PAD_VRESET:
+   return 14;
+
+   default:
+   if (function != CX25840_PAD_DEFAULT)
+   v4l_err(client,
+   "invalid function %u, assuming default\n",
+   (unsigned int)function);
+   return 0;
+   }
+}
+
+static void cx25840_set_invert(u8 *pinctrl3, u8 *voutctrl4, u8 function,
+  u8 pin, bool invert)
+{
+   if (function != CX25840_PAD_DEFAULT)
+   switch (function) {
+   case CX25840_PAD_IRQ_N:
+   if (invert)
+   *pinctrl3 &= ~2;
+   else
+   *pinctrl3 |= 2;
+   break;
+
+   case CX25840_PAD_ACTIVE:
+   if (invert)
+   *voutctrl4 |= BIT(2);
+   else
+   *voutctrl4 &= ~BIT(2);
+   break;
+
+   case CX25840_PAD_VACTIVE:
+   if (invert)
+   *voutctrl4 |= BIT(5);
+   else
+   *voutctrl4 &= ~BIT(5);
+   break;
+
+   case CX25840_PAD_CBFLAG:
+   if (invert)
+   *voutctrl4 |= BIT(4);
+   else
+   *voutctrl4 &= ~BIT(4);
+   break;
+
+   case CX25840_PAD_VRESET:
+   if (invert)
+   *voutctrl4 |= BIT(0);
+   else
+   *voutctrl4 &= ~BIT(0);
+   break;
+
+   default:
+   break;
+   }
+   else
+   switch (pin) {
+   case CX25840_PIN_DVALID_PRGM0:
+   if (invert)
+   *voutctrl4 |= BIT(6);
+   else
+   *voutctrl4 &= ~BIT(6);
+   break;
+
+   case CX25840_PIN_FIELD_PRGM1:
+   if (invert)
+   *voutctrl4 |= BIT(3);
+   else
+   *voutctrl4 &= ~BIT(3);
+   break;
+
+   case CX25840_PIN_HRESET_PRGM2:
+   if (invert)
+   *voutctrl4 |= 

[PATCH 4/5] [media] tuner-simple: allow setting mono radio mode

[Maciej S. Szmigiero]

For some types of tuners (Philips FMD1216ME(X) MK3 currently) we know that
letting TDA9887 output port 1 remain high (inactive) will switch FM radio
to mono mode.
Let's make use of this functionality - nothing changes for the default
stereo radio mode.

Tested on a Medion 95700 board which has a FMD1216ME tuner.

Signed-off-by: Maciej S. Szmigiero 
---
 drivers/media/tuners/tuner-simple.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/tuners/tuner-simple.c 
b/drivers/media/tuners/tuner-simple.c
index 3339b13dd3f5..568f108efac2 100644
--- a/drivers/media/tuners/tuner-simple.c
+++ b/drivers/media/tuners/tuner-simple.c
@@ -670,6 +670,7 @@ static int simple_set_radio_freq(struct dvb_frontend *fe,
int rc, j;
struct tuner_params *t_params;
unsigned int freq = params->frequency;
+   bool mono = params->audmode == V4L2_TUNER_MODE_MONO;
 
tun = priv->tun;
 
@@ -736,8 +737,8 @@ static int simple_set_radio_freq(struct dvb_frontend *fe,
config |= TDA9887_PORT2_ACTIVE;
if (t_params->intercarrier_mode)
config |= TDA9887_INTERCARRIER;
-/* if (t_params->port1_set_for_fm_mono)
-   config &= ~TDA9887_PORT1_ACTIVE;*/
+   if (t_params->port1_set_for_fm_mono && mono)
+   config &= ~TDA9887_PORT1_ACTIVE;
if (t_params->fm_gain_normal)
config |= TDA9887_GAIN_NORMAL;
if (t_params->radio_if == 2)

[PATCH 3/5] [media] cx25840: fix a possible divide by zero in set_fmt callback

[Maciej S. Szmigiero]

If set_fmt callback is called with format->width or format->height set to
zero and HACTIVE_CNT or VACTIVE_CNT bits (respectively) in chip are zero
we will divide by zero later in this callback when we try to calculate
HSC or VSC values.

Fix this by explicitly rejecting these values.

Signed-off-by: Maciej S. Szmigiero 
---
 drivers/media/i2c/cx25840/cx25840-core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/cx25840/cx25840-core.c 
b/drivers/media/i2c/cx25840/cx25840-core.c
index 2fa74c23d619..c19f39821f46 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.c
+++ b/drivers/media/i2c/cx25840/cx25840-core.c
@@ -1691,8 +1691,9 @@ static int cx25840_set_fmt(struct v4l2_subdev *sd,
 * height. Without that margin the cx23885 fails in this
 * check.
 */
-   if ((fmt->width * 16 < Hsrc) || (Hsrc < fmt->width) ||
-   (Vlines * 8 < Vsrc) || (Vsrc + 1 < Vlines)) {
+   if ((fmt->width == 0) || (Vlines == 0) ||
+   (fmt->width * 16 < Hsrc) || (Hsrc < fmt->width) ||
+   (Vlines * 8 < Vsrc) || (Vsrc + 1 < Vlines)) {
v4l_err(client, "%dx%d is not a valid size!\n",
fmt->width, fmt->height);
return -ERANGE;

Re: [PATCH] imon: constify attribute_group structures

[Sean Young]

On Fri, Aug 04, 2017 at 09:51:38PM -0400, Amitoj Kaur Chawla wrote:
> Functions working with attribute_groups provided by 
> work with const attribute_group. These attribute_group structures do not
> change at runtime so mark them as const.

I'm afraid the exact same patch has already been submitted before.

http://www.spinics.net/lists/linux-media/msg118090.html


Sean

> 
> File size before:
>  text  data bss dec hex filename
>  3698116776 960   54717d5bd drivers/media/rc/imon.o
> 
> File size after:
>  text  data bss dec hex filename
>  3717316584 960   54717d5bd drivers/media/rc/imon.o
> 
> This change was made with the help of Coccinelle.
> 
> Signed-off-by: Amitoj Kaur Chawla 
> ---
>  drivers/media/rc/imon.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
> index bd76534..717ba78 100644
> --- a/drivers/media/rc/imon.c
> +++ b/drivers/media/rc/imon.c
> @@ -911,7 +911,7 @@ static struct attribute *imon_display_sysfs_entries[] = {
>   NULL
>  };
>  
> -static struct attribute_group imon_display_attr_group = {
> +static const struct attribute_group imon_display_attr_group = {
>   .attrs = imon_display_sysfs_entries
>  };
>  
> @@ -920,7 +920,7 @@ static struct attribute *imon_rf_sysfs_entries[] = {
>   NULL
>  };
>  
> -static struct attribute_group imon_rf_attr_group = {
> +static const struct attribute_group imon_rf_attr_group = {
>   .attrs = imon_rf_sysfs_entries
>  };
>  
> -- 
> 2.7.4

Re: [PATCH 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX

[Sean Paul]

On Tue, Jul 11, 2017 at 03:30:09PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This adds support for the DisplayPort CEC-Tunneling-over-AUX
> feature that is part of the DisplayPort 1.3 standard.

Hi Hans,
Thank you for the patch, it looks great, I just have a few minor nits below. 

> 
> Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
> chip that has this capability actually hook up the CEC pin, so
> even though a CEC device is created, it may not actually work.

Boo :(

> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/gpu/drm/Kconfig  |  10 ++
>  drivers/gpu/drm/Makefile |   1 +
>  drivers/gpu/drm/drm_dp_cec.c | 308 
> +++
>  include/drm/drm_dp_helper.h  |  24 
>  4 files changed, 343 insertions(+)
>  create mode 100644 drivers/gpu/drm/drm_dp_cec.c
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 83cb2a88c204..1f2708df5c4e 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -120,6 +120,16 @@ config DRM_LOAD_EDID_FIRMWARE
> default case is N. Details and instructions how to build your own
> EDID data are given in Documentation/EDID/HOWTO.txt.
>  
> +config DRM_DP_CEC
> + bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
> + select CEC_CORE
> + help
> +   Choose this option if you want to enable HDMI CEC support for
> +   DisplayPort/USB-C to HDMI adapters.
> +
> +   Note: not all adapters support this feature, and even for those
> +   that do support this they often do not hook up the CEC pin.
> +
>  config DRM_TTM
>   tristate
>   depends on DRM && MMU
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 24a066e1841c..c6552c62049e 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -40,6 +40,7 @@ drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += 
> drm_edid_load.o
>  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
>  drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
>  drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
> +drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
>  
>  obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
>  obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> new file mode 100644
> index ..7f2e298d45c0
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -0,0 +1,308 @@
> +/*
> + * DisplayPort CEC-Tunneling-over-AUX support
> + *
> + * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights 
> reserved.
> + *
> + * This program is free software; you may 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.
> + *
> + * THE 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 OR THE USE OR OTHER DEALINGS IN THE
> + * SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Unfortunately it turns out that we have a chicken-and-egg situation
> + * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
> + * have a converter chip that supports CEC-Tunneling-over-AUX (usually the
> + * Parade PS176), but they do not wire up the CEC pin, thus making CEC
> + * useless.
> + *
> + * Sadly there is no way for this driver to know this. What happens is
> + * that a /dev/cecX device is created that is isolated and unable to see
> + * any of the other CEC devices. Quite literally the CEC wire is cut
> + * (or in this case, never connected in the first place).
> + *
> + * I suspect that the reason so few adapters support this is that this
> + * tunneling protocol was never supported by any OS. So there was no
> + * easy way of testing it, and no incentive to correctly wire up the
> + * CEC pin.
> + *
> + * Hopefully by creating this driver it will be easier for vendors to
> + * finally fix their adapters and test the CEC functionality.
> + *
> + * I keep a list of known working adapters here:
> + *
> + * https://hverkuil.home.xs4all.nl/cec-status.txt
> + *
> + * Please mail me (hverk...@xs4all.nl) if you find an adapter that works
> + * and is not yet listed there.

According to the schematics, the Google USB-C -> HDMI adapter[1] has CEC wired
up.

[1]- https://store.google.com/product/usb_type_c_to_hdmi_adapter

> + */
> +
> +/**
> + * DOC: dp cec helpers
> + *
> + * These functions take care of supporting 

Re: [PATCH 5/6] [media] rc: rename RC_TYPE_* to RC_PROTO_* and RC_BIT_* to RC_PROTO_BIT_*

[Hans Verkuil]

On 07/08/17 22:20, Sean Young wrote:
> RC_TYPE is confusing and it's just the protocol. So rename it.
> 
> Suggested-by: Hans Verkuil 

Acked-by: Hans Verkuil 

Much better! It's a bit of a painful patch, but so be it. The old names
were really confusing.

> Signed-off-by: Sean Young 
> ---
>  drivers/hid/hid-picolcd_cir.c  |   2 +-

Is a separate Ack needed for this change?

Regards,

Hans

Re: [PATCH] [media] rc: per-protocol repeat period

[Hans Verkuil]

On 09/08/17 19:19, Sean Young wrote:
> CEC needs a keypress timeout of 550ms, which is too high for the IR
> protocols. Also fill in known repeat times, with 50ms error margin.
> 
> Also, combine all protocol data into one structure.
> 
> Signed-off-by: Sean Young 
> Suggested-by: Hans Verkuil 

Much better! I'll mark my rc-main patch as superseded.

Acked-by: Hans Verkuil 

Thanks!

Hans

> ---
>  drivers/media/rc/rc-main.c | 138 
> +
>  1 file changed, 65 insertions(+), 73 deletions(-)
> 
> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> index c494a4ddc138..981cccd6b988 100644
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -30,8 +30,54 @@
>  #define IR_TAB_MAX_SIZE  8192
>  #define RC_DEV_MAX   256
>  
> -/* FIXME: IR_KEYPRESS_TIMEOUT should be protocol specific */
> -#define IR_KEYPRESS_TIMEOUT 250
> +static const struct {
> + const char *name;
> + unsigned int repeat_period;
> + unsigned int scancode_bits;
> +} protocols[] = {
> + [RC_PROTO_UNKNOWN] = { .name = "unknown", .repeat_period = 250 },
> + [RC_PROTO_OTHER] = { .name = "other", .repeat_period = 250 },
> + [RC_PROTO_RC5] = { .name = "rc-5",
> + .scancode_bits = 0x1f7f, .repeat_period = 164 },
> + [RC_PROTO_RC5X_20] = { .name = "rc-5x-20",
> + .scancode_bits = 0x1f7f3f, .repeat_period = 164 },
> + [RC_PROTO_RC5_SZ] = { .name = "rc-5-sz",
> + .scancode_bits = 0x2fff, .repeat_period = 164 },
> + [RC_PROTO_JVC] = { .name = "jvc",
> + .scancode_bits = 0x, .repeat_period = 250 },
> + [RC_PROTO_SONY12] = { .name = "sony-12",
> + .scancode_bits = 0x1f007f, .repeat_period = 100 },
> + [RC_PROTO_SONY15] = { .name = "sony-15",
> + .scancode_bits = 0xff007f, .repeat_period = 100 },
> + [RC_PROTO_SONY20] = { .name = "sony-20",
> + .scancode_bits = 0x1fff7f, .repeat_period = 100 },
> + [RC_PROTO_NEC] = { .name = "nec",
> + .scancode_bits = 0x, .repeat_period = 160 },
> + [RC_PROTO_NECX] = { .name = "nec-x",
> + .scancode_bits = 0xff, .repeat_period = 160 },
> + [RC_PROTO_NEC32] = { .name = "nec-32",
> + .scancode_bits = 0x, .repeat_period = 160 },
> + [RC_PROTO_SANYO] = { .name = "sanyo",
> + .scancode_bits = 0x1f, .repeat_period = 250 },
> + [RC_PROTO_MCIR2_KBD] = { .name = "mcir2-kbd",
> + .scancode_bits = 0x, .repeat_period = 150 },
> + [RC_PROTO_MCIR2_MSE] = { .name = "mcir2-mse",
> + .scancode_bits = 0x1f, .repeat_period = 150 },
> + [RC_PROTO_RC6_0] = { .name = "rc-6-0",
> + .scancode_bits = 0x, .repeat_period = 164 },
> + [RC_PROTO_RC6_6A_20] = { .name = "rc-6-6a-20",
> + .scancode_bits = 0xf, .repeat_period = 164 },
> + [RC_PROTO_RC6_6A_24] = { .name = "rc-6-6a-24",
> + .scancode_bits = 0xff, .repeat_period = 164 },
> + [RC_PROTO_RC6_6A_32] = { .name = "rc-6-6a-32",
> + .scancode_bits = 0x, .repeat_period = 164 },
> + [RC_PROTO_RC6_MCE] = { .name = "rc-6-mce",
> + .scancode_bits = 0x7fff, .repeat_period = 164 },
> + [RC_PROTO_SHARP] = { .name = "sharp",
> + .scancode_bits = 0x1fff, .repeat_period = 250 },
> + [RC_PROTO_XMP] = { .name = "xmp", .repeat_period = 250 },
> + [RC_PROTO_CEC] = { .name = "cec", .repeat_period = 550 },
> +};
>  
>  /* Used to keep track of known keymaps */
>  static LIST_HEAD(rc_map_list);
> @@ -613,6 +659,7 @@ static void ir_timer_keyup(unsigned long cookie)
>  void rc_repeat(struct rc_dev *dev)
>  {
>   unsigned long flags;
> + unsigned int timeout = protocols[dev->last_protocol].repeat_period;
>  
>   spin_lock_irqsave(>keylock, flags);
>  
> @@ -622,7 +669,7 @@ void rc_repeat(struct rc_dev *dev)
>   input_event(dev->input_dev, EV_MSC, MSC_SCAN, dev->last_scancode);
>   input_sync(dev->input_dev);
>  
> - dev->keyup_jiffies = jiffies + msecs_to_jiffies(IR_KEYPRESS_TIMEOUT);
> + dev->keyup_jiffies = jiffies + msecs_to_jiffies(timeout);
>   mod_timer(>timer_keyup, dev->keyup_jiffies);
>  
>  out:
> @@ -693,7 +740,8 @@ void rc_keydown(struct rc_dev *dev, enum rc_proto 
> protocol, u32 scancode,
>   ir_do_keydown(dev, protocol, scancode, keycode, toggle);
>  
>   if (dev->keypressed) {
> - dev->keyup_jiffies = jiffies + 
> msecs_to_jiffies(IR_KEYPRESS_TIMEOUT);
> + dev->keyup_jiffies = jiffies +
> + msecs_to_jiffies(protocols[protocol].repeat_period);
>   mod_timer(>timer_keyup, dev->keyup_jiffies);
>   }
>   spin_unlock_irqrestore(>keylock, flags);
> @@ -734,33 +782,14 @@ EXPORT_SYMBOL_GPL(rc_keydown_notimeout);
>  static int rc_validate_filter(struct rc_dev *dev,
>   

Re: [PATCH 2/2] cec: fix remote control passthrough

[Sean Young]

On Thu, Aug 10, 2017 at 03:00:21PM +0100, Sean Young wrote:
> On Thu, Aug 10, 2017 at 12:45:42PM +0200, Hans Verkuil wrote:
> > On 09/08/17 23:17, Sean Young wrote:
> > > On Tue, Aug 08, 2017 at 10:11:13AM +0200, Hans Verkuil wrote:
> > >> On 07/08/17 22:58, Sean Young wrote:
> > >>> On Mon, Aug 07, 2017 at 03:31:24PM +0200, Hans Verkuil wrote:
> >  From: Hans Verkuil 
> > 
> >  The 'Press and Hold' operation was not correctly implemented, in
> >  particular the requirement that the repeat doesn't start until
> >  the second identical keypress arrives. The REP_DELAY value also
> >  had to be adjusted (see the comment in the code) to achieve the
> >  desired behavior.
> > >>>
> > >>> I'm afraid I've caused some confusion; I had not read your last message
> > >>> about autorepeat on irc correctly, when I said "exactly".
> > >>>
> > >>> So if the input layer has not received a key up event after a key down
> > >>> event, after REP_DELAY it will generate another key down event every
> > >>> REP_PERIOD. So for example, here I'm holding a button on a rc-5 device
> > >>> for some time. Comments on lines with parentheses.
> > >>>
> > >>> # ir-keytable -t
> > >>> Testing events. Please, press CTRL-C to abort.
> > >>> 1502138577.703695: event type EV_MSC(0x04): scancode = 0x1e11
> > >>> (each time a driver receives something, scancode is reported.)
> > >>> 1502138577.703695: event type EV_KEY(0x01) key_down: 
> > >>> KEY_VOLUMEDOWN(0x0072)
> > >>> 1502138577.703695: event type EV_SYN(0x00).
> > >>> 1502138577.817682: event type EV_MSC(0x04): scancode = 0x1e11
> > >>> 1502138577.817682: event type EV_SYN(0x00).
> > >>> (rc-5 repeats the command after 115ms).
> > >>> 1502138577.930676: event type EV_MSC(0x04): scancode = 0x1e11
> > >>> 1502138577.930676: event type EV_SYN(0x00).
> > >>> 1502138578.044682: event type EV_MSC(0x04): scancode = 0x1e11
> > >>> 1502138578.044682: event type EV_SYN(0x00).
> > >>> 1502138578.181690: event type EV_MSC(0x04): scancode = 0x1e11
> > >>> 1502138578.181690: event type EV_SYN(0x00).
> > >>> 1502138578.205667: event type EV_KEY(0x01) key_down: 
> > >>> KEY_VOLUMEDOWN(0x0072)
> > >>> (this is 500ms after the initial key down, so this key down is generated
> > >>> by the input layer).
> > >>> 1502138578.205667: event type EV_SYN(0x00).
> > >>> 1502138578.333667: event type EV_KEY(0x01) key_down: 
> > >>> KEY_VOLUMEDOWN(0x0072)
> > >>> (this is 500 + 125 ms, so another key down event generated by input 
> > >>> layer).
> > >>> 1502138578.333667: event type EV_SYN(0x00).
> > >>> 1502138578.437662: event type EV_KEY(0x01) key_up: 
> > >>> KEY_VOLUMEDOWN(0x0072)
> > >>> 1502138578.437662: event type EV_SYN(0x00).
> > >>> (key up generated by rc-core after 250ms after last scancode received)
> > >>>
> > >>> So I think the autorepeat can do exactly what you want, without cec
> > >>> having any special code for it.
> > >>
> > >> It comes close, but not quite, to what I need. It has more to do with the
> > >> CEC peculiarities than the rc code.
> > >>
> > >> Specifically the CEC spec strongly recommends that the first reported key
> > >> press is always handled as a single non-repeating key press. Only if a 
> > >> second
> > >> identical key press is received within 550 ms will the 'Press and Hold' 
> > >> feature
> > >> kick in and will the key start repeating. This until a Release message is
> > >> received, a different key press is received or nothing is received for 
> > >> 550 ms.
> > > 
> > > Right, that make sense.
> > > 
> > >> Effectively the REP_DELAY is equal to the time between the first and 
> > >> second
> > >> key press message, and it immediately switches to repeat mode once the 
> > >> second
> > >> key press is received.
> > >>
> > >> This code models this behavior exactly.
> > > 
> > > Ok, although you're sending a keyup directly after the first keydown.
> > 
> > Yes, that's to prevent it from going into repeat mode. It shouldn't for
> > the first CEC key press message. Remember that CEC is slow, so it may
> > well take 500ms before you get the next message. And if REP_DELAY < 500ms
> > it will already start repeating which is not what you want for the first
> > key press. Calling keyup immediately will prevent this from happening.
> > 
> > > Another way of doing this is to set REP_DELAY/REP_PERIOD to 0 and
> > > sending the repeats yourself.
> > 
> > No, because you want the user to be able to influence the repeat speed.
> > And the repeat speed is supposed to be that of linux, the repeated CEC
> > messages are just to tell linux that it has to remain in key repeating
> > mode. I.e. if you receive 5 CEC messages while in Press and Hold mode,
> > then that can translate to 20 actual repeats (depending on the REP_PERIOD).
> > 
> > Besides, I don't want to have to write the timer code to repeat the keys
> > myself, after all, it's already there.
> 
> Yes, agreed. I don't think the key up is ideal, but the alternatives
> are 

[PATCH v3 3/3] v4l2-flash-led-class: Document v4l2_flash_init() references

[Sakari Ailus]

The v4l2_flash_init() keeps a reference to the ops struct but not to the
config struct (nor anything it contains). Document this.

Signed-off-by: Sakari Ailus 
Acked-by: Pavel Machek 
Acked-by: Hans Verkuil 
---
 include/media/v4l2-flash-led-class.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/media/v4l2-flash-led-class.h 
b/include/media/v4l2-flash-led-class.h
index c3f39992f3fa..6f4825b6a352 100644
--- a/include/media/v4l2-flash-led-class.h
+++ b/include/media/v4l2-flash-led-class.h
@@ -112,6 +112,9 @@ static inline struct v4l2_flash 
*v4l2_ctrl_to_v4l2_flash(struct v4l2_ctrl *c)
  * @config:initialization data for V4L2 Flash sub-device
  *
  * Create V4L2 Flash sub-device wrapping given LED subsystem device.
+ * The ops pointer is stored by the V4L2 flash framework. No
+ * references are held to config nor its contents once this function
+ * has returned.
  *
  * Returns: A valid pointer, or, when an error occurs, the return
  * value is encoded using ERR_PTR(). Use IS_ERR() to check and
@@ -130,6 +133,9 @@ struct v4l2_flash *v4l2_flash_init(
  * @config:initialization data for V4L2 Flash sub-device
  *
  * Create V4L2 Flash sub-device wrapping given LED subsystem device.
+ * The ops pointer is stored by the V4L2 flash framework. No
+ * references are held to config nor its contents once this function
+ * has returned.
  *
  * Returns: A valid pointer, or, when an error occurs, the return
  * value is encoded using ERR_PTR(). Use IS_ERR() to check and
-- 
2.11.0

[PATCH v3 2/3] v4l2-flash-led-class: Create separate sub-devices for indicators

[Sakari Ailus]

The V4L2 flash interface allows controlling multiple LEDs through a single
sub-devices if, and only if, these LEDs are of different types. This
approach scales badly for flash controllers that drive multiple flash LEDs
or for LED specific associations. Essentially, the original assumption of a
LED driver chip that drives a single flash LED and an indicator LED is no
longer valid.

Address the matter by registering one sub-device per LED.

Signed-off-by: Sakari Ailus 
Reviewed-by: Jacek Anaszewski 
Acked-by: Pavel Machek 
Reviewed-by: Rui Miguel Silva  (for greybus/light)
Acked-by: Hans Verkuil 
---
 drivers/leds/leds-aat1290.c|   4 +-
 drivers/leds/leds-max77693.c   |   4 +-
 drivers/media/v4l2-core/v4l2-flash-led-class.c | 113 +++--
 drivers/staging/greybus/light.c|  23 +++--
 include/media/v4l2-flash-led-class.h   |  41 ++---
 5 files changed, 117 insertions(+), 68 deletions(-)

diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c
index a21e19297745..424898e6c69d 100644
--- a/drivers/leds/leds-aat1290.c
+++ b/drivers/leds/leds-aat1290.c
@@ -432,7 +432,7 @@ static void aat1290_init_v4l2_flash_config(struct 
aat1290_led *led,
strlcpy(v4l2_sd_cfg->dev_name, led_cdev->name,
sizeof(v4l2_sd_cfg->dev_name));
 
-   s = _sd_cfg->torch_intensity;
+   s = _sd_cfg->intensity;
s->min = led->mm_current_scale[0];
s->max = led_cfg->max_mm_current;
s->step = 1;
@@ -504,7 +504,7 @@ static int aat1290_led_probe(struct platform_device *pdev)
 
/* Create V4L2 Flash subdev. */
led->v4l2_flash = v4l2_flash_init(dev, of_fwnode_handle(sub_node),
- fled_cdev, NULL, _flash_ops,
+ fled_cdev, _flash_ops,
  _sd_cfg);
if (IS_ERR(led->v4l2_flash)) {
ret = PTR_ERR(led->v4l2_flash);
diff --git a/drivers/leds/leds-max77693.c b/drivers/leds/leds-max77693.c
index 2d3062d53325..adf0f191f794 100644
--- a/drivers/leds/leds-max77693.c
+++ b/drivers/leds/leds-max77693.c
@@ -856,7 +856,7 @@ static void max77693_init_v4l2_flash_config(struct 
max77693_sub_led *sub_led,
 "%s %d-%04x", sub_led->fled_cdev.led_cdev.name,
 i2c_adapter_id(i2c->adapter), i2c->addr);
 
-   s = _sd_cfg->torch_intensity;
+   s = _sd_cfg->intensity;
s->min = TORCH_IOUT_MIN;
s->max = sub_led->fled_cdev.led_cdev.max_brightness * TORCH_IOUT_STEP;
s->step = TORCH_IOUT_STEP;
@@ -931,7 +931,7 @@ static int max77693_register_led(struct max77693_sub_led 
*sub_led,
 
/* Register in the V4L2 subsystem. */
sub_led->v4l2_flash = v4l2_flash_init(dev, of_fwnode_handle(sub_node),
- fled_cdev, NULL, _flash_ops,
+ fled_cdev, _flash_ops,
  _sd_cfg);
if (IS_ERR(sub_led->v4l2_flash)) {
ret = PTR_ERR(sub_led->v4l2_flash);
diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c 
b/drivers/media/v4l2-core/v4l2-flash-led-class.c
index aabc85dbb8b5..4ceef217de83 100644
--- a/drivers/media/v4l2-core/v4l2-flash-led-class.c
+++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c
@@ -197,7 +197,7 @@ static int v4l2_flash_s_ctrl(struct v4l2_ctrl *c)
 {
struct v4l2_flash *v4l2_flash = v4l2_ctrl_to_v4l2_flash(c);
struct led_classdev_flash *fled_cdev = v4l2_flash->fled_cdev;
-   struct led_classdev *led_cdev = _cdev->led_cdev;
+   struct led_classdev *led_cdev = fled_cdev ? _cdev->led_cdev : NULL;
struct v4l2_ctrl **ctrls = v4l2_flash->ctrls;
bool external_strobe;
int ret = 0;
@@ -299,10 +299,26 @@ static void __fill_ctrl_init_data(struct v4l2_flash 
*v4l2_flash,
  struct v4l2_flash_ctrl_data *ctrl_init_data)
 {
struct led_classdev_flash *fled_cdev = v4l2_flash->fled_cdev;
-   struct led_classdev *led_cdev = _cdev->led_cdev;
+   struct led_classdev *led_cdev = fled_cdev ? _cdev->led_cdev : NULL;
struct v4l2_ctrl_config *ctrl_cfg;
u32 mask;
 
+   /* Init INDICATOR_INTENSITY ctrl data */
+   if (v4l2_flash->iled_cdev) {
+   ctrl_init_data[INDICATOR_INTENSITY].cid =
+   V4L2_CID_FLASH_INDICATOR_INTENSITY;
+   ctrl_cfg = _init_data[INDICATOR_INTENSITY].config;
+   __lfs_to_v4l2_ctrl_config(_cfg->intensity,
+ ctrl_cfg);
+   ctrl_cfg->id = V4L2_CID_FLASH_INDICATOR_INTENSITY;
+   ctrl_cfg->min = 0;
+   ctrl_cfg->flags = V4L2_CTRL_FLAG_VOLATILE |
+ 

[PATCH v3 0/3] Create sub-device per LED

[Sakari Ailus]

Hi folks,

The original design decision in the V4L2 flash API allows controlling a two
LEDs (an indicator and a flash) through a single sub-device. This covered
virtually all flash driver chips back then but this no longer holds as
there are many LED driver chips with multiple flash LED outputs. This
necessitates creating as many sub-devices as there are flash LEDs.

Additionally the flash LEDs can be associated to different sensors. This is
not unconceivable although not very probable.

This patchset splits the indicator and flash LEDs exposed by the V4L2 flash
class framework into multiple sub-devices. This way the driver creates the
sub-devices individually for each LED which will also facilitate fwnode
matching (e.g. will you refer to LED or a LED driver chip with a phandle?).

Note that this set depends on patch 85f7ff9702bc ("media:
v4l2-flash: Use led_classdev instead of led_classdev_flash for
indicator") in mediatree master.

since v2:

- Add Hans's acks and Rui's reviewed-by.

- Use IS_ERR() instead of IS_ERR_OR_NULL() to check v4l2_flash_init()
  success --- it never returns NULL.

since v1:

- Drop patch "staging: greybus: light: Don't leak memory for no gain" in
  favour of Rui's "staging: greybus: light: fix memory leak in v4l2
  register".

- Rebase "staging: greybus: light: fix memory leak in v4l2 register" on
  "media: v4l2-flash: Use led_classdev instead of led_classdev_flash for
  indicator" already in mediatree.

- Add "v4l2-flash-led-class: Document v4l2_flash_init() references" to the
  set.

Rui Miguel Silva (1):
  staging: greybus: light: fix memory leak in v4l2 register

Sakari Ailus (2):
  v4l2-flash-led-class: Create separate sub-devices for indicators
  v4l2-flash-led-class: Document v4l2_flash_init() references

 drivers/leds/leds-aat1290.c|   4 +-
 drivers/leds/leds-max77693.c   |   4 +-
 drivers/media/v4l2-core/v4l2-flash-led-class.c | 113 +++--
 drivers/staging/greybus/light.c|  42 -
 include/media/v4l2-flash-led-class.h   |  47 +++---
 5 files changed, 127 insertions(+), 83 deletions(-)

-- 
2.11.0

[PATCH v3 1/3] staging: greybus: light: fix memory leak in v4l2 register

[Sakari Ailus]

From: Rui Miguel Silva 

We are allocating memory for the v4l2 flash configuration structure and
leak it in the normal path. Just use the stack for this as we do not
use it outside of this function.

Also use IS_ERR() instead of IS_ERR_OR_NULL() to check return value from
v4l2_flash_init() for it never returns NULL.

Fixes: 2870b52bae4c ("greybus: lights: add lights implementation")
Reported-by: Sakari Ailus 
Signed-off-by: Rui Miguel Silva 
Reviewed-by: Viresh Kumar 
Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 drivers/staging/greybus/light.c | 29 +
 1 file changed, 9 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c
index 129ceed39829..81469d087e74 100644
--- a/drivers/staging/greybus/light.c
+++ b/drivers/staging/greybus/light.c
@@ -534,25 +534,20 @@ static int gb_lights_light_v4l2_register(struct gb_light 
*light)
 {
struct gb_connection *connection = get_conn_from_light(light);
struct device *dev = >bundle->dev;
-   struct v4l2_flash_config *sd_cfg;
+   struct v4l2_flash_config sd_cfg = { {0} };
struct led_classdev_flash *fled;
struct led_classdev *iled = NULL;
struct gb_channel *channel_torch, *channel_ind, *channel_flash;
-   int ret = 0;
-
-   sd_cfg = kcalloc(1, sizeof(*sd_cfg), GFP_KERNEL);
-   if (!sd_cfg)
-   return -ENOMEM;
 
channel_torch = get_channel_from_mode(light, GB_CHANNEL_MODE_TORCH);
if (channel_torch)
__gb_lights_channel_v4l2_config(_torch->intensity_uA,
-   _cfg->torch_intensity);
+   _cfg.torch_intensity);
 
channel_ind = get_channel_from_mode(light, GB_CHANNEL_MODE_INDICATOR);
if (channel_ind) {
__gb_lights_channel_v4l2_config(_ind->intensity_uA,
-   _cfg->indicator_intensity);
+   _cfg.indicator_intensity);
iled = _ind->fled.led_cdev;
}
 
@@ -561,27 +556,21 @@ static int gb_lights_light_v4l2_register(struct gb_light 
*light)
 
fled = _flash->fled;
 
-   snprintf(sd_cfg->dev_name, sizeof(sd_cfg->dev_name), "%s", light->name);
+   snprintf(sd_cfg.dev_name, sizeof(sd_cfg.dev_name), "%s", light->name);
 
/* Set the possible values to faults, in our case all faults */
-   sd_cfg->flash_faults = LED_FAULT_OVER_VOLTAGE | LED_FAULT_TIMEOUT |
+   sd_cfg.flash_faults = LED_FAULT_OVER_VOLTAGE | LED_FAULT_TIMEOUT |
LED_FAULT_OVER_TEMPERATURE | LED_FAULT_SHORT_CIRCUIT |
LED_FAULT_OVER_CURRENT | LED_FAULT_INDICATOR |
LED_FAULT_UNDER_VOLTAGE | LED_FAULT_INPUT_VOLTAGE |
LED_FAULT_LED_OVER_TEMPERATURE;
 
light->v4l2_flash = v4l2_flash_init(dev, NULL, fled, iled,
-   _flash_ops, sd_cfg);
-   if (IS_ERR_OR_NULL(light->v4l2_flash)) {
-   ret = PTR_ERR(light->v4l2_flash);
-   goto out_free;
-   }
+   _flash_ops, _cfg);
+   if (IS_ERR(light->v4l2_flash))
+   return PTR_ERR(light->v4l2_flash);
 
-   return ret;
-
-out_free:
-   kfree(sd_cfg);
-   return ret;
+   return 0;
 }
 
 static void gb_lights_light_v4l2_unregister(struct gb_light *light)
-- 
2.11.0

Re: [PATCH v5 6/6] dt-bindings: Document the Rockchip RGA bindings

[Rob Herring]

On Wed, Aug 02, 2017 at 11:19:47AM +0800, Jacob Chen wrote:
> Add DT bindings documentation for Rockchip RGA
> 
> Signed-off-by: Jacob Chen 
> Signed-off-by: Yakir Yang 
> ---
>  .../devicetree/bindings/media/rockchip-rga.txt | 33 
> ++
>  1 file changed, 33 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt

Acked-by: Rob Herring 

[PATCH] dvb-usb: Add memory free on error path in dw2102_probe()

[Anton Vasilyev]

If dw2102_probe() fails on dvb_usb_device_init(), then memleak occurs.

The patch adds deallocation to the error path.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Anton Vasilyev 
---
 drivers/media/usb/dvb-usb/dw2102.c | 39 +-
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/dw2102.c 
b/drivers/media/usb/dvb-usb/dw2102.c
index 6e654e5..0d63693 100644
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -2332,10 +2332,12 @@ static struct dvb_usb_device_properties 
tt_s2_4600_properties = {
 static int dw2102_probe(struct usb_interface *intf,
const struct usb_device_id *id)
 {
+   int retval = -ENOMEM;
p1100 = kmemdup(_properties,
sizeof(struct dvb_usb_device_properties), GFP_KERNEL);
if (!p1100)
-   return -ENOMEM;
+   goto err0;
+
/* copy default structure */
/* fill only different fields */
p1100->firmware = P1100_FIRMWARE;
@@ -2346,10 +2348,9 @@ static int dw2102_probe(struct usb_interface *intf,
 
s660 = kmemdup(_properties,
   sizeof(struct dvb_usb_device_properties), GFP_KERNEL);
-   if (!s660) {
-   kfree(p1100);
-   return -ENOMEM;
-   }
+   if (!s660)
+   goto err1;
+
s660->firmware = S660_FIRMWARE;
s660->num_device_descs = 3;
s660->devices[0] = d660;
@@ -2359,11 +2360,9 @@ static int dw2102_probe(struct usb_interface *intf,
 
p7500 = kmemdup(_properties,
sizeof(struct dvb_usb_device_properties), GFP_KERNEL);
-   if (!p7500) {
-   kfree(p1100);
-   kfree(s660);
-   return -ENOMEM;
-   }
+   if (!p7500)
+   goto err2;
+
p7500->firmware = P7500_FIRMWARE;
p7500->devices[0] = d7500;
p7500->rc.core.rc_query = prof_rc_query;
@@ -2373,12 +2372,9 @@ static int dw2102_probe(struct usb_interface *intf,
 
s421 = kmemdup(_properties,
   sizeof(struct dvb_usb_device_properties), GFP_KERNEL);
-   if (!s421) {
-   kfree(p1100);
-   kfree(s660);
-   kfree(p7500);
-   return -ENOMEM;
-   }
+   if (!s421)
+   goto err3;
+
s421->num_device_descs = 2;
s421->devices[0] = d421;
s421->devices[1] = d632;
@@ -2408,7 +2404,16 @@ static int dw2102_probe(struct usb_interface *intf,
 THIS_MODULE, NULL, adapter_nr))
return 0;
 
-   return -ENODEV;
+   retval = -ENODEV;
+   kfree(s421);
+err3:
+   kfree(p7500);
+err2:
+   kfree(s660);
+err1:
+   kfree(p1100);
+err0:
+   return retval;
 }
 
 static void dw2102_disconnect(struct usb_interface *intf)
-- 
2.7.4

[PATCH] staging:media:atomisp:Fix code indent error

[Harold Gomez]

code indent should use tabs where possible
change spaces to tabs

Signed-off-by: Harold Gomez 
---
 drivers/staging/media/atomisp/i2c/ap1302.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/i2c/ap1302.c 
b/drivers/staging/media/atomisp/i2c/ap1302.c
index bacffbe..538a064 100644
--- a/drivers/staging/media/atomisp/i2c/ap1302.c
+++ b/drivers/staging/media/atomisp/i2c/ap1302.c
@@ -606,7 +606,7 @@ static s32 ap1302_try_mbus_fmt_locked(struct v4l2_subdev 
*sd,
 
 
 static int ap1302_get_fmt(struct v4l2_subdev *sd,
-struct v4l2_subdev_pad_config *cfg,
+struct v4l2_subdev_pad_config *cfg,
 struct v4l2_subdev_format *format)
 
 {
-- 
2.1.4

Re: [PATCH v2 1/3] staging: greybus: light: fix memory leak in v4l2 register

[Rui Miguel Silva]

Hi,
On Thu, Aug 10, 2017 at 04:56:50PM +0300, Sakari Ailus wrote:
> Hi Hans,
> 
> On Thu, Aug 10, 2017 at 03:02:46PM +0200, Hans Verkuil wrote:
> > > @@ -534,25 +534,20 @@ static int gb_lights_light_v4l2_register(struct 
> > > gb_light *light)
> > >  {
> > >   struct gb_connection *connection = get_conn_from_light(light);
> > >   struct device *dev = >bundle->dev;
> > > - struct v4l2_flash_config *sd_cfg;
> > > + struct v4l2_flash_config sd_cfg = { {0} };
> > 
> > Just use '= {};'
> 
> This is GCC specific whereas { {0} } is standard C. The latter is thus
> obviously better IMO.

My thought exactly. Let keep it this way, please.

> 
> > 
> > >   struct led_classdev_flash *fled;
> > >   struct led_classdev *iled = NULL;
> > >   struct gb_channel *channel_torch, *channel_ind, *channel_flash;
> > > - int ret = 0;
> > > -
> > > - sd_cfg = kcalloc(1, sizeof(*sd_cfg), GFP_KERNEL);
> > > - if (!sd_cfg)
> > > - return -ENOMEM;
> > >  
> > >   channel_torch = get_channel_from_mode(light, GB_CHANNEL_MODE_TORCH);
> > >   if (channel_torch)
> > >   __gb_lights_channel_v4l2_config(_torch->intensity_uA,
> > > - _cfg->torch_intensity);
> > > + _cfg.torch_intensity);
> > >  
> > >   channel_ind = get_channel_from_mode(light, GB_CHANNEL_MODE_INDICATOR);
> > >   if (channel_ind) {
> > >   __gb_lights_channel_v4l2_config(_ind->intensity_uA,
> > > - _cfg->indicator_intensity);
> > > + _cfg.indicator_intensity);
> > >   iled = _ind->fled.led_cdev;
> > >   }
> > >  
> > > @@ -561,27 +556,21 @@ static int gb_lights_light_v4l2_register(struct 
> > > gb_light *light)
> > >  
> > >   fled = _flash->fled;
> > >  
> > > - snprintf(sd_cfg->dev_name, sizeof(sd_cfg->dev_name), "%s", light->name);
> > > + snprintf(sd_cfg.dev_name, sizeof(sd_cfg.dev_name), "%s", light->name);
> > >  
> > >   /* Set the possible values to faults, in our case all faults */
> > > - sd_cfg->flash_faults = LED_FAULT_OVER_VOLTAGE | LED_FAULT_TIMEOUT |
> > > + sd_cfg.flash_faults = LED_FAULT_OVER_VOLTAGE | LED_FAULT_TIMEOUT |
> > >   LED_FAULT_OVER_TEMPERATURE | LED_FAULT_SHORT_CIRCUIT |
> > >   LED_FAULT_OVER_CURRENT | LED_FAULT_INDICATOR |
> > >   LED_FAULT_UNDER_VOLTAGE | LED_FAULT_INPUT_VOLTAGE |
> > >   LED_FAULT_LED_OVER_TEMPERATURE;
> > >  
> > >   light->v4l2_flash = v4l2_flash_init(dev, NULL, fled, iled,
> > > - _flash_ops, sd_cfg);
> > > - if (IS_ERR_OR_NULL(light->v4l2_flash)) {
> > > - ret = PTR_ERR(light->v4l2_flash);
> > > - goto out_free;
> > > - }
> > > + _flash_ops, _cfg);
> > > + if (IS_ERR_OR_NULL(light->v4l2_flash))
> > 
> > Just IS_ERR since v4l2_flash_init() never returns NULL.
> 
> Will fix.

Thanks for that Sakari.

---
Cheers,
Rui

> 
> > 
> > > + return PTR_ERR(light->v4l2_flash);
> > >  
> > > - return ret;
> > > -
> > > -out_free:
> > > - kfree(sd_cfg);
> > > - return ret;
> > > + return 0;
> > >  }
> > >  
> > >  static void gb_lights_light_v4l2_unregister(struct gb_light *light)
> > > 
> > 
> > After those two changes:
> > 
> > Acked-by: Hans Verkuil 
> 
> -- 
> Regards,
> 
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi   XMPP: sai...@retiisi.org.uk

[PATCH] staging:media:atomisp:Fix trivial codingstyle issues

[Harold Gomez]

change comment style to match codingstyle. Issue found by checkpatch
change four comments.

Signed-off-by: Harold Gomez 
---
 drivers/staging/media/atomisp/i2c/ap1302.c | 38 --
 1 file changed, 25 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/ap1302.c 
b/drivers/staging/media/atomisp/i2c/ap1302.c
index 3e229ba..68e0b83 100644
--- a/drivers/staging/media/atomisp/i2c/ap1302.c
+++ b/drivers/staging/media/atomisp/i2c/ap1302.c
@@ -321,12 +321,15 @@ static int ap1302_request_firmware(struct v4l2_subdev *sd)
return ret;
 }
 
-/* When loading firmware, host writes firmware data from address 0x8000.
-   When the address reaches 0x9FFF, the next address should return to 0x8000.
-   This function handles this address window and load firmware data to AP1302.
-   win_pos indicates the offset within this window. Firmware loading procedure
-   may call this function several times. win_pos records the current position
-   that has been written to.*/
+/*
+ * When loading firmware, host writes firmware data from address 0x8000.
+ * When the address reaches 0x9FFF, the next address should return to 0x8000.
+ * This function handles this address window and load firmware data to AP1302.
+ * win_pos indicates the offset within this window. Firmware loading procedure
+ * may call this function several times. win_pos records the current position
+ * that has been written to.
+ *
+ */
 static int ap1302_write_fw_window(struct v4l2_subdev *sd,
  u16 *win_pos, const u8 *buf, u32 len)
 {
@@ -371,9 +374,12 @@ static int ap1302_load_firmware(struct v4l2_subdev *sd)
dev_err(>dev, "firmware size does not match.\n");
return -EINVAL;
}
-   /* The fw binary contains a header of struct ap1302_firmware.
-  Following the header is the bootdata of AP1302.
-  The bootdata pointer can be referenced as [1]. */
+   /*
+* The fw binary contains a header of struct ap1302_firmware.
+* Following the header is the bootdata of AP1302.
+* The bootdata pointer can be referenced as [1].
+*
+*/
fw_data = (u8 *)[1];
 
/* Clear crc register. */
@@ -386,8 +392,11 @@ static int ap1302_load_firmware(struct v4l2_subdev *sd)
if (ret)
return ret;
 
-   /* Write 2 to bootdata_stage register to apply basic_init_hp
-  settings and enable PLL. */
+   /*
+* Write 2 to bootdata_stage register to apply basic_init_hp
+* settings and enable PLL.
+*
+*/
ret = ap1302_i2c_write_reg(sd, REG_BOOTDATA_STAGE,
   AP1302_REG16, 0x0002);
if (ret)
@@ -413,8 +422,11 @@ static int ap1302_load_firmware(struct v4l2_subdev *sd)
return -EAGAIN;
}
 
-   /* Write 0x to bootdata_stage register to indicate AP1302 that
-  the whole bootdata content has been loaded. */
+   /*
+* Write 0x to bootdata_stage register to indicate AP1302 that
+* the whole bootdata content has been loaded.
+*
+*/
ret = ap1302_i2c_write_reg(sd, REG_BOOTDATA_STAGE,
   AP1302_REG16, 0x);
if (ret)
-- 
2.1.4

Re: [PATCH 4/5] media: platform: s5p-jpeg: fix number of components macro

[Sylwester Nawrocki]

On 08/08/2017 01:27 PM, Andrzej Pietrasiewicz wrote:

The value to be processed must be first masked and then shifted,
not the other way round.

Signed-off-by: Andrzej Pietrasiewicz 
---
  drivers/media/platform/s5p-jpeg/jpeg-regs.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-regs.h 
b/drivers/media/platform/s5p-jpeg/jpeg-regs.h
index 1870400..df790b1 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-regs.h
+++ b/drivers/media/platform/s5p-jpeg/jpeg-regs.h
@@ -371,7 +371,7 @@
  #define EXYNOS4_NF_SHIFT  16
  #define EXYNOS4_NF_MASK   0xff
  #define EXYNOS4_NF(x) \
-   (((x) << EXYNOS4_NF_SHIFT) & EXYNOS4_NF_MASK)
+   (((x) & EXYNOS4_NF_MASK) << EXYNOS4_NF_SHIFT)


I'm going to add below tag when applying this patch.

Fixes: 6c96dbbc2aa9f5b4a ("[media] s5p-jpeg: add support for 5433")

--
Regards,
Sylwester

[PATCH] staging:media:atomisp:Fix block comments use * on subsequent lines ap1302.c

[Harold Gomez]

This patch fixes the warning

WARNING: Block comments use * on subsequent lines
+/* When loading firmware, host writes firmware data from address
0x8000.
+   When the address reaches 0x9FFF, the next address should return to
0x8000.

WARNING: Block comments use a trailing */ on a separate line
+   that has been written to.*/

WARNING: Block comments use * on subsequent lines
+   /* The fw binary contains a header of struct ap1302_firmware.
+  Following the header is the bootdata of AP1302.

WARNING: Block comments use a trailing */ on a separate line
+  The bootdata pointer can be referenced as [1]. */

WARNING: Block comments use * on subsequent lines
+   /* Write 2 to bootdata_stage register to apply basic_init_hp
+  settings and enable PLL. */

WARNING: Block comments use a trailing */ on a separate line
+  settings and enable PLL. */

WARNING: Block comments use * on subsequent lines
+   /* Write 0x to bootdata_stage register to indicate AP1302
that
+  the whole bootdata content has been loaded. */

WARNING: Block comments use a trailing */ on a separate line
+  the whole bootdata content has been loaded. */

Signed-off-by: Harold Gomez 
---
 drivers/staging/media/atomisp/i2c/ap1302.c | 38 --
 1 file changed, 25 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/ap1302.c 
b/drivers/staging/media/atomisp/i2c/ap1302.c
index 3e229ba..68e0b83 100644
--- a/drivers/staging/media/atomisp/i2c/ap1302.c
+++ b/drivers/staging/media/atomisp/i2c/ap1302.c
@@ -321,12 +321,15 @@ static int ap1302_request_firmware(struct v4l2_subdev *sd)
return ret;
 }
 
-/* When loading firmware, host writes firmware data from address 0x8000.
-   When the address reaches 0x9FFF, the next address should return to 0x8000.
-   This function handles this address window and load firmware data to AP1302.
-   win_pos indicates the offset within this window. Firmware loading procedure
-   may call this function several times. win_pos records the current position
-   that has been written to.*/
+/*
+ * When loading firmware, host writes firmware data from address 0x8000.
+ * When the address reaches 0x9FFF, the next address should return to 0x8000.
+ * This function handles this address window and load firmware data to AP1302.
+ * win_pos indicates the offset within this window. Firmware loading procedure
+ * may call this function several times. win_pos records the current position
+ * that has been written to.
+ *
+ */
 static int ap1302_write_fw_window(struct v4l2_subdev *sd,
  u16 *win_pos, const u8 *buf, u32 len)
 {
@@ -371,9 +374,12 @@ static int ap1302_load_firmware(struct v4l2_subdev *sd)
dev_err(>dev, "firmware size does not match.\n");
return -EINVAL;
}
-   /* The fw binary contains a header of struct ap1302_firmware.
-  Following the header is the bootdata of AP1302.
-  The bootdata pointer can be referenced as [1]. */
+   /*
+* The fw binary contains a header of struct ap1302_firmware.
+* Following the header is the bootdata of AP1302.
+* The bootdata pointer can be referenced as [1].
+*
+*/
fw_data = (u8 *)[1];
 
/* Clear crc register. */
@@ -386,8 +392,11 @@ static int ap1302_load_firmware(struct v4l2_subdev *sd)
if (ret)
return ret;
 
-   /* Write 2 to bootdata_stage register to apply basic_init_hp
-  settings and enable PLL. */
+   /*
+* Write 2 to bootdata_stage register to apply basic_init_hp
+* settings and enable PLL.
+*
+*/
ret = ap1302_i2c_write_reg(sd, REG_BOOTDATA_STAGE,
   AP1302_REG16, 0x0002);
if (ret)
@@ -413,8 +422,11 @@ static int ap1302_load_firmware(struct v4l2_subdev *sd)
return -EAGAIN;
}
 
-   /* Write 0x to bootdata_stage register to indicate AP1302 that
-  the whole bootdata content has been loaded. */
+   /*
+* Write 0x to bootdata_stage register to indicate AP1302 that
+* the whole bootdata content has been loaded.
+*
+*/
ret = ap1302_i2c_write_reg(sd, REG_BOOTDATA_STAGE,
   AP1302_REG16, 0x);
if (ret)
-- 
2.1.4

Re: [PATCH 2/2] cec: fix remote control passthrough

[Sean Young]

On Thu, Aug 10, 2017 at 12:45:42PM +0200, Hans Verkuil wrote:
> On 09/08/17 23:17, Sean Young wrote:
> > On Tue, Aug 08, 2017 at 10:11:13AM +0200, Hans Verkuil wrote:
> >> On 07/08/17 22:58, Sean Young wrote:
> >>> On Mon, Aug 07, 2017 at 03:31:24PM +0200, Hans Verkuil wrote:
>  From: Hans Verkuil 
> 
>  The 'Press and Hold' operation was not correctly implemented, in
>  particular the requirement that the repeat doesn't start until
>  the second identical keypress arrives. The REP_DELAY value also
>  had to be adjusted (see the comment in the code) to achieve the
>  desired behavior.
> >>>
> >>> I'm afraid I've caused some confusion; I had not read your last message
> >>> about autorepeat on irc correctly, when I said "exactly".
> >>>
> >>> So if the input layer has not received a key up event after a key down
> >>> event, after REP_DELAY it will generate another key down event every
> >>> REP_PERIOD. So for example, here I'm holding a button on a rc-5 device
> >>> for some time. Comments on lines with parentheses.
> >>>
> >>> # ir-keytable -t
> >>> Testing events. Please, press CTRL-C to abort.
> >>> 1502138577.703695: event type EV_MSC(0x04): scancode = 0x1e11
> >>> (each time a driver receives something, scancode is reported.)
> >>> 1502138577.703695: event type EV_KEY(0x01) key_down: 
> >>> KEY_VOLUMEDOWN(0x0072)
> >>> 1502138577.703695: event type EV_SYN(0x00).
> >>> 1502138577.817682: event type EV_MSC(0x04): scancode = 0x1e11
> >>> 1502138577.817682: event type EV_SYN(0x00).
> >>> (rc-5 repeats the command after 115ms).
> >>> 1502138577.930676: event type EV_MSC(0x04): scancode = 0x1e11
> >>> 1502138577.930676: event type EV_SYN(0x00).
> >>> 1502138578.044682: event type EV_MSC(0x04): scancode = 0x1e11
> >>> 1502138578.044682: event type EV_SYN(0x00).
> >>> 1502138578.181690: event type EV_MSC(0x04): scancode = 0x1e11
> >>> 1502138578.181690: event type EV_SYN(0x00).
> >>> 1502138578.205667: event type EV_KEY(0x01) key_down: 
> >>> KEY_VOLUMEDOWN(0x0072)
> >>> (this is 500ms after the initial key down, so this key down is generated
> >>> by the input layer).
> >>> 1502138578.205667: event type EV_SYN(0x00).
> >>> 1502138578.333667: event type EV_KEY(0x01) key_down: 
> >>> KEY_VOLUMEDOWN(0x0072)
> >>> (this is 500 + 125 ms, so another key down event generated by input 
> >>> layer).
> >>> 1502138578.333667: event type EV_SYN(0x00).
> >>> 1502138578.437662: event type EV_KEY(0x01) key_up: KEY_VOLUMEDOWN(0x0072)
> >>> 1502138578.437662: event type EV_SYN(0x00).
> >>> (key up generated by rc-core after 250ms after last scancode received)
> >>>
> >>> So I think the autorepeat can do exactly what you want, without cec
> >>> having any special code for it.
> >>
> >> It comes close, but not quite, to what I need. It has more to do with the
> >> CEC peculiarities than the rc code.
> >>
> >> Specifically the CEC spec strongly recommends that the first reported key
> >> press is always handled as a single non-repeating key press. Only if a 
> >> second
> >> identical key press is received within 550 ms will the 'Press and Hold' 
> >> feature
> >> kick in and will the key start repeating. This until a Release message is
> >> received, a different key press is received or nothing is received for 550 
> >> ms.
> > 
> > Right, that make sense.
> > 
> >> Effectively the REP_DELAY is equal to the time between the first and second
> >> key press message, and it immediately switches to repeat mode once the 
> >> second
> >> key press is received.
> >>
> >> This code models this behavior exactly.
> > 
> > Ok, although you're sending a keyup directly after the first keydown.
> 
> Yes, that's to prevent it from going into repeat mode. It shouldn't for
> the first CEC key press message. Remember that CEC is slow, so it may
> well take 500ms before you get the next message. And if REP_DELAY < 500ms
> it will already start repeating which is not what you want for the first
> key press. Calling keyup immediately will prevent this from happening.
> 
> > Another way of doing this is to set REP_DELAY/REP_PERIOD to 0 and
> > sending the repeats yourself.
> 
> No, because you want the user to be able to influence the repeat speed.
> And the repeat speed is supposed to be that of linux, the repeated CEC
> messages are just to tell linux that it has to remain in key repeating
> mode. I.e. if you receive 5 CEC messages while in Press and Hold mode,
> then that can translate to 20 actual repeats (depending on the REP_PERIOD).
> 
> Besides, I don't want to have to write the timer code to repeat the keys
> myself, after all, it's already there.

Yes, agreed. I don't think the key up is ideal, but the alternatives
are worse.

> > I'm not sure it's worth it just to prevent the keyup.

Sean

> > 
> > 
> > Sean
> > 
> >>
> >> Regards,
> >>
> >>Hans
> >>
> >>>
> >>> On a side note, here you can see that for rc-5 the IR_KEYPRESS_TIMEOUT
> >>> should be 115ms (with a little extra 

Re: [PATCH v2 1/3] staging: greybus: light: fix memory leak in v4l2 register

[Sakari Ailus]

Hi Hans,

On Thu, Aug 10, 2017 at 03:02:46PM +0200, Hans Verkuil wrote:
> > @@ -534,25 +534,20 @@ static int gb_lights_light_v4l2_register(struct 
> > gb_light *light)
> >  {
> > struct gb_connection *connection = get_conn_from_light(light);
> > struct device *dev = >bundle->dev;
> > -   struct v4l2_flash_config *sd_cfg;
> > +   struct v4l2_flash_config sd_cfg = { {0} };
> 
> Just use '= {};'

This is GCC specific whereas { {0} } is standard C. The latter is thus
obviously better IMO.

> 
> > struct led_classdev_flash *fled;
> > struct led_classdev *iled = NULL;
> > struct gb_channel *channel_torch, *channel_ind, *channel_flash;
> > -   int ret = 0;
> > -
> > -   sd_cfg = kcalloc(1, sizeof(*sd_cfg), GFP_KERNEL);
> > -   if (!sd_cfg)
> > -   return -ENOMEM;
> >  
> > channel_torch = get_channel_from_mode(light, GB_CHANNEL_MODE_TORCH);
> > if (channel_torch)
> > __gb_lights_channel_v4l2_config(_torch->intensity_uA,
> > -   _cfg->torch_intensity);
> > +   _cfg.torch_intensity);
> >  
> > channel_ind = get_channel_from_mode(light, GB_CHANNEL_MODE_INDICATOR);
> > if (channel_ind) {
> > __gb_lights_channel_v4l2_config(_ind->intensity_uA,
> > -   _cfg->indicator_intensity);
> > +   _cfg.indicator_intensity);
> > iled = _ind->fled.led_cdev;
> > }
> >  
> > @@ -561,27 +556,21 @@ static int gb_lights_light_v4l2_register(struct 
> > gb_light *light)
> >  
> > fled = _flash->fled;
> >  
> > -   snprintf(sd_cfg->dev_name, sizeof(sd_cfg->dev_name), "%s", light->name);
> > +   snprintf(sd_cfg.dev_name, sizeof(sd_cfg.dev_name), "%s", light->name);
> >  
> > /* Set the possible values to faults, in our case all faults */
> > -   sd_cfg->flash_faults = LED_FAULT_OVER_VOLTAGE | LED_FAULT_TIMEOUT |
> > +   sd_cfg.flash_faults = LED_FAULT_OVER_VOLTAGE | LED_FAULT_TIMEOUT |
> > LED_FAULT_OVER_TEMPERATURE | LED_FAULT_SHORT_CIRCUIT |
> > LED_FAULT_OVER_CURRENT | LED_FAULT_INDICATOR |
> > LED_FAULT_UNDER_VOLTAGE | LED_FAULT_INPUT_VOLTAGE |
> > LED_FAULT_LED_OVER_TEMPERATURE;
> >  
> > light->v4l2_flash = v4l2_flash_init(dev, NULL, fled, iled,
> > -   _flash_ops, sd_cfg);
> > -   if (IS_ERR_OR_NULL(light->v4l2_flash)) {
> > -   ret = PTR_ERR(light->v4l2_flash);
> > -   goto out_free;
> > -   }
> > +   _flash_ops, _cfg);
> > +   if (IS_ERR_OR_NULL(light->v4l2_flash))
> 
> Just IS_ERR since v4l2_flash_init() never returns NULL.

Will fix.

> 
> > +   return PTR_ERR(light->v4l2_flash);
> >  
> > -   return ret;
> > -
> > -out_free:
> > -   kfree(sd_cfg);
> > -   return ret;
> > +   return 0;
> >  }
> >  
> >  static void gb_lights_light_v4l2_unregister(struct gb_light *light)
> > 
> 
> After those two changes:
> 
> Acked-by: Hans Verkuil 

-- 
Regards,

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

[PATCH] staging: media: atomisp: Add blank line after variable declarations.

[Harold Gomez]

This patch fixes the checkpatch.pl warning

WARNING: Missing a blank line after declarations
+   int i;
+   dev_dbg(>dev, "Dump registers for context[%d]:\n",
context)

WARNING: Missing a blank line after declarations
+   int ret;
+   ret = request_firmware(>fw, "ap1302_fw.bin", >dev);

WARNING: Missing a blank line after declarations
+   u32 sub_len;
+   for (pos = 0; pos < len; pos += sub_len) {

WARNING: Missing a blank line after declarations
+   struct ap1302_device *dev = to_ap1302_device(sd);
+   return dev->cur_context;

WARNING: Missing a blank line after declarations
+   enum ap1302_contexts context, main_context;
+   if (format->pad)

WARNING: Missing a blank line after declarations
+   long ret = 0;
+   switch (cmd) {

Signed-off-by: Harold Gomez 
---
 drivers/staging/media/atomisp/i2c/ap1302.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/staging/media/atomisp/i2c/ap1302.c 
b/drivers/staging/media/atomisp/i2c/ap1302.c
index fba4f96..3e229ba 100644
--- a/drivers/staging/media/atomisp/i2c/ap1302.c
+++ b/drivers/staging/media/atomisp/i2c/ap1302.c
@@ -275,6 +275,7 @@ static int ap1302_write_context_reg(struct v4l2_subdev *sd,
 {
struct ap1302_device *dev = to_ap1302_device(sd);
u16 reg_addr = ap1302_calculate_context_reg_addr(context, offset);
+
if (reg_addr == 0)
return -EINVAL;
return ap1302_i2c_write_reg(sd, reg_addr, len,
@@ -287,6 +288,7 @@ static int ap1302_dump_context_reg(struct v4l2_subdev *sd,
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct ap1302_device *dev = to_ap1302_device(sd);
int i;
+
dev_dbg(>dev, "Dump registers for context[%d]:\n", context);
for (i = 0; i < ARRAY_SIZE(context_info); i++) {
struct ap1302_context_info *info = _info[i];
@@ -311,6 +313,7 @@ static int ap1302_request_firmware(struct v4l2_subdev *sd)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct ap1302_device *dev = to_ap1302_device(sd);
int ret;
+
ret = request_firmware(>fw, "ap1302_fw.bin", >dev);
if (ret)
dev_err(>dev,
@@ -539,6 +542,7 @@ static int ap1302_s_config(struct v4l2_subdev *sd, void 
*pdata)
 static enum ap1302_contexts ap1302_get_context(struct v4l2_subdev *sd)
 {
struct ap1302_device *dev = to_ap1302_device(sd);
+
return dev->cur_context;
 }
 
@@ -641,6 +645,7 @@ static int ap1302_set_fmt(struct v4l2_subdev *sd,
struct atomisp_input_stream_info *stream_info =
(struct atomisp_input_stream_info *)fmt->reserved;
enum ap1302_contexts context, main_context;
+
if (format->pad)
return -EINVAL;
if (!fmt)
@@ -1003,6 +1008,7 @@ static int ap1302_s_register(struct v4l2_subdev *sd,
 static long ap1302_ioctl(struct v4l2_subdev *sd, unsigned int cmd, void *arg)
 {
long ret = 0;
+
switch (cmd) {
case VIDIOC_DBG_G_REGISTER:
ret = ap1302_g_register(sd, arg);
-- 
2.1.4

Re: [PATCH 04/12] [media] V4L2: platform: rcar_jpu: constify v4l2_m2m_ops structures

[Mikhail Ulyanov]

On Sun, Aug 6, 2017 at 11:25 AM, Julia Lawall  wrote:
> The v4l2_m2m_ops structures are only passed as the only
> argument to v4l2_m2m_init, which is declared as const.
> Thus the v4l2_m2m_ops structures themselves can be const.
>
> Done with the help of Coccinelle.
>
> // 
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct v4l2_m2m_ops i@p = { ... };
>
> @ok1@
> identifier r.i;
> position p;
> @@
> v4l2_m2m_init(@p)
>
> @bad@
> position p != {r.p,ok1.p};
> identifier r.i;
> struct v4l2_m2m_ops e;
> @@
> e@i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> static
> +const
>  struct v4l2_m2m_ops i = { ... };
> // 
>
> Signed-off-by: Julia Lawall 

Acked-by: Ulyanov Mikhail 

Re: [PATCH v2 2/3] v4l2-flash-led-class: Create separate sub-devices for indicators

[Hans Verkuil]

On 09/08/17 13:15, Sakari Ailus wrote:
> The V4L2 flash interface allows controlling multiple LEDs through a single
> sub-devices if, and only if, these LEDs are of different types. This
> approach scales badly for flash controllers that drive multiple flash LEDs
> or for LED specific associations. Essentially, the original assumption of a
> LED driver chip that drives a single flash LED and an indicator LED is no
> longer valid.
> 
> Address the matter by registering one sub-device per LED.
> 
> Signed-off-by: Sakari Ailus 
> Reviewed-by: Jacek Anaszewski 
> Acked-by: Pavel Machek 

Looks good, but I have the same comment about using '= {};' to zero a struct and
the use of IS_ERR instead of IS_ERR_OR_NULL for the return value check of
v4l2_flash_init as in the 1/3 patch.

After updating that you can add my:

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/leds/leds-aat1290.c|   4 +-
>  drivers/leds/leds-max77693.c   |   4 +-
>  drivers/media/v4l2-core/v4l2-flash-led-class.c | 113 
> +++--
>  drivers/staging/greybus/light.c|  23 +++--
>  include/media/v4l2-flash-led-class.h   |  41 ++---
>  5 files changed, 117 insertions(+), 68 deletions(-)
> 
> diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c
> index a21e19297745..424898e6c69d 100644
> --- a/drivers/leds/leds-aat1290.c
> +++ b/drivers/leds/leds-aat1290.c
> @@ -432,7 +432,7 @@ static void aat1290_init_v4l2_flash_config(struct 
> aat1290_led *led,
>   strlcpy(v4l2_sd_cfg->dev_name, led_cdev->name,
>   sizeof(v4l2_sd_cfg->dev_name));
>  
> - s = _sd_cfg->torch_intensity;
> + s = _sd_cfg->intensity;
>   s->min = led->mm_current_scale[0];
>   s->max = led_cfg->max_mm_current;
>   s->step = 1;
> @@ -504,7 +504,7 @@ static int aat1290_led_probe(struct platform_device *pdev)
>  
>   /* Create V4L2 Flash subdev. */
>   led->v4l2_flash = v4l2_flash_init(dev, of_fwnode_handle(sub_node),
> -   fled_cdev, NULL, _flash_ops,
> +   fled_cdev, _flash_ops,
> _sd_cfg);
>   if (IS_ERR(led->v4l2_flash)) {
>   ret = PTR_ERR(led->v4l2_flash);
> diff --git a/drivers/leds/leds-max77693.c b/drivers/leds/leds-max77693.c
> index 2d3062d53325..adf0f191f794 100644
> --- a/drivers/leds/leds-max77693.c
> +++ b/drivers/leds/leds-max77693.c
> @@ -856,7 +856,7 @@ static void max77693_init_v4l2_flash_config(struct 
> max77693_sub_led *sub_led,
>"%s %d-%04x", sub_led->fled_cdev.led_cdev.name,
>i2c_adapter_id(i2c->adapter), i2c->addr);
>  
> - s = _sd_cfg->torch_intensity;
> + s = _sd_cfg->intensity;
>   s->min = TORCH_IOUT_MIN;
>   s->max = sub_led->fled_cdev.led_cdev.max_brightness * TORCH_IOUT_STEP;
>   s->step = TORCH_IOUT_STEP;
> @@ -931,7 +931,7 @@ static int max77693_register_led(struct max77693_sub_led 
> *sub_led,
>  
>   /* Register in the V4L2 subsystem. */
>   sub_led->v4l2_flash = v4l2_flash_init(dev, of_fwnode_handle(sub_node),
> -   fled_cdev, NULL, _flash_ops,
> +   fled_cdev, _flash_ops,
> _sd_cfg);
>   if (IS_ERR(sub_led->v4l2_flash)) {
>   ret = PTR_ERR(sub_led->v4l2_flash);
> diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c 
> b/drivers/media/v4l2-core/v4l2-flash-led-class.c
> index aabc85dbb8b5..4ceef217de83 100644
> --- a/drivers/media/v4l2-core/v4l2-flash-led-class.c
> +++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c
> @@ -197,7 +197,7 @@ static int v4l2_flash_s_ctrl(struct v4l2_ctrl *c)
>  {
>   struct v4l2_flash *v4l2_flash = v4l2_ctrl_to_v4l2_flash(c);
>   struct led_classdev_flash *fled_cdev = v4l2_flash->fled_cdev;
> - struct led_classdev *led_cdev = _cdev->led_cdev;
> + struct led_classdev *led_cdev = fled_cdev ? _cdev->led_cdev : NULL;
>   struct v4l2_ctrl **ctrls = v4l2_flash->ctrls;
>   bool external_strobe;
>   int ret = 0;
> @@ -299,10 +299,26 @@ static void __fill_ctrl_init_data(struct v4l2_flash 
> *v4l2_flash,
> struct v4l2_flash_ctrl_data *ctrl_init_data)
>  {
>   struct led_classdev_flash *fled_cdev = v4l2_flash->fled_cdev;
> - struct led_classdev *led_cdev = _cdev->led_cdev;
> + struct led_classdev *led_cdev = fled_cdev ? _cdev->led_cdev : NULL;
>   struct v4l2_ctrl_config *ctrl_cfg;
>   u32 mask;
>  
> + /* Init INDICATOR_INTENSITY ctrl data */
> + if (v4l2_flash->iled_cdev) {
> + ctrl_init_data[INDICATOR_INTENSITY].cid =
> + V4L2_CID_FLASH_INDICATOR_INTENSITY;
> + ctrl_cfg = _init_data[INDICATOR_INTENSITY].config;
> 

Re: [PATCH v2 3/3] v4l2-flash-led-class: Document v4l2_flash_init() references

[Hans Verkuil]

On 09/08/17 13:15, Sakari Ailus wrote:
> The v4l2_flash_init() keeps a reference to the ops struct but not to the
> config struct (nor anything it contains). Document this.
> 
> Signed-off-by: Sakari Ailus 
> Acked-by: Pavel Machek 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  include/media/v4l2-flash-led-class.h | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/include/media/v4l2-flash-led-class.h 
> b/include/media/v4l2-flash-led-class.h
> index c3f39992f3fa..6f4825b6a352 100644
> --- a/include/media/v4l2-flash-led-class.h
> +++ b/include/media/v4l2-flash-led-class.h
> @@ -112,6 +112,9 @@ static inline struct v4l2_flash 
> *v4l2_ctrl_to_v4l2_flash(struct v4l2_ctrl *c)
>   * @config:  initialization data for V4L2 Flash sub-device
>   *
>   * Create V4L2 Flash sub-device wrapping given LED subsystem device.
> + * The ops pointer is stored by the V4L2 flash framework. No
> + * references are held to config nor its contents once this function
> + * has returned.
>   *
>   * Returns: A valid pointer, or, when an error occurs, the return
>   * value is encoded using ERR_PTR(). Use IS_ERR() to check and
> @@ -130,6 +133,9 @@ struct v4l2_flash *v4l2_flash_init(
>   * @config:  initialization data for V4L2 Flash sub-device
>   *
>   * Create V4L2 Flash sub-device wrapping given LED subsystem device.
> + * The ops pointer is stored by the V4L2 flash framework. No
> + * references are held to config nor its contents once this function
> + * has returned.
>   *
>   * Returns: A valid pointer, or, when an error occurs, the return
>   * value is encoded using ERR_PTR(). Use IS_ERR() to check and
> 

Re: [PATCH v2 1/3] staging: greybus: light: fix memory leak in v4l2 register

[Hans Verkuil]

On 10/08/17 15:02, Hans Verkuil wrote:
> On 09/08/17 13:15, Sakari Ailus wrote:
>> From: Rui Miguel Silva 
>>
>> We are allocating memory for the v4l2 flash configuration structure and
>> leak it in the normal path. Just use the stack for this as we do not
>> use it outside of this function.
> 
> I'm not sure why this is part of this patch series. This is a greybus
> bug fix, right? And independent from the other two patches.

Ah, I see. The second patch sits on top of this change. Sorry, I was a bit
too quick there.

Hans

> 
>>
>> Fixes: 2870b52bae4c ("greybus: lights: add lights implementation")
>> Reported-by: Sakari Ailus 
>> Signed-off-by: Rui Miguel Silva 
>> Reviewed-by: Viresh Kumar 
>> ---
>>  drivers/staging/greybus/light.c | 29 +
>>  1 file changed, 9 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/staging/greybus/light.c 
>> b/drivers/staging/greybus/light.c
>> index 129ceed39829..0771db418f84 100644
>> --- a/drivers/staging/greybus/light.c
>> +++ b/drivers/staging/greybus/light.c
>> @@ -534,25 +534,20 @@ static int gb_lights_light_v4l2_register(struct 
>> gb_light *light)
>>  {
>>  struct gb_connection *connection = get_conn_from_light(light);
>>  struct device *dev = >bundle->dev;
>> -struct v4l2_flash_config *sd_cfg;
>> +struct v4l2_flash_config sd_cfg = { {0} };
> 
> Just use '= {};'
> 
>>  struct led_classdev_flash *fled;
>>  struct led_classdev *iled = NULL;
>>  struct gb_channel *channel_torch, *channel_ind, *channel_flash;
>> -int ret = 0;
>> -
>> -sd_cfg = kcalloc(1, sizeof(*sd_cfg), GFP_KERNEL);
>> -if (!sd_cfg)
>> -return -ENOMEM;
>>  
>>  channel_torch = get_channel_from_mode(light, GB_CHANNEL_MODE_TORCH);
>>  if (channel_torch)
>>  __gb_lights_channel_v4l2_config(_torch->intensity_uA,
>> -_cfg->torch_intensity);
>> +_cfg.torch_intensity);
>>  
>>  channel_ind = get_channel_from_mode(light, GB_CHANNEL_MODE_INDICATOR);
>>  if (channel_ind) {
>>  __gb_lights_channel_v4l2_config(_ind->intensity_uA,
>> -_cfg->indicator_intensity);
>> +_cfg.indicator_intensity);
>>  iled = _ind->fled.led_cdev;
>>  }
>>  
>> @@ -561,27 +556,21 @@ static int gb_lights_light_v4l2_register(struct 
>> gb_light *light)
>>  
>>  fled = _flash->fled;
>>  
>> -snprintf(sd_cfg->dev_name, sizeof(sd_cfg->dev_name), "%s", light->name);
>> +snprintf(sd_cfg.dev_name, sizeof(sd_cfg.dev_name), "%s", light->name);
>>  
>>  /* Set the possible values to faults, in our case all faults */
>> -sd_cfg->flash_faults = LED_FAULT_OVER_VOLTAGE | LED_FAULT_TIMEOUT |
>> +sd_cfg.flash_faults = LED_FAULT_OVER_VOLTAGE | LED_FAULT_TIMEOUT |
>>  LED_FAULT_OVER_TEMPERATURE | LED_FAULT_SHORT_CIRCUIT |
>>  LED_FAULT_OVER_CURRENT | LED_FAULT_INDICATOR |
>>  LED_FAULT_UNDER_VOLTAGE | LED_FAULT_INPUT_VOLTAGE |
>>  LED_FAULT_LED_OVER_TEMPERATURE;
>>  
>>  light->v4l2_flash = v4l2_flash_init(dev, NULL, fled, iled,
>> -_flash_ops, sd_cfg);
>> -if (IS_ERR_OR_NULL(light->v4l2_flash)) {
>> -ret = PTR_ERR(light->v4l2_flash);
>> -goto out_free;
>> -}
>> +_flash_ops, _cfg);
>> +if (IS_ERR_OR_NULL(light->v4l2_flash))
> 
> Just IS_ERR since v4l2_flash_init() never returns NULL.
> 
>> +return PTR_ERR(light->v4l2_flash);
>>  
>> -return ret;
>> -
>> -out_free:
>> -kfree(sd_cfg);
>> -return ret;
>> +return 0;
>>  }
>>  
>>  static void gb_lights_light_v4l2_unregister(struct gb_light *light)
>>
> 
> After those two changes:
> 
> Acked-by: Hans Verkuil 
> 
> Regards,
> 
>   Hans
> 

[PATCH] media:atomisp:ap1302 Fix style warning

[Harold Gomez]

Add a blank line after declarations
to avoid checkpatch.pl script warning

Signed-off-by: Harold Gomez 
---
 drivers/staging/media/atomisp/i2c/ap1302.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/atomisp/i2c/ap1302.c 
b/drivers/staging/media/atomisp/i2c/ap1302.c
index 7a0c0d5..fba4f96 100644
--- a/drivers/staging/media/atomisp/i2c/ap1302.c
+++ b/drivers/staging/media/atomisp/i2c/ap1302.c
@@ -263,6 +263,7 @@ static int ap1302_read_context_reg(struct v4l2_subdev *sd,
 {
struct ap1302_device *dev = to_ap1302_device(sd);
u16 reg_addr = ap1302_calculate_context_reg_addr(context, offset);
+
if (reg_addr == 0)
return -EINVAL;
return ap1302_i2c_read_reg(sd, reg_addr, len,
-- 
2.1.4

Re: [PATCH] Subject:staging:media:atomisp:ap1302: fix comments style

[Sakari Ailus]

On Thu, Aug 10, 2017 at 05:57:35PM +0530, Harold Gomez wrote:
> fix comment style Warning in ap1302.c
> fix WARNING on Block comments use * on subsequent lines
> 
> Signed-off-by: Harold Gomez 

If you're making a number of trivial cleanups to a single driver, please
submit them as a single patch instead. And do continue paying attention to
commit message subject and body.

Thanks.

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

Re: [PATCH v2 1/3] staging: greybus: light: fix memory leak in v4l2 register

[Hans Verkuil]

On 09/08/17 13:15, Sakari Ailus wrote:
> From: Rui Miguel Silva 
> 
> We are allocating memory for the v4l2 flash configuration structure and
> leak it in the normal path. Just use the stack for this as we do not
> use it outside of this function.

I'm not sure why this is part of this patch series. This is a greybus
bug fix, right? And independent from the other two patches.

> 
> Fixes: 2870b52bae4c ("greybus: lights: add lights implementation")
> Reported-by: Sakari Ailus 
> Signed-off-by: Rui Miguel Silva 
> Reviewed-by: Viresh Kumar 
> ---
>  drivers/staging/greybus/light.c | 29 +
>  1 file changed, 9 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c
> index 129ceed39829..0771db418f84 100644
> --- a/drivers/staging/greybus/light.c
> +++ b/drivers/staging/greybus/light.c
> @@ -534,25 +534,20 @@ static int gb_lights_light_v4l2_register(struct 
> gb_light *light)
>  {
>   struct gb_connection *connection = get_conn_from_light(light);
>   struct device *dev = >bundle->dev;
> - struct v4l2_flash_config *sd_cfg;
> + struct v4l2_flash_config sd_cfg = { {0} };

Just use '= {};'

>   struct led_classdev_flash *fled;
>   struct led_classdev *iled = NULL;
>   struct gb_channel *channel_torch, *channel_ind, *channel_flash;
> - int ret = 0;
> -
> - sd_cfg = kcalloc(1, sizeof(*sd_cfg), GFP_KERNEL);
> - if (!sd_cfg)
> - return -ENOMEM;
>  
>   channel_torch = get_channel_from_mode(light, GB_CHANNEL_MODE_TORCH);
>   if (channel_torch)
>   __gb_lights_channel_v4l2_config(_torch->intensity_uA,
> - _cfg->torch_intensity);
> + _cfg.torch_intensity);
>  
>   channel_ind = get_channel_from_mode(light, GB_CHANNEL_MODE_INDICATOR);
>   if (channel_ind) {
>   __gb_lights_channel_v4l2_config(_ind->intensity_uA,
> - _cfg->indicator_intensity);
> + _cfg.indicator_intensity);
>   iled = _ind->fled.led_cdev;
>   }
>  
> @@ -561,27 +556,21 @@ static int gb_lights_light_v4l2_register(struct 
> gb_light *light)
>  
>   fled = _flash->fled;
>  
> - snprintf(sd_cfg->dev_name, sizeof(sd_cfg->dev_name), "%s", light->name);
> + snprintf(sd_cfg.dev_name, sizeof(sd_cfg.dev_name), "%s", light->name);
>  
>   /* Set the possible values to faults, in our case all faults */
> - sd_cfg->flash_faults = LED_FAULT_OVER_VOLTAGE | LED_FAULT_TIMEOUT |
> + sd_cfg.flash_faults = LED_FAULT_OVER_VOLTAGE | LED_FAULT_TIMEOUT |
>   LED_FAULT_OVER_TEMPERATURE | LED_FAULT_SHORT_CIRCUIT |
>   LED_FAULT_OVER_CURRENT | LED_FAULT_INDICATOR |
>   LED_FAULT_UNDER_VOLTAGE | LED_FAULT_INPUT_VOLTAGE |
>   LED_FAULT_LED_OVER_TEMPERATURE;
>  
>   light->v4l2_flash = v4l2_flash_init(dev, NULL, fled, iled,
> - _flash_ops, sd_cfg);
> - if (IS_ERR_OR_NULL(light->v4l2_flash)) {
> - ret = PTR_ERR(light->v4l2_flash);
> - goto out_free;
> - }
> + _flash_ops, _cfg);
> + if (IS_ERR_OR_NULL(light->v4l2_flash))

Just IS_ERR since v4l2_flash_init() never returns NULL.

> + return PTR_ERR(light->v4l2_flash);
>  
> - return ret;
> -
> -out_free:
> - kfree(sd_cfg);
> - return ret;
> + return 0;
>  }
>  
>  static void gb_lights_light_v4l2_unregister(struct gb_light *light)
> 

After those two changes:

Acked-by: Hans Verkuil 

Regards,

Hans

[PATCH] media:staging:atomisp:ap1302: Fix comment style

[Harold Gomez]

fix comment style to avoid warning from
checkpatch.pl script

Signed-off-by: Harold Gomez 
---
 drivers/staging/media/atomisp/i2c/ap1302.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/ap1302.c 
b/drivers/staging/media/atomisp/i2c/ap1302.c
index fd0f2ac..7a0c0d5 100644
--- a/drivers/staging/media/atomisp/i2c/ap1302.c
+++ b/drivers/staging/media/atomisp/i2c/ap1302.c
@@ -235,11 +235,14 @@ static u16
 ap1302_calculate_context_reg_addr(enum ap1302_contexts context, u16 offset)
 {
u16 reg_addr;
-   /* The register offset is defined according to preview/video registers.
-  Preview and video context have the same register definition.
-  But snapshot context does not have register S1_SENSOR_MODE.
-  When setting snapshot registers, if the offset exceeds
-  S1_SENSOR_MODE, the actual offset needs to minus 2. */
+   /*
+* The register offset is defined according to preview/video registers.
+* Preview and video context have the same register definition.
+* But snapshot context does not have register S1_SENSOR_MODE.
+* When setting snapshot registers, if the offset exceeds
+* S1_SENSOR_MODE, the actual offset needs to minus 2.
+*
+*/
if (context == CONTEXT_SNAPSHOT) {
if (offset == CNTX_S1_SENSOR_MODE)
return 0;
-- 
2.1.4

[PATCH] staging:media:atomisp: Add blank line after declarations

[Harold Gomez]

Add blank line after declarations
to avoid warning from checkpatch.pl script

Signed-off-by: Harold Gomez 
---
 drivers/staging/media/atomisp/i2c/ap1302.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/atomisp/i2c/ap1302.c 
b/drivers/staging/media/atomisp/i2c/ap1302.c
index 995f243..fd0f2ac 100644
--- a/drivers/staging/media/atomisp/i2c/ap1302.c
+++ b/drivers/staging/media/atomisp/i2c/ap1302.c
@@ -211,6 +211,7 @@ static int ap1302_i2c_write_reg(struct v4l2_subdev *sd,
struct ap1302_device *dev = to_ap1302_device(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
int ret;
+
if (len == AP1302_REG16)
ret = regmap_write(dev->regmap16, reg, val);
else if (len == AP1302_REG32)
-- 
2.1.4

Re: [PATCH] drm/bridge/sii8620: add remote control support

[Maciej Purski]

Hi Hans,

Thank you for your reply.  All dongles that we used to work with in Samsung
convert CEC protocol to RCP which we get through MHL Sideband Channel.
All we can do in the driver is to report RCP messages to user-space.

On the RC subsystem: your point is right, which was confirmed
by Sean and I'm going to use RC subsystem there.

Regards,

Maciej Purski

On 08/03/2017 10:28 AM, Hans Verkuil wrote:


Hi Maciej,

Unfortunately I do not have the MHL spec, but I was wondering what the
relationship between RCP and CEC is. CEC has remote control support as
well, so is RCP that subset of the CEC specification or is it completely
separate?

I'm CC-ing Sean Young and the linux-media mailinglist as well since Sean
maintains the rc subsystem. Which you probably should use, but I'm not the
expert on that.

Regards,

Hans

On 08/03/17 09:44, Maciej Purski wrote:

MHL specification defines Remote Control Protocol(RCP) to
send input events between MHL devices.
The driver now recognizes RCP messages and reacts to them
by reporting key events to input subsystem, allowing
a user to control a device using TV remote control.

Signed-off-by: Maciej Purski 
---
  drivers/gpu/drm/bridge/sil-sii8620.c | 188 ++-
  include/drm/bridge/mhl.h |   4 +
  2 files changed, 187 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 2d51a22..7e75f2f 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -19,6 +19,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -58,6 +59,7 @@ enum sii8620_mt_state {
  struct sii8620 {
struct drm_bridge bridge;
struct device *dev;
+   struct input_dev *rcp_input_dev;
struct clk *clk_xtal;
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_int;
@@ -106,6 +108,82 @@ struct sii8620_mt_msg {
sii8620_cb continuation;
  };
  
+static struct {

+   u16 key;
+   u16 extra_key;
+   bool autorepeat;
+}  rcp_keymap[] = {
+   [0x00] = { KEY_SELECT },
+   [0x01] = { KEY_UP, 0, true },
+   [0x02] = { KEY_DOWN, 0, true },
+   [0x03] = { KEY_LEFT, 0, true },
+   [0x04] = { KEY_RIGHT, 0, true },
+
+   [0x05] = { KEY_RIGHT, KEY_UP, true },
+   [0x06] = { KEY_RIGHT, KEY_DOWN, true },
+   [0x07] = { KEY_LEFT,  KEY_UP, true },
+   [0x08] = { KEY_LEFT,  KEY_DOWN, true },
+
+   [0x09] = { KEY_MENU },
+   [0x0A] = { KEY_UNKNOWN },
+   [0x0B] = { KEY_UNKNOWN },
+   [0x0C] = { KEY_BOOKMARKS },
+   [0x0D] = { KEY_EXIT },
+
+   [0x20] = { KEY_NUMERIC_0 },
+   [0x21] = { KEY_NUMERIC_1 },
+   [0x22] = { KEY_NUMERIC_2 },
+   [0x23] = { KEY_NUMERIC_3 },
+   [0x24] = { KEY_NUMERIC_4 },
+   [0x25] = { KEY_NUMERIC_5 },
+   [0x26] = { KEY_NUMERIC_6 },
+   [0x27] = { KEY_NUMERIC_7 },
+   [0x28] = { KEY_NUMERIC_8 },
+   [0x29] = { KEY_NUMERIC_9 },
+
+   [0x2A] = { KEY_DOT },
+   [0x2B] = { KEY_ENTER },
+   [0x2C] = { KEY_CLEAR },
+
+   [0x30] = { KEY_CHANNELUP, 0, true },
+   [0x31] = { KEY_CHANNELDOWN, 0, true },
+
+   [0x33] = { KEY_SOUND },
+   [0x35] = { KEY_PROGRAM }, /* Show Information */
+
+   [0x37] = { KEY_PAGEUP, 0, true },
+   [0x38] = { KEY_PAGEDOWN, 0, true },
+
+   [0x41] = { KEY_VOLUMEUP, 0, true },
+   [0x42] = { KEY_VOLUMEDOWN, 0, true },
+   [0x43] = { KEY_MUTE },
+   [0x44] = { KEY_PLAY },
+   [0x45] = { KEY_STOP },
+   [0x46] = { KEY_PLAYPAUSE }, /* Pause */
+   [0x47] = { KEY_RECORD },
+   [0x48] = { KEY_REWIND, 0, true },
+   [0x49] = { KEY_FASTFORWARD, 0, true },
+   [0x4A] = { KEY_EJECTCD },
+   [0x4B] = { KEY_NEXTSONG, 0, true }, /* Forward */
+   [0x4C] = { KEY_PREVIOUSSONG, 0, true }, /* Backward */
+
+   [0x60] = { KEY_PLAYPAUSE }, /* Play */
+   [0x61] = { KEY_PLAYPAUSE }, /* Pause the Play */
+   [0x62] = { KEY_RECORD },
+   [0x63] = { KEY_PAUSE },
+   [0x64] = { KEY_STOP },
+   [0x65] = { KEY_MUTE },
+   [0x66] = { KEY_MUTE }, /* Restore Mute */
+
+   [0x71] = { KEY_F1 },
+   [0x72] = { KEY_F2 },
+   [0x73] = { KEY_F3 },
+   [0x74] = { KEY_F4 },
+   [0x75] = { KEY_F5 },
+
+   [0x7E] = { KEY_VENDOR },
+};
+
  static const u8 sii8620_i2c_page[] = {
0x39, /* Main System */
0x3d, /* TDM and HSIC */
@@ -431,6 +509,16 @@ static void sii8620_mt_rap(struct sii8620 *ctx, u8 code)
sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RAP, code);
  }
  
+static void sii8620_mt_rcpk(struct sii8620 *ctx, u8 code)

+{
+   sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPK, code);
+}
+
+static void sii8620_mt_rcpe(struct sii8620 *ctx, u8 code)
+{
+   sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPE, code);
+}
+
  static void sii8620_mt_read_devcap_send(struct sii8620 *ctx,
   

[PATCH] Subject:staging:media:atomisp:ap1302: fix comments style

[Harold Gomez]

fix comment style Warning in ap1302.c
fix WARNING on Block comments use * on subsequent lines

Signed-off-by: Harold Gomez 
---
 drivers/staging/media/atomisp/i2c/ap1302.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/i2c/ap1302.c 
b/drivers/staging/media/atomisp/i2c/ap1302.c
index ac1aa96..995f243 100644
--- a/drivers/staging/media/atomisp/i2c/ap1302.c
+++ b/drivers/staging/media/atomisp/i2c/ap1302.c
@@ -157,9 +157,11 @@ static struct ap1302_context_info context_info[] = {
{CNTX_HINF_CTRL, AP1302_REG16, "hinf_ctrl"},
 };
 
-/* This array stores the description list for metadata.
+/*
+ * This array stores the description list for metadata.
  * The metadata contains exposure settings and face
  * detection results.
+ *
  */
 static u16 ap1302_ss_list[] = {
0xb01c, /* From 0x0186 with size 0x1C are exposure settings. */
-- 
2.1.4

[PATCH] [media] staging: atomisp: fix bounds checking in mt9m114_s_exposure_selection()

[Dan Carpenter]

These clamp_t() calls are no-ops because we don't save the results.  It
leads to an array out of bounds bug.

Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/media/atomisp/i2c/mt9m114.c 
b/drivers/staging/media/atomisp/i2c/mt9m114.c
index 448e072ca037..7816bc428641 100644
--- a/drivers/staging/media/atomisp/i2c/mt9m114.c
+++ b/drivers/staging/media/atomisp/i2c/mt9m114.c
@@ -1209,10 +1209,10 @@ static int mt9m114_s_exposure_selection(struct 
v4l2_subdev *sd,
return -EINVAL;
}
 
-   clamp_t(int, win_left, 0, 4);
-   clamp_t(int, win_top, 0, 4);
-   clamp_t(int, win_right, 0, 4);
-   clamp_t(int, win_bottom, 0, 4);
+   win_left   = clamp_t(int, win_left, 0, 4);
+   win_top= clamp_t(int, win_top, 0, 4);
+   win_right  = clamp_t(int, win_right, 0, 4);
+   win_bottom = clamp_t(int, win_bottom, 0, 4);
 
ret = mt9m114_write_reg_array(client, mt9m114_exp_average, NO_POLLING);
if (ret) {

Re: [GIT PULL for 4.14] Stream control documentation

[Hans Verkuil]

Hi Sakari,

My apologies, I should have reviewed this weeks ago. Please ping me next time,
this got buried under all the other patches, even though it was delegated to me.

Anyway, better late than never:

On 09/08/17 17:57, Mauro Carvalho Chehab wrote:
> Em Wed, 9 Aug 2017 12:29:17 -0300
> Mauro Carvalho Chehab  escreveu:
> 
>> Em Wed, 9 Aug 2017 11:03:40 +0300
>> Sakari Ailus  escreveu:
>>
>>> Hi Mauro,
>>>
>>> Add stream control documentation.
>>>
>>> We have recently added support for hardware that makes it possible to have
>>> pipelines that are controlled by more than two drivers. This necessitates
>>> documenting V4L2 stream control behaviour for such pipelines.  
>>
>> Perhaps I missed this one, but I'm not seeing any e-mail with
>>  "docs-rst: media: Document s_stream() video op usage"
>>
>> Please always submit patches via e-mail too, as it makes easier for
>> us to comment/review when needed.
>>
>> In any case, I'm appending the patch contents here. I'll reply to it
>> on a next e-mail.
>>
>>> From ef8e5d20b45b05290c56450d2130a0dc3c021c5a Mon Sep 17 00:00:00 2001
>>> From: Sakari Ailus 
>>> Date: Thu, 9 Mar 2017 15:07:57 +0200
>>> Subject: docs-rst: media: Document s_stream() video op usage
>>> MIME-Version: 1.0
>>> Content-Type: text/plain; charset=UTF-8
>>> Content-Transfer-Encoding: 8bit
>>> Cc: Linux Media Mailing List ,
>>> Mauro Carvalho Chehab 
>>>
>>> As we begin to add support for systems with media pipelines controlled by
>>> more than one device driver, it is essential that we precisely define the
>>> responsibilities of each component in the stream control and common
>>> practices.
> 
> Not sure what you meant here. Currently, there is support already
> for multiple subdevs attached to a driver.
> 
> As we're talking here about kAPI, it is quite common that a V4L2 the
> need to set multiple devices while stream. A typical non-MC device like
> bttv can set up to 4 types of devices:
>   - tuner;
>   - audio decoder;
>   - video decoder;
>   - video enhancers.

I agree. The document *only* applies to MC-controlled pipelines and that
should be made clear.

> 
>>> Specifically, this patch documents two things:
>>>
>>> 1) streaming control is done per sub-device and sub-device drivers
>>> themselves are responsible for streaming setup in upstream sub-devices and
> 
> In the case of non-MC devices, it is the bridge driver that it is
> responsible to pass a "broadcast" message to all subdevices for
> them to be at "stream mode".

Indeed.

> 
>>>
>>> 2) broken frames should be tolerated at streaming stop. It is the
>>> responsibility of the sub-device driver to stop the transmitter after
>>> itself if it cannot handle broken frames (and it should be probably be
>>> done anyway).
> 
> You should define what you mean by "transmitter".

Please note that partial/broken frames can *also* happen at streaming *start*,
especially HDMI receivers often do that. And especially in the case of HDMI
(also DVI, VGA, etc) you can get frames that are too long or too short.

Particularly too long frames can be a nightmare (happens when due to a 
pin-bounce
when connecting an HDMI device the receiver misses the v-sync and so the frame
is suddenly twice the normal height). And yes, this really can happen.

> 
>>>
>>> Signed-off-by: Sakari Ailus 
>>> Acked-by: Niklas Söderlund 
>>> ---
>>>  Documentation/media/kapi/v4l2-subdev.rst | 36 
>>> 
>>>  1 file changed, 36 insertions(+)
>>>
>>> diff --git a/Documentation/media/kapi/v4l2-subdev.rst 
>>> b/Documentation/media/kapi/v4l2-subdev.rst
>>> index e1f0b726e438..100ffc783f72 100644
>>> --- a/Documentation/media/kapi/v4l2-subdev.rst
>>> +++ b/Documentation/media/kapi/v4l2-subdev.rst
>>> @@ -262,6 +262,42 @@ 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.
>>>  
>>> +Streaming control
>>> +^
>>> +
>>> +Starting and stopping the stream are somewhat complex operations that
>>> +often require walking the media graph to enable streaming on
>>> +sub-devices which the pipeline consists of. This involves interaction
>>> +between multiple drivers, sometimes more than two.
>>> +
>>> +The ``.s_stream()`` op in :c:type:`v4l2_subdev_video_ops` is responsible
>>> +for starting and stopping the stream on the sub-device it is called on.
>>> +Additionally, if there are sub-devices further up in the pipeline, i.e.
>>> +connected to that sub-device's sink pads through enabled links, the
>>> +sub-device driver must call the ``.s_stream()`` video op of all such
>>> +sub-devices.

I think you mean that it calls s_stream for the immediately connected subdevs,
not 

Re: [PATCH] Subject:drivers:staging:media:atomisp:

[Sakari Ailus]

Hi Harold,

Please use a better subject line.

On Thu, Aug 10, 2017 at 03:08:26PM +0530, Harold Gomez wrote:
> Fix Warning from checkpatch.pl 
> Block comments use * on subsequent lines
> 
> Signed-off-by: Harold Gomez 
> ---
>  drivers/staging/media/atomisp/i2c/ap1302.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/media/atomisp/i2c/ap1302.c 
> b/drivers/staging/media/atomisp/i2c/ap1302.c
> index 9d6ce36..ac1aa96 100644
> --- a/drivers/staging/media/atomisp/i2c/ap1302.c
> +++ b/drivers/staging/media/atomisp/i2c/ap1302.c
> @@ -158,8 +158,9 @@ static struct ap1302_context_info context_info[] = {
>  };
>  
>  /* This array stores the description list for metadata.
> -   The metadata contains exposure settings and face
> -   detection results. */
> + * The metadata contains exposure settings and face
> + * detection results.
> + */

/*
 * Multi-line comments
 * look like this.
 */

>  static u16 ap1302_ss_list[] = {
>   0xb01c, /* From 0x0186 with size 0x1C are exposure settings. */
>   0x0186,
> -- 
> 2.1.4
> 

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

Re: [PATCH 2/2] cec: fix remote control passthrough

[Hans Verkuil]

On 09/08/17 23:17, Sean Young wrote:
> On Tue, Aug 08, 2017 at 10:11:13AM +0200, Hans Verkuil wrote:
>> On 07/08/17 22:58, Sean Young wrote:
>>> On Mon, Aug 07, 2017 at 03:31:24PM +0200, Hans Verkuil wrote:
 From: Hans Verkuil 

 The 'Press and Hold' operation was not correctly implemented, in
 particular the requirement that the repeat doesn't start until
 the second identical keypress arrives. The REP_DELAY value also
 had to be adjusted (see the comment in the code) to achieve the
 desired behavior.
>>>
>>> I'm afraid I've caused some confusion; I had not read your last message
>>> about autorepeat on irc correctly, when I said "exactly".
>>>
>>> So if the input layer has not received a key up event after a key down
>>> event, after REP_DELAY it will generate another key down event every
>>> REP_PERIOD. So for example, here I'm holding a button on a rc-5 device
>>> for some time. Comments on lines with parentheses.
>>>
>>> # ir-keytable -t
>>> Testing events. Please, press CTRL-C to abort.
>>> 1502138577.703695: event type EV_MSC(0x04): scancode = 0x1e11
>>> (each time a driver receives something, scancode is reported.)
>>> 1502138577.703695: event type EV_KEY(0x01) key_down: KEY_VOLUMEDOWN(0x0072)
>>> 1502138577.703695: event type EV_SYN(0x00).
>>> 1502138577.817682: event type EV_MSC(0x04): scancode = 0x1e11
>>> 1502138577.817682: event type EV_SYN(0x00).
>>> (rc-5 repeats the command after 115ms).
>>> 1502138577.930676: event type EV_MSC(0x04): scancode = 0x1e11
>>> 1502138577.930676: event type EV_SYN(0x00).
>>> 1502138578.044682: event type EV_MSC(0x04): scancode = 0x1e11
>>> 1502138578.044682: event type EV_SYN(0x00).
>>> 1502138578.181690: event type EV_MSC(0x04): scancode = 0x1e11
>>> 1502138578.181690: event type EV_SYN(0x00).
>>> 1502138578.205667: event type EV_KEY(0x01) key_down: KEY_VOLUMEDOWN(0x0072)
>>> (this is 500ms after the initial key down, so this key down is generated
>>> by the input layer).
>>> 1502138578.205667: event type EV_SYN(0x00).
>>> 1502138578.333667: event type EV_KEY(0x01) key_down: KEY_VOLUMEDOWN(0x0072)
>>> (this is 500 + 125 ms, so another key down event generated by input layer).
>>> 1502138578.333667: event type EV_SYN(0x00).
>>> 1502138578.437662: event type EV_KEY(0x01) key_up: KEY_VOLUMEDOWN(0x0072)
>>> 1502138578.437662: event type EV_SYN(0x00).
>>> (key up generated by rc-core after 250ms after last scancode received)
>>>
>>> So I think the autorepeat can do exactly what you want, without cec
>>> having any special code for it.
>>
>> It comes close, but not quite, to what I need. It has more to do with the
>> CEC peculiarities than the rc code.
>>
>> Specifically the CEC spec strongly recommends that the first reported key
>> press is always handled as a single non-repeating key press. Only if a second
>> identical key press is received within 550 ms will the 'Press and Hold' 
>> feature
>> kick in and will the key start repeating. This until a Release message is
>> received, a different key press is received or nothing is received for 550 
>> ms.
> 
> Right, that make sense.
> 
>> Effectively the REP_DELAY is equal to the time between the first and second
>> key press message, and it immediately switches to repeat mode once the second
>> key press is received.
>>
>> This code models this behavior exactly.
> 
> Ok, although you're sending a keyup directly after the first keydown.

Yes, that's to prevent it from going into repeat mode. It shouldn't for
the first CEC key press message. Remember that CEC is slow, so it may
well take 500ms before you get the next message. And if REP_DELAY < 500ms
it will already start repeating which is not what you want for the first
key press. Calling keyup immediately will prevent this from happening.

> Another way of doing this is to set REP_DELAY/REP_PERIOD to 0 and
> sending the repeats yourself.

No, because you want the user to be able to influence the repeat speed.
And the repeat speed is supposed to be that of linux, the repeated CEC
messages are just to tell linux that it has to remain in key repeating
mode. I.e. if you receive 5 CEC messages while in Press and Hold mode,
then that can translate to 20 actual repeats (depending on the REP_PERIOD).

Besides, I don't want to have to write the timer code to repeat the keys
myself, after all, it's already there.

Regards,

Hans

> 
> I'm not sure it's worth it just to prevent the keyup.
> 
> 
> Sean
> 
>>
>> Regards,
>>
>>  Hans
>>
>>>
>>> On a side note, here you can see that for rc-5 the IR_KEYPRESS_TIMEOUT
>>> should be 115ms (with a little extra margin). 
>>>
>>> My apologies.
>>>
>>> Sean
>>>

 The 'enabled_protocols' field was also never set, fix that too. Since
 CEC is a fixed protocol the driver has to set this field.

 Signed-off-by: Hans Verkuil 
 ---
  drivers/media/cec/cec-adap.c | 56 
 
  

Re: [PATCH 0/4] drm/bridge/adv7511: add CEC support

[Hans Verkuil]

On 10/08/17 11:08, Archit Taneja wrote:
> 
> 
> On 08/10/2017 02:26 PM, Hans Verkuil wrote:
>> On 10/08/17 10:49, Archit Taneja wrote:
>>> Hi Hans,
>>>
>>> On 07/30/2017 06:37 PM, Hans Verkuil wrote:
 From: Hans Verkuil 

 This patch series adds CEC support to the drm adv7511/adv7533 drivers.

 I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
 and the Renesas R-Car Koelsch board (adv7511 based).

 Note: the Dragonboard needs this patch:

 https://patchwork.kernel.org/patch/9824773/

 Archit, can you confirm that this patch will go to kernel 4.14?

 And the Koelsch board needs this 4.13 fix:

 https://patchwork.kernel.org/patch/9836865/

 I only have the Koelsch board to test with, but it looks like other
 R-Car boards use the same adv7511. It would be nice if someone can
 add CEC support to the other R-Car boards as well. The main thing
 to check is if they all use the same 12 MHz fixed CEC clock source.

 Anyone who wants to test this will need the CEC utilities that
 are part of the v4l-utils git repository:

 git clone git://linuxtv.org/v4l-utils.git
 cd v4l-utils
 ./bootstrap.sh
 ./configure
 make
 sudo make install

 Now configure the CEC adapter as a Playback device:

 cec-ctl --playback

 Discover other CEC devices:

 cec-ctl -S
>>>
>>> I tried the instructions, and I get the following output. I don't think I 
>>> have
>>> any CEC device connected, though. Is this the expected behaviour?
>>>
>>> #cec-ctl -S
>>> Driver Info:
>>>  Driver Name: adv7511
>>>  Adapter Name   : 3-0039
>>>  Capabilities   : 0x000e
>>>  Logical Addresses
>>>  Transmit
>>>  Passthrough
>>>  Driver version : 4.13.0
>>>  Available Logical Addresses: 3
>>>  Physical Address   : 1.0.0.0
>>>  Logical Address Mask   : 0x
>>>  CEC Version: 2.0
>>>  Logical Addresses  : 0
>>>
>>> #cec-ctl --playback
>>> [ 1038.761545] cec-3-0039: cec_thread_func: message 44 timed out!
>>
>> This isn't right. You shouldn't see this. It never receives an interrupt
>> when the transmit has finished, which causes these time outs.
>>
>> What are you testing this on? The Dragonboard c410?
> 
> Yes.

On top of which kernel tree are these patches applied? I can try and reproduce
it.

Regards,

Hans

[PATCH] Subject:drivers:staging:media:atomisp:

[Harold Gomez]

Fix Warning from checkpatch.pl 
Block comments use * on subsequent lines

Signed-off-by: Harold Gomez 
---
 drivers/staging/media/atomisp/i2c/ap1302.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/ap1302.c 
b/drivers/staging/media/atomisp/i2c/ap1302.c
index 9d6ce36..ac1aa96 100644
--- a/drivers/staging/media/atomisp/i2c/ap1302.c
+++ b/drivers/staging/media/atomisp/i2c/ap1302.c
@@ -158,8 +158,9 @@ static struct ap1302_context_info context_info[] = {
 };
 
 /* This array stores the description list for metadata.
-   The metadata contains exposure settings and face
-   detection results. */
+ * The metadata contains exposure settings and face
+ * detection results.
+ */
 static u16 ap1302_ss_list[] = {
0xb01c, /* From 0x0186 with size 0x1C are exposure settings. */
0x0186,
-- 
2.1.4

[PATCH 2/2] media: ov7670: Add the s_power operation

[Wenyou Yang]

Add the s_power operation which is responsible for manipulating the
power dowm mode through the PWDN pin and the reset operation through
the RESET pin.

Signed-off-by: Wenyou Yang 
---

 drivers/media/i2c/ov7670.c | 30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 5c8460ee65c3..5ed79ccfaf91 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1506,6 +1506,22 @@ static int ov7670_s_register(struct v4l2_subdev *sd, 
const struct v4l2_dbg_regis
 }
 #endif
 
+static int ov7670_s_power(struct v4l2_subdev *sd, int on)
+{
+   struct ov7670_info *info = to_state(sd);
+
+   if (info->pwdn_gpio)
+   gpiod_direction_output(info->pwdn_gpio, !on);
+   if (on && info->resetb_gpio) {
+   gpiod_set_value(info->resetb_gpio, 1);
+   usleep_range(500, 1000);
+   gpiod_set_value(info->resetb_gpio, 0);
+   usleep_range(3000, 5000);
+   }
+
+   return 0;
+}
+
 /* --- */
 
 static const struct v4l2_subdev_core_ops ov7670_core_ops = {
@@ -1515,6 +1531,7 @@ static const struct v4l2_subdev_core_ops ov7670_core_ops 
= {
.g_register = ov7670_g_register,
.s_register = ov7670_s_register,
 #endif
+   .s_power = ov7670_s_power,
 };
 
 static const struct v4l2_subdev_video_ops ov7670_video_ops = {
@@ -1568,8 +1585,6 @@ static int ov7670_init_gpio(struct i2c_client *client, 
struct ov7670_info *info)
return PTR_ERR(info->resetb_gpio);
}
 
-   usleep_range(3000, 5000);
-
return 0;
 }
 
@@ -1630,13 +1645,19 @@ static int ov7670_probe(struct i2c_client *client,
goto clk_disable;
}
 
+   ret = ov7670_init_gpio(client, info);
+   if (ret)
+   goto clk_disable;
+
+   ov7670_s_power(sd, 1);
+
/* Make sure it's an ov7670 */
ret = ov7670_detect(sd);
if (ret) {
v4l_dbg(1, debug, client,
"chip found @ 0x%x (%s) is not an ov7670 chip.\n",
client->addr << 1, client->adapter->name);
-   goto clk_disable;
+   goto power_off;
}
v4l_info(client, "chip found @ 0x%02x (%s)\n",
client->addr << 1, client->adapter->name);
@@ -1708,6 +1729,8 @@ static int ov7670_probe(struct i2c_client *client,
media_entity_cleanup(>sd.entity);
 hdl_free:
v4l2_ctrl_handler_free(>hdl);
+power_off:
+   ov7670_s_power(sd, 0);
 clk_disable:
clk_disable_unprepare(info->clk);
return ret;
@@ -1723,6 +1746,7 @@ static int ov7670_remove(struct i2c_client *client)
v4l2_ctrl_handler_free(>hdl);
clk_disable_unprepare(info->clk);
media_entity_cleanup(>sd.entity);
+   ov7670_s_power(sd, 0);
return 0;
 }
 
-- 
2.13.0

[PATCH 1/2] media: ov7670: Add entity pads initialization

[Wenyou Yang]

Add the media entity pads initialization.

Signed-off-by: Wenyou Yang 
---

 drivers/media/i2c/ov7670.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index e88549f0e704..5c8460ee65c3 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -213,6 +213,7 @@ struct ov7670_devtype {
 struct ov7670_format_struct;  /* coming later */
 struct ov7670_info {
struct v4l2_subdev sd;
+   struct media_pad pad;
struct v4l2_ctrl_handler hdl;
struct {
/* gain cluster */
@@ -1688,14 +1689,23 @@ static int ov7670_probe(struct i2c_client *client,
v4l2_ctrl_auto_cluster(2, >auto_exposure,
   V4L2_EXPOSURE_MANUAL, false);
v4l2_ctrl_cluster(2, >saturation);
+
+   info->pad.flags = MEDIA_PAD_FL_SOURCE;
+   info->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
+   ret = media_entity_pads_init(>sd.entity, 1, >pad);
+   if (ret < 0)
+   goto hdl_free;
+
v4l2_ctrl_handler_setup(>hdl);
 
ret = v4l2_async_register_subdev(>sd);
if (ret < 0)
-   goto hdl_free;
+   goto entity_cleanup;
 
return 0;
 
+entity_cleanup:
+   media_entity_cleanup(>sd.entity);
 hdl_free:
v4l2_ctrl_handler_free(>hdl);
 clk_disable:
@@ -1712,6 +1722,7 @@ static int ov7670_remove(struct i2c_client *client)
v4l2_device_unregister_subdev(sd);
v4l2_ctrl_handler_free(>hdl);
clk_disable_unprepare(info->clk);
+   media_entity_cleanup(>sd.entity);
return 0;
 }
 
-- 
2.13.0

[PATCH 0/2] media: ov7670: Add entity init and power operation

[Wenyou Yang]

This patch set is to add the media entity pads initialization and add
the s_power operation.


Wenyou Yang (2):
  media: ov7670: Add entity pads initialization
  media: ov7670: Add the s_power operation

 drivers/media/i2c/ov7670.c | 43 +++
 1 file changed, 39 insertions(+), 4 deletions(-)

-- 
2.13.0

Re: [PATCH 0/4] drm/bridge/adv7511: add CEC support

[Archit Taneja]

On 08/10/2017 02:26 PM, Hans Verkuil wrote:

On 10/08/17 10:49, Archit Taneja wrote:

Hi Hans,

On 07/30/2017 06:37 PM, Hans Verkuil wrote:

From: Hans Verkuil 

This patch series adds CEC support to the drm adv7511/adv7533 drivers.

I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
and the Renesas R-Car Koelsch board (adv7511 based).

Note: the Dragonboard needs this patch:

https://patchwork.kernel.org/patch/9824773/

Archit, can you confirm that this patch will go to kernel 4.14?

And the Koelsch board needs this 4.13 fix:

https://patchwork.kernel.org/patch/9836865/

I only have the Koelsch board to test with, but it looks like other
R-Car boards use the same adv7511. It would be nice if someone can
add CEC support to the other R-Car boards as well. The main thing
to check is if they all use the same 12 MHz fixed CEC clock source.

Anyone who wants to test this will need the CEC utilities that
are part of the v4l-utils git repository:

git clone git://linuxtv.org/v4l-utils.git
cd v4l-utils
./bootstrap.sh
./configure
make
sudo make install

Now configure the CEC adapter as a Playback device:

cec-ctl --playback

Discover other CEC devices:

cec-ctl -S


I tried the instructions, and I get the following output. I don't think I have
any CEC device connected, though. Is this the expected behaviour?

#cec-ctl -S
Driver Info:
 Driver Name: adv7511
 Adapter Name   : 3-0039
 Capabilities   : 0x000e
 Logical Addresses
 Transmit
 Passthrough
 Driver version : 4.13.0
 Available Logical Addresses: 3
 Physical Address   : 1.0.0.0
 Logical Address Mask   : 0x
 CEC Version: 2.0
 Logical Addresses  : 0

#cec-ctl --playback
[ 1038.761545] cec-3-0039: cec_thread_func: message 44 timed out!


This isn't right. You shouldn't see this. It never receives an interrupt
when the transmit has finished, which causes these time outs.

What are you testing this on? The Dragonboard c410?


Yes.



Can you check the cec clock frequency? It should be 19.2 MHz.
Remember to apply this patch: https://patchwork.kernel.org/patch/9824773/
You probably did, but just in case...


clk_summary does show bb_clk2 to be set to 19.2 Mhz.

I applied a newer version of this patch, which got merged in clk-next:

https://patchwork.kernel.org/patch/9845493/

I will try to apply the patch you use and check again.

Thanks,
Archit



Regards,

Hans


Driver Info:
 Driver Name: adv7511
 Adapter Name   : 3-0039
 Capabilities   : 0x000e
 Logical Addresses
 Transmit
 Passthrough
 Driver version : 4.13.0
 Available Logical Addresses: 3
 Physical Address   : 1.0.0.0
 Logical Address Mask   : 0x0010
 CEC Version: 2.0
 Vendor ID  : 0x000c03
 Logical Addresses  : 1 (Allow RC Passthrough)

   Logical Address  : 4
 Primary Device Type: Playback
 Logical Address Type   : Playback
 All Device Types   : Playback
 RC TV Profile  : None
 Device Features:
 None


[ 1041.063605] cec-3-0039: cec_thread_func: message 4f a6 06 10 00 00 timed out!
[ 1043.367482] cec-3-0039: cec_thread_func: message 4f 84 10 00 04 timed out!

Thanks,
Archit



Regards,

 Hans

Hans Verkuil (4):
dt-bindings: adi,adv7511.txt: document cec clock
arm: dts: qcom: add cec clock for apq8016 board
arm: dts: renesas: add cec clock for Koelsch board
drm: adv7511/33: add HDMI CEC support

   .../bindings/display/bridge/adi,adv7511.txt|   4 +
   arch/arm/boot/dts/r8a7791-koelsch.dts  |   8 +
   arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  |   2 +
   drivers/gpu/drm/bridge/adv7511/Kconfig |   8 +
   drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
   drivers/gpu/drm/bridge/adv7511/adv7511.h   |  45 ++-
   drivers/gpu/drm/bridge/adv7511/adv7511_cec.c   | 314 
+
   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 152 +-
   drivers/gpu/drm/bridge/adv7511/adv7533.c   |  30 +-
   9 files changed, 514 insertions(+), 50 deletions(-)
   create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c





--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] Subject:drivers:staging:media:atomisp:i2c:api1302.c

[Harold Gomez]

Fix Warning Block comments use * on subsequent lines

Signed-off-by: Harold Gomez 
---
 drivers/staging/media/atomisp/i2c/ap1302.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/ap1302.c 
b/drivers/staging/media/atomisp/i2c/ap1302.c
index 9d6ce36..ac1aa96 100644
--- a/drivers/staging/media/atomisp/i2c/ap1302.c
+++ b/drivers/staging/media/atomisp/i2c/ap1302.c
@@ -158,8 +158,9 @@ static struct ap1302_context_info context_info[] = {
 };
 
 /* This array stores the description list for metadata.
-   The metadata contains exposure settings and face
-   detection results. */
+ * The metadata contains exposure settings and face
+ * detection results.
+ */
 static u16 ap1302_ss_list[] = {
0xb01c, /* From 0x0186 with size 0x1C are exposure settings. */
0x0186,
-- 
2.1.4

Re: [PATCH 0/4] drm/bridge/adv7511: add CEC support

[Hans Verkuil]

On 10/08/17 10:49, Archit Taneja wrote:
> Hi Hans,
> 
> On 07/30/2017 06:37 PM, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> This patch series adds CEC support to the drm adv7511/adv7533 drivers.
>>
>> I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
>> and the Renesas R-Car Koelsch board (adv7511 based).
>>
>> Note: the Dragonboard needs this patch:
>>
>> https://patchwork.kernel.org/patch/9824773/
>>
>> Archit, can you confirm that this patch will go to kernel 4.14?
>>
>> And the Koelsch board needs this 4.13 fix:
>>
>> https://patchwork.kernel.org/patch/9836865/
>>
>> I only have the Koelsch board to test with, but it looks like other
>> R-Car boards use the same adv7511. It would be nice if someone can
>> add CEC support to the other R-Car boards as well. The main thing
>> to check is if they all use the same 12 MHz fixed CEC clock source.
>>
>> Anyone who wants to test this will need the CEC utilities that
>> are part of the v4l-utils git repository:
>>
>> git clone git://linuxtv.org/v4l-utils.git
>> cd v4l-utils
>> ./bootstrap.sh
>> ./configure
>> make
>> sudo make install
>>
>> Now configure the CEC adapter as a Playback device:
>>
>> cec-ctl --playback
>>
>> Discover other CEC devices:
>>
>> cec-ctl -S
> 
> I tried the instructions, and I get the following output. I don't think I have
> any CEC device connected, though. Is this the expected behaviour?
> 
> #cec-ctl -S
> Driver Info:
> Driver Name: adv7511
> Adapter Name   : 3-0039
> Capabilities   : 0x000e
> Logical Addresses
> Transmit
> Passthrough
> Driver version : 4.13.0
> Available Logical Addresses: 3
> Physical Address   : 1.0.0.0
> Logical Address Mask   : 0x
> CEC Version: 2.0
> Logical Addresses  : 0
> 
> #cec-ctl --playback
> [ 1038.761545] cec-3-0039: cec_thread_func: message 44 timed out!

This isn't right. You shouldn't see this. It never receives an interrupt
when the transmit has finished, which causes these time outs.

What are you testing this on? The Dragonboard c410?

Can you check the cec clock frequency? It should be 19.2 MHz.
Remember to apply this patch: https://patchwork.kernel.org/patch/9824773/
You probably did, but just in case...

Regards,

Hans

> Driver Info:
> Driver Name: adv7511
> Adapter Name   : 3-0039
> Capabilities   : 0x000e
> Logical Addresses
> Transmit
> Passthrough
> Driver version : 4.13.0
> Available Logical Addresses: 3
> Physical Address   : 1.0.0.0
> Logical Address Mask   : 0x0010
> CEC Version: 2.0
> Vendor ID  : 0x000c03
> Logical Addresses  : 1 (Allow RC Passthrough)
> 
>   Logical Address  : 4
> Primary Device Type: Playback
> Logical Address Type   : Playback
> All Device Types   : Playback
> RC TV Profile  : None
> Device Features:
> None
> 
> 
> [ 1041.063605] cec-3-0039: cec_thread_func: message 4f a6 06 10 00 00 timed 
> out!
> [ 1043.367482] cec-3-0039: cec_thread_func: message 4f 84 10 00 04 timed out!
> 
> Thanks,
> Archit
> 
>>
>> Regards,
>>
>> Hans
>>
>> Hans Verkuil (4):
>>dt-bindings: adi,adv7511.txt: document cec clock
>>arm: dts: qcom: add cec clock for apq8016 board
>>arm: dts: renesas: add cec clock for Koelsch board
>>drm: adv7511/33: add HDMI CEC support
>>
>>   .../bindings/display/bridge/adi,adv7511.txt|   4 +
>>   arch/arm/boot/dts/r8a7791-koelsch.dts  |   8 +
>>   arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  |   2 +
>>   drivers/gpu/drm/bridge/adv7511/Kconfig |   8 +
>>   drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
>>   drivers/gpu/drm/bridge/adv7511/adv7511.h   |  45 ++-
>>   drivers/gpu/drm/bridge/adv7511/adv7511_cec.c   | 314 
>> +
>>   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 152 +-
>>   drivers/gpu/drm/bridge/adv7511/adv7533.c   |  30 +-
>>   9 files changed, 514 insertions(+), 50 deletions(-)
>>   create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
>>
> 

Re: [PATCH 0/4] drm/bridge/adv7511: add CEC support

[Archit Taneja]

Hi Hans,

On 07/30/2017 06:37 PM, Hans Verkuil wrote:

From: Hans Verkuil 

This patch series adds CEC support to the drm adv7511/adv7533 drivers.

I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
and the Renesas R-Car Koelsch board (adv7511 based).

Note: the Dragonboard needs this patch:

https://patchwork.kernel.org/patch/9824773/

Archit, can you confirm that this patch will go to kernel 4.14?

And the Koelsch board needs this 4.13 fix:

https://patchwork.kernel.org/patch/9836865/

I only have the Koelsch board to test with, but it looks like other
R-Car boards use the same adv7511. It would be nice if someone can
add CEC support to the other R-Car boards as well. The main thing
to check is if they all use the same 12 MHz fixed CEC clock source.

Anyone who wants to test this will need the CEC utilities that
are part of the v4l-utils git repository:

git clone git://linuxtv.org/v4l-utils.git
cd v4l-utils
./bootstrap.sh
./configure
make
sudo make install

Now configure the CEC adapter as a Playback device:

cec-ctl --playback

Discover other CEC devices:

cec-ctl -S


I tried the instructions, and I get the following output. I don't think I have
any CEC device connected, though. Is this the expected behaviour?

#cec-ctl -S
Driver Info:
Driver Name: adv7511
Adapter Name   : 3-0039
Capabilities   : 0x000e
Logical Addresses
Transmit
Passthrough
Driver version : 4.13.0
Available Logical Addresses: 3
Physical Address   : 1.0.0.0
Logical Address Mask   : 0x
CEC Version: 2.0
Logical Addresses  : 0

#cec-ctl --playback
[ 1038.761545] cec-3-0039: cec_thread_func: message 44 timed out!
Driver Info:
Driver Name: adv7511
Adapter Name   : 3-0039
Capabilities   : 0x000e
Logical Addresses
Transmit
Passthrough
Driver version : 4.13.0
Available Logical Addresses: 3
Physical Address   : 1.0.0.0
Logical Address Mask   : 0x0010
CEC Version: 2.0
Vendor ID  : 0x000c03
Logical Addresses  : 1 (Allow RC Passthrough)

  Logical Address  : 4
Primary Device Type: Playback
Logical Address Type   : Playback
All Device Types   : Playback
RC TV Profile  : None
Device Features:
None


[ 1041.063605] cec-3-0039: cec_thread_func: message 4f a6 06 10 00 00 timed out!
[ 1043.367482] cec-3-0039: cec_thread_func: message 4f 84 10 00 04 timed out!

Thanks,
Archit



Regards,

Hans

Hans Verkuil (4):
   dt-bindings: adi,adv7511.txt: document cec clock
   arm: dts: qcom: add cec clock for apq8016 board
   arm: dts: renesas: add cec clock for Koelsch board
   drm: adv7511/33: add HDMI CEC support

  .../bindings/display/bridge/adi,adv7511.txt|   4 +
  arch/arm/boot/dts/r8a7791-koelsch.dts  |   8 +
  arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  |   2 +
  drivers/gpu/drm/bridge/adv7511/Kconfig |   8 +
  drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  45 ++-
  drivers/gpu/drm/bridge/adv7511/adv7511_cec.c   | 314 +
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 152 +-
  drivers/gpu/drm/bridge/adv7511/adv7533.c   |  30 +-
  9 files changed, 514 insertions(+), 50 deletions(-)
  create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 4/4] drm: adv7511/33: add HDMI CEC support

[Archit Taneja]

On 07/30/2017 06:37 PM, Hans Verkuil wrote:

From: Hans Verkuil 

Add support for HDMI CEC to the drm adv7511/adv7533 drivers.

The CEC registers that we need to use are identical for both drivers,
but they appear at different offsets in the register map.


Thanks for the patch. Some minor comments below.



Signed-off-by: Hans Verkuil 
---
  drivers/gpu/drm/bridge/adv7511/Kconfig   |   8 +
  drivers/gpu/drm/bridge/adv7511/Makefile  |   1 +
  drivers/gpu/drm/bridge/adv7511/adv7511.h |  45 +++-
  drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 314 +++
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 152 +++--
  drivers/gpu/drm/bridge/adv7511/adv7533.c |  30 +--
  6 files changed, 500 insertions(+), 50 deletions(-)
  create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c

diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig 
b/drivers/gpu/drm/bridge/adv7511/Kconfig
index 2fed567f9943..592b9d2ec034 100644
--- a/drivers/gpu/drm/bridge/adv7511/Kconfig
+++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
@@ -21,3 +21,11 @@ config DRM_I2C_ADV7533
default y
help
  Support for the Analog Devices ADV7533 DSI to HDMI encoder.
+
+config DRM_I2C_ADV7511_CEC
+   bool "ADV7511/33 HDMI CEC driver"
+   depends on DRM_I2C_ADV7511
+   select CEC_CORE
+   default y
+   help
+ When selected the HDMI transmitter will support the CEC feature.
diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile 
b/drivers/gpu/drm/bridge/adv7511/Makefile
index 5ba675534f6e..5bb384938a71 100644
--- a/drivers/gpu/drm/bridge/adv7511/Makefile
+++ b/drivers/gpu/drm/bridge/adv7511/Makefile
@@ -1,4 +1,5 @@
  adv7511-y := adv7511_drv.o
  adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
+adv7511-$(CONFIG_DRM_I2C_ADV7511_CEC) += adv7511_cec.o
  adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index fe18a5d2d84b..4fd7b14f619b 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -195,6 +195,25 @@
  #define ADV7511_PACKET_GM(x)  ADV7511_PACKET(5, x)
  #define ADV7511_PACKET_SPARE(x)   ADV7511_PACKET(6, x)
  
+#define ADV7511_REG_CEC_TX_FRAME_HDR	0x00

+#define ADV7511_REG_CEC_TX_FRAME_DATA0 0x01
+#define ADV7511_REG_CEC_TX_FRAME_LEN   0x10
+#define ADV7511_REG_CEC_TX_ENABLE  0x11
+#define ADV7511_REG_CEC_TX_RETRY   0x12
+#define ADV7511_REG_CEC_TX_LOW_DRV_CNT 0x14
+#define ADV7511_REG_CEC_RX_FRAME_HDR   0x15
+#define ADV7511_REG_CEC_RX_FRAME_DATA0 0x16
+#define ADV7511_REG_CEC_RX_FRAME_LEN   0x25
+#define ADV7511_REG_CEC_RX_ENABLE  0x26
+#define ADV7511_REG_CEC_RX_BUFFERS 0x4a
+#define ADV7511_REG_CEC_LOG_ADDR_MASK  0x4b
+#define ADV7511_REG_CEC_LOG_ADDR_0_1   0x4c
+#define ADV7511_REG_CEC_LOG_ADDR_2 0x4d
+#define ADV7511_REG_CEC_CLK_DIV0x4e
+#define ADV7511_REG_CEC_SOFT_RESET 0x50
+
+#define ADV7533_REG_CEC_OFFSET 0x70
+
  enum adv7511_input_clock {
ADV7511_INPUT_CLOCK_1X,
ADV7511_INPUT_CLOCK_2X,
@@ -297,6 +316,8 @@ enum adv7511_type {
ADV7533,
  };
  
+#define ADV7511_MAX_ADDRS 3

+
  struct adv7511 {
struct i2c_client *i2c_main;
struct i2c_client *i2c_edid;
@@ -343,15 +364,29 @@ struct adv7511 {
  
  	enum adv7511_type type;

struct platform_device *audio_pdev;
+
+   struct cec_adapter *cec_adap;
+   u8   cec_addr[ADV7511_MAX_ADDRS];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+   struct clk *cec_clk;
+   u32 cec_clk_freq;
  };
  
+#ifdef CONFIG_DRM_I2C_ADV7511_CEC

+extern const struct cec_adap_ops adv7511_cec_adap_ops;
+
+void adv7511_cec_init(struct adv7511 *adv7511, unsigned int offset);
+int adv7511_cec_parse_dt(struct device *dev, struct adv7511 *adv7511);
+void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
+#endif
+
  #ifdef CONFIG_DRM_I2C_ADV7533
  void adv7533_dsi_power_on(struct adv7511 *adv);
  void adv7533_dsi_power_off(struct adv7511 *adv);
  void adv7533_mode_set(struct adv7511 *adv, struct drm_display_mode *mode);
  int adv7533_patch_registers(struct adv7511 *adv);
-void adv7533_uninit_cec(struct adv7511 *adv);
-int adv7533_init_cec(struct adv7511 *adv);
+int adv7533_patch_cec_registers(struct adv7511 *adv);
  int adv7533_attach_dsi(struct adv7511 *adv);
  void adv7533_detach_dsi(struct adv7511 *adv);
  int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv);
@@ -374,11 +409,7 @@ static inline int adv7533_patch_registers(struct adv7511 
*adv)
return -ENODEV;
  }
  
-static inline void adv7533_uninit_cec(struct adv7511 *adv)

-{
-}
-
-static inline int adv7533_init_cec(struct adv7511 *adv)
+static inline int adv7533_patch_cec_registers(struct adv7511 *adv)
  {
return -ENODEV;
  }
diff --git 

Re: [PATCH] Subject: drivers:staging:media:atomisp:12c:ab1302.c fix CHECK

[Sakari Ailus]

Hi Harold,

On Thu, Aug 10, 2017 at 01:58:24PM +0530, Harold Gomez wrote:
> CHECK: Do not include the paragraph about writing to the Free Software
> Foundation's mailing address from the sample GPL notice.
> The FSF has changed addresses in the past, and may do so again.
> Linux already includes a copy of the GPL.

Applied, with the subject line changed to "staging: media: atomisp: ap1302:
Remove FSF postal address" and "CHECK: " removed. Please look e.g. git log
on the atomisp driver for subject examples in the future.

Thanks.

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

[PATCHv2 2/3] cec-gpio: add HDMI CEC GPIO driver

[Hans Verkuil]

From: Hans Verkuil 

Add a simple HDMI CEC GPIO driver that sits on top of the cec-pin framework.

While I have heard of SoCs that use the GPIO pin for CEC (apparently an
early RockChip SoC used that), the main use-case of this driver is to
function as a debugging tool.

By connecting the CEC line to a GPIO pin on a Raspberry Pi 3 for example
it turns it into a CEC debugger and protocol analyzer.

With 'cec-ctl --monitor-pin' the CEC traffic can be analyzed.

But of course it can also be used with any hardware project where the
HDMI CEC pin is hooked up to a pull-up gpio pin.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/Kconfig |  10 ++
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/cec-gpio/Makefile   |   1 +
 drivers/media/platform/cec-gpio/cec-gpio.c | 190 +
 4 files changed, 203 insertions(+)
 create mode 100644 drivers/media/platform/cec-gpio/Makefile
 create mode 100644 drivers/media/platform/cec-gpio/cec-gpio.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 0c741d12dbc9..681507727259 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -537,6 +537,16 @@ menuconfig CEC_PLATFORM_DRIVERS
 
 if CEC_PLATFORM_DRIVERS
 
+config CEC_GPIO
+   tristate "Generic GPIO-based CEC driver"
+   depends on PREEMPT
+   select CEC_CORE
+   select CEC_PIN
+   ---help---
+ This is a generic GPIO-based CEC driver.
+ The CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 config VIDEO_SAMSUNG_S5P_CEC
tristate "Samsung S5P CEC driver"
depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 9beadc760467..d01cc1886ad1 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_VIDEO_CODA)  += coda/
 
 obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o
 
+obj-$(CONFIG_CEC_GPIO) += cec-gpio/
+
 obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o
 
 obj-$(CONFIG_VIDEO_MUX)+= video-mux.o
diff --git a/drivers/media/platform/cec-gpio/Makefile 
b/drivers/media/platform/cec-gpio/Makefile
new file mode 100644
index ..e82b258afa55
--- /dev/null
+++ b/drivers/media/platform/cec-gpio/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_CEC_GPIO) += cec-gpio.o
diff --git a/drivers/media/platform/cec-gpio/cec-gpio.c 
b/drivers/media/platform/cec-gpio/cec-gpio.c
new file mode 100644
index ..43e1d447ad98
--- /dev/null
+++ b/drivers/media/platform/cec-gpio/cec-gpio.c
@@ -0,0 +1,190 @@
+/*
+ * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may 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.
+ *
+ * THE 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 OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct cec_gpio {
+   struct cec_adapter  *adap;
+   struct device   *dev;
+   int gpio;
+   int irq;
+   boolis_low;
+   boolhave_irq;
+};
+
+static bool cec_gpio_read(struct cec_adapter *adap)
+{
+   struct cec_gpio *cec = cec_get_drvdata(adap);
+
+   if (cec->is_low)
+   return false;
+   return gpio_get_value(cec->gpio);
+}
+
+static void cec_gpio_high(struct cec_adapter *adap)
+{
+   struct cec_gpio *cec = cec_get_drvdata(adap);
+
+   if (!cec->is_low)
+   return;
+   cec->is_low = false;
+   gpio_direction_input(cec->gpio);
+}
+
+static void cec_gpio_low(struct cec_adapter *adap)
+{
+   struct cec_gpio *cec = cec_get_drvdata(adap);
+
+   if (cec->is_low)
+   return;
+   if (WARN_ON_ONCE(cec->have_irq))
+   free_irq(cec->irq, cec);
+   cec->have_irq = false;
+   cec->is_low = true;
+   gpio_direction_output(cec->gpio, 0);
+}
+
+static irqreturn_t cec_gpio_irq_handler(int irq, void *priv)
+{
+   struct cec_gpio *cec = priv;
+
+   cec_pin_changed(cec->adap, gpio_get_value(cec->gpio));
+   return IRQ_HANDLED;
+}
+
+static bool cec_gpio_enable_irq(struct 

[PATCHv2 3/3] MAINTAINERS: add cec-gpio entry

[Hans Verkuil]

From: Hans Verkuil 

Add an entry for the CEC GPIO driver.

Signed-off-by: Hans Verkuil 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index aeb84877854b..d85959f82a09 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3199,6 +3199,15 @@ F:   include/uapi/linux/cec.h
 F: include/uapi/linux/cec-funcs.h
 F: Documentation/devicetree/bindings/media/cec.txt
 
+CEC GPIO DRIVER
+M: Hans Verkuil 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Supported
+F: drivers/media/platform/cec-gpio/
+F: Documentation/devicetree/bindings/media/cec-gpio.txt
+
 CELL BROADBAND ENGINE ARCHITECTURE
 M: Arnd Bergmann 
 L: linuxppc-...@lists.ozlabs.org
-- 
2.13.2

[PATCHv2 0/3] cec-gpio: add HDMI CEC GPIO-based driver

[Hans Verkuil]

From: Hans Verkuil 

This driver adds support for CEC implementations that use a pull-up
GPIO pin. While SoCs exist that do this, the primary use-case is to
turn a single-board computer into a cheap CEC debugger.

Together with 'cec-ctl --monitor-pin' you can do low-level CEC bus
monitoring and do protocol analysis. And error injection is also
planned for the future.

Here is an example using the Raspberry Pi 3:

https://hverkuil.home.xs4all.nl/rpi3-cec.jpg

A patch for the Raspberry Pi 2B/3 is added below for reference.
It uses pin 7 aka BCM4 aka GPCLK0 on the GPIO pin header.

While this example is for the Rpi, this driver will work for any
SoC with a pull-up GPIO pin.

I have one question: is there a generic way to check/force the gpio
to pull-up mode? I have not found that, but I am no gpio-expert.

Regards,

Hans

Changes since v1:

- Updated the bindings doc to not refer to the driver, instead
  refer to the hardware.

Hans Verkuil (3):
  dt-bindings: document the CEC GPIO bindings
  cec-gpio: add HDMI CEC GPIO driver
  MAINTAINERS: add cec-gpio entry

 .../devicetree/bindings/media/cec-gpio.txt |  16 ++
 MAINTAINERS|   9 +
 drivers/media/platform/Kconfig |  10 ++
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/cec-gpio/Makefile   |   1 +
 drivers/media/platform/cec-gpio/cec-gpio.c | 190 +
 6 files changed, 228 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt
 create mode 100644 drivers/media/platform/cec-gpio/Makefile
 create mode 100644 drivers/media/platform/cec-gpio/cec-gpio.c

-- 
2.13.2

[PATCHv2 1/3] dt-bindings: document the CEC GPIO bindings

[Hans Verkuil]

From: Hans Verkuil 

Document the bindings for the cec-gpio module for hardware where the
CEC pin is connected to a GPIO pin.

Signed-off-by: Hans Verkuil 
---
 Documentation/devicetree/bindings/media/cec-gpio.txt | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt

diff --git a/Documentation/devicetree/bindings/media/cec-gpio.txt 
b/Documentation/devicetree/bindings/media/cec-gpio.txt
new file mode 100644
index ..e34a175468e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec-gpio.txt
@@ -0,0 +1,16 @@
+* HDMI CEC GPIO-based hardware
+
+Use these bindings for HDMI CEC hardware where the CEC pin is hooked up
+to a pull-up GPIO pin.
+
+Required properties:
+  - compatible: value must be "cec-gpio"
+  - gpio: gpio that the CEC line is connected to
+
+Example for the Raspberry Pi 3 where the CEC line is connected to
+pin 7 aka BCM4 aka GPCLK0 on the GPIO pin header:
+
+cec-gpio {
+   compatible = "cec-gpio";
+   gpio = < 4 GPIO_ACTIVE_HIGH>;
+};
-- 
2.13.2

[PATCH] Subject: drivers:staging:media:atomisp:12c:ab1302.c fix CHECK

[Harold Gomez]

CHECK: Do not include the paragraph about writing to the Free Software
Foundation's mailing address from the sample GPL notice.
The FSF has changed addresses in the past, and may do so again.
Linux already includes a copy of the GPL.

remove the unnecessary paragraph

Signed-off-by: Harold Gomez 
---
 drivers/staging/media/atomisp/i2c/ap1302.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/ap1302.c 
b/drivers/staging/media/atomisp/i2c/ap1302.c
index bacffbe..9d6ce36 100644
--- a/drivers/staging/media/atomisp/i2c/ap1302.c
+++ b/drivers/staging/media/atomisp/i2c/ap1302.c
@@ -11,11 +11,6 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
- * 02110-1301, USA.
- *
  */
 
 #include "../include/linux/atomisp.h"
-- 
2.1.4

[PATCHv3 3/4] tegra-cec: add Tegra HDMI CEC driver

[Hans Verkuil]

From: Hans Verkuil 

This driver adds support for the Tegra CEC IP. It is based on the
NVIDIA drivers/misc/tegra-cec driver in their 3.10 kernel.

This has been converted to the CEC framework and cleaned up.

Tested with my Jetson TK1 board. It has also been tested with the
Tegra X1 in an embedded product.

Note of warning for the Tegra X2: this SoC supports two HDMI outputs,
but only one CEC adapter and the CEC bus is shared between the
two outputs. This is a design mistake and the CEC adapter can
control only one HDMI output. Never hook up both HDMI outputs
to the CEC bus in a hardware design: this is illegal as per the
CEC specification.

The CEC bus can be shared between multiple inputs and zero or one
outputs, but not between multiple outputs.

Signed-off-by: Hans Verkuil 
---
 MAINTAINERS  |   8 +
 drivers/media/platform/Kconfig   |  11 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/tegra-cec/Makefile|   1 +
 drivers/media/platform/tegra-cec/tegra_cec.c | 506 +++
 drivers/media/platform/tegra-cec/tegra_cec.h | 127 +++
 6 files changed, 655 insertions(+)
 create mode 100644 drivers/media/platform/tegra-cec/Makefile
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.c
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 84d6a8277cbd..56b47c721704 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1917,6 +1917,14 @@ M:   Lennert Buytenhek 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 
+ARM/TEGRA HDMI CEC SUBSYSTEM SUPPORT
+M: Hans Verkuil 
+L: linux-te...@vger.kernel.org
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/platform/tegra-cec/
+F: Documentation/devicetree/bindings/media/tegra-cec.txt
+
 ARM/TETON BGA MACHINE SUPPORT
 M: "Mark F. Brown" 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index fb1fa0b82077..7a4db3046161 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -570,6 +570,17 @@ config VIDEO_STM32_HDMI_CEC
  CEC bus is present in the HDMI connector and enables communication
  between compatible devices.
 
+config VIDEO_TEGRA_HDMI_CEC
+   tristate "Tegra HDMI CEC driver"
+   depends on ARCH_TEGRA || COMPILE_TEST
+   select CEC_CORE
+   select CEC_NOTIFIER
+   ---help---
+ This is a driver for the Tegra HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ The CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 endif #CEC_PLATFORM_DRIVERS
 
 menuconfig SDR_PLATFORM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 9beadc760467..9da73532e556 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -46,6 +46,8 @@ obj-$(CONFIG_VIDEO_STI_HDMI_CEC)  += sti/cec/
 
 obj-$(CONFIG_VIDEO_STI_DELTA)  += sti/delta/
 
+obj-$(CONFIG_VIDEO_TEGRA_HDMI_CEC) += tegra-cec/
+
 obj-y  += stm32/
 
 obj-y   += blackfin/
diff --git a/drivers/media/platform/tegra-cec/Makefile 
b/drivers/media/platform/tegra-cec/Makefile
new file mode 100644
index ..f3d81127589f
--- /dev/null
+++ b/drivers/media/platform/tegra-cec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_TEGRA_HDMI_CEC) += tegra_cec.o
diff --git a/drivers/media/platform/tegra-cec/tegra_cec.c 
b/drivers/media/platform/tegra-cec/tegra_cec.c
new file mode 100644
index ..346586c3ad6d
--- /dev/null
+++ b/drivers/media/platform/tegra-cec/tegra_cec.c
@@ -0,0 +1,506 @@
+/*
+ * Tegra CEC implementation
+ *
+ * The original 3.10 CEC driver using a custom API:
+ *
+ * Copyright (c) 2012-2015, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * Conversion to the CEC framework and to the mainline kernel:
+ *
+ * Copyright 2016-2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 

[PATCHv3 4/4] drm/tegra: add cec-notifier support

[Hans Verkuil]

From: Hans Verkuil 

In order to support CEC the HDMI driver has to inform the CEC driver
whenever the physical address changes. So when the EDID is read the
CEC driver has to be informed and whenever the hotplug detect goes
away.

This is done through the cec-notifier framework.

The link between the HDMI driver and the CEC driver is done through
the hdmi_phandle in the tegra-cec node in the device tree.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/tegra/Kconfig  | 1 +
 drivers/gpu/drm/tegra/drm.h| 3 +++
 drivers/gpu/drm/tegra/hdmi.c   | 9 +
 drivers/gpu/drm/tegra/output.c | 6 ++
 4 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 2db29d67193d..c882918c2024 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -8,6 +8,7 @@ config DRM_TEGRA
select DRM_PANEL
select TEGRA_HOST1X
select IOMMU_IOVA if IOMMU_SUPPORT
+   select CEC_CORE if CEC_NOTIFIER
help
  Choose this option if you have an NVIDIA Tegra SoC.
 
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 6d6da01282f3..c0a18b60caf1 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -212,6 +212,8 @@ int tegra_dc_state_setup_clock(struct tegra_dc *dc,
   struct clk *clk, unsigned long pclk,
   unsigned int div);
 
+struct cec_notifier;
+
 struct tegra_output {
struct device_node *of_node;
struct device *dev;
@@ -219,6 +221,7 @@ struct tegra_output {
struct drm_panel *panel;
struct i2c_adapter *ddc;
const struct edid *edid;
+   struct cec_notifier *notifier;
unsigned int hpd_irq;
int hpd_gpio;
enum of_gpio_flags hpd_gpio_flags;
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index cda0491ed6bf..fbf14e1efd0e 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -21,6 +21,8 @@
 
 #include 
 
+#include 
+
 #include "hdmi.h"
 #include "drm.h"
 #include "dc.h"
@@ -1720,6 +1722,10 @@ static int tegra_hdmi_probe(struct platform_device *pdev)
return PTR_ERR(hdmi->vdd);
}
 
+   hdmi->output.notifier = cec_notifier_get(>dev);
+   if (hdmi->output.notifier == NULL)
+   return -ENOMEM;
+
hdmi->output.dev = >dev;
 
err = tegra_output_probe(>output);
@@ -1778,6 +1784,9 @@ static int tegra_hdmi_remove(struct platform_device *pdev)
 
tegra_output_remove(>output);
 
+   if (hdmi->output.notifier)
+   cec_notifier_put(hdmi->output.notifier);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 595d1ec3e02e..57c052521a44 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -11,6 +11,8 @@
 #include 
 #include "drm.h"
 
+#include 
+
 int tegra_output_connector_get_modes(struct drm_connector *connector)
 {
struct tegra_output *output = connector_to_output(connector);
@@ -33,6 +35,7 @@ int tegra_output_connector_get_modes(struct drm_connector 
*connector)
edid = drm_get_edid(connector, output->ddc);
 
drm_mode_connector_update_edid_property(connector, edid);
+   cec_notifier_set_phys_addr_from_edid(output->notifier, edid);
 
if (edid) {
err = drm_add_edid_modes(connector, edid);
@@ -68,6 +71,9 @@ tegra_output_connector_detect(struct drm_connector 
*connector, bool force)
status = connector_status_connected;
}
 
+   if (status != connector_status_connected)
+   cec_notifier_phys_addr_invalidate(output->notifier);
+
return status;
 }
 
-- 
2.13.2

[PATCHv3 1/4] dt-bindings: document the tegra CEC bindings

[Hans Verkuil]

From: Hans Verkuil 

This documents the binding for the Tegra CEC module.

Signed-off-by: Hans Verkuil 
---
 .../devicetree/bindings/media/tegra-cec.txt| 27 ++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/tegra-cec.txt

diff --git a/Documentation/devicetree/bindings/media/tegra-cec.txt 
b/Documentation/devicetree/bindings/media/tegra-cec.txt
new file mode 100644
index ..c503f06f3b84
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/tegra-cec.txt
@@ -0,0 +1,27 @@
+* Tegra HDMI CEC hardware
+
+The HDMI CEC module is present in Tegra SoCs and its purpose is to
+handle communication between HDMI connected devices over the CEC bus.
+
+Required properties:
+  - compatible : value should be one of the following:
+   "nvidia,tegra114-cec"
+   "nvidia,tegra124-cec"
+   "nvidia,tegra210-cec"
+  - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+  - interrupts : HDMI CEC interrupt number to the CPU.
+  - clocks : from common clock binding: handle to HDMI CEC clock.
+  - clock-names : from common clock binding: must contain "cec",
+ corresponding to the entry in the clocks property.
+  - hdmi-phandle : phandle to the HDMI controller, see also cec.txt.
+
+Example:
+
+cec@70015000 {
+   compatible = "nvidia,tegra124-cec";
+   reg = <0x0 0x70015000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <_car TEGRA124_CLK_CEC>;
+   clock-names = "cec";
+};
-- 
2.13.2

[PATCHv3 2/4] ARM: tegra: add CEC support to tegra124.dtsi

[Hans Verkuil]

From: Hans Verkuil 

Add support for the Tegra CEC IP to tegra124.dtsi and enable it on the
Jetson TK1.

Signed-off-by: Hans Verkuil 
---
 arch/arm/boot/dts/tegra124-jetson-tk1.dts |  4 
 arch/arm/boot/dts/tegra124.dtsi   | 12 +++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts 
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 7bacb2954f58..7f56de6890c3 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -67,6 +67,10 @@
};
};
 
+   cec@70015000 {
+   status = "okay";
+   };
+
gpu@0,5700 {
/*
 * Node left disabled on purpose - the bootloader will enable
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 1b10b14a6abd..1a21e527fb6e 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -123,7 +123,7 @@
nvidia,head = <1>;
};
 
-   hdmi@5428 {
+   hdmi: hdmi@5428 {
compatible = "nvidia,tegra124-hdmi";
reg = <0x0 0x5428 0x0 0x0004>;
interrupts = ;
@@ -851,6 +851,16 @@
status = "disabled";
};
 
+   cec@70015000 {
+   compatible = "nvidia,tegra124-cec";
+   reg = <0x0 0x70015000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <_car TEGRA124_CLK_CEC>;
+   clock-names = "cec";
+   hdmi-phandle = <>;
+   status = "disabled";
+   };
+
soctherm: thermal-sensor@700e2000 {
compatible = "nvidia,tegra124-soctherm";
reg = <0x0 0x700e2000 0x0 0x600 /* SOC_THERM reg_base */
-- 
2.13.2

[PATCHv3 0/4] tegra-cec: add Tegra HDMI CEC support

[Hans Verkuil]

From: Hans Verkuil 

This patch series adds support for the Tegra CEC functionality.

It has this prerequisite: https://patchwork.linuxtv.org/patch/42521/

That patch has been merged in 4.13-rc4.

The first patch documents the CEC bindings, the second adds support
for this to tegra124.dtsi and enables it for the Jetson TK1.

The third patch adds the CEC driver itself and the final patch adds
the cec notifier support to the drm/tegra driver in order to notify
the CEC driver whenever the physical address changes.

I expect that the dts changes apply as well to the Tegra X1/X2 and possibly
other Tegra SoCs, but I can only test this with my Jetson TK1 board.

The dt-bindings and the tegra-cec driver would go in through the media
subsystem, the drm/tegra part through the drm subsystem and the dts
changes through (I guess) the linux-tegra developers. Luckily they are
all independent of one another.

To test this you need the CEC utilities from git://linuxtv.org/v4l-utils.git.

To build this:

git clone git://linuxtv.org/v4l-utils.git
cd v4l-utils
./bootstrap.sh; ./configure
make
sudo make install # optional, you really only need utils/cec*

To test:

cec-ctl --playback # configure as playback device
cec-ctl -Subject # detect all connected CEC devices

See here for the public CEC API:

https://hverkuil.home.xs4all.nl/spec/uapi/cec/cec-api.html

Regards,

Hans

Changes since v1:

- Update the bindings doc so it no longer refers to 'driver', instead it
  only refers to the hardware.
- Add 'select CEC_CORE if CEC_NOTIFIER' to Kconfig. If the tegra-cec driver
  is a module and the drm tegra driver is built-in, then the CEC core
  will be a module also, causing the CEC notifier to fail (will be
  compiled as empty functions). This select forces the correct dependency.
  (Note: this was posted separately as a v2 patch)

Hans Verkuil (4):
  dt-bindings: document the tegra CEC bindings
  ARM: tegra: add CEC support to tegra124.dtsi
  tegra-cec: add Tegra HDMI CEC driver
  drm/tegra: add cec-notifier support

 .../devicetree/bindings/media/tegra-cec.txt|  27 ++
 MAINTAINERS|   8 +
 arch/arm/boot/dts/tegra124-jetson-tk1.dts  |   4 +
 arch/arm/boot/dts/tegra124.dtsi|  12 +-
 drivers/gpu/drm/tegra/Kconfig  |   1 +
 drivers/gpu/drm/tegra/drm.h|   3 +
 drivers/gpu/drm/tegra/hdmi.c   |   9 +
 drivers/gpu/drm/tegra/output.c |   6 +
 drivers/media/platform/Kconfig |  11 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/tegra-cec/Makefile  |   1 +
 drivers/media/platform/tegra-cec/tegra_cec.c   | 506 +
 drivers/media/platform/tegra-cec/tegra_cec.h   | 127 ++
 13 files changed, 716 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/media/tegra-cec.txt
 create mode 100644 drivers/media/platform/tegra-cec/Makefile
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.c
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.h

-- 
2.13.2

[PATCH] Subject: drivers:staging:media:atomisp:12c:ab1302.c fix CHECK

[Harold Gomez]

CHECK: Do not include the paragraph about writing to the Free Software
Foundation's mailing address from the sample GPL notice.
The FSF has changed addresses in the past, and may do so again.
Linux already includes a copy of the GPL.

remove the unnecessary paragraph

Signed-off-by: Harold Gomez 
---
 drivers/staging/media/atomisp/i2c/ap1302.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/ap1302.c 
b/drivers/staging/media/atomisp/i2c/ap1302.c
index bacffbe..9d6ce36 100644
--- a/drivers/staging/media/atomisp/i2c/ap1302.c
+++ b/drivers/staging/media/atomisp/i2c/ap1302.c
@@ -11,11 +11,6 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
- * 02110-1301, USA.
- *
  */
 
 #include "../include/linux/atomisp.h"
-- 
2.1.4

Re: [PATCH 1/3] dt-bindings: document the CEC GPIO bindings

[Hans Verkuil]

On 10/08/17 10:03, Hans Verkuil wrote:
> On 02/08/17 10:42, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> Document the bindings for the cec-gpio module for hardware where the
>> CEC pin is connected to a GPIO pin.
> 
> ping?
> 
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>>  Documentation/devicetree/bindings/media/cec-gpio.txt | 18 ++
>>  1 file changed, 18 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/cec-gpio.txt 
>> b/Documentation/devicetree/bindings/media/cec-gpio.txt
>> new file mode 100644
>> index ..58fa56080cda
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/cec-gpio.txt
>> @@ -0,0 +1,18 @@
>> +* HDMI CEC GPIO driver

OK, reading your comments from an other bindings patch I realize that 'bindings
refer to hardware, not drivers'. I'll fix and repost :-)

Regards,

Hans

>> +
>> +The HDMI CEC GPIO module supports CEC implementations where the CEC pin
>> +is hooked up to a pull-up GPIO pin.
>> +
>> +The CEC GPIO
>> +
>> +Required properties:
>> +  - compatible: value must be "cec-gpio"
>> +  - gpio: gpio that the CEC line is connected to
>> +
>> +Example for the Raspberry Pi 3 where the CEC line is connected to
>> +pin 7 aka BCM4 aka GPCLK0 on the GPIO pin header:
>> +
>> +cec-gpio {
>> +   compatible = "cec-gpio";
>> +   gpio = < 4 GPIO_ACTIVE_HIGH>;
>> +};
>>
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

Re: [PATCH 1/3] dt-bindings: document the CEC GPIO bindings

[Hans Verkuil]

On 02/08/17 10:42, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Document the bindings for the cec-gpio module for hardware where the
> CEC pin is connected to a GPIO pin.

ping?

> 
> Signed-off-by: Hans Verkuil 
> ---
>  Documentation/devicetree/bindings/media/cec-gpio.txt | 18 ++
>  1 file changed, 18 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/cec-gpio.txt 
> b/Documentation/devicetree/bindings/media/cec-gpio.txt
> new file mode 100644
> index ..58fa56080cda
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/cec-gpio.txt
> @@ -0,0 +1,18 @@
> +* HDMI CEC GPIO driver
> +
> +The HDMI CEC GPIO module supports CEC implementations where the CEC pin
> +is hooked up to a pull-up GPIO pin.
> +
> +The CEC GPIO
> +
> +Required properties:
> +  - compatible: value must be "cec-gpio"
> +  - gpio: gpio that the CEC line is connected to
> +
> +Example for the Raspberry Pi 3 where the CEC line is connected to
> +pin 7 aka BCM4 aka GPCLK0 on the GPIO pin header:
> +
> +cec-gpio {
> +   compatible = "cec-gpio";
> +   gpio = < 4 GPIO_ACTIVE_HIGH>;
> +};
> 

[GIT FIXES for 4.13] Revert full OF path comparison in OF matching

[Sakari Ailus]

Hi Mauro,

This reverts the change from pointer comparison to full OF node path
comparison. As per commit message:

The commit was flawed in that if the device_node pointers are different,
then in fact a different device is present and the device node could be
different in ways other than full_name.

As Frank Rowand explained:

"When an overlay (1) is removed, all uses and references to the nodes and
properties in that overlay are no longer valid.  Any driver that uses any
information from the overlay _must_ stop using any data from the overlay.
Any driver that is bound to a new node in the overlay _must_ unbind.  Any
driver that became bound to a pre-existing node that was modified by the
overlay (became bound after the overlay was applied) _must_ adjust itself
to account for any changes to that node when the overlay is removed.  One
way to do this is to unbind when notified that the overlay is about to
be removed, then to re-bind after the overlay is completely removed.

If an overlay (2) is subsequently applied, a node with the same
full_name as from overlay (1) may exist.  There is no guarantee
that overlay (1) and overlay (2) are the same overlay, even if
that node has the same full_name in both cases."

Also, there's not sufficient overlay support in mainline to actually
remove and re-apply an overlay to hit this condition as overlays can
only be applied from in kernel APIs.

Cc: Mauro Carvalho Chehab 
Cc: Sakari Ailus 
Cc: Javi Merino 
Cc: Javier Martinez Canillas 
Cc: Sylwester Nawrocki 
Cc: Frank Rowand 
Signed-off-by: Rob Herring 
Acked-by: Javi Merino 
Signed-off-by: Sakari Ailus 

Please pull.


The following changes since commit 0659445f47586b128613e011eae9f24b07ebe838:

  media: staging: atomisp: sh_css_calloc shall return a pointer to the 
allocated space (2017-08-09 10:49:36 -0400)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git fwnode-fix

for you to fetch changes up to 219ebbde1b134f9ae357b6e45c215f71de6f48d3:

  Revert "[media] v4l: async: make v4l2 coexist with devicetree nodes in a dt 
overlay" (2017-08-10 10:40:51 +0300)


Rob Herring (1):
  Revert "[media] v4l: async: make v4l2 coexist with devicetree nodes in a 
dt overlay"

 drivers/media/v4l2-core/v4l2-async.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

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

Re: [PATCH v2] media: ov5670: Fix incorrect frame timing reported to user

[Sakari Ailus]

On Thu, Aug 10, 2017 at 04:00:05PM +0900, Tomasz Figa wrote:
> Hi Chiranjeevi,
> 
> On Thu, Aug 10, 2017 at 6:59 AM, Chiranjeevi Rapolu
>  wrote:
> > Previously, pixel-rate/(pixels-per-line * lines-per-frame) was
> > yielding incorrect frame timing for the user.
> >
> > OV sensor is using internal timing and this requires
> > conversion (internal timing -> PPL) for correct HBLANK calculation.
> >
> > Now, change pixels-per-line domain from internal sensor clock to
> > pixels domain. Set HBLANK read-only because fixed PPL is used for all
> > resolutions. And, use more accurate link-frequency 422.4MHz instead of
> > rounding down to 420MHz.
> >
> > Signed-off-by: Chiranjeevi Rapolu 
> > ---
> > Changes in v2:
> > - Change subject to reflect frame timing info.
> > - Change OV5670_DEF_PPL so that it doesn't convey a register default
> >   value. And, add more comments to it.
> >  drivers/media/i2c/ov5670.c | 45 
> > +++--
> >  1 file changed, 23 insertions(+), 22 deletions(-)
> 
> Okay, the numbers in this version finally make sense. Thanks for
> figuring this out.
> 
> Reviewed-by: Tomasz Figa 

Thanks, applied!

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

Re: [PATCH v2] media: ov5670: Fix incorrect frame timing reported to user

[Tomasz Figa]

Hi Chiranjeevi,

On Thu, Aug 10, 2017 at 6:59 AM, Chiranjeevi Rapolu
 wrote:
> Previously, pixel-rate/(pixels-per-line * lines-per-frame) was
> yielding incorrect frame timing for the user.
>
> OV sensor is using internal timing and this requires
> conversion (internal timing -> PPL) for correct HBLANK calculation.
>
> Now, change pixels-per-line domain from internal sensor clock to
> pixels domain. Set HBLANK read-only because fixed PPL is used for all
> resolutions. And, use more accurate link-frequency 422.4MHz instead of
> rounding down to 420MHz.
>
> Signed-off-by: Chiranjeevi Rapolu 
> ---
> Changes in v2:
> - Change subject to reflect frame timing info.
> - Change OV5670_DEF_PPL so that it doesn't convey a register default
>   value. And, add more comments to it.
>  drivers/media/i2c/ov5670.c | 45 +++--
>  1 file changed, 23 insertions(+), 22 deletions(-)

Okay, the numbers in this version finally make sense. Thanks for
figuring this out.

Reviewed-by: Tomasz Figa 

Best regards,
Tomasz