cron job: media_tree daily build: ERRORS

2018-03-24 Thread 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:   Sun Mar 25 05:00:11 CEST 2018
media-tree git hash:6ccd228e0cfce2a4f44558422d25c60fcb1a6710
media_build git hash:   78828a70baab71c5b81107b2fbea0a354e01a34f
v4l-utils git hash: 098e402950fd45b5a572cccfe1d103661d418417
gcc version:i686-linux-gcc (GCC) 7.3.0
sparse version: v0.5.0-3994-g45eb2282
smatch version: v0.5.0-3994-g45eb2282
host hardware:  x86_64
host os:4.14.0-3-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.101-i686: ERRORS
linux-3.0.101-x86_64: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.100-i686: ERRORS
linux-3.2.100-x86_64: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.113-i686: ERRORS
linux-3.4.113-x86_64: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.10-i686: ERRORS
linux-3.7.10-x86_64: ERRORS
linux-3.8.13-i686: ERRORS
linux-3.8.13-x86_64: ERRORS
linux-3.9.11-i686: ERRORS
linux-3.9.11-x86_64: ERRORS
linux-3.10.108-i686: ERRORS
linux-3.10.108-x86_64: ERRORS
linux-3.11.10-i686: ERRORS
linux-3.11.10-x86_64: ERRORS
linux-3.12.74-i686: ERRORS
linux-3.12.74-x86_64: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.79-i686: ERRORS
linux-3.14.79-x86_64: ERRORS
linux-3.15.10-i686: ERRORS
linux-3.15.10-x86_64: ERRORS
linux-3.16.55-i686: ERRORS
linux-3.16.55-x86_64: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.100-i686: ERRORS
linux-3.18.100-x86_64: ERRORS
linux-3.19.8-i686: ERRORS
linux-3.19.8-x86_64: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.50-i686: ERRORS
linux-4.1.50-x86_64: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.99-i686: ERRORS
linux-4.4.99-x86_64: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.10-i686: ERRORS
linux-4.7.10-x86_64: ERRORS
linux-4.8.17-i686: OK
linux-4.8.17-x86_64: WARNINGS
linux-4.9.87-i686: WARNINGS
linux-4.9.87-x86_64: WARNINGS
linux-4.10.17-i686: OK
linux-4.10.17-x86_64: WARNINGS
linux-4.11.12-i686: OK
linux-4.11.12-x86_64: WARNINGS
linux-4.12.14-i686: OK
linux-4.12.14-x86_64: OK
linux-4.13.16-i686: OK
linux-4.13.16-x86_64: OK
linux-4.14.27-i686: OK
linux-4.14.27-x86_64: OK
linux-4.15.10-i686: OK
linux-4.15.10-x86_64: OK
linux-4.16-rc5-i686: OK
linux-4.16-rc5-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS
smatch: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

[PATCH] media: cec-pin: Fixed ktime_t to ns conversion

2018-03-24 Thread Jasmin J. 
From: Jasmin Jessich 

Older Kernels use a struct for ktime_t, which requires the conversion
function ktime_to_ns to be used on some places. With this patch it will
compile now also for older Kernel versions.

Signed-off-by: Jasmin Jessich 
---
 drivers/media/cec/cec-pin.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/cec/cec-pin.c b/drivers/media/cec/cec-pin.c
index fafe1eb..2a5df99 100644
--- a/drivers/media/cec/cec-pin.c
+++ b/drivers/media/cec/cec-pin.c
@@ -668,7 +668,7 @@ static void cec_pin_rx_states(struct cec_pin *pin, ktime_t 
ts)
/* Start bit low is too short, go back to idle */
if (delta < CEC_TIM_START_BIT_LOW_MIN - CEC_TIM_IDLE_SAMPLE) {
if (!pin->rx_start_bit_low_too_short_cnt++) {
-   pin->rx_start_bit_low_too_short_ts = pin->ts;
+   pin->rx_start_bit_low_too_short_ts = 
ktime_to_ns(pin->ts);
pin->rx_start_bit_low_too_short_delta = delta;
}
cec_pin_to_idle(pin);
@@ -700,7 +700,7 @@ static void cec_pin_rx_states(struct cec_pin *pin, ktime_t 
ts)
/* Start bit is too short, go back to idle */
if (delta < CEC_TIM_START_BIT_TOTAL_MIN - CEC_TIM_IDLE_SAMPLE) {
if (!pin->rx_start_bit_too_short_cnt++) {
-   pin->rx_start_bit_too_short_ts = pin->ts;
+   pin->rx_start_bit_too_short_ts = 
ktime_to_ns(pin->ts);
pin->rx_start_bit_too_short_delta = delta;
}
cec_pin_to_idle(pin);
@@ -770,7 +770,7 @@ static void cec_pin_rx_states(struct cec_pin *pin, ktime_t 
ts)
 */
if (delta < CEC_TIM_DATA_BIT_TOTAL_MIN) {
if (!pin->rx_data_bit_too_short_cnt++) {
-   pin->rx_data_bit_too_short_ts = pin->ts;
+   pin->rx_data_bit_too_short_ts = 
ktime_to_ns(pin->ts);
pin->rx_data_bit_too_short_delta = delta;
}
cec_pin_low(pin);
-- 
2.7.4

[PATCH 0/3] Improve latency of IR decoding

2018-03-24 Thread Sean Young 
The current IR decoding is much too slow. Many IR protocols rely on
a trailing space for decoding (e.g. rc-6 needs to know when the bits
end). The trailing space is generated by the IR timeout, and if this
is longer than required, keys can be perceived as sticky and slugish.

The other issue the keyup timer. IR has no concept of a keyup message,
this is implied by the absence of IR. So, minimising the timeout for
this further improves the handling.

With these patches in place, using IR with the builtin decoders is much
improved and feels very snappy.

Sean Young (3):
  media: rc: set timeout to smallest value required by enabled protocols
  media: rc: add ioctl to get the current timeout
  media: rc: per-protocol repeat period and minimum keyup timer

 Documentation/media/uapi/rc/lirc-func.rst  |  1 +
 .../media/uapi/rc/lirc-set-rec-timeout.rst | 14 +++--
 drivers/media/cec/cec-core.c   |  2 +-
 drivers/media/rc/ir-imon-decoder.c |  1 +
 drivers/media/rc/ir-jvc-decoder.c  |  1 +
 drivers/media/rc/ir-mce_kbd-decoder.c  |  1 +
 drivers/media/rc/ir-nec-decoder.c  |  1 +
 drivers/media/rc/ir-rc5-decoder.c  |  1 +
 drivers/media/rc/ir-rc6-decoder.c  |  1 +
 drivers/media/rc/ir-sanyo-decoder.c|  1 +
 drivers/media/rc/ir-sharp-decoder.c|  1 +
 drivers/media/rc/ir-sony-decoder.c |  1 +
 drivers/media/rc/ir-xmp-decoder.c  |  1 +
 drivers/media/rc/lirc_dev.c|  9 ++-
 drivers/media/rc/rc-core-priv.h|  1 +
 drivers/media/rc/rc-ir-raw.c   | 31 +-
 drivers/media/rc/rc-main.c | 68 +++---
 include/uapi/linux/lirc.h  |  6 ++
 18 files changed, 101 insertions(+), 41 deletions(-)

-- 
2.14.3

[PATCH 1/3] media: rc: set timeout to smallest value required by enabled protocols

2018-03-24 Thread Sean Young 
The longer the IR timeout, the longer we wait until delivering each
scancode. By reducing this timeout, we reduce the time it take for the
last scancode to be delivered.

Note that the lirc daemon disables all protocols, in case we revert back
to the default value.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-imon-decoder.c|  1 +
 drivers/media/rc/ir-jvc-decoder.c |  1 +
 drivers/media/rc/ir-mce_kbd-decoder.c |  1 +
 drivers/media/rc/ir-nec-decoder.c |  1 +
 drivers/media/rc/ir-rc5-decoder.c |  1 +
 drivers/media/rc/ir-rc6-decoder.c |  1 +
 drivers/media/rc/ir-sanyo-decoder.c   |  1 +
 drivers/media/rc/ir-sharp-decoder.c   |  1 +
 drivers/media/rc/ir-sony-decoder.c|  1 +
 drivers/media/rc/ir-xmp-decoder.c |  1 +
 drivers/media/rc/rc-core-priv.h   |  1 +
 drivers/media/rc/rc-ir-raw.c  | 31 ++-
 drivers/media/rc/rc-main.c| 12 ++--
 13 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/drivers/media/rc/ir-imon-decoder.c 
b/drivers/media/rc/ir-imon-decoder.c
index a1ff06a26542..9024b359e5ee 100644
--- a/drivers/media/rc/ir-imon-decoder.c
+++ b/drivers/media/rc/ir-imon-decoder.c
@@ -170,6 +170,7 @@ static struct ir_raw_handler imon_handler = {
.decode = ir_imon_decode,
.encode = ir_imon_encode,
.carrier= 38000,
+   .max_space  = IMON_UNIT * IMON_BITS * 2,
 };
 
 static int __init ir_imon_decode_init(void)
diff --git a/drivers/media/rc/ir-jvc-decoder.c 
b/drivers/media/rc/ir-jvc-decoder.c
index 8cb68ae43282..190c690b14f8 100644
--- a/drivers/media/rc/ir-jvc-decoder.c
+++ b/drivers/media/rc/ir-jvc-decoder.c
@@ -213,6 +213,7 @@ static struct ir_raw_handler jvc_handler = {
.decode = ir_jvc_decode,
.encode = ir_jvc_encode,
.carrier= 38000,
+   .max_space  = JVC_TRAILER_SPACE,
 };
 
 static int __init ir_jvc_decode_init(void)
diff --git a/drivers/media/rc/ir-mce_kbd-decoder.c 
b/drivers/media/rc/ir-mce_kbd-decoder.c
index c110984ca671..ae4b980c4a16 100644
--- a/drivers/media/rc/ir-mce_kbd-decoder.c
+++ b/drivers/media/rc/ir-mce_kbd-decoder.c
@@ -475,6 +475,7 @@ static struct ir_raw_handler mce_kbd_handler = {
.raw_register   = ir_mce_kbd_register,
.raw_unregister = ir_mce_kbd_unregister,
.carrier= 36000,
+   .max_space  = MCIR2_MAX_LEN,
 };
 
 static int __init ir_mce_kbd_decode_init(void)
diff --git a/drivers/media/rc/ir-nec-decoder.c 
b/drivers/media/rc/ir-nec-decoder.c
index 21647b809e6f..fac12f867a81 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -253,6 +253,7 @@ static struct ir_raw_handler nec_handler = {
.decode = ir_nec_decode,
.encode = ir_nec_encode,
.carrier= 38000,
+   .max_space  = NEC_TRAILER_SPACE,
 };
 
 static int __init ir_nec_decode_init(void)
diff --git a/drivers/media/rc/ir-rc5-decoder.c 
b/drivers/media/rc/ir-rc5-decoder.c
index 74d3b859c3a2..711068c8de90 100644
--- a/drivers/media/rc/ir-rc5-decoder.c
+++ b/drivers/media/rc/ir-rc5-decoder.c
@@ -274,6 +274,7 @@ static struct ir_raw_handler rc5_handler = {
.decode = ir_rc5_decode,
.encode = ir_rc5_encode,
.carrier= 36000,
+   .max_space  = RC5_TRAILER,
 };
 
 static int __init ir_rc5_decode_init(void)
diff --git a/drivers/media/rc/ir-rc6-decoder.c 
b/drivers/media/rc/ir-rc6-decoder.c
index 8314da32453f..9cc4820878c7 100644
--- a/drivers/media/rc/ir-rc6-decoder.c
+++ b/drivers/media/rc/ir-rc6-decoder.c
@@ -394,6 +394,7 @@ static struct ir_raw_handler rc6_handler = {
.decode = ir_rc6_decode,
.encode = ir_rc6_encode,
.carrier= 36000,
+   .max_space  = RC6_SUFFIX_SPACE,
 };
 
 static int __init ir_rc6_decode_init(void)
diff --git a/drivers/media/rc/ir-sanyo-decoder.c 
b/drivers/media/rc/ir-sanyo-decoder.c
index 4efe6db5376a..e72787b446c9 100644
--- a/drivers/media/rc/ir-sanyo-decoder.c
+++ b/drivers/media/rc/ir-sanyo-decoder.c
@@ -210,6 +210,7 @@ static struct ir_raw_handler sanyo_handler = {
.decode = ir_sanyo_decode,
.encode = ir_sanyo_encode,
.carrier= 38000,
+   .max_space  = SANYO_TRAILER_SPACE,
 };
 
 static int __init ir_sanyo_decode_init(void)
diff --git a/drivers/media/rc/ir-sharp-decoder.c 
b/drivers/media/rc/ir-sharp-decoder.c
index 6a38c50566a4..ccbd4c12d1d7 100644
--- a/drivers/media/rc/ir-sharp-decoder.c
+++ b/drivers/media/rc/ir-sharp-decoder.c
@@ -226,6 +226,7 @@ static struct ir_raw_handler sharp_handler = {
.decode = ir_sharp_decode,
.encode = ir_sharp_encode,
.carrier= 38000,
+   .max_space  = SHARP_TRAILER_SPACE,
 };
 
 static int __init ir_sharp_decode_init(void)
diff --git a/drivers/media/rc/ir-sony-decoder.c

[PATCH 3/3] media: rc: per-protocol repeat period and minimum keyup timer

2018-03-24 Thread Sean Young 
Each IR protocol has its own repeat period. We can minimise the keyup
timer to be the protocol period + IR timeout. This makes keys less
"sticky" and makes IR more reactive and nicer to use.

This feature was previously attempted in commit d57ea877af38 ("media: rc:
per-protocol repeat period"), but that did not take the IR timeout into
account, and had to be reverted.

Signed-off-by: Sean Young 
---
 drivers/media/cec/cec-core.c |  2 +-
 drivers/media/rc/lirc_dev.c  |  2 +-
 drivers/media/rc/rc-main.c   | 56 +++-
 3 files changed, 31 insertions(+), 29 deletions(-)

diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index b0c87f9ea08f..b278ab90b387 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -322,7 +322,7 @@ struct cec_adapter *cec_allocate_adapter(const struct 
cec_adap_ops *ops,
adap->rc->allowed_protocols = RC_PROTO_BIT_CEC;
adap->rc->priv = adap;
adap->rc->map_name = RC_MAP_CEC;
-   adap->rc->timeout = MS_TO_NS(100);
+   adap->rc->timeout = MS_TO_NS(550);
 #endif
return adap;
 }
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 17f40c8e939f..19660f9757e1 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -583,7 +583,7 @@ static long ir_lirc_ioctl(struct file *file, unsigned int 
cmd,
break;
 
case LIRC_SET_REC_TIMEOUT_REPORTS:
-   if (!dev->timeout)
+   if (dev->driver_type != RC_DRIVER_IR_RAW)
ret = -ENOTTY;
else
fh->send_timeout_reports = !!val;
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 6a720e9c7aa8..9f4df60f62e1 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -26,50 +26,50 @@ static const struct {
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_UNKNOWN] = { .name = "unknown", .repeat_period = 125 },
+   [RC_PROTO_OTHER] = { .name = "other", .repeat_period = 125 },
[RC_PROTO_RC5] = { .name = "rc-5",
-   .scancode_bits = 0x1f7f, .repeat_period = 250 },
+   .scancode_bits = 0x1f7f, .repeat_period = 114 },
[RC_PROTO_RC5X_20] = { .name = "rc-5x-20",
-   .scancode_bits = 0x1f7f3f, .repeat_period = 250 },
+   .scancode_bits = 0x1f7f3f, .repeat_period = 114 },
[RC_PROTO_RC5_SZ] = { .name = "rc-5-sz",
-   .scancode_bits = 0x2fff, .repeat_period = 250 },
+   .scancode_bits = 0x2fff, .repeat_period = 114 },
[RC_PROTO_JVC] = { .name = "jvc",
-   .scancode_bits = 0x, .repeat_period = 250 },
+   .scancode_bits = 0x, .repeat_period = 125 },
[RC_PROTO_SONY12] = { .name = "sony-12",
-   .scancode_bits = 0x1f007f, .repeat_period = 250 },
+   .scancode_bits = 0x1f007f, .repeat_period = 100 },
[RC_PROTO_SONY15] = { .name = "sony-15",
-   .scancode_bits = 0xff007f, .repeat_period = 250 },
+   .scancode_bits = 0xff007f, .repeat_period = 100 },
[RC_PROTO_SONY20] = { .name = "sony-20",
-   .scancode_bits = 0x1fff7f, .repeat_period = 250 },
+   .scancode_bits = 0x1fff7f, .repeat_period = 100 },
[RC_PROTO_NEC] = { .name = "nec",
-   .scancode_bits = 0x, .repeat_period = 250 },
+   .scancode_bits = 0x, .repeat_period = 110 },
[RC_PROTO_NECX] = { .name = "nec-x",
-   .scancode_bits = 0xff, .repeat_period = 250 },
+   .scancode_bits = 0xff, .repeat_period = 110 },
[RC_PROTO_NEC32] = { .name = "nec-32",
-   .scancode_bits = 0x, .repeat_period = 250 },
+   .scancode_bits = 0x, .repeat_period = 110 },
[RC_PROTO_SANYO] = { .name = "sanyo",
-   .scancode_bits = 0x1f, .repeat_period = 250 },
+   .scancode_bits = 0x1f, .repeat_period = 125 },
[RC_PROTO_MCIR2_KBD] = { .name = "mcir2-kbd",
-   .scancode_bits = 0x, .repeat_period = 250 },
+   .scancode_bits = 0x, .repeat_period = 100 },
[RC_PROTO_MCIR2_MSE] = { .name = "mcir2-mse",
-   .scancode_bits = 0x1f, .repeat_period = 250 },
+   .scancode_bits = 0x1f, .repeat_period = 100 },
[RC_PROTO_RC6_0] = { .name = "rc-6-0",
-   .scancode_bits = 0x, .repeat_period = 250 },
+   .scancode_bits = 0x, .repeat_period = 114 },
[RC_PROTO_RC6_6A_20] = { .name = "rc-6-6a-20",
-   .scancode_bits = 0xf, .repeat_period = 250 },
+   .scancode_bits = 0xf, .repeat_period = 114 },

[PATCH 2/3] media: rc: add ioctl to get the current timeout

2018-03-24 Thread Sean Young 
Since the kernel now modifies the timeout, make it possible to retrieve
the current value.

Signed-off-by: Sean Young 
---
 Documentation/media/uapi/rc/lirc-func.rst|  1 +
 Documentation/media/uapi/rc/lirc-set-rec-timeout.rst | 14 +-
 drivers/media/rc/lirc_dev.c  |  7 +++
 include/uapi/linux/lirc.h|  6 ++
 4 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/Documentation/media/uapi/rc/lirc-func.rst 
b/Documentation/media/uapi/rc/lirc-func.rst
index ddb4620de294..9656423a3f28 100644
--- a/Documentation/media/uapi/rc/lirc-func.rst
+++ b/Documentation/media/uapi/rc/lirc-func.rst
@@ -17,6 +17,7 @@ LIRC Function Reference
 lirc-get-rec-resolution
 lirc-set-send-duty-cycle
 lirc-get-timeout
+lirc-get-rec-timeout
 lirc-set-rec-timeout
 lirc-set-rec-carrier
 lirc-set-rec-carrier-range
diff --git a/Documentation/media/uapi/rc/lirc-set-rec-timeout.rst 
b/Documentation/media/uapi/rc/lirc-set-rec-timeout.rst
index b3e16bbdbc90..a833a6a4c25a 100644
--- a/Documentation/media/uapi/rc/lirc-set-rec-timeout.rst
+++ b/Documentation/media/uapi/rc/lirc-set-rec-timeout.rst
@@ -1,19 +1,23 @@
 .. -*- coding: utf-8; mode: rst -*-
 
 .. _lirc_set_rec_timeout:
+.. _lirc_get_rec_timeout:
 
-**
-ioctl LIRC_SET_REC_TIMEOUT
-**
+***
+ioctl LIRC_GET_REC_TIMEOUT and LIRC_SET_REC_TIMEOUT
+***
 
 Name
 
 
-LIRC_SET_REC_TIMEOUT - sets the integer value for IR inactivity timeout.
+LIRC_GET_REC_TIMEOUT/LIRC_SET_REC_TIMEOUT - Get/set the integer value for IR 
inactivity timeout.
 
 Synopsis
 
 
+.. c:function:: int ioctl( int fd, LIRC_GET_REC_TIMEOUT, __u32 *timeout )
+:name: LIRC_GET_REC_TIMEOUT
+
 .. c:function:: int ioctl( int fd, LIRC_SET_REC_TIMEOUT, __u32 *timeout )
 :name: LIRC_SET_REC_TIMEOUT
 
@@ -30,7 +34,7 @@ Arguments
 Description
 ===
 
-Sets the integer value for IR inactivity timeout.
+Get and set the integer value for IR inactivity timeout.
 
 If supported by the hardware, setting it to 0  disables all hardware timeouts
 and data should be reported as soon as possible. If the exact value
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 24e9fbb80e81..17f40c8e939f 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -575,6 +575,13 @@ static long ir_lirc_ioctl(struct file *file, unsigned int 
cmd,
}
break;
 
+   case LIRC_GET_REC_TIMEOUT:
+   if (!dev->timeout)
+   ret = -ENOTTY;
+   else
+   val = DIV_ROUND_UP(dev->timeout, 1000);
+   break;
+
case LIRC_SET_REC_TIMEOUT_REPORTS:
if (!dev->timeout)
ret = -ENOTTY;
diff --git a/include/uapi/linux/lirc.h b/include/uapi/linux/lirc.h
index 948d9a491083..7db6063fa6a2 100644
--- a/include/uapi/linux/lirc.h
+++ b/include/uapi/linux/lirc.h
@@ -134,6 +134,12 @@
 
 #define LIRC_SET_WIDEBAND_RECEIVER _IOW('i', 0x0023, __u32)
 
+/*
+ * Return the recording timeout, which is either set by
+ * the ioctl LIRC_SET_REC_TIMEOUT or by the kernel after setting the protocols.
+ */
+#define LIRC_GET_REC_TIMEOUT  _IOR('i', 0x0024, __u32)
+
 /*
  * struct lirc_scancode - decoded scancode with protocol for use with
  * LIRC_MODE_SCANCODE
-- 
2.14.3

Re: [PATCHv2 0/3] dw-hdmi: add property to disable CEC

2018-03-24 Thread Martin Blumenstingl 
Hi Neil,

On Sat, Mar 24, 2018 at 2:41 PM, Neil Armstrong  wrote:
> Hi Martin,
>
>> Le 24 mars 2018 à 12:00, Martin Blumenstingl 
>>  a écrit :
>>
>> Hello Hans, Hi Neil,
>>
>> (apologies in advance if any of this is wrong, I don't have any CEC
>> capable TV so I can't test it)
>>
>> On Fri, Mar 23, 2018 at 1:59 PM, Hans Verkuil  wrote:
>>> From: Hans Verkuil 
>>>
>>> Some boards (amlogic) have two CEC controllers: the DesignWare controller
>>> and their own CEC controller (meson ao-cec).
>> as far as I understand the Amlogic Meson SoCs have two domains:
>> - AO (always-on, powered even in suspend mode) where meson-ao-cec can
>> wake up the system from suspend
>> - EE (everything else, not powered during suspend) where dw-hdmi-cec lives
>>
>
> Exact, except … the EE CEC is not hooked to the DW-HDMI TX but the RX, and 
> thus cannot be used on GXBB/GXL/GXM.
I see, thank you for the explanation

>> this far everything is OK
>>
>>> Since the CEC line is not hooked up to the DW controller we need a way
>>> to disable that controller. This patch series adds the cec-disable
>>> property for that purpose.
>> drivers/pinctrl/meson/pinctrl-meson-gxbb.c has ao_cec_pins and
>> ee_cec_pins, both use GPIOAO_12
>> drivers/pinctrl/meson/pinctrl-meson-gxl.c has ao_cec_pins and
>> ee_cec_pins, both use GPIOAO_8
>>
>> @Neil: do you know if the CEC signal routing is:
>> ao_cec_pins -> meson-ao-cec
>> ee_cec_pins -> dw-hdmi-cec
>
> It’s hooked to the DW-HDMI RX IP used in the TV SoCs.
>
>>
>> I'm curious because if both CEC controllers can be used then it might
>> be worth mentioning this in the cover-letter and patch description
>>
>
> Initially I thought it was hooked to the DW-HDMI TX, but no, I guess I should 
> remove the ee_cec pinmux…
right, or rename it to ee_cec_rx (or something similar)


Regards
Martin

[PATCH 3/3] media: ov13858: Remove owner assignment from i2c_driver

2018-03-24 Thread Fabio Estevam 
From: Fabio Estevam 

Structure i2c_driver does not need to set the owner field, as this will
be populated by the driver core.

Generated by scripts/coccinelle/api/platform_no_drv_owner.cocci.

Cc: Sakari Ailus 
Signed-off-by: Fabio Estevam 
---
 drivers/media/i2c/ov13858.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c
index 30ee9f7..5b617a7 100644
--- a/drivers/media/i2c/ov13858.c
+++ b/drivers/media/i2c/ov13858.c
@@ -1805,7 +1805,6 @@ MODULE_DEVICE_TABLE(acpi, ov13858_acpi_ids);
 static struct i2c_driver ov13858_i2c_driver = {
.driver = {
.name = "ov13858",
-   .owner = THIS_MODULE,
.pm = _pm_ops,
.acpi_match_table = ACPI_PTR(ov13858_acpi_ids),
},
-- 
2.7.4

[PATCH 1/3] media: si2165: Remove owner assignment from i2c_driver

2018-03-24 Thread Fabio Estevam 
From: Fabio Estevam 

Structure i2c_driver does not need to set the owner field, as this will
be populated by the driver core.

Generated by scripts/coccinelle/api/platform_no_drv_owner.cocci.

Cc: Matthias Schwarzott 
Signed-off-by: Fabio Estevam 
---
 drivers/media/dvb-frontends/si2165.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index 2dd336f..d132e3c 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -1299,7 +1299,6 @@ MODULE_DEVICE_TABLE(i2c, si2165_id_table);
 
 static struct i2c_driver si2165_driver = {
.driver = {
-   .owner  = THIS_MODULE,
.name   = "si2165",
},
.probe  = si2165_probe,
-- 
2.7.4

[PATCH 2/3] media: ov5695: Remove owner assignment from i2c_driver

2018-03-24 Thread Fabio Estevam 
From: Fabio Estevam 

Structure i2c_driver does not need to set the owner field, as this will
be populated by the driver core.

Generated by scripts/coccinelle/api/platform_no_drv_owner.cocci.

Cc: Shunqian Zheng 
Signed-off-by: Fabio Estevam 
---
 drivers/media/i2c/ov5695.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/i2c/ov5695.c b/drivers/media/i2c/ov5695.c
index 9be38a0..9a80dec 100644
--- a/drivers/media/i2c/ov5695.c
+++ b/drivers/media/i2c/ov5695.c
@@ -1385,7 +1385,6 @@ MODULE_DEVICE_TABLE(of, ov5695_of_match);
 static struct i2c_driver ov5695_i2c_driver = {
.driver = {
.name = "ov5695",
-   .owner = THIS_MODULE,
.pm = _pm_ops,
.of_match_table = of_match_ptr(ov5695_of_match),
},
-- 
2.7.4

Re: [PATCHv2 0/3] dw-hdmi: add property to disable CEC

2018-03-24 Thread Neil Armstrong 
Hi Martin,

> Le 24 mars 2018 à 12:00, Martin Blumenstingl 
>  a écrit :
> 
> Hello Hans, Hi Neil,
> 
> (apologies in advance if any of this is wrong, I don't have any CEC
> capable TV so I can't test it)
> 
> On Fri, Mar 23, 2018 at 1:59 PM, Hans Verkuil  wrote:
>> From: Hans Verkuil 
>> 
>> Some boards (amlogic) have two CEC controllers: the DesignWare controller
>> and their own CEC controller (meson ao-cec).
> as far as I understand the Amlogic Meson SoCs have two domains:
> - AO (always-on, powered even in suspend mode) where meson-ao-cec can
> wake up the system from suspend
> - EE (everything else, not powered during suspend) where dw-hdmi-cec lives
> 

Exact, except … the EE CEC is not hooked to the DW-HDMI TX but the RX, and thus 
cannot be used on GXBB/GXL/GXM.

> this far everything is OK
> 
>> Since the CEC line is not hooked up to the DW controller we need a way
>> to disable that controller. This patch series adds the cec-disable
>> property for that purpose.
> drivers/pinctrl/meson/pinctrl-meson-gxbb.c has ao_cec_pins and
> ee_cec_pins, both use GPIOAO_12
> drivers/pinctrl/meson/pinctrl-meson-gxl.c has ao_cec_pins and
> ee_cec_pins, both use GPIOAO_8
> 
> @Neil: do you know if the CEC signal routing is:
> ao_cec_pins -> meson-ao-cec
> ee_cec_pins -> dw-hdmi-cec

It’s hooked to the DW-HDMI RX IP used in the TV SoCs.

> 
> I'm curious because if both CEC controllers can be used then it might
> be worth mentioning this in the cover-letter and patch description
> 

Initially I thought it was hooked to the DW-HDMI TX, but no, I guess I should 
remove the ee_cec pinmux…

Neil

> 
> Regards
> Martin

Re: [PATCH v2] media: ov5640: fix frame interval enumeration

2018-03-24 Thread Sakari Ailus 
Hi Hugues,

On Thu, Mar 08, 2018 at 04:07:14PM +0100, Hugues Fruchet wrote:
> Driver must reject frame interval enumeration of unsupported resolution.
> This was detected by v4l2-compliance format ioctl test:
> v4l2-compliance Format ioctls:
> info: found 2 frameintervals for pixel format 4745504a and size 176x144
>   fail: v4l2-test-formats.cpp(123):
>found frame intervals for invalid size 177x144
> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: FAIL
> 
> Signed-off-by: Hugues Fruchet 
> ---
> version 2:
>   - revisit patch according to Mauro comments:
> See 
> https://www.mail-archive.com/linux-media@vger.kernel.org/msg127380.html
> 
>  drivers/media/i2c/ov5640.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index 676f635..5c08124 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -1397,8 +1397,12 @@ static int ov5640_set_virtual_channel(struct 
> ov5640_dev *sensor)
>   break;
>   }
>  
> - if (nearest && i < 0)
> + if (i < 0) {
> + /* no match */
> + if (!nearest)
> + return NULL;
>   mode = _mode_data[fr][0];

I looked at the ov5640_find_mode() and its implementation is somewhat
different from what many other drivers use. Could you switch to
v4l2_find_nearest_size() instead?

There was a problem in my earlier pull request to Mauro but that should be
going in as it was intended Very Soon now.



If you need additional checks, you could put them to enum_frame_interval
itself.

What do you think?

> + }
>  
>   return mode;
>  }
> @@ -2381,8 +2385,14 @@ static int ov5640_s_frame_interval(struct v4l2_subdev 
> *sd,
>  
>   sensor->current_fr = frame_rate;
>   sensor->frame_interval = fi->interval;
> - sensor->current_mode = ov5640_find_mode(sensor, frame_rate, mode->width,
> - mode->height, true);
> + mode = ov5640_find_mode(sensor, frame_rate, mode->width,
> + mode->height, true);
> + if (!mode) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + sensor->current_mode = mode;
>   sensor->pending_mode_change = true;
>  out:
>   mutex_unlock(>lock);

-- 
Kind regards,

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

Re: [PATCHv2 0/3] dw-hdmi: add property to disable CEC

2018-03-24 Thread Martin Blumenstingl 
Hello Hans, Hi Neil,

(apologies in advance if any of this is wrong, I don't have any CEC
capable TV so I can't test it)

On Fri, Mar 23, 2018 at 1:59 PM, Hans Verkuil  wrote:
> From: Hans Verkuil 
>
> Some boards (amlogic) have two CEC controllers: the DesignWare controller
> and their own CEC controller (meson ao-cec).
as far as I understand the Amlogic Meson SoCs have two domains:
- AO (always-on, powered even in suspend mode) where meson-ao-cec can
wake up the system from suspend
- EE (everything else, not powered during suspend) where dw-hdmi-cec lives

this far everything is OK

> Since the CEC line is not hooked up to the DW controller we need a way
> to disable that controller. This patch series adds the cec-disable
> property for that purpose.
drivers/pinctrl/meson/pinctrl-meson-gxbb.c has ao_cec_pins and
ee_cec_pins, both use GPIOAO_12
drivers/pinctrl/meson/pinctrl-meson-gxl.c has ao_cec_pins and
ee_cec_pins, both use GPIOAO_8

@Neil: do you know if the CEC signal routing is:
ao_cec_pins -> meson-ao-cec
ee_cec_pins -> dw-hdmi-cec

I'm curious because if both CEC controllers can be used then it might
be worth mentioning this in the cover-letter and patch description


Regards
Martin

Re: [PATCH v3 2/2] media: ov2680: Add Omnivision OV2680 sensor driver

2018-03-24 Thread Sakari Ailus 
Hi Rui,

I wanted to go through the code the last time and I'd have a few review
comments below...

On Tue, Mar 13, 2018 at 11:33:11AM +, Rui Miguel Silva wrote:
...
> +static int ov2680_gain_set(struct ov2680_dev *sensor, bool auto_gain)
> +{
> + struct ov2680_ctrls *ctrls = >ctrls;
> + u32 gain;
> + int ret;
> +
> + ret = ov2680_mod_reg(sensor, OV2680_REG_R_MANUAL, BIT(1),
> +  auto_gain ? 0 : BIT(1));
> + if (ret < 0)
> + return ret;
> +
> + if (auto_gain || !ctrls->gain->is_new)
> + return 0;
> +
> + gain = ctrls->gain->val;
> +
> + ret = ov2680_write_reg16(sensor, OV2680_REG_GAIN_PK, gain);
> +
> + return 0;
> +}
> +
> +static int ov2680_gain_get(struct ov2680_dev *sensor)
> +{
> + u32 gain;
> + int ret;
> +
> + ret = ov2680_read_reg16(sensor, OV2680_REG_GAIN_PK, );
> + if (ret)
> + return ret;
> +
> + return gain;
> +}
> +
> +static int ov2680_auto_gain_enable(struct ov2680_dev *sensor)
> +{
> + return ov2680_gain_set(sensor, true);
> +}
> +
> +static int ov2680_auto_gain_disable(struct ov2680_dev *sensor)
> +{
> + return ov2680_gain_set(sensor, false);
> +}
> +
> +static int ov2680_exposure_set(struct ov2680_dev *sensor, bool auto_exp)
> +{
> + struct ov2680_ctrls *ctrls = >ctrls;
> + u32 exp;
> + int ret;
> +
> + ret = ov2680_mod_reg(sensor, OV2680_REG_R_MANUAL, BIT(0),
> +  auto_exp ? 0 : BIT(0));
> + if (ret < 0)
> + return ret;
> +
> + if (auto_exp || !ctrls->exposure->is_new)
> + return 0;
> +
> + exp = (u32)ctrls->exposure->val;
> + exp <<= 4;
> +
> + return ov2680_write_reg24(sensor, OV2680_REG_EXPOSURE_PK_HIGH, exp);
> +}
> +
> +static int ov2680_exposure_get(struct ov2680_dev *sensor)
> +{
> + int ret;
> + u32 exp;
> +
> + ret = ov2680_read_reg24(sensor, OV2680_REG_EXPOSURE_PK_HIGH, );
> + if (ret)
> + return ret;
> +
> + return exp >> 4;
> +}
> +
> +static int ov2680_auto_exposure_enable(struct ov2680_dev *sensor)
> +{
> + return ov2680_exposure_set(sensor, true);
> +}
> +
> +static int ov2680_auto_exposure_disable(struct ov2680_dev *sensor)
> +{
> + return ov2680_exposure_set(sensor, false);
> +}

I still think you could call the function actually doing the work, and pass
the bool parameter. That'd be much clearer. Please see the comments below,
too; they're related. Same for gain.

...

> +static int ov2680_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
> +{
> + struct v4l2_subdev *sd = ctrl_to_sd(ctrl);
> + struct ov2680_dev *sensor = to_ov2680_dev(sd);
> + int val;
> +
> + if (!sensor->is_enabled)
> + return 0;
> +
> + switch (ctrl->id) {
> + case V4L2_CID_AUTOGAIN:
> + if (!ctrl->val)
> + return 0;
> + val = ov2680_gain_get(sensor);
> + if (val < 0)
> + return val;
> + sensor->ctrls.gain->val = val;
> + break;
> + case V4L2_CID_EXPOSURE_AUTO:

I reckon the purpose of implementing volatile controls here would be to
provide the exposure and gain values to the user. But the controls here are
the ones enabling or disabling the automatic behaviour, not the value of
those settings themselves.

> + if (ctrl->val == V4L2_EXPOSURE_MANUAL)
> + return 0;
> + val = ov2680_exposure_get(sensor);
> + if (val < 0)
> + return val;
> + sensor->ctrls.exposure->val = val;
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static int ov2680_s_ctrl(struct v4l2_ctrl *ctrl)
> +{
> + struct v4l2_subdev *sd = ctrl_to_sd(ctrl);
> + struct ov2680_dev *sensor = to_ov2680_dev(sd);
> +
> + if (!sensor->is_enabled)
> + return 0;
> +
> + switch (ctrl->id) {
> + case V4L2_CID_AUTOGAIN:
> + return ov2680_gain_set(sensor, !!ctrl->val);
> + case V4L2_CID_EXPOSURE_AUTO:
> + return ov2680_exposure_set(sensor, !!ctrl->val);

With this, you can enable or disable automatic exposure and gain, but you
cannot manually set the values. Are such controls useful?

Unless I'm mistaken, exposure or gain are not settable, so you should make
them read-only controls. Or better, allow setting them if automatic control
is disabled.

> + case V4L2_CID_VFLIP:
> + if (sensor->is_streaming)
> + return -EBUSY;
> + if (ctrl->val)
> + return ov2680_vflip_enable(sensor);
> + else
> + return ov2680_vflip_disable(sensor);
> + case V4L2_CID_HFLIP:
> + if (ctrl->val)
> + return ov2680_hflip_enable(sensor);
> + else
> + return ov2680_hflip_disable(sensor);
> + case V4L2_CID_TEST_PATTERN:
> + return ov2680_test_pattern_set(sensor,