cron job: media_tree daily build: ERRORS

2018-01-28 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:   Mon Jan 29 05:00:16 CET 2018
media-tree git hash:4852fdca8818972d0ea5b5ce7114da628f9954a4
media_build git hash:   d17383327f00d45e6c07161876fb4f3d9d9358e1
v4l-utils git hash: c2cc9e17b1411865d40a0e7d3ab027204fc0cf19
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3911-g6f737e1f
smatch version: v0.5.0-3911-g6f737e1f
host hardware:  x86_64
host os:4.14.0-364

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: 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.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: WARNINGS
linux-3.10.1-i686: WARNINGS
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: ERRORS
linux-4.8-i686: ERRORS
linux-4.9.26-i686: ERRORS
linux-4.10.14-i686: WARNINGS
linux-4.11-i686: WARNINGS
linux-4.12.1-i686: WARNINGS
linux-4.13-i686: WARNINGS
linux-4.14-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: WARNINGS
linux-3.10.1-x86_64: WARNINGS
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: ERRORS
linux-4.8-x86_64: ERRORS
linux-4.9.26-x86_64: ERRORS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
linux-4.13-x86_64: WARNINGS
linux-4.14-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
smatch: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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


Re: [PATCH 2/2] drm: adv7511: Add support for i2c_new_secondary_device

2018-01-28 Thread Archit Taneja

Hi,

On 01/22/2018 06:20 PM, Kieran Bingham wrote:

The ADV7511 has four 256-byte maps that can be accessed via the main I²C
ports. Each map has it own I²C address and acts as a standard slave
device on the I²C bus.

Allow a device tree node to override the default addresses so that
address conflicts with other devices on the same bus may be resolved at
the board description level.

Signed-off-by: Kieran Bingham 
---
  .../bindings/display/bridge/adi,adv7511.txt| 10 +-
  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 +++
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 36 ++
  3 files changed, 37 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 0047b1394c70..f6bb9f6d3f48 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -70,6 +70,9 @@ Optional properties:
rather than generate its own timings for HDMI output.
  - clocks: from common clock binding: reference to the CEC clock.
  - clock-names: from common clock binding: must be "cec".
+- reg-names : Names of maps with programmable addresses.
+   It can contain any map needing a non-default address.
+   Possible maps names are : "main", "edid", "cec", "packet"
  
  Required nodes:
  
@@ -88,7 +91,12 @@ Example
  
  	adv7511w: hdmi@39 {

compatible = "adi,adv7511w";
-   reg = <39>;
+   /*
+* The EDID page will be accessible on address 0x66 on the i2c
+* bus. All other maps continue to use their default addresses.
+*/
+   reg = <0x39 0x66>;
+   reg-names = "main", "edid";
interrupt-parent = <&gpio3>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
clocks = <&cec_clock>;
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index d034b2cb5eee..7d81ce3808e0 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -53,8 +53,10 @@
  #define ADV7511_REG_POWER 0x41
  #define ADV7511_REG_STATUS0x42
  #define ADV7511_REG_EDID_I2C_ADDR 0x43
+#define ADV7511_REG_EDID_I2C_ADDR_DEFAULT  0x3f
  #define ADV7511_REG_PACKET_ENABLE10x44
  #define ADV7511_REG_PACKET_I2C_ADDR   0x45
+#define ADV7511_REG_PACKET_I2C_ADDR_DEFAULT0x38
  #define ADV7511_REG_DSD_ENABLE0x46
  #define ADV7511_REG_VIDEO_INPUT_CFG2  0x48
  #define ADV7511_REG_INFOFRAME_UPDATE  0x4a
@@ -89,6 +91,7 @@
  #define ADV7511_REG_TMDS_CLOCK_INV0xde
  #define ADV7511_REG_ARC_CTRL  0xdf
  #define ADV7511_REG_CEC_I2C_ADDR  0xe1
+#define ADV7511_REG_CEC_I2C_ADDR_DEFAULT   0x3c


Minor comment: The defines above make look like new register
defines. It would be nice to remove the "REG_" from them, and
place them somewhere after the register definitions.


  #define ADV7511_REG_CEC_CTRL  0xe2
  #define ADV7511_REG_CHIP_ID_HIGH  0xf5
  #define ADV7511_REG_CHIP_ID_LOW   0xf6
@@ -322,6 +325,7 @@ struct adv7511 {
struct i2c_client *i2c_main;
struct i2c_client *i2c_edid;
struct i2c_client *i2c_cec;
+   struct i2c_client *i2c_packet;
  
  	struct regmap *regmap;

struct regmap *regmap_cec;
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index efa29db5fc2b..7ec33837752b 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -969,8 +969,8 @@ static int adv7511_init_cec_regmap(struct adv7511 *adv)
  {
int ret;
  
-	adv->i2c_cec = i2c_new_dummy(adv->i2c_main->adapter,

-adv->i2c_main->addr - 1);


This patch avoids deriving the CEC/EDID map addresses from the main map. I think this would break 
what the original patch tried to do:


d25a4cbba4b9da7c2d674b2f8ecf84af1b24988e
"drm/bridge: adv7511: add support for the 2nd chip"

Maybe the default macros can be a function of the main address?



+   adv->i2c_cec = i2c_new_secondary_device(adv->i2c_main, "cec",
+   ADV7511_REG_CEC_I2C_ADDR_DEFAULT);


Also, I'm a bit unclear on the default address values. For example, previously, 
the CEC
address was calculated as "adv->i2c_main->addr - 1", which is 0x38. The new 
CEC_I2C_ADDR_DEFAULT
define sets it to 0x3c.

Thanks,
Archit


if (!adv->i2c_cec)
return -ENOMEM;
i2c_set_clientdata(adv->i2c_cec, adv);
@@ -1082,8 +1082,6 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
struct adv7511_link_config

Re: Regression in VB2 alloc prepare/finish balancing with em28xx/au0828

2018-01-28 Thread Sakari Ailus
Hi Devin,

On Sun, Jan 28, 2018 at 09:12:44AM -0500, Devin Heitmueller wrote:
> Hello all,
> 
> I recently updated to the latest kernel, and I am seeing the following
> dumped to dmesg with both au0828 and em28xx based devices whenever I
> exit tvtime (my kernel is compiled with CONFIG_VIDEO_ADV_DEBUG=y by
> default):

Thanks for reporting this. Would you be able to provide the full dmesg,
with VB2 debug parameter set to 2?

I can't immediately see how you'd get this, well, without triggering a
kernel warning or two. The code is pretty complex though.

Cc Hans.

> 
> [  129.219666] vb2: counters for queue 88026463ac48:
> [  129.219667] vb2: setup: 1 start_streaming: 2 stop_streaming: 2
> [  129.219667] vb2: wait_prepare: 0 wait_finish: 0
> [  129.219668] vb2:   counters for queue 88026463ac48, buffer 0: 
> UNBALANCED!
> [  129.219669] vb2: buf_init: 1 buf_cleanup: 1 buf_prepare: 14
> buf_finish: 14
> [  129.219669] vb2: buf_queue: 13 buf_done: 13
> [  129.219673] vb2: alloc: 1 put: 1 prepare: 14 finish: 13 mmap: 1
> [  129.219674] vb2: get_userptr: 0 put_userptr: 0
> [  129.219674] vb2: attach_dmabuf: 0 detach_dmabuf: 0 map_dmabuf:
> 0 unmap_dmabuf: 0
> [  129.219675] vb2: get_dmabuf: 0 num_users: 0 vaddr: 13 cookie: 0
> [  129.219676] vb2:   counters for queue 88026463ac48, buffer 1: 
> UNBALANCED!
> [  129.219676] vb2: buf_init: 1 buf_cleanup: 1 buf_prepare: 13
> buf_finish: 13
> [  129.219677] vb2: buf_queue: 12 buf_done: 12
> [  129.219678] vb2: alloc: 1 put: 1 prepare: 13 finish: 12 mmap: 1
> [  129.219678] vb2: get_userptr: 0 put_userptr: 0
> [  129.219679] vb2: attach_dmabuf: 0 detach_dmabuf: 0 map_dmabuf:
> 0 unmap_dmabuf: 0
> [  129.219679] vb2: get_dmabuf: 0 num_users: 0 vaddr: 12 cookie: 0
> [  129.219680] vb2:   counters for queue 88026463ac48, buffer 2: 
> UNBALANCED!
> [  129.219680] vb2: buf_init: 1 buf_cleanup: 1 buf_prepare: 13
> buf_finish: 13
> [  129.219681] vb2: buf_queue: 12 buf_done: 12
> [  129.219682] vb2: alloc: 1 put: 1 prepare: 13 finish: 12 mmap: 1
> [  129.219682] vb2: get_userptr: 0 put_userptr: 0
> [  129.219683] vb2: attach_dmabuf: 0 detach_dmabuf: 0 map_dmabuf:
> 0 unmap_dmabuf: 0
> [  129.219683] vb2: get_dmabuf: 0 num_users: 0 vaddr: 12 cookie: 0
> [  129.219684] vb2:   counters for queue 88026463ac48, buffer 3: 
> UNBALANCED!
> [  129.219684] vb2: buf_init: 1 buf_cleanup: 1 buf_prepare: 13
> buf_finish: 13
> [  129.219685] vb2: buf_queue: 12 buf_done: 12
> [  129.219686] vb2: alloc: 1 put: 1 prepare: 13 finish: 12 mmap: 1
> [  129.219686] vb2: get_userptr: 0 put_userptr: 0
> [  129.219687] vb2: attach_dmabuf: 0 detach_dmabuf: 0 map_dmabuf:
> 0 unmap_dmabuf: 0
> [  129.219687] vb2: get_dmabuf: 0 num_users: 0 vaddr: 12 cookie: 0
> 
> The above suggests that the prepare/finish calls are unbalanced.  I
> added a bit of debug and identified that it only occurs with the video
> node; it's not happening with the VBI node (which when using tvtime
> makes use of the read() emulation done by videobuf2).
> 
> I went through a git bisect, and came up with the following patch
> which introduced the issue:
> 
> commit a136f59c0a1f1b09eb203951975e3fc5e8d3e722
> Author: Sakari Ailus 
> Date:   Wed May 31 11:17:26 2017 -0300
> 
> [media] vb2: Move buffer cache synchronisation to prepare from queue
> 
> The buffer cache should be synchronised in buffer preparation, not when
> the buffer is queued to the device. Fix this.
> 
> Mmap buffers do not need cache synchronisation since they are always
> coherent.
> 
> Signed-off-by: Sakari Ailus 
> Acked-by: Hans Verkuil 
> Signed-off-by: Mauro Carvalho Chehab 
> 
> It's not clear to me whether this is really a regression in videobuf2,
> or if it's a change in behavior that exposes some improper handling in
> em28xx/au0828 when the device node is closed.
> 
> To reproduce:
> 
> 1.  compile kernel with CONFIG_VIDEO_ADV_DEBUG=y
> 2.  Plug in au0828 or em28xx device (reproduced with HVR-950 and HVR-950q)
> 3.  start tvtime
> 4.  exit tvtime
> 
> I don't claim to be videobuf2 expert, so any advice that could be
> offered with regards to a fix (either in videobuf2 or in au0828) would
> certainly be welcome.
> 
> Thanks in advance,
> 
> Devin
> 
> -- 
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com

-- 
Sakari Ailus
sakari.ai...@linux.intel.com


[PATCH] media: mantis: remove mantis_vp3028.c/mantis_vp3028.h

2018-01-28 Thread Corentin Labbe
Thoses files are unused since commit b3b961448f70 ("V4L/DVB (13795): 
[Mantis/Hopper] Code overhaul, add Hopper devices into the PCI ID list")
8 year after, we could remove it.

Signed-off-by: Corentin Labbe 
---
 drivers/media/pci/mantis/mantis_vp3028.c | 38 
 drivers/media/pci/mantis/mantis_vp3028.h | 33 ---
 2 files changed, 71 deletions(-)
 delete mode 100644 drivers/media/pci/mantis/mantis_vp3028.c
 delete mode 100644 drivers/media/pci/mantis/mantis_vp3028.h

diff --git a/drivers/media/pci/mantis/mantis_vp3028.c 
b/drivers/media/pci/mantis/mantis_vp3028.c
deleted file mode 100644
index 4155c838a18a..
--- a/drivers/media/pci/mantis/mantis_vp3028.c
+++ /dev/null
@@ -1,38 +0,0 @@
-/*
-   Mantis VP-3028 driver
-
-   Copyright (C) Manu Abraham (abraham.m...@gmail.com)
-
-   This program is free software; you can redistribute it and/or modify
-   it under the terms of the GNU General Public License as published by
-   the Free Software Foundation; either version 2 of the License, or
-   (at your option) any later version.
-
-   This program is distributed in the hope that it will be useful,
-   but WITHOUT ANY WARRANTY; without even the implied warranty of
-   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-   GNU General Public License for more details.
-
-   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., 675 Mass Ave, Cambridge, MA 02139, USA.
-*/
-
-#include "mantis_common.h"
-#include "mantis_vp3028.h"
-
-struct zl10353_config mantis_vp3028_config = {
-   .demod_address  = 0x0f,
-};
-
-#define MANTIS_MODEL_NAME  "VP-3028"
-#define MANTIS_DEV_TYPE"DVB-T"
-
-struct mantis_hwconfig vp3028_mantis_config = {
-   .model_name = MANTIS_MODEL_NAME,
-   .dev_type   = MANTIS_DEV_TYPE,
-   .ts_size= MANTIS_TS_188,
-   .baud_rate  = MANTIS_BAUD_9600,
-   .parity = MANTIS_PARITY_NONE,
-   .bytes  = 0,
-};
diff --git a/drivers/media/pci/mantis/mantis_vp3028.h 
b/drivers/media/pci/mantis/mantis_vp3028.h
deleted file mode 100644
index 34130d29e0aa..
--- a/drivers/media/pci/mantis/mantis_vp3028.h
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
-   Mantis VP-3028 driver
-
-   Copyright (C) Manu Abraham (abraham.m...@gmail.com)
-
-   This program is free software; you can redistribute it and/or modify
-   it under the terms of the GNU General Public License as published by
-   the Free Software Foundation; either version 2 of the License, or
-   (at your option) any later version.
-
-   This program is distributed in the hope that it will be useful,
-   but WITHOUT ANY WARRANTY; without even the implied warranty of
-   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-   GNU General Public License for more details.
-
-   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., 675 Mass Ave, Cambridge, MA 02139, USA.
-*/
-
-#ifndef __MANTIS_VP3028_H
-#define __MANTIS_VP3028_H
-
-#include 
-#include "mantis_common.h"
-#include "zl10353.h"
-
-#define MANTIS_VP_3028_DVB_T   0x0028
-
-extern struct zl10353_config mantis_vp3028_config;
-extern struct mantis_hwconfig vp3028_mantis_config;
-
-#endif /* __MANTIS_VP3028_H */
-- 
2.13.6



[PATCH] media: rc: prev_ev is dead code, every call is a new edge

2018-01-28 Thread Sean Young
The raw kfifo should never contain successive pulse events or space
events. If it did occur, The IR decoders would not be able to deal
with this anyway. There is no need to check that a raw timing event
is a transition: it always is.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-mce_kbd-decoder.c | 6 --
 drivers/media/rc/ir-rc5-decoder.c | 3 ---
 drivers/media/rc/ir-rc6-decoder.c | 9 +
 drivers/media/rc/rc-core-priv.h   | 6 --
 drivers/media/rc/rc-ir-raw.c  | 1 -
 5 files changed, 1 insertion(+), 24 deletions(-)

diff --git a/drivers/media/rc/ir-mce_kbd-decoder.c 
b/drivers/media/rc/ir-mce_kbd-decoder.c
index 2c3df02e05ff..fb318bdd6193 100644
--- a/drivers/media/rc/ir-mce_kbd-decoder.c
+++ b/drivers/media/rc/ir-mce_kbd-decoder.c
@@ -262,9 +262,6 @@ static int ir_mce_kbd_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
return 0;
 
case STATE_HEADER_BIT_END:
-   if (!is_transition(&ev, &dev->raw->prev_ev))
-   break;
-
decrease_duration(&ev, MCIR2_BIT_END);
 
if (data->count != MCIR2_HEADER_NBITS) {
@@ -301,9 +298,6 @@ static int ir_mce_kbd_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
return 0;
 
case STATE_BODY_BIT_END:
-   if (!is_transition(&ev, &dev->raw->prev_ev))
-   break;
-
if (data->count == data->wanted_bits)
data->state = STATE_FINISHED;
else
diff --git a/drivers/media/rc/ir-rc5-decoder.c 
b/drivers/media/rc/ir-rc5-decoder.c
index 11a28f8772da..dd41d389f8d2 100644
--- a/drivers/media/rc/ir-rc5-decoder.c
+++ b/drivers/media/rc/ir-rc5-decoder.c
@@ -88,9 +88,6 @@ static int ir_rc5_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
return 0;
 
case STATE_BIT_END:
-   if (!is_transition(&ev, &dev->raw->prev_ev))
-   break;
-
if (data->count == CHECK_RC5X_NBITS)
data->state = STATE_CHECK_RC5X;
else
diff --git a/drivers/media/rc/ir-rc6-decoder.c 
b/drivers/media/rc/ir-rc6-decoder.c
index 55bb19bbd4e9..3e3659c0875c 100644
--- a/drivers/media/rc/ir-rc6-decoder.c
+++ b/drivers/media/rc/ir-rc6-decoder.c
@@ -145,9 +145,6 @@ static int ir_rc6_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
return 0;
 
case STATE_HEADER_BIT_END:
-   if (!is_transition(&ev, &dev->raw->prev_ev))
-   break;
-
if (data->count == RC6_HEADER_NBITS)
data->state = STATE_TOGGLE_START;
else
@@ -165,8 +162,7 @@ static int ir_rc6_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
return 0;
 
case STATE_TOGGLE_END:
-   if (!is_transition(&ev, &dev->raw->prev_ev) ||
-   !geq_margin(ev.duration, RC6_TOGGLE_END, RC6_UNIT / 2))
+   if (!geq_margin(ev.duration, RC6_TOGGLE_END, RC6_UNIT / 2))
break;
 
if (!(data->header & RC6_STARTBIT_MASK)) {
@@ -210,9 +206,6 @@ static int ir_rc6_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
break;
 
case STATE_BODY_BIT_END:
-   if (!is_transition(&ev, &dev->raw->prev_ev))
-   break;
-
if (data->count == data->wanted_bits)
data->state = STATE_FINISHED;
else
diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
index 458e9eb2d6a9..96a941aa2581 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -54,7 +54,6 @@ struct ir_raw_event_ctrl {
struct timer_list edge_handle;
 
/* raw decoder state follows */
-   struct ir_raw_event prev_ev;
struct ir_raw_event this_ev;
struct nec_dec {
int state;
@@ -130,11 +129,6 @@ static inline bool eq_margin(unsigned d1, unsigned d2, 
unsigned margin)
return ((d1 > (d2 - margin)) && (d1 < (d2 + margin)));
 }
 
-static inline bool is_transition(struct ir_raw_event *x, struct ir_raw_event 
*y)
-{
-   return x->pulse != y->pulse;
-}
-
 static inline void decrease_duration(struct ir_raw_event *ev, unsigned 
duration)
 {
if (duration > ev->duration)
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 18504870b9f0..ea96df49f176 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -32,7 +32,6 @@ static int ir_raw_event_thread(void *data)
handler->protocols || !handler->protocols)
handler->decode(raw->dev, ev);
ir_lirc_raw_event(raw->dev, ev);
-   raw->prev_ev = ev;
}
mutex_unlock(&ir_raw_handler_lock);
 
-- 
2.14.3



BUSINESS PROPOSAL (DATE 28/1/2018)

2018-01-28 Thread 50ª Vara do Trabalho de São Paulo
 I am Mrs. Fatimah Hassan.I have picked your email address for an 
inheritance of $250,000,000 Million Dollars.Please contact me for more 
details via   
 email:   fatimahha...@hotmail.comif interested.
.




Regression in VB2 alloc prepare/finish balancing with em28xx/au0828

2018-01-28 Thread Devin Heitmueller
Hello all,

I recently updated to the latest kernel, and I am seeing the following
dumped to dmesg with both au0828 and em28xx based devices whenever I
exit tvtime (my kernel is compiled with CONFIG_VIDEO_ADV_DEBUG=y by
default):

[  129.219666] vb2: counters for queue 88026463ac48:
[  129.219667] vb2: setup: 1 start_streaming: 2 stop_streaming: 2
[  129.219667] vb2: wait_prepare: 0 wait_finish: 0
[  129.219668] vb2:   counters for queue 88026463ac48, buffer 0: UNBALANCED!
[  129.219669] vb2: buf_init: 1 buf_cleanup: 1 buf_prepare: 14
buf_finish: 14
[  129.219669] vb2: buf_queue: 13 buf_done: 13
[  129.219673] vb2: alloc: 1 put: 1 prepare: 14 finish: 13 mmap: 1
[  129.219674] vb2: get_userptr: 0 put_userptr: 0
[  129.219674] vb2: attach_dmabuf: 0 detach_dmabuf: 0 map_dmabuf:
0 unmap_dmabuf: 0
[  129.219675] vb2: get_dmabuf: 0 num_users: 0 vaddr: 13 cookie: 0
[  129.219676] vb2:   counters for queue 88026463ac48, buffer 1: UNBALANCED!
[  129.219676] vb2: buf_init: 1 buf_cleanup: 1 buf_prepare: 13
buf_finish: 13
[  129.219677] vb2: buf_queue: 12 buf_done: 12
[  129.219678] vb2: alloc: 1 put: 1 prepare: 13 finish: 12 mmap: 1
[  129.219678] vb2: get_userptr: 0 put_userptr: 0
[  129.219679] vb2: attach_dmabuf: 0 detach_dmabuf: 0 map_dmabuf:
0 unmap_dmabuf: 0
[  129.219679] vb2: get_dmabuf: 0 num_users: 0 vaddr: 12 cookie: 0
[  129.219680] vb2:   counters for queue 88026463ac48, buffer 2: UNBALANCED!
[  129.219680] vb2: buf_init: 1 buf_cleanup: 1 buf_prepare: 13
buf_finish: 13
[  129.219681] vb2: buf_queue: 12 buf_done: 12
[  129.219682] vb2: alloc: 1 put: 1 prepare: 13 finish: 12 mmap: 1
[  129.219682] vb2: get_userptr: 0 put_userptr: 0
[  129.219683] vb2: attach_dmabuf: 0 detach_dmabuf: 0 map_dmabuf:
0 unmap_dmabuf: 0
[  129.219683] vb2: get_dmabuf: 0 num_users: 0 vaddr: 12 cookie: 0
[  129.219684] vb2:   counters for queue 88026463ac48, buffer 3: UNBALANCED!
[  129.219684] vb2: buf_init: 1 buf_cleanup: 1 buf_prepare: 13
buf_finish: 13
[  129.219685] vb2: buf_queue: 12 buf_done: 12
[  129.219686] vb2: alloc: 1 put: 1 prepare: 13 finish: 12 mmap: 1
[  129.219686] vb2: get_userptr: 0 put_userptr: 0
[  129.219687] vb2: attach_dmabuf: 0 detach_dmabuf: 0 map_dmabuf:
0 unmap_dmabuf: 0
[  129.219687] vb2: get_dmabuf: 0 num_users: 0 vaddr: 12 cookie: 0

The above suggests that the prepare/finish calls are unbalanced.  I
added a bit of debug and identified that it only occurs with the video
node; it's not happening with the VBI node (which when using tvtime
makes use of the read() emulation done by videobuf2).

I went through a git bisect, and came up with the following patch
which introduced the issue:

commit a136f59c0a1f1b09eb203951975e3fc5e8d3e722
Author: Sakari Ailus 
Date:   Wed May 31 11:17:26 2017 -0300

[media] vb2: Move buffer cache synchronisation to prepare from queue

The buffer cache should be synchronised in buffer preparation, not when
the buffer is queued to the device. Fix this.

Mmap buffers do not need cache synchronisation since they are always
coherent.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

It's not clear to me whether this is really a regression in videobuf2,
or if it's a change in behavior that exposes some improper handling in
em28xx/au0828 when the device node is closed.

To reproduce:

1.  compile kernel with CONFIG_VIDEO_ADV_DEBUG=y
2.  Plug in au0828 or em28xx device (reproduced with HVR-950 and HVR-950q)
3.  start tvtime
4.  exit tvtime

I don't claim to be videobuf2 expert, so any advice that could be
offered with regards to a fix (either in videobuf2 or in au0828) would
certainly be welcome.

Thanks in advance,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com