date:20160701

Re: [PATCH] [media] rc: ir-spi: add support for IR LEDs connected with SPI

2016-07-01 Thread kbuild test robot

Hi,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.7-rc5 next-20160701]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andi-Shyti/rc-ir-spi-add-support-for-IR-LEDs-connected-with-SPI/20160702-102955
base:   git://linuxtv.org/media_tree.git master
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   include/linux/compiler.h:232:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
   drivers/media/rc/ir-spi.c:156:14: sparse: undefined identifier 
'LIRC_SET_LENGTH'
>> drivers/media/rc/ir-spi.c:156:14: sparse: incompatible types for 'case' 
>> statement
   drivers/media/rc/ir-spi.c:156:14: sparse: Expected constant expression in 
case statement
   drivers/media/rc/ir-spi.c: In function 'ir_spi_chardev_ioctl':
   drivers/media/rc/ir-spi.c:156:7: error: 'LIRC_SET_LENGTH' undeclared (first 
use in this function)
 case LIRC_SET_LENGTH: {
  ^~~
   drivers/media/rc/ir-spi.c:156:7: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/case +156 drivers/media/rc/ir-spi.c

   140  
   141  static long ir_spi_chardev_ioctl(struct file *file, unsigned int cmd,
   142  unsigned long arg)
   143  {
   144  __u32 p;
   145  s32 ret;
   146  struct ir_spi_data *idata = file->private_data;
   147  
   148  switch (cmd) {
   149  case LIRC_GET_FEATURES:
   150  return put_user(idata->lirc_driver.features,
   151  (__u32 __user *) arg);
   152  
   153  case LIRC_GET_LENGTH:
   154  return put_user(idata->xfer.len, (__u32 __user *) arg);
   155  
 > 156  case LIRC_SET_LENGTH: {
   157  void *new;
   158  
   159  ret = get_user(p, (__u32 __user *) arg);
   160  if (ret)
   161  return ret;
   162  
   163  /*
   164   * the user is trying to set the same

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 28/38] v4l: Add signal lock status to source change events

2016-07-01 Thread Steve Longerbeam




On 07/01/2016 12:24 AM, Hans Verkuil wrote:

On 06/15/2016 12:49 AM, Steve Longerbeam wrote:

Add a signal lock status change to the source changes bitmask.
This indicates there was a signal lock or unlock event detected
at the input of a video decoder.

Signed-off-by: Steve Longerbeam 
---
  Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 12 ++--
  include/uapi/linux/videodev2.h |  1 +
  2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml 
b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
index c9c3c77..7758ad7 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -233,8 +233,9 @@

  This event is triggered when a source parameter change is
   detected during runtime by the video device. It can be a
-  runtime resolution change triggered by a video decoder or the
-  format change happening on an input connector.
+  runtime resolution change or signal lock status change
+  triggered by a video decoder, or the format change happening
+  on an input connector.
   This event requires that the id
   matches the input index (when used with a video device node)
   or the pad index (when used with a subdevice node) from which
@@ -461,6 +462,13 @@
from a video decoder.

  
+ 
+   V4L2_EVENT_SRC_CH_LOCK_STATUS
+   0x0002
+   This event gets triggered when there is a signal lock or
+   unlock detected at the input of a video decoder.
+   
+ 

I'm not entirely sure I like this. Typically losing lock means that this event
is triggered with the V4L2_EVENT_SRC_CH_RESOLUTION flag set, and userspace has
to check the new timings etc., which will fail if there is no lock anymore.

This information is also available through ENUMINPUT.

I would need to know more about why you think this is needed, because I don't
see what this adds.


Hi Hans,

At least on the ADV718x, a source resolution change (from an 
autodetected video
standard change) and a signal lock status change are distinct events. 
For example
there can be a temporary loss of input signal lock without a change in 
detected

input video standard/resolution.

Steve

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

Re: [PATCH] [media] rc: ir-spi: add support for IR LEDs connected with SPI

2016-07-01 Thread kbuild test robot

Hi,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.7-rc5 next-20160701]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andi-Shyti/rc-ir-spi-add-support-for-IR-LEDs-connected-with-SPI/20160702-102955
base:   git://linuxtv.org/media_tree.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/media/rc/ir-spi.c: In function 'ir_spi_chardev_ioctl':
>> drivers/media/rc/ir-spi.c:156:7: error: 'LIRC_SET_LENGTH' undeclared (first 
>> use in this function)
 case LIRC_SET_LENGTH: {
  ^~~
   drivers/media/rc/ir-spi.c:156:7: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/LIRC_SET_LENGTH +156 drivers/media/rc/ir-spi.c

   150  return put_user(idata->lirc_driver.features,
   151  (__u32 __user *) arg);
   152  
   153  case LIRC_GET_LENGTH:
   154  return put_user(idata->xfer.len, (__u32 __user *) arg);
   155  
 > 156  case LIRC_SET_LENGTH: {
   157  void *new;
   158  
   159  ret = get_user(p, (__u32 __user *) arg);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH 00/38] i.MX5/6 Video Capture

2016-07-01 Thread Steve Longerbeam


Hi Tim,

Pardon late reply, I'm on vacation. See below...


On 06/28/2016 11:54 AM, Tim Harvey wrote:

On Tue, Jun 14, 2016 at 3:48 PM, Steve Longerbeam  wrote:

Tested on imx6q SabreAuto with ADV7180, and imx6q SabreSD with
mipi-csi2 OV5640. There is device-tree support also for imx6qdl
SabreLite, but that is not tested. Also, this driver should
theoretically work on i.MX5 targets, but that is also untested.

Not run through v4l2-compliance yet, but that is in my queue.



Steve,

I've tested this series successfully with a Gateworks Ventana GW5300
which has an IMX6Q and an adv7180 attached to IPU2_CSI1.

First of all, a big 'thank you' for taking the time to rebase and
re-submit this series!

However based on the lack of feedback of the individual patches as
well as the fact they touch varied subsystems I think we are going to
have better luck getting this functionality accepted if you broke it
into separate series.

Here are my thoughts:


   gpu: ipu-v3: Add Video Deinterlacer unit
   gpu: ipu-cpmem: Add ipu_cpmem_set_uv_offset()
   gpu: ipu-cpmem: Add ipu_cpmem_get_burstsize()
   gpu: ipu-v3: Add ipu_get_num()
   gpu: ipu-v3: Add IDMA channel linking support
   gpu: ipu-v3: Add ipu_set_vdi_src_mux()
   gpu: ipu-v3: Add VDI input IDMAC channels
   gpu: ipu-v3: Add ipu_csi_set_src()
   gpu: ipu-v3: Add ipu_ic_set_src()
   gpu: ipu-v3: set correct full sensor frame for PAL/NTSC
   gpu: ipu-v3: Fix CSI data format for 16-bit media bus formats
   gpu: ipu-v3: Fix IRT usage
   gpu: ipu-v3: Fix CSI0 blur in NTSC format
   gpu: ipu-ic: Add complete image conversion support with tiling
   gpu: ipu-ic: allow multiple handles to ic
   gpu: ipu-v3: rename CSI client device

These are all enhancements to the ipu-v3 driver shared by DRM and
maintained by Philipp Zabel and there is no way to 'stage' them.


Just a note here, all these patches to ipu-v3 driver are to the
capture units, and should have no effect on DRM.


Philipp, these have bee submitted previously with little to no changes
or feedback - can we get sign-off or comment on these from you?

Next I would submit the set of drivers that depend on the above into
staging as Hans has said he would accept those (assuming the deps are
accepted). Also, you should submit the drivers first in your series,
then the imx6q.dtsi/imx6qdl.dtsi patches following such as:


   media: imx: Add MIPI CSI-2 Receiver driver
   media: Add camera interface driver for i.MX5/6
   media: Add i.MX5/6 mem2mem driver
   media: imx: Add video switch
   ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers
   ARM: dts: imx6qdl: Add mipi_ipu1/2 video muxes, mipi_csi, and their 
connections
   ARM: dts: imx6qdl: Flesh out MIPI CSI2 receiver node
   ARM: dts: imx6qdl: add mem2mem device for sabre* boards


Ok I will reorder the patches.


I think this last one should add the mem2mem nodes to imx6q.dtsi and
imx6dl.dtsi to be useable by all boards with IPUs right?


Yeah, I'll move the mem2mem nodes to imx6qdl.dtsi and imx6q.dtsi.



After this we have a platform that many imx6 boards with capture
devices can build on.

In parallel, you have a couple of other dependencies before saber*
boards have full capture support that need to through other trees:


   gpio: pca953x: Add reset-gpios property

This should be submitted through the linux-gpio list/subsystem.


I've really got a lot on my plate, I'd appreciate if someone else
could help me out with that.




   clocksource/drivers/imx: add input capture support

Not sure what path this one goes through but it looks to me this patch
adds a feature that only some boards may require (input-capture).


Well, the input-capture support should be usable by any imx6 based
target, and not just for v4l2 subsystem.




   media: imx: Add support for MIPI CSI-2 OV5640
   media: imx: Add support for Parallel OV5642

shouldn't these be subdev drivers?


Well, they _are_ subdev drivers. I guess you mean they should be
moved to drivers/media/i2c? Agreed, at some point they need some
cleaning up and probably consolidated into a single subdev and moved
there.


  Perhaps the can make it into
staging at least in the form you have them now.


   v4l: Add signal lock status to source change events
   media: imx: Add support for ADV7180 Video Decoder

These should be dropped (the 1st is a dependency of the 2nd) and
instead we should be using the subdev driver. I believe you have this
working, and I have been somewhat successful with some of your patches
as well although I still have a 'rolling image' and do not appear to
be getting signal detect interrupts after the first one (which is
likely causing the rolling).


Tim, I've started a new branch 'adv718x' in my mediatree github fork
and moved all the patches to drivers/media/i2c/adv7180.c there. Note
the first commit in that branch!

As I'm currently on vacation and away from the h/w I won't be able to test
this branch with imx6 backend until I return on 7/6. Once the branch is

cron job: media_tree daily build: ERRORS

2016-07-01 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:   Sat Jul  2 04:00:27 CEST 2016
git branch: test
git hash:   d81295d1bed850335f9f4ccb6b1aa4f6a123d4f0
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3428-gdfe27cf
host hardware:  x86_64
host os:4.6.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mtk: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-pxa: 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: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
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.23-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-i686: ERRORS
linux-4.1.1-i686: ERRORS
linux-4.2-i686: ERRORS
linux-4.3-i686: ERRORS
linux-4.4-i686: OK
linux-4.5-i686: OK
linux-4.6-i686: OK
linux-4.7-rc1-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
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.23-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-x86_64: ERRORS
linux-4.1.1-x86_64: ERRORS
linux-4.2-x86_64: ERRORS
linux-4.3-x86_64: ERRORS
linux-4.4-x86_64: OK
linux-4.5-x86_64: OK
linux-4.6-x86_64: OK
linux-4.7-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 10/11] Input: synaptics-rmi4 - add support for F54 diagnostics

2016-07-01 Thread Andrew Duggan


On 06/30/2016 10:38 AM, Nick Dyer wrote:

Function 54 implements access to various RMI4 diagnostic features.

This patch adds support for retrieving this data. It registers a V4L2
device to output the data to user space.

Signed-off-by: Nick Dyer 


Tested-by: Andrew Duggan 


---
  drivers/input/rmi4/Kconfig  |  11 +
  drivers/input/rmi4/Makefile |   1 +
  drivers/input/rmi4/rmi_bus.c|   3 +
  drivers/input/rmi4/rmi_driver.h |   1 +
  drivers/input/rmi4/rmi_f54.c| 754 
  5 files changed, 770 insertions(+)
  create mode 100644 drivers/input/rmi4/rmi_f54.c

diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig
index f73df24..f3418b6 100644
--- a/drivers/input/rmi4/Kconfig
+++ b/drivers/input/rmi4/Kconfig
@@ -61,3 +61,14 @@ config RMI4_F30
  
  	  Function 30 provides GPIO and LED support for RMI4 devices. This

  includes support for buttons on TouchPads and ClickPads.
+
+config RMI4_F54
+   bool "RMI4 Function 54 (Analog diagnostics)"
+   depends on RMI4_CORE
+   depends on VIDEO_V4L2
+   select VIDEOBUF2_VMALLOC
+   help
+ Say Y here if you want to add support for RMI4 function 54
+
+ Function 54 provides access to various diagnostic features in certain
+ RMI4 touch sensors.
diff --git a/drivers/input/rmi4/Makefile b/drivers/input/rmi4/Makefile
index 95c00a7..0bafc85 100644
--- a/drivers/input/rmi4/Makefile
+++ b/drivers/input/rmi4/Makefile
@@ -7,6 +7,7 @@ rmi_core-$(CONFIG_RMI4_2D_SENSOR) += rmi_2d_sensor.o
  rmi_core-$(CONFIG_RMI4_F11) += rmi_f11.o
  rmi_core-$(CONFIG_RMI4_F12) += rmi_f12.o
  rmi_core-$(CONFIG_RMI4_F30) += rmi_f30.o
+rmi_core-$(CONFIG_RMI4_F54) += rmi_f54.o
  
  # Transports

  obj-$(CONFIG_RMI4_I2C) += rmi_i2c.o
diff --git a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
index b368b05..3aedc65 100644
--- a/drivers/input/rmi4/rmi_bus.c
+++ b/drivers/input/rmi4/rmi_bus.c
@@ -315,6 +315,9 @@ static struct rmi_function_handler *fn_handlers[] = {
  #ifdef CONFIG_RMI4_F30
_f30_handler,
  #endif
+#ifdef CONFIG_RMI4_F54
+   _f54_handler,
+#endif
  };
  
  static void __rmi_unregister_function_handlers(int start_idx)

diff --git a/drivers/input/rmi4/rmi_driver.h b/drivers/input/rmi4/rmi_driver.h
index 6e140fa..8dfbebe 100644
--- a/drivers/input/rmi4/rmi_driver.h
+++ b/drivers/input/rmi4/rmi_driver.h
@@ -102,4 +102,5 @@ extern struct rmi_function_handler rmi_f01_handler;
  extern struct rmi_function_handler rmi_f11_handler;
  extern struct rmi_function_handler rmi_f12_handler;
  extern struct rmi_function_handler rmi_f30_handler;
+extern struct rmi_function_handler rmi_f54_handler;
  #endif
diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
new file mode 100644
index 000..2361157
--- /dev/null
+++ b/drivers/input/rmi4/rmi_f54.c
@@ -0,0 +1,754 @@
+/*
+ * Copyright (c) 2012-2015 Synaptics Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rmi_driver.h"
+
+#define F54_NAME   "rmi4_f54"
+
+/* F54 data offsets */
+#define F54_REPORT_DATA_OFFSET  3
+#define F54_FIFO_OFFSET 1
+#define F54_NUM_TX_OFFSET   1
+#define F54_NUM_RX_OFFSET   0
+
+/* F54 commands */
+#define F54_GET_REPORT  1
+#define F54_FORCE_CAL   2
+
+/* Fixed sizes of reports */
+#define F54_QUERY_LEN  27
+
+/* F54 capabilities */
+#define F54_CAP_BASELINE   (1 << 2)
+#define F54_CAP_IMAGE8 (1 << 3)
+#define F54_CAP_IMAGE16(1 << 6)
+
+/**
+ * enum rmi_f54_report_type - RMI4 F54 report types
+ *
+ * @F54_8BIT_IMAGE:Normalized 8-Bit Image Report. The capacitance variance
+ * from baseline for each pixel.
+ *
+ * @F54_16BIT_IMAGE:   Normalized 16-Bit Image Report. The capacitance variance
+ * from baseline for each pixel.
+ *
+ * @F54_RAW_16BIT_IMAGE:
+ * Raw 16-Bit Image Report. The raw capacitance for each
+ * pixel.
+ *
+ * @F54_TRUE_BASELINE: True Baseline Report. The baseline capacitance for each
+ * pixel.
+ *
+ * @F54_FULL_RAW_CAP:   Full Raw Capacitance Report. The raw capacitance with
+ * low reference set to its minimum value and high
+ * reference set to its maximum value.
+ *
+ * @F54_FULL_RAW_CAP_RX_OFFSET_REMOVED:
+ * Full Raw Capacitance with Receiver Offset Removed
+ * Report. Set Low reference to its minimum value and high
+ * references to its maximum value, then report the raw
+ * capacitance for each pixel.
+ */
+enum

Re: square-only image on Nokia N900 camera -- pipeline setup in python (was Re: [RFC PATCH 00/24] Make Nokia N900 cameras working)

2016-07-01 Thread Pavel Machek

On Fri 2016-07-01 13:01:54, Pavel Machek wrote:
> On Fri 2016-07-01 10:50:25, Pavel Machek wrote:
> > Hi!
> > 
> > > On gitlab is the latest version of pipeline setup if python. I also
> > > got fcam to work (slowly) on the camera, with autofocus and
> > > autogain. Capturing from preview modes works fine, but image quality
> > > is not good, as expected. Capturing raw GRBG10 images works, but
> > > images are square, with values being outside square being 0.
> > > 
> > > Same problem is there with yavta and fcam-dev capture, so I suspect
> > > there's something in kernel. If you have an idea what could be wrong /
> > > what to try, let me know. If omap3isp works for you in v4.6, and
> > > produces expected rectangular images, that would be useful to know,
> > > too.
> > > 
> > > Python capture script is at
> > > 
> > > https://gitlab.com/tui/tui/commit/266b6eb302dcf1481e3e90a05bf98180e5759168
> > 
> > I switched to the front camera (vs6555 pixel array 2-0010 + vs6555
> > binner 2-0010) and got same effect: preview image works fine, raw
> > image is square. Still kernel v4.6.
> 
> Same issue with kernel v4.7-rc5.

And this seems to fix it. Now image fills whole frame.

But I still can't get 5MP format to work, it fails with:

[  497.929016] check_format checking px 808534338 808534338, h 1968
1968, w 2592 2592, bpline 5184 5184, size 10202112 10202112 field 1 1
[  497.929107] configuring for 2592(5184)x1968
[  497.936248] stream on success
[  498.020233] omap3isp 480bc000.isp: CCDC won't become idle!
[  525.563476] omap3isp 480bc000.isp: Unable to stop OMAP3 ISP CCDC


commit 5268a954cd6af4853ad8e05f32ff4741c245e65e
Author: Pavel 
Date:   Fri Jul 1 21:34:35 2016 +0200

This seems to fix stuff for me -- now square limitation of images is gone.

diff --git a/drivers/media/platform/omap3isp/ispccdc.c 
b/drivers/media/platform/omap3isp/ispccdc.c
index 5c52ae8..0e052e6 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -1185,7 +1185,8 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
/* Use the raw, unprocessed data when writing to memory. The H3A and
 * histogram modules are still fed with lens shading corrected data.
 */
-   syn_mode &= ~ISPCCDC_SYN_MODE_VP2SDR;
+// syn_mode &= ~ISPCCDC_SYN_MODE_VP2SDR;
+   syn_mode |= ISPCCDC_SYN_MODE_VP2SDR;
 
if (ccdc->output & CCDC_OUTPUT_MEMORY)
syn_mode |= ISPCCDC_SYN_MODE_WEN;

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] cxd2841er: fix signal strength scale for ISDB-T

2016-07-01 Thread Mauro Carvalho Chehab

The scale for ISDB-T was wrong too: it was inverted, and
on a relative scale.

Use a linear interpolation to make it look better.
The formula was empirically determined, using 3 frequencies
(175 MHz, 410 MHz and 800 MHz), measuring from -50dBm to
-12dBm in steps of 0.5dB.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/cxd2841er.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index 6c660761563d..b706118903fa 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -1731,7 +1731,7 @@ static void cxd2841er_read_signal_strength(struct 
dvb_frontend *fe)
 {
struct dtv_frontend_properties *p = >dtv_property_cache;
struct cxd2841er_priv *priv = fe->demodulator_priv;
-   u32 strength;
+   s32 strength;
 
dev_dbg(>i2c->dev, "%s()\n", __func__);
switch (p->delivery_system) {
@@ -1741,7 +1741,7 @@ static void cxd2841er_read_signal_strength(struct 
dvb_frontend *fe)
p->delivery_system);
p->strength.stat[0].scale = FE_SCALE_DECIBEL;
/* Formula was empirically determinated @ 410 MHz */
-   p->strength.stat[0].uvalue = ((s32)strength) * 366 / 100 - 
89520;
+   p->strength.stat[0].uvalue = strength * 366 / 100 - 89520;
break;  /* Code moved out of the function */
case SYS_DVBC_ANNEX_A:
strength = cxd2841er_read_agc_gain_t_t2(priv,
@@ -1752,13 +1752,16 @@ static void cxd2841er_read_signal_strength(struct 
dvb_frontend *fe)
 * using frequencies: 175 MHz, 410 MHz and 800 MHz, and a
 * stream modulated with QAM64
 */
-   p->strength.stat[0].uvalue = ((s32)strength) * 4045 / 1000 - 
85224;
+   p->strength.stat[0].uvalue = strength * 4045 / 1000 - 85224;
break;
case SYS_ISDBT:
-   strength = 65535 - cxd2841er_read_agc_gain_i(
-   priv, p->delivery_system);
-   p->strength.stat[0].scale = FE_SCALE_RELATIVE;
-   p->strength.stat[0].uvalue = strength;
+   strength = cxd2841er_read_agc_gain_i(priv, p->delivery_system);
+   p->strength.stat[0].scale = FE_SCALE_DECIBEL;
+   /*
+* Formula was empirically determinated via linear regression,
+* using frequencies: 175 MHz, 410 MHz and 800 MHz.
+*/
+   p->strength.stat[0].uvalue = strength * 3775 / 1000 - 90185;
break;
case SYS_DVBS:
case SYS_DVBS2:
-- 
2.7.4

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

Re: [PATCH] [media] cec: add missing inline stubs

2016-07-01 Thread Hans Verkuil

On 07/01/2016 05:37 PM, Arnd Bergmann wrote:
> On Friday, July 1, 2016 5:22:32 PM CEST Hans Verkuil wrote:
>>> diff --git a/drivers/media/platform/vivid/Kconfig 
>>> b/drivers/media/platform/vivid/Kconfig
>>> index 8e6918c5c87c..8e31146d079a 100644
>>> --- a/drivers/media/platform/vivid/Kconfig
>>> +++ b/drivers/media/platform/vivid/Kconfig
>>> @@ -26,6 +26,7 @@ config VIDEO_VIVID
>>>  config VIDEO_VIVID_CEC
>>>   bool "Enable CEC emulation support"
>>>   depends on VIDEO_VIVID && MEDIA_CEC
>>> + depends on VIDEO_VIVID=m || MEDIA_CEC=y
>>>   ---help---
>>> When selected the vivid module will emulate the optional
>>> HDMI CEC feature.
>>>
>>> which is still not overly nice, but it manages to avoid the
>>> IS_REACHABLE() check and it lets MEDIA_CEC be a module.
>>
>> The only IS_REACHABLE is for the RC_CORE check, and that should remain.
> 
> I believe that is already taken care of by my earlier "[media] cec: add
> RC_CORE dependency" patch, https://patchwork.linuxtv.org/patch/34892/
> which seems to handle the dependency more gracefully (preventing nonsense
> configurations rather than just not using RC_CORE).
> 
>> With my patch MEDIA_CEC can remain a module provided MEDIA_SUPPORT is also
>> a module. All drivers depending on MEDIA_CEC also depend on MEDIA_SUPPORT,
>> so that works.
> 
> To clarify, the problem with the option above is that VIDEO_VIVID_CEC
> is a 'bool' option, and Kconfig lets that be turned on if both
> VIDEO_VIVID and MEDIA_CEC are enabled, including the case where MEDIA_CEC
> is a module and VIDEO_VIVID is not.
> 
> Your patch avoids that problem by making MEDIA_CEC a 'bool', my patch
> above is an alternative by ensuring that VIDEO_VIVID_CEC cannot be
> enabled if MEDIA_CEC is a module and VIDEO_VIVID is not.

The problem I have with both your suggestions is that options disappear just
because one dependency is a module. Very unexpected and hard to figure out.

I am not enthusiastic about the IS_REACHABLE(RC_CORE) solution either, but it
will do for now while it is in staging. I still think it is better then making
MEDIA_CEC depend on whether RC_CORE is a module or not. The RC support is an
optional extension and CEC still works fine without it.

Regards,

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

Re: A potential race

2016-07-01 Thread Hans Verkuil

On 07/01/2016 05:02 PM, Pavel Andrianov wrote:
> 01.07.2016 19:53, Hans Verkuil пишет:
>> On 07/01/2016 04:39 PM, Pavel Andrianov wrote:
>>>   Hi!
>>>
>>> There is a potential race condition between usbvision_v4l2_close and 
>>> usbvision_disconnect. The possible scenario may be the following. 
>>> usbvision_disconnect starts execution, assigns usbvision->remove_pending = 
>>> 1, and is interrupted
>>> (rescheduled) after mutex_unlock. After that usbvision_v4l2_close is 
>>> executed, decrease usbvision->user-- , checks usbvision->remove_pending, 
>>> executes usbvision_release and finishes. Then usbvision_disconnect 
>>> continues its execution. It checks
>>> usbversion->user (it is already 0) and also execute usbvision_release. 
>>> Thus, release is executed twice. The same situation may
>>> occur if usbvision_v4l2_close is interrupted by usbvision_disconnect. 
>>> Moreover, the same problem is in usbvision_radio_close. In all these cases 
>>> the check before call usbvision_release under mutex_lock protection does 
>>> not solve the problem, because  there may occur an open() after the check 
>>> and the race takes place again. The question is: why the usbvision_release
>>> is called from close() (usbvision_v4l2_close and usbvision_radio_close)? 
>>> Usually release functions are called from
>>> disconnect.
>> Please don't use html mail, mailinglists will silently reject this.
>>
>> The usbvision driver is old and unloved and known to be very bad code. It 
>> needs a huge amount of work to make all this work correctly.
>>
>> I don't see anyone picking this up...
>>
>> Regards,
>>
>>  Hans
> If you know the driver, could you, please, explain me, why 
> usbvision_release is called from close functions (usbvision_v4l2_close 
> and usbvision_radio_close) and not only from disconnect? Thanks!
> 

Because the author didn't know what he was doing. Although, to be fair, we have 
much better
solutions for this. But who is willing to put in the time to fix this properly?

The basic idea was: if someone still has a video/radio node open when 
disconnect happens, then
we leave it to the last close to call release, otherwise we can call release 
right away.

It needs to be rewritten.

If you're volunteering to clean this up, then I can give pointers.

Regards,

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

Re: A potential race

2016-07-01 Thread Pavel Andrianov


01.07.2016 19:53, Hans Verkuil пишет:

On 07/01/2016 04:39 PM, Pavel Andrianov wrote:

  Hi!

There is a potential race condition between usbvision_v4l2_close and 
usbvision_disconnect. The possible scenario may be the following. 
usbvision_disconnect starts execution, assigns usbvision->remove_pending = 1, 
and is interrupted
(rescheduled) after mutex_unlock. After that usbvision_v4l2_close is executed, 
decrease usbvision->user-- , checks usbvision->remove_pending, executes 
usbvision_release and finishes. Then usbvision_disconnect continues its execution. It 
checks
usbversion->user (it is already 0) and also execute usbvision_release. Thus, 
release is executed twice. The same situation may
occur if usbvision_v4l2_close is interrupted by usbvision_disconnect. Moreover, 
the same problem is in usbvision_radio_close. In all these cases the check 
before call usbvision_release under mutex_lock protection does not solve the 
problem, because  there may occur an open() after the check and the race takes 
place again. The question is: why the usbvision_release
is called from close() (usbvision_v4l2_close and usbvision_radio_close)? 
Usually release functions are called from
disconnect.

Please don't use html mail, mailinglists will silently reject this.

The usbvision driver is old and unloved and known to be very bad code. It needs 
a huge amount of work to make all this work correctly.

I don't see anyone picking this up...

Regards,

Hans
If you know the driver, could you, please, explain me, why 
usbvision_release is called from close functions (usbvision_v4l2_close 
and usbvision_radio_close) and not only from disconnect? Thanks!


--
Pavel Andrianov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: andria...@ispras.ru

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

Re: A potential race

2016-07-01 Thread Hans Verkuil

On 07/01/2016 04:39 PM, Pavel Andrianov wrote:
>  Hi!
> 
> There is a potential race condition between usbvision_v4l2_close
> 
>  and usbvision_disconnect
> .
>  The possible scenario may be the following.
> usbvision_disconnect 
> 
>  starts execution, assigns
> usbvision->remove_pending = 1 
> ,
>  and is interrupted
> (rescheduled) after mutex_unlock 
> .
>  After that
> usbvision_v4l2_close 
> 
>  is executed, decrease
> usbvision->user-- 
> ,
>  checks
> usbvision->remove_pending 
> ,
>  executes
> usbvision_release  
> and finishes. Then usbvision_disconnect
> 
>  continues its execution. It checks
> usbversion->user 
> 
>  (it is already 0) and also
> execute usbvision_release 
> . Thus, release is 
> executed twice. The same situation may
> occur if usbvision_v4l2_close 
> 
>  is interrupted by
> usbvision_disconnect 
> .
>  Moreover, the same problem
> is in usbvision_radio_close 
> .
>  In all these cases
> the check before call usbvision_release 
>  under mutex_lock 
> protection does not solve
> the problem, because  there may occur an open() after the check and the race 
> takes place again. The question is: why the usbvision_release
>  is called from 
> close() (usbvision_v4l2_close
> 
>  and usbvision_radio_close
> )?
>  Usually release functions are called from
> disconnect.

Please don't use html mail, mailinglists will silently reject this.

The usbvision driver is old and unloved and known to be very bad code. It needs 
a huge amount of work to make all this work correctly.

I don't see anyone picking this up...

Regards,

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

Re: [PATCHv5 05/13] media/pci: convert drivers to use the new vb2_queue dev field

2016-07-01 Thread Ezequiel Garcia

On 01 Jul 11:55 AM, Hans Verkuil wrote:
> From 62ddd1aabe5672541055bc6de3c80ca1e3635729 Mon Sep 17 00:00:00 2001
> From: Hans Verkuil 
> Date: Mon, 15 Feb 2016 15:37:15 +0100
> Subject: [PATCH 05/13] media/pci: convert drivers to use the new vb2_queue dev
>  field
> 
> Stop using alloc_ctx and just fill in the device pointer.
> 
> Signed-off-by: Hans Verkuil 
> Cc: Federico Vaga 
> Cc: Mauro Carvalho Chehab 
> ---
> After rebasing the vb2: replace allocation context by device pointer patch 
> series I discovered
> that newly committed changes to tw686x required that driver to be updated as 
> well.
> This is the patch for that.

Reviewed-by: Ezequiel Garcia 

Thanks for the cleanup,
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] cec: add missing inline stubs

2016-07-01 Thread Arnd Bergmann

On Friday, July 1, 2016 5:22:32 PM CEST Hans Verkuil wrote:
> > diff --git a/drivers/media/platform/vivid/Kconfig 
> > b/drivers/media/platform/vivid/Kconfig
> > index 8e6918c5c87c..8e31146d079a 100644
> > --- a/drivers/media/platform/vivid/Kconfig
> > +++ b/drivers/media/platform/vivid/Kconfig
> > @@ -26,6 +26,7 @@ config VIDEO_VIVID
> >  config VIDEO_VIVID_CEC
> >   bool "Enable CEC emulation support"
> >   depends on VIDEO_VIVID && MEDIA_CEC
> > + depends on VIDEO_VIVID=m || MEDIA_CEC=y
> >   ---help---
> > When selected the vivid module will emulate the optional
> > HDMI CEC feature.
> > 
> > which is still not overly nice, but it manages to avoid the
> > IS_REACHABLE() check and it lets MEDIA_CEC be a module.
> 
> The only IS_REACHABLE is for the RC_CORE check, and that should remain.

I believe that is already taken care of by my earlier "[media] cec: add
RC_CORE dependency" patch, https://patchwork.linuxtv.org/patch/34892/
which seems to handle the dependency more gracefully (preventing nonsense
configurations rather than just not using RC_CORE).

> With my patch MEDIA_CEC can remain a module provided MEDIA_SUPPORT is also
> a module. All drivers depending on MEDIA_CEC also depend on MEDIA_SUPPORT,
> so that works.

To clarify, the problem with the option above is that VIDEO_VIVID_CEC
is a 'bool' option, and Kconfig lets that be turned on if both
VIDEO_VIVID and MEDIA_CEC are enabled, including the case where MEDIA_CEC
is a module and VIDEO_VIVID is not.

Your patch avoids that problem by making MEDIA_CEC a 'bool', my patch
above is an alternative by ensuring that VIDEO_VIVID_CEC cannot be
enabled if MEDIA_CEC is a module and VIDEO_VIVID is not.

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

Re: [PATCH] [media] cec: add missing inline stubs

2016-07-01 Thread Hans Verkuil

On 07/01/2016 05:13 PM, Arnd Bergmann wrote:
> On Friday, July 1, 2016 4:35:09 PM CEST Hans Verkuil wrote:
>> On 07/01/2016 01:19 PM, Arnd Bergmann wrote:
>>> The linux/cec.h header file contains empty inline definitions for
>>> a subset of the API for the case in which CEC is not enabled,
>>> however we have driver that call other functions as well:
>>>
>>> drivers/media/i2c/adv7604.c: In function 'adv76xx_cec_tx_raw_status':
>>> drivers/media/i2c/adv7604.c:1956:3: error: implicit declaration of function 
>>> 'cec_transmit_done' [-Werror=implicit-function-declaration]
>>> drivers/media/i2c/adv7604.c: In function 'adv76xx_cec_isr':
>>> drivers/media/i2c/adv7604.c:2012:4: error: implicit declaration of function 
>>> 'cec_received_msg' [-Werror=implicit-function-declaration]
>>> drivers/media/i2c/adv7604.c: In function 'adv76xx_probe':
>>> drivers/media/i2c/adv7604.c:3482:20: error: implicit declaration of 
>>> function 'cec_allocate_adapter' [-Werror=implicit-function-declaration]
>>
>> I don't understand this. These calls are under #if 
>> IS_ENABLED(CONFIG_VIDEO_ADV7842_CEC),
>> and that should be 0 if MEDIA_CEC is not selected.
>>
>> Am I missing some weird config combination?
> 
> This must have been a build error I ran into before your patch, when I
> had this one applied locally instead:
> 
> diff --git a/include/media/cec.h b/include/media/cec.h
> index c462f9b44074..564a6a06bed7 100644
> --- a/include/media/cec.h
> +++ b/include/media/cec.h
> @@ -187,7 +187,7 @@ static inline bool cec_is_sink(const struct cec_adapter 
> *adap)
>   return adap->phys_addr == 0;
>  }
>  
> -#if IS_ENABLED(CONFIG_MEDIA_CEC)
> +#if IS_REACHABLE(CONFIG_MEDIA_CEC)
>  struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
>   void *priv, const char *name, u32 caps, u8 available_las,
>   struct device *parent);
> 
> because that was hiding the declarations when the code could not
> reach it. With your newer patch that is not possible any more.
> 
> I also wasn't aware that each of these already had their own Kconfig
> symbols. Could we just do this instead of your patch then:
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index ce9006e10a30..73e047220905 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -222,6 +222,7 @@ config VIDEO_ADV7604
>  config VIDEO_ADV7604_CEC
>   bool "Enable Analog Devices ADV7604 CEC support"
>   depends on VIDEO_ADV7604 && MEDIA_CEC
> + depends on VIDEO_ADV7604=m || MEDIA_CEC=y
>   ---help---
> When selected the adv7604 will support the optional
> HDMI CEC feature.
> @@ -243,6 +244,7 @@ config VIDEO_ADV7842
>  config VIDEO_ADV7842_CEC
>   bool "Enable Analog Devices ADV7842 CEC support"
>   depends on VIDEO_ADV7842 && MEDIA_CEC
> + depends on VIDEO_ADV7842=m || MEDIA_CEC=y
>   ---help---
> When selected the adv7842 will support the optional
> HDMI CEC feature.
> @@ -475,6 +477,7 @@ config VIDEO_ADV7511
>  config VIDEO_ADV7511_CEC
>   bool "Enable Analog Devices ADV7511 CEC support"
>   depends on VIDEO_ADV7511 && MEDIA_CEC
> + depends on VIDEO_ADV7511=m || MEDIA_CEC=y
>   ---help---
> When selected the adv7511 will support the optional
> HDMI CEC feature.
> diff --git a/drivers/media/platform/vivid/Kconfig 
> b/drivers/media/platform/vivid/Kconfig
> index 8e6918c5c87c..8e31146d079a 100644
> --- a/drivers/media/platform/vivid/Kconfig
> +++ b/drivers/media/platform/vivid/Kconfig
> @@ -26,6 +26,7 @@ config VIDEO_VIVID
>  config VIDEO_VIVID_CEC
>   bool "Enable CEC emulation support"
>   depends on VIDEO_VIVID && MEDIA_CEC
> + depends on VIDEO_VIVID=m || MEDIA_CEC=y
>   ---help---
> When selected the vivid module will emulate the optional
> HDMI CEC feature.
> 
> which is still not overly nice, but it manages to avoid the
> IS_REACHABLE() check and it lets MEDIA_CEC be a module.

The only IS_REACHABLE is for the RC_CORE check, and that should remain.

With my patch MEDIA_CEC can remain a module provided MEDIA_SUPPORT is also
a module. All drivers depending on MEDIA_CEC also depend on MEDIA_SUPPORT,
so that works.

As I mentioned in a previous post, this will change in the future but while
it is in staging I prefer to keep it like this.

Regards,

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

Re: [PATCH] [media] cec: add missing inline stubs

2016-07-01 Thread Arnd Bergmann

On Friday, July 1, 2016 4:35:09 PM CEST Hans Verkuil wrote:
> On 07/01/2016 01:19 PM, Arnd Bergmann wrote:
> > The linux/cec.h header file contains empty inline definitions for
> > a subset of the API for the case in which CEC is not enabled,
> > however we have driver that call other functions as well:
> > 
> > drivers/media/i2c/adv7604.c: In function 'adv76xx_cec_tx_raw_status':
> > drivers/media/i2c/adv7604.c:1956:3: error: implicit declaration of function 
> > 'cec_transmit_done' [-Werror=implicit-function-declaration]
> > drivers/media/i2c/adv7604.c: In function 'adv76xx_cec_isr':
> > drivers/media/i2c/adv7604.c:2012:4: error: implicit declaration of function 
> > 'cec_received_msg' [-Werror=implicit-function-declaration]
> > drivers/media/i2c/adv7604.c: In function 'adv76xx_probe':
> > drivers/media/i2c/adv7604.c:3482:20: error: implicit declaration of 
> > function 'cec_allocate_adapter' [-Werror=implicit-function-declaration]
> 
> I don't understand this. These calls are under #if 
> IS_ENABLED(CONFIG_VIDEO_ADV7842_CEC),
> and that should be 0 if MEDIA_CEC is not selected.
> 
> Am I missing some weird config combination?

This must have been a build error I ran into before your patch, when I
had this one applied locally instead:

diff --git a/include/media/cec.h b/include/media/cec.h
index c462f9b44074..564a6a06bed7 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -187,7 +187,7 @@ static inline bool cec_is_sink(const struct cec_adapter 
*adap)
return adap->phys_addr == 0;
 }
 
-#if IS_ENABLED(CONFIG_MEDIA_CEC)
+#if IS_REACHABLE(CONFIG_MEDIA_CEC)
 struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
void *priv, const char *name, u32 caps, u8 available_las,
struct device *parent);

because that was hiding the declarations when the code could not
reach it. With your newer patch that is not possible any more.

I also wasn't aware that each of these already had their own Kconfig
symbols. Could we just do this instead of your patch then:

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index ce9006e10a30..73e047220905 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -222,6 +222,7 @@ config VIDEO_ADV7604
 config VIDEO_ADV7604_CEC
bool "Enable Analog Devices ADV7604 CEC support"
depends on VIDEO_ADV7604 && MEDIA_CEC
+   depends on VIDEO_ADV7604=m || MEDIA_CEC=y
---help---
  When selected the adv7604 will support the optional
  HDMI CEC feature.
@@ -243,6 +244,7 @@ config VIDEO_ADV7842
 config VIDEO_ADV7842_CEC
bool "Enable Analog Devices ADV7842 CEC support"
depends on VIDEO_ADV7842 && MEDIA_CEC
+   depends on VIDEO_ADV7842=m || MEDIA_CEC=y
---help---
  When selected the adv7842 will support the optional
  HDMI CEC feature.
@@ -475,6 +477,7 @@ config VIDEO_ADV7511
 config VIDEO_ADV7511_CEC
bool "Enable Analog Devices ADV7511 CEC support"
depends on VIDEO_ADV7511 && MEDIA_CEC
+   depends on VIDEO_ADV7511=m || MEDIA_CEC=y
---help---
  When selected the adv7511 will support the optional
  HDMI CEC feature.
diff --git a/drivers/media/platform/vivid/Kconfig 
b/drivers/media/platform/vivid/Kconfig
index 8e6918c5c87c..8e31146d079a 100644
--- a/drivers/media/platform/vivid/Kconfig
+++ b/drivers/media/platform/vivid/Kconfig
@@ -26,6 +26,7 @@ config VIDEO_VIVID
 config VIDEO_VIVID_CEC
bool "Enable CEC emulation support"
depends on VIDEO_VIVID && MEDIA_CEC
+   depends on VIDEO_VIVID=m || MEDIA_CEC=y
---help---
  When selected the vivid module will emulate the optional
  HDMI CEC feature.

which is still not overly nice, but it manages to avoid the
IS_REACHABLE() check and it lets MEDIA_CEC be a module.

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

[GIT PULL FOR v4.8] vb2: replace allocation context by device pointer

2016-07-01 Thread Hans Verkuil

This pull request is a rebased version of the patch v5 series:

http://www.mail-archive.com/linux-media@vger.kernel.org/msg98729.html

together with the tw686x fix (needed due to the rebase):

https://patchwork.linuxtv.org/patch/34965/

(note: the subject and commit log as posted on the list is a bit garbled, but 
that is fixed in
this pull request).

See the cover letter (first link above) of the patch series for the details.

It greatly simplifies drivers: 663 lines were removed.

Regards,

Hans

The following changes since commit ab46f6d24bf57ddac0f5abe2f546a78af57b476c:

  [media] videodev2.h: Fix V4L2_PIX_FMT_YUV411P description (2016-06-28 
11:54:52 -0300)

are available in the git repository at:

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

for you to fetch changes up to 78a40101e916b4c265f763d63eff8daa0e3b2932:

  vb2: replace void *alloc_ctxs by struct device *alloc_devs (2016-07-01 
11:51:12 +0200)


Hans Verkuil (14):
  vb2: move dma_attrs to vb2_queue
  vb2: add a dev field to use for the default allocation context
  v4l2-pci-skeleton: set q->dev instead of allocating a context
  sur40: set q->dev instead of allocating a context
  media/pci: convert drivers to use the new vb2_queue dev field
  media/pci/tw686x: convert driver to use the new vb2_queue dev field
  staging/media: convert drivers to use the new vb2_queue dev field
  media/platform: convert drivers to use the new vb2_queue dev field
  media/platform: convert drivers to use the new vb2_queue dev field
  media/platform: convert drivers to use the new vb2_queue dev field
  media/.../soc-camera: convert drivers to use the new vb2_queue dev field
  media/platform: convert drivers to use the new vb2_queue dev field
  media/platform: convert drivers to use the new vb2_queue dev field
  vb2: replace void *alloc_ctxs by struct device *alloc_devs

 drivers/input/touchscreen/sur40.c| 15 ++
 drivers/media/dvb-frontends/rtl2832_sdr.c|  2 +-
 drivers/media/pci/cobalt/cobalt-driver.c |  9 
 drivers/media/pci/cobalt/cobalt-driver.h |  1 -
 drivers/media/pci/cobalt/cobalt-v4l2.c   |  4 ++--
 drivers/media/pci/cx23885/cx23885-417.c  |  3 +--
 drivers/media/pci/cx23885/cx23885-core.c | 10 +
 drivers/media/pci/cx23885/cx23885-dvb.c  |  4 ++--
 drivers/media/pci/cx23885/cx23885-vbi.c  |  3 +--
 drivers/media/pci/cx23885/cx23885-video.c|  5 +++--
 drivers/media/pci/cx23885/cx23885.h  |  1 -
 drivers/media/pci/cx25821/cx25821-core.c | 10 +
 drivers/media/pci/cx25821/cx25821-video.c|  5 ++---
 drivers/media/pci/cx25821/cx25821.h  |  1 -
 drivers/media/pci/cx88/cx88-blackbird.c  |  4 ++--
 drivers/media/pci/cx88/cx88-dvb.c|  4 ++--
 drivers/media/pci/cx88/cx88-mpeg.c   | 10 +
 drivers/media/pci/cx88/cx88-vbi.c|  3 +--
 drivers/media/pci/cx88/cx88-video.c  | 13 +++-
 drivers/media/pci/cx88/cx88.h|  2 --
 drivers/media/pci/dt3155/dt3155.c| 15 +++---
 drivers/media/pci/dt3155/dt3155.h|  2 --
 drivers/media/pci/netup_unidvb/netup_unidvb_core.c   |  2 +-
 drivers/media/pci/saa7134/saa7134-core.c | 22 
+++-
 drivers/media/pci/saa7134/saa7134-ts.c   |  3 +--
 drivers/media/pci/saa7134/saa7134-vbi.c  |  3 +--
 drivers/media/pci/saa7134/saa7134-video.c|  5 +++--
 drivers/media/pci/saa7134/saa7134.h  |  3 +--
 drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c   | 13 ++--
 drivers/media/pci/solo6x10/solo6x10-v4l2.c   | 12 ++-
 drivers/media/pci/solo6x10/solo6x10.h|  2 --
 drivers/media/pci/sta2x11/sta2x11_vip.c  | 20 
+++---
 drivers/media/pci/tw68/tw68-core.c   | 15 +++---
 drivers/media/pci/tw68/tw68-video.c  |  4 ++--
 drivers/media/pci/tw68/tw68.h|  1 -
 drivers/media/pci/tw686x/tw686x-video.c  | 36 
++--
 drivers/media/pci/tw686x/tw686x.h|  3 ---
 drivers/media/platform/am437x/am437x-vpfe.c  | 14 +++--
 drivers/media/platform/am437x/am437x-vpfe.h  |  2 --
 drivers/media/platform/blackfin/bfin_capture.c   | 17 +++
 drivers/media/platform/coda/coda-common.c| 18 +++-
 drivers/media/platform/coda/coda.h   |  1 -

[PATCH] tw686x: make const structs static

2016-07-01 Thread Hans Verkuil

Fix sparse warnings:

tw686x-video.c:148:29: warning: symbol 'memcpy_dma_ops' was not declared. 
Should it be static?
tw686x-video.c:195:29: warning: symbol 'contig_dma_ops' was not declared. 
Should it be static?
tw686x-video.c:361:29: warning: symbol 'sg_dma_ops' was not declared. Should it 
be static?

Signed-off-by: Hans Verkuil 
---
 drivers/media/pci/tw686x/tw686x-video.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/pci/tw686x/tw686x-video.c 
b/drivers/media/pci/tw686x/tw686x-video.c
index 0e839f6..bae33d9 100644
--- a/drivers/media/pci/tw686x/tw686x-video.c
+++ b/drivers/media/pci/tw686x/tw686x-video.c
@@ -145,7 +145,7 @@ static void tw686x_memcpy_buf_refill(struct 
tw686x_video_channel *vc,
vc->curr_bufs[pb] = NULL;
 }

-const struct tw686x_dma_ops memcpy_dma_ops = {
+static const struct tw686x_dma_ops memcpy_dma_ops = {
.alloc  = tw686x_memcpy_dma_alloc,
.free   = tw686x_memcpy_dma_free,
.buf_refill = tw686x_memcpy_buf_refill,
@@ -192,7 +192,7 @@ static int tw686x_contig_setup(struct tw686x_dev *dev)
return 0;
 }

-const struct tw686x_dma_ops contig_dma_ops = {
+static const struct tw686x_dma_ops contig_dma_ops = {
.setup  = tw686x_contig_setup,
.cleanup= tw686x_contig_cleanup,
.buf_refill = tw686x_contig_buf_refill,
@@ -358,7 +358,7 @@ static int tw686x_sg_setup(struct tw686x_dev *dev)
return 0;
 }

-const struct tw686x_dma_ops sg_dma_ops = {
+static const struct tw686x_dma_ops sg_dma_ops = {
.setup  = tw686x_sg_setup,
.cleanup= tw686x_sg_cleanup,
.alloc  = tw686x_sg_dma_alloc,
-- 
2.8.1

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

[GIT PULL FOR v4.8] Various fixes/improvements

2016-07-01 Thread Hans Verkuil

Hi Mauro,

Here is my yield of one day of patch processing. On Monday I plan to do another 
round,
then for patches that are not directly my core activity. Although there are one 
or two
dvb patches in this pull request as well.

Regards,

Hans

The following changes since commit ab46f6d24bf57ddac0f5abe2f546a78af57b476c:

  [media] videodev2.h: Fix V4L2_PIX_FMT_YUV411P description (2016-06-28 
11:54:52 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.8d

for you to fetch changes up to 0fcfba86e6bc9c6aae17bbe5bd9444698a37992e:

  tw686x: make const structs static (2016-07-01 16:37:27 +0200)


Alexander Shiyan (1):
  media: coda: Fix probe() if reset controller is missing

Alexey Khoroshilov (1):
  bt8xx: remove needless module refcounting

Amitoj Kaur Chawla (2):
  saa7164: Replace if and BUG with BUG_ON
  ddbridge: Replace vmalloc with vzalloc

Arnd Bergmann (1):
  dvb: use ktime_t for internal timeout

Dragos Bogdan (1):
  adv7604: Add support for hardware reset

Florian Echtler (3):
  sur40: properly report a single frame rate of 60 FPS
  sur40: lower poll interval to fix occasional FPS drops to ~56 FPS
  sur40: fix occasional oopses on device close

Guennadi Liakhovetski (1):
  V4L: fix the Z16 format definition

Hans Verkuil (4):
  v4l2-tpg: ignore V4L2_DV_RGB_RANGE setting for YUV formats
  rc-main: fix kernel oops after unloading keymap module
  sur40: drop unnecessary format description
  tw686x: make const structs static

Javier Martinez Canillas (2):
  DocBook: add dmabuf as streaming I/O in VIDIOC_REQBUFS description
  DocBook: mention the memory type to be set for all streaming I/O

Lubomir Rintel (2):
  usbtv: clarify the licensing
  usbtv: improve a comment

Ricardo Ribalda Delgado (4):
  vb2: V4L2_BUF_FLAG_DONE is set after DQBUF
  vb2: Merge vb2_internal_dqbuf and vb2_dqbuf
  vb2: Merge vb2_internal_qbuf and vb2_qbuf
  vb2: Fix comment

 Documentation/DocBook/media/v4l/io.xml |  4 ++--
 Documentation/DocBook/media/v4l/pixfmt-z16.xml |  2 +-
 Documentation/DocBook/media/v4l/vidioc-reqbufs.xml |  2 +-
 drivers/input/touchscreen/sur40.c  | 26 +-
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c  |  4 ++--
 drivers/media/dvb-core/demux.h |  2 +-
 drivers/media/dvb-core/dmxdev.c|  2 +-
 drivers/media/dvb-core/dvb_demux.c | 17 +--
 drivers/media/dvb-core/dvb_demux.h |  4 ++--
 drivers/media/dvb-core/dvb_net.c   |  2 +-
 drivers/media/i2c/adv7604.c| 20 +
 drivers/media/pci/bt8xx/dst_ca.c   |  2 --
 drivers/media/pci/ddbridge/ddbridge-core.c |  3 +--
 drivers/media/pci/saa7164/saa7164-encoder.c|  6 ++---
 drivers/media/pci/tw686x/tw686x-video.c|  6 ++---
 drivers/media/platform/coda/coda-common.c  |  2 +-
 drivers/media/rc/rc-main.c | 10 +++--
 drivers/media/usb/usbtv/usbtv-audio.c  | 28 
++--
 drivers/media/usb/usbtv/usbtv-core.c   | 40 
+++---
 drivers/media/usb/usbtv/usbtv-video.c  | 59 
+-
 drivers/media/usb/usbtv/usbtv.h| 22 +++
 drivers/media/v4l2-core/videobuf2-core.c   |  2 +-
 drivers/media/v4l2-core/videobuf2-v4l2.c   | 47 
+++-
 23 files changed, 206 insertions(+), 106 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] cec: add missing inline stubs

2016-07-01 Thread Hans Verkuil

On 07/01/2016 01:19 PM, Arnd Bergmann wrote:
> The linux/cec.h header file contains empty inline definitions for
> a subset of the API for the case in which CEC is not enabled,
> however we have driver that call other functions as well:
> 
> drivers/media/i2c/adv7604.c: In function 'adv76xx_cec_tx_raw_status':
> drivers/media/i2c/adv7604.c:1956:3: error: implicit declaration of function 
> 'cec_transmit_done' [-Werror=implicit-function-declaration]
> drivers/media/i2c/adv7604.c: In function 'adv76xx_cec_isr':
> drivers/media/i2c/adv7604.c:2012:4: error: implicit declaration of function 
> 'cec_received_msg' [-Werror=implicit-function-declaration]
> drivers/media/i2c/adv7604.c: In function 'adv76xx_probe':
> drivers/media/i2c/adv7604.c:3482:20: error: implicit declaration of function 
> 'cec_allocate_adapter' [-Werror=implicit-function-declaration]

I don't understand this. These calls are under #if 
IS_ENABLED(CONFIG_VIDEO_ADV7842_CEC),
and that should be 0 if MEDIA_CEC is not selected.

Am I missing some weird config combination?

Regards,

Hans


> 
> This adds stubs for the remaining interfaces as well.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  include/media/cec.h | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/include/media/cec.h b/include/media/cec.h
> index 9a791c08a789..c462f9b44074 100644
> --- a/include/media/cec.h
> +++ b/include/media/cec.h
> @@ -208,6 +208,12 @@ void cec_transmit_done(struct cec_adapter *adap, u8 
> status, u8 arb_lost_cnt,
>  void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg);
>  
>  #else
> +static inline struct cec_adapter *cec_allocate_adapter(
> + const struct cec_adap_ops *ops, void *priv, const char *name,
> + u32 caps, u8 available_las, struct device *parent)
> +{
> + return NULL;
> +}
>  
>  static inline int cec_register_adapter(struct cec_adapter *adap)
>  {
> @@ -227,6 +233,25 @@ static inline void cec_s_phys_addr(struct cec_adapter 
> *adap, u16 phys_addr,
>  {
>  }
>  
> +static inline int cec_transmit_msg(struct cec_adapter *adap,
> +struct cec_msg *msg, bool block)
> +{
> + return 0;
> +}
> +
> +/* Called by the adapter */
> +static inline void cec_transmit_done(struct cec_adapter *adap, u8 status,
> +  u8 arb_lost_cnt, u8 nack_cnt,
> +  u8 low_drive_cnt, u8 error_cnt)
> +{
> +}
> +
> +static inline void cec_received_msg(struct cec_adapter *adap,
> + struct cec_msg *msg)
> +{
> +}
> +
> +
>  #endif
>  
>  #endif /* _MEDIA_CEC_H */
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] cxd2841er: don't expose a dvbv5 stats to userspace if not available

2016-07-01 Thread Mauro Carvalho Chehab

The current code will expose a zero value if one of the stats is
not available, but this is not what userspace expects. Instead,
if something goes wrong on providing some stats, it should be
changing the scale to FE_SCALE_NOT_AVAILABLE.

So, change the logic to do the right thing.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/cxd2841er.c | 92 +
 1 file changed, 48 insertions(+), 44 deletions(-)

diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index c960e8a725cc..543b20155efc 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -1330,7 +1330,7 @@ static int cxd2841er_read_packet_errors_i(
return 0;
 }
 
-static u32 cxd2841er_mon_read_ber_s(struct cxd2841er_priv *priv)
+static int cxd2841er_mon_read_ber_s(struct cxd2841er_priv *priv, u32 *ber)
 {
u8 data[11];
u32 bit_error, bit_count;
@@ -1365,25 +1365,25 @@ static u32 cxd2841er_mon_read_ber_s(struct 
cxd2841er_priv *priv)
dev_dbg(>i2c->dev,
"%s(): invalid bit_error %d, bit_count %d\n",
__func__, bit_error, bit_count);
-   return 0;
+   return -EINVAL;
}
temp_q = div_u64_rem(1000ULL * bit_error,
bit_count, _r);
if (bit_count != 1 && temp_r >= bit_count / 2)
temp_q++;
-   return temp_q;
+   *ber = temp_q;
+   return 0;
}
dev_dbg(>i2c->dev, "%s(): no data available\n", __func__);
-   return 0;
+   return -EINVAL;
 }
 
 
-static u32 cxd2841er_mon_read_ber_s2(struct cxd2841er_priv *priv)
+static int cxd2841er_mon_read_ber_s2(struct cxd2841er_priv *priv, u32 *ber)
 {
u8 data[5];
u32 bit_error, period;
u32 temp_q, temp_r;
-   u32 result = 0;
 
/* Set SLV-T Bank : 0xB2 */
cxd2841er_write_reg(priv, I2C_SLVT, 0x00, 0xb2);
@@ -1411,13 +1411,13 @@ static u32 cxd2841er_mon_read_ber_s2(struct 
cxd2841er_priv *priv)
if (period == 0) {
dev_dbg(>i2c->dev,
"%s(): period is 0\n", __func__);
-   return 0;
+   return -EINVAL;
}
if (bit_error > (period * 64800)) {
dev_dbg(>i2c->dev,
"%s(): invalid bit_err 0x%x period 0x%x\n",
__func__, bit_error, period);
-   return 0;
+   return -EINVAL;
}
/*
 * BER = bitError / (period * 64800)
@@ -1430,12 +1430,13 @@ static u32 cxd2841er_mon_read_ber_s2(struct 
cxd2841er_priv *priv)
period * 81, _r);
if (temp_r >= period * 40)
temp_q++;
-   result = temp_q;
+   *ber = temp_q;
+   return 0;
} else {
dev_dbg(>i2c->dev,
"%s(): no data available\n", __func__);
}
-   return result;
+   return -EINVAL;
 }
 
 static int cxd2841er_read_ber_t2(struct cxd2841er_priv *priv, u32 *ber)
@@ -1702,29 +1703,37 @@ static u16 cxd2841er_read_agc_gain_s(struct 
cxd2841er_priv *priv)
return u16)data[0] & 0x1F) << 8) | (u16)(data[1] & 0xFF)) << 3;
 }
 
-static int cxd2841er_read_ber(struct dvb_frontend *fe, u32 *ber)
+static void cxd2841er_read_ber(struct dvb_frontend *fe)
 {
struct dtv_frontend_properties *p = >dtv_property_cache;
struct cxd2841er_priv *priv = fe->demodulator_priv;
+   u32 ber = 0, ret;
 
dev_dbg(>i2c->dev, "%s()\n", __func__);
-   *ber = 0;
switch (p->delivery_system) {
case SYS_DVBS:
-   *ber = cxd2841er_mon_read_ber_s(priv);
+   ret = cxd2841er_mon_read_ber_s(priv, );
break;
case SYS_DVBS2:
-   *ber = cxd2841er_mon_read_ber_s2(priv);
+   ret = cxd2841er_mon_read_ber_s2(priv, );
break;
case SYS_DVBT:
-   return cxd2841er_read_ber_t(priv, ber);
+   ret = cxd2841er_read_ber_t(priv, );
+   break;
case SYS_DVBT2:
-   return cxd2841er_read_ber_t2(priv, ber);
+   ret = cxd2841er_read_ber_t2(priv, );
+   break;
default:
-   *ber = 0;
-   break;
+   p->post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+   return;
+   }
+
+   if (!ret) {
+   p->post_bit_error.stat[0].scale = FE_SCALE_COUNTER;
+   p->post_bit_error.stat[0].uvalue = ber;
+   } else {
+

Re: [PATCH] cec: fix Kconfig dependency problems

2016-07-01 Thread Arnd Bergmann

On Friday, July 1, 2016 12:37:06 PM CEST Hans Verkuil wrote:
> - Use IS_REACHABLE(RC_CORE) instead of IS_ENABLED: if cec is built-in and
>   RC_CORE is a module, then CEC can't reach the RC symbols.
> - Both cec and cec-edid should be bool and use the same build 'mode' as
>   MEDIA_SUPPORT (just as is done for the media controller code).
> - Add a note to staging that this should be changed once the cec framework
>   is moved out of staging.
> 
> Signed-off-by: Hans Verkuil 
> Reported-by: Arnd Bergmann 
> 

I see no further build failures with this and my "[media] cec:
add missing inline stubs" patch applied.

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

[PATCH 4/4] cxd2841er: adjust the dB scale for DVB-C

2016-07-01 Thread Mauro Carvalho Chehab

Instead of using a relative frequency range, calibrate it to
show the results in dB. The callibration was done getting
samples with a signal generated from -50dBm to -12dBm,
incremented in steps of 0.5 dB, using 3 frequencies:
175 MHz, 410 MHz and 800 MHz. The modulated signal was
using QAM64, and it was used a linear interpolation of all
the results.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/cxd2841er.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index e2f3ea55897b..6c660761563d 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -1746,8 +1746,13 @@ static void cxd2841er_read_signal_strength(struct 
dvb_frontend *fe)
case SYS_DVBC_ANNEX_A:
strength = cxd2841er_read_agc_gain_t_t2(priv,
p->delivery_system);
-   p->strength.stat[0].scale = FE_SCALE_RELATIVE;
-   p->strength.stat[0].uvalue = strength;
+   p->strength.stat[0].scale = FE_SCALE_DECIBEL;
+   /*
+* Formula was empirically determinated via linear regression,
+* using frequencies: 175 MHz, 410 MHz and 800 MHz, and a
+* stream modulated with QAM64
+*/
+   p->strength.stat[0].uvalue = ((s32)strength) * 4045 / 1000 - 
85224;
break;
case SYS_ISDBT:
strength = 65535 - cxd2841er_read_agc_gain_i(
-- 
2.7.4

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

[PATCH 2/4] cxd2841er: provide signal strength for DVB-C

2016-07-01 Thread Mauro Carvalho Chehab

Currently, there's no stats for DVB-C. Let's at least return
signal strength. The scale is different than on DVB-T, so let's
use a relative scale, for now.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/cxd2841er.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index 543b20155efc..e35f5d0d3f34 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -1752,6 +1752,12 @@ static void cxd2841er_read_signal_strength(struct 
dvb_frontend *fe)
/* Formula was empirically determinated @ 410 MHz */
p->strength.stat[0].uvalue = ((s32)strength) * 366 / 100 - 
89520;
break;  /* Code moved out of the function */
+   case SYS_DVBC_ANNEX_A:
+   strength = cxd2841er_read_agc_gain_t_t2(priv,
+   p->delivery_system);
+   p->strength.stat[0].scale = FE_SCALE_RELATIVE;
+   p->strength.stat[0].uvalue = strength;
+   break;
case SYS_ISDBT:
strength = 65535 - cxd2841er_read_agc_gain_i(
priv, p->delivery_system);
-- 
2.7.4

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

[PATCH 3/4] cxd2841er: fix BER report via DVBv5 stats API

2016-07-01 Thread Mauro Carvalho Chehab

What userspace expects is to receive both bit_error and bit_count
counters. So, instead of doing the division at the Kernel,
return the counters for userspace to handle it the way it
wants.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/cxd2841er.c | 137 +++-
 1 file changed, 66 insertions(+), 71 deletions(-)

diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index e35f5d0d3f34..e2f3ea55897b 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -1330,11 +1330,10 @@ static int cxd2841er_read_packet_errors_i(
return 0;
 }
 
-static int cxd2841er_mon_read_ber_s(struct cxd2841er_priv *priv, u32 *ber)
+static int cxd2841er_mon_read_ber_s(struct cxd2841er_priv *priv,
+   u32 *bit_error, u32 *bit_count)
 {
u8 data[11];
-   u32 bit_error, bit_count;
-   u32 temp_q, temp_r;
 
/* Set SLV-T Bank : 0xA0 */
cxd2841er_write_reg(priv, I2C_SLVT, 0x00, 0xa0);
@@ -1350,28 +1349,18 @@ static int cxd2841er_mon_read_ber_s(struct 
cxd2841er_priv *priv, u32 *ber)
 */
cxd2841er_read_regs(priv, I2C_SLVT, 0x35, data, 11);
if (data[0] & 0x01) {
-   bit_error = ((u32)(data[1]  & 0x3F) << 16) |
-   ((u32)(data[2]  & 0xFF) <<  8) |
-   (u32)(data[3]  & 0xFF);
-   bit_count = ((u32)(data[8]  & 0x3F) << 16) |
-   ((u32)(data[9]  & 0xFF) <<  8) |
-   (u32)(data[10] & 0xFF);
-   /*
-*  BER = bitError / bitCount
-*  = (bitError * 10^7) / bitCount
-*  = ((bitError * 625 * 125 * 128) / bitCount
-*/
-   if ((bit_count == 0) || (bit_error > bit_count)) {
+   *bit_error = ((u32)(data[1]  & 0x3F) << 16) |
+((u32)(data[2]  & 0xFF) <<  8) |
+(u32)(data[3]  & 0xFF);
+   *bit_count = ((u32)(data[8]  & 0x3F) << 16) |
+((u32)(data[9]  & 0xFF) <<  8) |
+(u32)(data[10] & 0xFF);
+   if ((*bit_count == 0) || (*bit_error > *bit_count)) {
dev_dbg(>i2c->dev,
"%s(): invalid bit_error %d, bit_count %d\n",
-   __func__, bit_error, bit_count);
+   __func__, *bit_error, *bit_count);
return -EINVAL;
}
-   temp_q = div_u64_rem(1000ULL * bit_error,
-   bit_count, _r);
-   if (bit_count != 1 && temp_r >= bit_count / 2)
-   temp_q++;
-   *ber = temp_q;
return 0;
}
dev_dbg(>i2c->dev, "%s(): no data available\n", __func__);
@@ -1379,11 +1368,11 @@ static int cxd2841er_mon_read_ber_s(struct 
cxd2841er_priv *priv, u32 *ber)
 }
 
 
-static int cxd2841er_mon_read_ber_s2(struct cxd2841er_priv *priv, u32 *ber)
+static int cxd2841er_mon_read_ber_s2(struct cxd2841er_priv *priv,
+u32 *bit_error, u32 *bit_count)
 {
u8 data[5];
-   u32 bit_error, period;
-   u32 temp_q, temp_r;
+   u32 period;
 
/* Set SLV-T Bank : 0xB2 */
cxd2841er_write_reg(priv, I2C_SLVT, 0x00, 0xb2);
@@ -1398,10 +1387,10 @@ static int cxd2841er_mon_read_ber_s2(struct 
cxd2841er_priv *priv, u32 *ber)
cxd2841er_read_regs(priv, I2C_SLVT, 0x30, data, 5);
if (data[0] & 0x01) {
/* Bit error count */
-   bit_error = ((u32)(data[1] & 0x0F) << 24) |
-   ((u32)(data[2] & 0xFF) << 16) |
-   ((u32)(data[3] & 0xFF) <<  8) |
-   (u32)(data[4] & 0xFF);
+   *bit_error = ((u32)(data[1] & 0x0F) << 24) |
+((u32)(data[2] & 0xFF) << 16) |
+((u32)(data[3] & 0xFF) <<  8) |
+(u32)(data[4] & 0xFF);
 
/* Set SLV-T Bank : 0xA0 */
cxd2841er_write_reg(priv, I2C_SLVT, 0x00, 0xa0);
@@ -1413,24 +1402,14 @@ static int cxd2841er_mon_read_ber_s2(struct 
cxd2841er_priv *priv, u32 *ber)
"%s(): period is 0\n", __func__);
return -EINVAL;
}
-   if (bit_error > (period * 64800)) {
+   if (*bit_error > (period * 64800)) {
dev_dbg(>i2c->dev,
"%s(): invalid bit_err 0x%x period 0x%x\n",
-   __func__, bit_error, period);
+   __func__, *bit_error, period);
return -EINVAL;
}
-   /*
-* BER =

Re: [PATCH] [media] rc: ir-spi: add support for IR LEDs connected with SPI

2016-07-01 Thread Andi Shyti

Hi Sean,

> > > Also I don't see what justifies this new interface. This can be 
> > > implemented in rc-core in less lines of code and it will be entirely 
> > > compatible with existing user-space.
> > 
> > Also here I'm getting a bit confused. When I started writing
> > this, I didn't even know of the existence of a remote controlling
> > framework, but then I run across this:
> > 
> > "LIRC is a package that allows you to decode and send infra-red
> > signals of many (but not all) commonly used remote controls. "
> > 
> > taken from lirc.org: my case is exactly falling into this
> > description.
> > 
> > Am I missing anything?
> 
> See drivers/staging/media/lirc/TODO: "All drivers should either be 
> ported to ir-core, or dropped entirely".  ir-core has since been renamed 
> to rc-core; it is uses for non-IR purposes like cec.
> 
> lirc exists as the user-space ABI but not it is not the preferred 
> framework for kernel space.

I missed this part and now what you say makes sense.

> I'm happy to help. 

I will do as you recommend and thanks a lot, appreciated :)

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

Re: [PATCH v2] Add tw5864 driver

2016-07-01 Thread Hans Verkuil

On 06/10/2016 12:11 AM, Andrey Utkin wrote:
> Fixed most of issues discovered by v1 and RFCv0 reviewers. Refactored a lot.
> 
> The only thing from previous review I haven't got my head around yet is
> framerate control - Hans Verkuil has told to support 1001/3 frame 
> interval,
> but it's hard for me to fit it into current model. I see that I'm still not
> getting this aspect right so I'd be grateful for some more spoon-feeding on
> this. Otherwise, it would be nice to get some more reviews while I'm figuring
> this out by myself, so I dare to submit the current state for review.
> 
> This submission is awkward in a way. There was a code to "initialize" the
> subordinate chips tw286{4,5} which are connected to main chip via I2C, by 
> means
> of special r/w procedure on dedicated register. I was told to organize the
> I2C-related code using kernel-provided interfaces (struct i2c_adapter etc.),
> which I have accomplished. It was tested and traced in runtime, and supposedly
> this new code works. But after that, I figured out that this
> initialize-chips-via-i2c code is not necessary at all. So now there are
> "proper" I2C I/O routines, but they are unused. Also, there remains a very
> similar mechanism which is called "indirect space map" which exposes mostly 
> the
> same registers which tw286{4,5} chips expose by themselves and which could be
> accessed also by "i2c communication" routines. But address mapping between
> these spaces seems inconsistent: some addresses match, some don't, and both
> current code and reference driver use mostly "indirect space map" mechanism. 
> In
> current code there are 33 invocations of "indirect" i/o. They are left intact
> for now, but if maintainers insist on reworking that to "i2c communication",
> I'm ok to do this.

So if I understand this correctly instead of using i2c you can now use the
indirect i/o to program these internal tw286{4,5} devices? I assume these
are integrated on the same die and the i2c bus is internal to the tw5864 chip?

Assuming this is true, then I would just drop the i2c part since it is unused
and since I suspect that the indirect i/o is faster anyway.

> 
> checkpatch.pl gives no notices on a patch nor on individual source files.
> 
> sparse ("make C=2 M=drivers/media/pci/tw5864") also gives no notices.
> 
> root@localhost:~# v4l2-compliance -d 6 -s
> Driver Info:
> Driver name   : tw5864
> Card type : TW5864 Encoder 2
> Bus info  : PCI::06:05.0
> Driver version: 4.7.0
> Capabilities  : 0x8521
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps   : 0x0521
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
> 
> Compliance test for device /dev/video6 (not using libv4l2):
> 
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
> 
> Allow for multiple opens:
> test second video open: OK
> test VIDIOC_QUERYCAP: OK
> test VIDIOC_G/S_PRIORITY: OK
> 
> Debug ioctls:
> test VIDIOC_DBG_G/S_REGISTER: OK
> test VIDIOC_LOG_STATUS: OK
> 
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 1 Audio Inputs: 0 Tuners: 0
> 
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
> 
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> test VIDIOC_G/S_EDID: OK (Not Supported)
> 
> Test input 0:
> 
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
> test VIDIOC_QUERYCTRL: OK
> test VIDIOC_G/S_CTRL: OK
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 11 Private Controls: 0
> 
> Format ioctls:
> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> test VIDIOC_G/S_PARM: OK
> test VIDIOC_G_FBUF: OK (Not Supported)
> test VIDIOC_G_FMT: OK
> test VIDIOC_TRY_FMT: OK
> test

Re: [PATCH] [media] rc: ir-spi: add support for IR LEDs connected with SPI

2016-07-01 Thread Sean Young

On Fri, Jul 01, 2016 at 09:30:35PM +0900, Andi Shyti wrote:
> Hi Sean,
> 
> > > The ir-spi is a simple device driver which supports the
> > > connection between an IR LED and the MOSI line of an SPI device.
> > > 
> > > The driver, indeed, uses the SPI framework to stream the raw data
> > > provided by userspace through a character device. The chardev is
> > > handled by the LIRC framework and its functionality basically
> > > provides:
> > > 
> > >  - raw write: data to be sent to the SPI and then streamed to the
> > >MOSI line;
> > >  - set frequency: sets the frequency whith which the data should
> > >be sent;
> > >  - set length: sets the data length. This information is
> > >optional, if the length is set, then userspace should send raw
> > >data only with that length; while if the length is set to '0',
> > >then the driver will figure out himself the length of the data
> > >based on the length of the data written on the character
> > >device.
> > >The latter is not recommended, though, as the driver, at
> > >any write, allocates and deallocates a buffer where the data
> > >from userspace are stored.
> > > 
> > > The driver provides three feedback commands:
> > > 
> > >  - get length: reads the length set and (as mentioned), if the
> > >length is '0' it will be calculated at any write
> > >  - get frequency: the driver reports the frequency. If userpace
> > >doesn't set the frequency, the driver will use a default value
> > >of 38000Hz.
> > 
> > This interface is not compatible with other lirc devices; there is no
> > way of determining whether this is a regular lirc device or this new
> > flavour you've invented.
> 
> except of the set length and get length which I'm using a bit
> freely because I am dealing with devices that exchange always the
> same amount of data, so that I don't need (in my case) to
> pre-allocate or overallocate or runtime allocate. I don't
> understand what else I invented :)

Other than the LIRC_{GET,SET}_LENGTH it might very well be compatible;
you're reusing LIRC_GET_LENGTH for a different purpose.

Is the kmalloc() really that costly that it needs to be avoided for
each transmit?

> This is a simple driver which is driving an LED connected through
> SPI and userspace writes raw data in it (LIRC_CAN_SEND_RAW).

And some odd ioctl.

> > Also I don't see what justifies this new interface. This can be 
> > implemented in rc-core in less lines of code and it will be entirely 
> > compatible with existing user-space.
> 
> Also here I'm getting a bit confused. When I started writing
> this, I didn't even know of the existence of a remote controlling
> framework, but then I run across this:
> 
> "LIRC is a package that allows you to decode and send infra-red
> signals of many (but not all) commonly used remote controls. "
> 
> taken from lirc.org: my case is exactly falling into this
> description.
> 
> Am I missing anything?

See drivers/staging/media/lirc/TODO: "All drivers should either be 
ported to ir-core, or dropped entirely".  ir-core has since been renamed 
to rc-core; it is uses for non-IR purposes like cec.

lirc exists as the user-space ABI but not it is not the preferred 
framework for kernel space.

There is one problem here. rc-core does not provide very well for
transmit-only hardware, so rc-core needs some modifications. This is
what I suggest to make it work:

1. in include/media/rc-core.h add a new entry to the enum rc_driver_type
   called "RC_DRIVER_IR_RAW_TX_ONLY" (or something like that).
2. rc_allocate_device() needs an argument "enum rc_driver_type"; in the
   case it would not allocate an input device. All drivers needs to
   pass in this argument.
3. rc_register_device() and rc_unregister_device() should not execute
   anything with to do with input devices or key maps for tx only
   devices.
4. ir_lirc_register() should not set the LIRC_CAN_REC_MODE2 feature
   or allocate an input buffer in the case of TX only device.

With these changes all you need to do in ir-spi is:

struct rc_dev *rc = rc_allocate_device(RC_DRIVER_IR_RAW_TX_ONLY);
strcpy(rc->name, "IR SPI");
rc->s_tx_carrier = ir_spi_set_tx_carrier; // write function
rc->tx_ir = ir_spi_tx; // write function
rc->driver_name = "ir-spi";

rc_register_driver(rc);


I'm happy to help. 


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

[GIT PULL] mem2mem changes

2016-07-01 Thread Kamil Debski

The following changes since commit 0db5c79989de2c68d5abb7ba891bfdb3cd3b7e05:

  [media] media-devnode.h: Fix documentation (2016-06-16 08:14:56 -0300)

are available in the git repository at:

  git://linuxtv.org/kdebski/media_tree_2.git master-20160627

for you to fetch changes up to 54fd06bfa3aed1c14731a372be92c15d3cdd6998:

  exynos4-is: Fix buffer release issue on fimc m2m video nodes (2016-06-30
16:03:02 +0200)


Javier Martinez Canillas (5):
  s5p-mfc: fix typo in s5p_mfc_dec function comment
  s5p-mfc: don't print errors on VIDIOC_REQBUFS unsupported mem type
  s5p-mfc: use vb2_is_streaming() to check vb2 queue status
  s5p-mfc: set capablity bus_info as required by VIDIOC_QUERYCAP
  s5p-mfc: improve v4l2_capability driver and card fields

Marek Szyprowski (1):
  media: s5p-mfc: fix error path in driver probe

Shuah Khan (3):
  media: s5p-mfc fix video device release double release in probe error
path
  media: s5p-mfc fix memory leak in s5p_mfc_remove()
  media: s5p-mfc fix null pointer deference in clk_core_enable()

Sylwester Nawrocki (1):
  exynos4-is: Fix buffer release issue on fimc m2m video nodes

 drivers/media/platform/exynos4-is/fimc-m2m.c| 24
++--
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 19 +++
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  2 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 15 ---
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|  7 ---
 drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 12 +---
 6 files changed, 44 insertions(+), 35 deletions(-)

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

Re: [PATCH v4] [media] vimc: Virtual Media Controller core, capture and sensor

2016-07-01 Thread Hans Verkuil

Hi Helen,

Better late than never, but I finally have time for a review, mostly with a eye 
for V4L2 issues.

Please note the 'kbuild test robot' mails you received: those issues should be 
resolved
in v5. It looks like it misses the media controller dependency in the Kconfig.

On 05/31/2016 05:02 PM, Helen Koike wrote:
> From: Helen Fornazier 
> 
> First version of the Virtual Media Controller.
> Add a simple version of the core of the driver, the capture and
> sensor nodes in the topology, generating a grey image in a hardcoded
> format.
> 
> Signed-off-by: Helen Fornazier 
> 
> ---
> Changes since v3: fix rmmod crash and built-in compile
> - Re-order unregister calls in vimc_device_unregister function (remove
> rmmod issue)
> - Call media_device_unregister_entity in vimc_raw_destroy
> - Add depends on VIDEO_DEV && VIDEO_V4L2 and select VIDEOBUF2_VMALLOC
> - Check *nplanes in queue_setup (this remove v4l2-compliance fail)
> - Include  in vimc-sensor.c
> - Move include of  from vimc-core.c to vimc-core.h
> - Generate 60 frames per sec instead of 1 in the sensor
> 
> Changes since v2: update with current media master tree
> - Add struct media_pipeline in vimc_cap_device
> - Use vb2_v4l2_buffer instead of vb2_buffer
> - Typos
> - Remove usage of entity->type and use entity->function instead
> - Remove fmt argument from queue setup
> - Use ktime_get_ns instead of v4l2_get_timestamp
> - Iterate over link's list using list_for_each_entry
> - Use media_device_{init, cleanup}
> - Use entity->use_count to keep track of entities instead of the old
> entity->id
> - Replace media_entity_init by media_entity_pads_init
> 
>  drivers/media/platform/Kconfig |   2 +
>  drivers/media/platform/Makefile|   1 +
>  drivers/media/platform/vimc/Kconfig|   8 +
>  drivers/media/platform/vimc/Makefile   |   3 +
>  drivers/media/platform/vimc/vimc-capture.c | 536 ++
>  drivers/media/platform/vimc/vimc-capture.h |  28 ++
>  drivers/media/platform/vimc/vimc-core.c| 595 
> +
>  drivers/media/platform/vimc/vimc-core.h|  56 +++
>  drivers/media/platform/vimc/vimc-sensor.c  | 278 ++
>  drivers/media/platform/vimc/vimc-sensor.h  |  28 ++
>  10 files changed, 1535 insertions(+)
>  create mode 100644 drivers/media/platform/vimc/Kconfig
>  create mode 100644 drivers/media/platform/vimc/Makefile
>  create mode 100644 drivers/media/platform/vimc/vimc-capture.c
>  create mode 100644 drivers/media/platform/vimc/vimc-capture.h
>  create mode 100644 drivers/media/platform/vimc/vimc-core.c
>  create mode 100644 drivers/media/platform/vimc/vimc-core.h
>  create mode 100644 drivers/media/platform/vimc/vimc-sensor.c
>  create mode 100644 drivers/media/platform/vimc/vimc-sensor.h
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 84e041c..9e10d49 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -284,6 +284,8 @@ menuconfig V4L_TEST_DRIVERS
>  
>  if V4L_TEST_DRIVERS
>  
> +source "drivers/media/platform/vimc/Kconfig"
> +
>  source "drivers/media/platform/vivid/Kconfig"
>  
>  config VIDEO_VIM2M
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index bbb7bd1..e4508fe 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_VIDEO_OMAP3)   += omap3isp/
>  
>  obj-$(CONFIG_VIDEO_VIU) += fsl-viu.o
>  
> +obj-$(CONFIG_VIDEO_VIMC) += vimc/
>  obj-$(CONFIG_VIDEO_VIVID)+= vivid/
>  obj-$(CONFIG_VIDEO_VIM2M)+= vim2m.o
>  
> diff --git a/drivers/media/platform/vimc/Kconfig 
> b/drivers/media/platform/vimc/Kconfig
> new file mode 100644
> index 000..c99666a
> --- /dev/null
> +++ b/drivers/media/platform/vimc/Kconfig
> @@ -0,0 +1,8 @@
> +config VIDEO_VIMC
> + tristate "Virtual Media Controller Driver (VIMC)"
> + depends on VIDEO_DEV && VIDEO_V4L2
> + select VIDEO_V4L2_SUBDEV_API

This should be depends on.

> + select VIDEOBUF2_VMALLOC
> + default n
> + ---help---
> +   Skeleton driver for Virtual Media Controller
> diff --git a/drivers/media/platform/vimc/Makefile 
> b/drivers/media/platform/vimc/Makefile
> new file mode 100644
> index 000..c45195e
> --- /dev/null
> +++ b/drivers/media/platform/vimc/Makefile
> @@ -0,0 +1,3 @@
> +vimc-objs := vimc-core.o vimc-capture.o vimc-sensor.o
> +
> +obj-$(CONFIG_VIDEO_VIMC) += vimc.o
> diff --git a/drivers/media/platform/vimc/vimc-capture.c 
> b/drivers/media/platform/vimc/vimc-capture.c
> new file mode 100644
> index 000..82de8b89
> --- /dev/null
> +++ b/drivers/media/platform/vimc/vimc-capture.c
> @@ -0,0 +1,536 @@
> +/*
> + * vimc-capture.c Virtual Media Controller Driver
> + *
> + * Copyright (C) 2015 Helen Fornazier 

Copyright year can be updated to 2016.

> + *
> + * This program is

Re: [PATCH] [media] rc: ir-spi: add support for IR LEDs connected with SPI

2016-07-01 Thread Andi Shyti

Hi Sean,

> > The ir-spi is a simple device driver which supports the
> > connection between an IR LED and the MOSI line of an SPI device.
> > 
> > The driver, indeed, uses the SPI framework to stream the raw data
> > provided by userspace through a character device. The chardev is
> > handled by the LIRC framework and its functionality basically
> > provides:
> > 
> >  - raw write: data to be sent to the SPI and then streamed to the
> >MOSI line;
> >  - set frequency: sets the frequency whith which the data should
> >be sent;
> >  - set length: sets the data length. This information is
> >optional, if the length is set, then userspace should send raw
> >data only with that length; while if the length is set to '0',
> >then the driver will figure out himself the length of the data
> >based on the length of the data written on the character
> >device.
> >The latter is not recommended, though, as the driver, at
> >any write, allocates and deallocates a buffer where the data
> >from userspace are stored.
> > 
> > The driver provides three feedback commands:
> > 
> >  - get length: reads the length set and (as mentioned), if the
> >length is '0' it will be calculated at any write
> >  - get frequency: the driver reports the frequency. If userpace
> >doesn't set the frequency, the driver will use a default value
> >of 38000Hz.
> 
> This interface is not compatible with other lirc devices; there is no
> way of determining whether this is a regular lirc device or this new
> flavour you've invented.

except of the set length and get length which I'm using a bit
freely because I am dealing with devices that exchange always the
same amount of data, so that I don't need (in my case) to
pre-allocate or overallocate or runtime allocate. I don't
understand what else I invented :)

This is a simple driver which is driving an LED connected through
SPI and userspace writes raw data in it (LIRC_CAN_SEND_RAW).

> Also I don't see what justifies this new interface. This can be 
> implemented in rc-core in less lines of code and it will be entirely 
> compatible with existing user-space.

Also here I'm getting a bit confused. When I started writing
this, I didn't even know of the existence of a remote controlling
framework, but then I run across this:

"LIRC is a package that allows you to decode and send infra-red
signals of many (but not all) commonly used remote controls. "

taken from lirc.org: my case is exactly falling into this
description.

Am I missing anything?

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

Re: [PATCH v5 0/2] [media] atmel-isc: add driver for Atmel ISC

2016-07-01 Thread Hans Verkuil

Hi Songjun,

First of all, please CC patch 2/2 to linux-media as well the next time you post 
this.
I only see 1/2 on the mailinglist, and we need both.

Secondly, before I can accept it you need to run the v4l2-compliance test first 
and
I need to see the output of that test.

The compliance test is here: https://git.linuxtv.org/v4l-utils.git. Always 
compile it from
the repository so you know you are using the latest most up to date version.

Since this driver supports multiple pixelformats you need to test with the -f 
option,
which tests streaming for all pixelformats.

Obviously, there shouldn't be any FAILs :-)

I greatly simplifies the code review if I know it passes the compliance test.

Regards,

Hans

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

Re: [PATCH v3 0/9] Add MT8173 Video Decoder Driver

2016-07-01 Thread andrew-ct chen

On Fri, 2016-07-01 at 12:11 +0200, Hans Verkuil wrote:
> On 06/16/2016 12:54 PM, Mauro Carvalho Chehab wrote:
> > Em Tue, 14 Jun 2016 19:08:08 +0800
> > tiffany lin  escreveu:
> > 
> >> Hi Mauro,
> >>
> >>
> >> On Wed, 2016-06-08 at 07:13 +0900, Hans Verkuil wrote:
> >>>
> >>> On 06/07/2016 11:22 PM, Mauro Carvalho Chehab wrote:  
>  Em Mon, 30 May 2016 20:29:14 +0800
>  Tiffany Lin  escreveu:
>   
> > ==
> >   Introduction
> > ==
> >
> > The purpose of this series is to add the driver for video codec hw 
> > embedded in the Mediatek's MT8173 SoCs.
> > Mediatek Video Codec is able to handle video decoding of in a range of 
> > formats.
> >
> > This patch series add Mediatek block format V4L2_PIX_FMT_MT21, the 
> > decoder driver will decoded bitstream to
> > V4L2_PIX_FMT_MT21 format.
> >
> > This patch series rely on MTK VPU driver in patch series "Add MT8173 
> > Video Encoder Driver and VPU Driver"[1]
> > and patch "CHROMIUM: v4l: Add V4L2_PIX_FMT_VP9 definition"[2] for VP9 
> > support.
> > Mediatek Video Decoder driver rely on VPU driver to load, communicate 
> > with VPU.
> >
> > Internally the driver uses videobuf2 framework and MTK IOMMU and MTK 
> > SMI both have been merged in v4.6-rc1.
> >
> > [1]https://patchwork.linuxtv.org/patch/33734/
> > [2]https://chromium-review.googlesource.com/#/c/245241/  
> 
>  Hmm... I'm not seeing the firmware for this driver at the
>  linux-firmware tree:
>   
>  https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/log/
> 
>  Nor I'm seeing any pull request for them. Did you send it?
>  I'll only merge the driver upstream after seeing such pull request.  
> >>>   
> >> Sorry, I am not familiar with how to upstream firmware.
> >> Do you mean we need to upstream vpu firmware first before merge encoder
> >> driver upstream?
> > 
> > Please look at this page:
> > 
> > https://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches#Firmware_submission
> > 
> > The information here can also be useful:
> > https://www.kernel.org/doc/readme/firmware-README.AddingFirmware
> > 
> > In summary, you need to provide redistribution rights for the
> > firmware blob. You can either submit it to me or directly to
> > linux-firmware. In the latter, please c/c me on such patch.
> 
> Tiffany, what is the status of the firmware submission?
> 
> Regards,
> 
>   Hans

Hi Hans,
We are working on firmware test to make sure that both decoder and
encoder work well. Hopes it can be ready (firmware submission) on July 4
or July 5.

Thanks.
Andrew

> 
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek


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

Re: [PATCH v3 0/9] Add MT8173 Video Decoder Driver

2016-07-01 Thread Hans Verkuil

On 07/01/2016 01:53 PM, andrew-ct chen wrote:
> On Fri, 2016-07-01 at 12:11 +0200, Hans Verkuil wrote:
>> On 06/16/2016 12:54 PM, Mauro Carvalho Chehab wrote:
>>> Em Tue, 14 Jun 2016 19:08:08 +0800
>>> tiffany lin  escreveu:
>>>
 Hi Mauro,


 On Wed, 2016-06-08 at 07:13 +0900, Hans Verkuil wrote:
>
> On 06/07/2016 11:22 PM, Mauro Carvalho Chehab wrote:  
>> Em Mon, 30 May 2016 20:29:14 +0800
>> Tiffany Lin  escreveu:
>>  
>>> ==
>>>   Introduction
>>> ==
>>>
>>> The purpose of this series is to add the driver for video codec hw 
>>> embedded in the Mediatek's MT8173 SoCs.
>>> Mediatek Video Codec is able to handle video decoding of in a range of 
>>> formats.
>>>
>>> This patch series add Mediatek block format V4L2_PIX_FMT_MT21, the 
>>> decoder driver will decoded bitstream to
>>> V4L2_PIX_FMT_MT21 format.
>>>
>>> This patch series rely on MTK VPU driver in patch series "Add MT8173 
>>> Video Encoder Driver and VPU Driver"[1]
>>> and patch "CHROMIUM: v4l: Add V4L2_PIX_FMT_VP9 definition"[2] for VP9 
>>> support.
>>> Mediatek Video Decoder driver rely on VPU driver to load, communicate 
>>> with VPU.
>>>
>>> Internally the driver uses videobuf2 framework and MTK IOMMU and MTK 
>>> SMI both have been merged in v4.6-rc1.
>>>
>>> [1]https://patchwork.linuxtv.org/patch/33734/
>>> [2]https://chromium-review.googlesource.com/#/c/245241/  
>>
>> Hmm... I'm not seeing the firmware for this driver at the
>> linux-firmware tree:
>>  
>> https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/log/
>>
>> Nor I'm seeing any pull request for them. Did you send it?
>> I'll only merge the driver upstream after seeing such pull request.  
>   
 Sorry, I am not familiar with how to upstream firmware.
 Do you mean we need to upstream vpu firmware first before merge encoder
 driver upstream?
>>>
>>> Please look at this page:
>>> 
>>> https://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches#Firmware_submission
>>>
>>> The information here can also be useful:
>>> https://www.kernel.org/doc/readme/firmware-README.AddingFirmware
>>>
>>> In summary, you need to provide redistribution rights for the
>>> firmware blob. You can either submit it to me or directly to
>>> linux-firmware. In the latter, please c/c me on such patch.
>>
>> Tiffany, what is the status of the firmware submission?
>>
>> Regards,
>>
>>  Hans
> 
> Hi Hans,
> We are working on firmware test to make sure that both decoder and
> encoder work well. Hopes it can be ready (firmware submission) on July 4
> or July 5.

OK, great! Just wanted to make sure that this work was progressing and not 
stalled.

Thanks!

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

Re: [PATCH] [media] v4l2-async: Always unregister the subdev on failure

2016-07-01 Thread Hans Verkuil

On 05/11/2016 06:32 PM, Alban Bedel wrote:
> On Wed, 11 May 2016 12:22:44 -0400
> Javier Martinez Canillas  wrote:
> 
>> Hello Alban,
>>
>> On 05/11/2016 11:40 AM, Alban Bedel wrote:
>>> In v4l2_async_test_notify() if the registered_async callback or the
>>> complete notifier returns an error the subdev is not unregistered.
>>> This leave paths where v4l2_async_register_subdev() can fail but
>>> leave the subdev still registered.
>>>
>>> Add the required calls to v4l2_device_unregister_subdev() to plug
>>> these holes.
>>>
>>> Signed-off-by: Alban Bedel 
>>> ---
>>>  drivers/media/v4l2-core/v4l2-async.c | 10 --
>>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
>>> b/drivers/media/v4l2-core/v4l2-async.c
>>> index ceb28d4..43393f8 100644
>>> --- a/drivers/media/v4l2-core/v4l2-async.c
>>> +++ b/drivers/media/v4l2-core/v4l2-async.c
>>> @@ -121,13 +121,19 @@ static int v4l2_async_test_notify(struct 
>>> v4l2_async_notifier *notifier,
>>>  
>>> ret = v4l2_subdev_call(sd, core, registered_async);
>>> if (ret < 0 && ret != -ENOIOCTLCMD) {
>>> +   v4l2_device_unregister_subdev(sd);
>>> if (notifier->unbind)
>>> notifier->unbind(notifier, sd, asd);
>>> return ret;
>>> }
>>>  
>>> -   if (list_empty(>waiting) && notifier->complete)
>>> -   return notifier->complete(notifier);
>>> +   if (list_empty(>waiting) && notifier->complete) {
>>> +   ret = notifier->complete(notifier);
>>> +   if (ret < 0) {
>>> +   v4l2_device_unregister_subdev(sd);
>>
>> Isn't a call to notifier->unbind() missing here as well?
>>
>> Also, I think the error path is becoming too duplicated and complex, so
>> maybe we can have a single error path and use goto labels as is common
>> in Linux? For example something like the following (not tested) can be
>> squashed on top of your change:
> 
> Yes, that look better. I'll test it and report tomorrow.

I haven't heard anything back about this. Did you manage to test it?

Regards,

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

Re: [patch V4 14/31] media: use parity functions in saa7115

2016-07-01 Thread Hans Verkuil

On 05/11/2016 11:19 AM, zengzhao...@163.com wrote:
> From: Zhaoxiu Zeng 
> 
> Signed-off-by: Zhaoxiu Zeng 

Acked-by: Hans Verkuil 

Thanks,

Hans

> ---
>  drivers/media/i2c/saa7115.c | 17 ++---
>  1 file changed, 2 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/media/i2c/saa7115.c b/drivers/media/i2c/saa7115.c
> index d2a1ce2..4c22df8 100644
> --- a/drivers/media/i2c/saa7115.c
> +++ b/drivers/media/i2c/saa7115.c
> @@ -672,15 +672,6 @@ static const unsigned char saa7115_init_misc[] = {
>   0x00, 0x00
>  };
>  
> -static int saa711x_odd_parity(u8 c)
> -{
> - c ^= (c >> 4);
> - c ^= (c >> 2);
> - c ^= (c >> 1);
> -
> - return c & 1;
> -}
> -
>  static int saa711x_decode_vps(u8 *dst, u8 *p)
>  {
>   static const u8 biphase_tbl[] = {
> @@ -733,7 +724,6 @@ static int saa711x_decode_wss(u8 *p)
>   static const int wss_bits[8] = {
>   0, 0, 0, 1, 0, 1, 1, 1
>   };
> - unsigned char parity;
>   int wss = 0;
>   int i;
>  
> @@ -745,11 +735,8 @@ static int saa711x_decode_wss(u8 *p)
>   return -1;
>   wss |= b2 << i;
>   }
> - parity = wss & 15;
> - parity ^= parity >> 2;
> - parity ^= parity >> 1;
>  
> - if (!(parity & 1))
> + if (!parity4(wss))
>   return -1;
>  
>   return wss;
> @@ -1235,7 +1222,7 @@ static int saa711x_decode_vbi_line(struct v4l2_subdev 
> *sd, struct v4l2_decode_vb
>   vbi->type = V4L2_SLICED_TELETEXT_B;
>   break;
>   case 4:
> - if (!saa711x_odd_parity(p[0]) || !saa711x_odd_parity(p[1]))
> + if (!parity8(p[0]) || !parity8(p[1]))
>   return 0;
>   vbi->type = V4L2_SLICED_CAPTION_525;
>   break;
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [media] cec: add missing inline stubs

2016-07-01 Thread Arnd Bergmann

The linux/cec.h header file contains empty inline definitions for
a subset of the API for the case in which CEC is not enabled,
however we have driver that call other functions as well:

drivers/media/i2c/adv7604.c: In function 'adv76xx_cec_tx_raw_status':
drivers/media/i2c/adv7604.c:1956:3: error: implicit declaration of function 
'cec_transmit_done' [-Werror=implicit-function-declaration]
drivers/media/i2c/adv7604.c: In function 'adv76xx_cec_isr':
drivers/media/i2c/adv7604.c:2012:4: error: implicit declaration of function 
'cec_received_msg' [-Werror=implicit-function-declaration]
drivers/media/i2c/adv7604.c: In function 'adv76xx_probe':
drivers/media/i2c/adv7604.c:3482:20: error: implicit declaration of function 
'cec_allocate_adapter' [-Werror=implicit-function-declaration]

This adds stubs for the remaining interfaces as well.

Signed-off-by: Arnd Bergmann 
---
 include/media/cec.h | 25 +
 1 file changed, 25 insertions(+)

diff --git a/include/media/cec.h b/include/media/cec.h
index 9a791c08a789..c462f9b44074 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -208,6 +208,12 @@ void cec_transmit_done(struct cec_adapter *adap, u8 
status, u8 arb_lost_cnt,
 void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg);
 
 #else
+static inline struct cec_adapter *cec_allocate_adapter(
+   const struct cec_adap_ops *ops, void *priv, const char *name,
+   u32 caps, u8 available_las, struct device *parent)
+{
+   return NULL;
+}
 
 static inline int cec_register_adapter(struct cec_adapter *adap)
 {
@@ -227,6 +233,25 @@ static inline void cec_s_phys_addr(struct cec_adapter 
*adap, u16 phys_addr,
 {
 }
 
+static inline int cec_transmit_msg(struct cec_adapter *adap,
+  struct cec_msg *msg, bool block)
+{
+   return 0;
+}
+
+/* Called by the adapter */
+static inline void cec_transmit_done(struct cec_adapter *adap, u8 status,
+u8 arb_lost_cnt, u8 nack_cnt,
+u8 low_drive_cnt, u8 error_cnt)
+{
+}
+
+static inline void cec_received_msg(struct cec_adapter *adap,
+   struct cec_msg *msg)
+{
+}
+
+
 #endif
 
 #endif /* _MEDIA_CEC_H */
-- 
2.9.0

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

Re: usbvision: problems adding support for ATI TV Wonder USB Edition

2016-07-01 Thread Hans Verkuil

Hi Christopher,

On 12/19/2015 07:12 AM, Christopher Chavez wrote:
> Hi,
> 
> Not yet an experienced developer here, still working on BSCmpE.
> 
> I have attempted to add long-awaited support for the ATI TV Wonder USB Edition
> (NTSC) to usbvision. I have patches of what I've accomplished so far, but I'm
> not yet able to test it due to a couple of issues, at least one of which 
> appears
> to be an outstanding bug from a few years ago (the "cannot change alternate
> number to 1 (error=-22)" issue). The entry in usbvision-cards.c is based on a
> similar Pinnacle and Hauppauge entries: the device looks like it might have 
> been
> a rebadged Hauppauge WinTV USB, but inside it has both the NT1004 and NT1005
> bridges, SAA7113H input processor, and FI1236MK2 tuner (although none of the
> supported devices use .tuner_type = TUNER_PHILIPS_NTSC).
> 
> I'm still researching what other programs to test this with (VLC? 
> v4l-utils?)...

I use qv4l2 from v4l-utils.

Did you make any progress with this?

The problem is that the usbvision driver is very old and very badly written. And
I doubt anyone will have time to upgrade this driver to modern standards.

I don't mind taking this patch, but I should at least have confirmation that you
got it to work :-)

Regards,

Hans (who is cleaning out old submitted patches)

> 
> Christopher Chavez
> 
> 
> ---
>  drivers/media/usb/usbvision/usbvision-cards.c | 15 +++
>  drivers/media/usb/usbvision/usbvision-cards.h |  1 +
>  drivers/media/usb/usbvision/usbvision-video.c |  3 ++-
>  3 files changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/usb/usbvision/usbvision-cards.c
> b/drivers/media/usb/usbvision/usbvision-cards.c
> index 3103d0d..7b1edb7 100644
> --- a/drivers/media/usb/usbvision/usbvision-cards.c
> +++ b/drivers/media/usb/usbvision/usbvision-cards.c
> @@ -1054,6 +1054,20 @@ struct usbvision_device_data_st
> usbvision_device_data[] = {
>  .y_offset   = 18,
>  .model_string   = "Nogatech USB MicroCam PAL (NV3001P)",
>  },
> +[ATI_TV_WONDER_USB_NTSC] = {
> +.interface  = 0,
> +.codec  = CODEC_SAA7113,
> +.video_channels = 3,
> +.video_norm = V4L2_STD_NTSC,
> +.audio_channels = 1,
> +.radio  = 0,
> +.vbi= 1,
> +.tuner  = 1,
> +.tuner_type = TUNER_PHILIPS_NTSC,
> +.x_offset   = -1,
> +.y_offset   = -1,
> +.model_string   = "ATI TV Wonder USB Edition (NTSC)",
> +},
>  };
>  const int usbvision_device_data_size = ARRAY_SIZE(usbvision_device_data);
> 
> @@ -1064,6 +1078,7 @@ struct usb_device_id usbvision_table[] = {
>  { USB_DEVICE(0x050d, 0x0106), .driver_info = BELKIN_VIDEOBUS_II },
>  { USB_DEVICE(0x050d, 0x0207), .driver_info = BELKIN_VIDEOBUS },
>  { USB_DEVICE(0x050d, 0x0208), .driver_info = BELKIN_USB_VIDEOBUS_II },
> +{ USB_DEVICE(0x0528, 0x7561), .driver_info = ATI_TV_WONDER_USB_NTSC },
>  { USB_DEVICE(0x0571, 0x0002), .driver_info = ECHOFX_INTERVIEW_LITE },
>  { USB_DEVICE(0x0573, 0x0003), .driver_info = USBGEAR_USBG_V1 },
>  { USB_DEVICE(0x0573, 0x0400), .driver_info = D_LINK_V100 },
> diff --git a/drivers/media/usb/usbvision/usbvision-cards.h
> b/drivers/media/usb/usbvision/usbvision-cards.h
> index a51cc11..ed1197c 100644
> --- a/drivers/media/usb/usbvision/usbvision-cards.h
> +++ b/drivers/media/usb/usbvision/usbvision-cards.h
> @@ -65,5 +65,6 @@
>  #define PINNA_PCTV_USB_NTSC_FM_V364
>  #define MICROCAM_NTSC65
>  #define MICROCAM_PAL 66
> +#define ATI_TV_WONDER_USB_NTSC   67
> 
>  extern const int usbvision_device_data_size;
> diff --git a/drivers/media/usb/usbvision/usbvision-video.c
> b/drivers/media/usb/usbvision/usbvision-video.c
> index de9ff3b..c76e1397 100644
> --- a/drivers/media/usb/usbvision/usbvision-video.c
> +++ b/drivers/media/usb/usbvision/usbvision-video.c
> @@ -1511,7 +1511,8 @@ static int usbvision_probe(struct usb_interface *intf,
> 
>  if (dev->descriptor.bNumConfigurations > 1)
>  usbvision->bridge_type = BRIDGE_NT1004;
> -else if (model == DAZZLE_DVC_90_REV_1_SECAM)
> +else if ((model == DAZZLE_DVC_90_REV_1_SECAM) ||
> + (model == ATI_TV_WONDER_USB_NTSC))
>  usbvision->bridge_type = BRIDGE_NT1005;
>  else
>  usbvision->bridge_type = BRIDGE_NT1003;
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: square-only image on Nokia N900 camera -- pipeline setup in python (was Re: [RFC PATCH 00/24] Make Nokia N900 cameras working)

2016-07-01 Thread Pavel Machek

On Fri 2016-07-01 10:50:25, Pavel Machek wrote:
> Hi!
> 
> > On gitlab is the latest version of pipeline setup if python. I also
> > got fcam to work (slowly) on the camera, with autofocus and
> > autogain. Capturing from preview modes works fine, but image quality
> > is not good, as expected. Capturing raw GRBG10 images works, but
> > images are square, with values being outside square being 0.
> > 
> > Same problem is there with yavta and fcam-dev capture, so I suspect
> > there's something in kernel. If you have an idea what could be wrong /
> > what to try, let me know. If omap3isp works for you in v4.6, and
> > produces expected rectangular images, that would be useful to know,
> > too.
> > 
> > Python capture script is at
> > 
> > https://gitlab.com/tui/tui/commit/266b6eb302dcf1481e3e90a05bf98180e5759168
> 
> I switched to the front camera (vs6555 pixel array 2-0010 + vs6555
> binner 2-0010) and got same effect: preview image works fine, raw
> image is square. Still kernel v4.6.

Same issue with kernel v4.7-rc5.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cec: fix Kconfig dependency problems

2016-07-01 Thread Arnd Bergmann

On Friday, July 1, 2016 12:37:06 PM CEST Hans Verkuil wrote:
> - Use IS_REACHABLE(RC_CORE) instead of IS_ENABLED: if cec is built-in and
>   RC_CORE is a module, then CEC can't reach the RC symbols.
> - Both cec and cec-edid should be bool and use the same build 'mode' as
>   MEDIA_SUPPORT (just as is done for the media controller code).
> - Add a note to staging that this should be changed once the cec framework
>   is moved out of staging.
> 
> Signed-off-by: Hans Verkuil 
> Reported-by: Arnd Bergmann 

This looks ok, but I'll give it some more randconfig build testing and will
try to report back later today. If you don't hear from me, it's probably
ok.

There is still another issue with the header, I'll send a patch for it
since I've already done one.

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

Re: [PATCH] v4l: ioctl: Clear the v4l2_pix_format_mplane reserved field

2016-07-01 Thread Hans Verkuil

On 06/28/2016 03:20 PM, Laurent Pinchart wrote:
> The S_FMT and TRY_FMT handlers in multiplane mode attempt at clearing
> the reserved fields of the v4l2_format structure after the pix_mp
> member. However, the reserved fields are inside pix_mp, not after it.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> Kieran, this should fix the v4l2-compliance failures you saw when not clearing
> pix_mp.reserved manually in the FDP1 driver. Could you please test it ?
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 19d3aee3b374..86332072a575 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1508,7 +1508,7 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
>   case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
>   if (unlikely(!is_rx || !is_vid || 
> !ops->vidioc_s_fmt_vid_cap_mplane))
>   break;
> - CLEAR_AFTER_FIELD(p, fmt.pix_mp);
> + CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);

The same is needed in v4l_try_fmt.

Regards,

Hans

>   return ops->vidioc_s_fmt_vid_cap_mplane(file, fh, arg);
>   case V4L2_BUF_TYPE_VIDEO_OVERLAY:
>   if (unlikely(!is_rx || !is_vid || 
> !ops->vidioc_s_fmt_vid_overlay))
> @@ -1536,7 +1536,7 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
>   case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
>   if (unlikely(!is_tx || !is_vid || 
> !ops->vidioc_s_fmt_vid_out_mplane))
>   break;
> - CLEAR_AFTER_FIELD(p, fmt.pix_mp);
> + CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
>   return ops->vidioc_s_fmt_vid_out_mplane(file, fh, arg);
>   case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
>   if (unlikely(!is_tx || !is_vid || 
> !ops->vidioc_s_fmt_vid_out_overlay))
> @@ -1598,7 +1598,7 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
>   case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
>   if (unlikely(!is_rx || !is_vid || 
> !ops->vidioc_try_fmt_vid_cap_mplane))
>   break;
> - CLEAR_AFTER_FIELD(p, fmt.pix_mp);
> + CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
>   return ops->vidioc_try_fmt_vid_cap_mplane(file, fh, arg);
>   case V4L2_BUF_TYPE_VIDEO_OVERLAY:
>   if (unlikely(!is_rx || !is_vid || 
> !ops->vidioc_try_fmt_vid_overlay))
> @@ -1626,7 +1626,7 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
>   case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
>   if (unlikely(!is_tx || !is_vid || 
> !ops->vidioc_try_fmt_vid_out_mplane))
>   break;
> - CLEAR_AFTER_FIELD(p, fmt.pix_mp);
> + CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
>   return ops->vidioc_try_fmt_vid_out_mplane(file, fh, arg);
>   case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
>   if (unlikely(!is_tx || !is_vid || 
> !ops->vidioc_try_fmt_vid_out_overlay))
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] tw686x: Support VIDIOC_{S,G}_PARM ioctls

2016-07-01 Thread Hans Verkuil

On 06/29/2016 04:17 AM, Ezequiel Garcia wrote:
> Now that the frame rate can be properly set, this commit adds support
> for S_PARM and G_PARM.

As mentioned in our irc discussion you also need to add 
enum_framesize/intervals.
Otherwise applications won't know what values to use with s_parm.

> 
> Signed-off-by: Ezequiel Garcia 
> ---
>  drivers/media/pci/tw686x/tw686x-video.c | 46 
> ++---
>  1 file changed, 43 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/pci/tw686x/tw686x-video.c 
> b/drivers/media/pci/tw686x/tw686x-video.c
> index 3131f9305313..40b5b835d452 100644
> --- a/drivers/media/pci/tw686x/tw686x-video.c
> +++ b/drivers/media/pci/tw686x/tw686x-video.c
> @@ -437,9 +437,6 @@ static void tw686x_set_framerate(struct 
> tw686x_video_channel *vc,
>  {
>   unsigned int i;
>  
> - if (vc->fps == fps)
> - return;
> -
>   i = tw686x_fps_idx(fps, TW686X_MAX_FPS(vc->video_standard));
>   reg_write(vc->dev, VIDEO_FIELD_CTRL[vc->ch], fps_map[i]);
>   vc->fps = tw686x_real_fps(i, TW686X_MAX_FPS(vc->video_standard));
> @@ -843,6 +840,12 @@ static int tw686x_s_std(struct file *file, void *priv, 
> v4l2_std_id id)
>   ret = tw686x_g_fmt_vid_cap(file, priv, );
>   if (!ret)
>   tw686x_s_fmt_vid_cap(file, priv, );
> +
> + /*
> +  * Frame decimation depends on the chosen standard,
> +  * so reset it to the current value.
> +  */
> + tw686x_set_framerate(vc, vc->fps);
>   return 0;
>  }
>  
> @@ -912,6 +915,40 @@ static int tw686x_g_std(struct file *file, void *priv, 
> v4l2_std_id *id)
>   return 0;
>  }
>  
> +static int tw686x_g_parm(struct file *file, void *priv,
> +  struct v4l2_streamparm *sp)
> +{
> + struct tw686x_video_channel *vc = video_drvdata(file);
> + struct v4l2_captureparm *cp = >parm.capture;
> +
> + if (sp->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
> + return -EINVAL;

You need this check in s_parm as well.

> + sp->parm.capture.readbuffers = 3;
> +
> + cp->capability = V4L2_CAP_TIMEPERFRAME;
> + cp->timeperframe.numerator = 1;
> + cp->timeperframe.denominator = vc->fps;
> + return 0;
> +}
> +
> +static int tw686x_s_parm(struct file *file, void *priv,
> +  struct v4l2_streamparm *sp)
> +{
> + struct tw686x_video_channel *vc = video_drvdata(file);
> + struct v4l2_captureparm *cp = >parm.capture;
> + unsigned int denominator = cp->timeperframe.denominator;
> + unsigned int numerator = cp->timeperframe.numerator;
> + unsigned int fps;
> +
> + if (vb2_is_busy(>vidq))
> + return -EBUSY;
> +
> + fps = (!numerator || !denominator) ? 0 : denominator / numerator;
> + if (vc->fps != fps)
> + tw686x_set_framerate(vc, fps);
> + return tw686x_g_parm(file, priv, sp);
> +}
> +
>  static int tw686x_enum_fmt_vid_cap(struct file *file, void *priv,
>  struct v4l2_fmtdesc *f)
>  {
> @@ -998,6 +1035,9 @@ static const struct v4l2_ioctl_ops 
> tw686x_video_ioctl_ops = {
>   .vidioc_g_std   = tw686x_g_std,
>   .vidioc_s_std   = tw686x_s_std,
>  
> + .vidioc_g_parm  = tw686x_g_parm,
> + .vidioc_s_parm  = tw686x_s_parm,
> +
>   .vidioc_enum_input  = tw686x_enum_input,
>   .vidioc_g_input = tw686x_g_input,
>   .vidioc_s_input = tw686x_s_input,
> 

Regards,

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

Re: [PATCH v3 0/9] Add MT8173 Video Decoder Driver

2016-07-01 Thread 李務誠

+Andrew. Last I heard the license was ready and Andrew was preparing
the VPU firmware. Andrew. Is the firmware ready to submit?

On Fri, Jul 1, 2016 at 6:11 PM, Hans Verkuil  wrote:
> On 06/16/2016 12:54 PM, Mauro Carvalho Chehab wrote:
>> Em Tue, 14 Jun 2016 19:08:08 +0800
>> tiffany lin  escreveu:
>>
>>> Hi Mauro,
>>>
>>>
>>> On Wed, 2016-06-08 at 07:13 +0900, Hans Verkuil wrote:

 On 06/07/2016 11:22 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 30 May 2016 20:29:14 +0800
> Tiffany Lin  escreveu:
>
>> ==
>>   Introduction
>> ==
>>
>> The purpose of this series is to add the driver for video codec hw 
>> embedded in the Mediatek's MT8173 SoCs.
>> Mediatek Video Codec is able to handle video decoding of in a range of 
>> formats.
>>
>> This patch series add Mediatek block format V4L2_PIX_FMT_MT21, the 
>> decoder driver will decoded bitstream to
>> V4L2_PIX_FMT_MT21 format.
>>
>> This patch series rely on MTK VPU driver in patch series "Add MT8173 
>> Video Encoder Driver and VPU Driver"[1]
>> and patch "CHROMIUM: v4l: Add V4L2_PIX_FMT_VP9 definition"[2] for VP9 
>> support.
>> Mediatek Video Decoder driver rely on VPU driver to load, communicate 
>> with VPU.
>>
>> Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI 
>> both have been merged in v4.6-rc1.
>>
>> [1]https://patchwork.linuxtv.org/patch/33734/
>> [2]https://chromium-review.googlesource.com/#/c/245241/
>
> Hmm... I'm not seeing the firmware for this driver at the
> linux-firmware tree:
>
> https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/log/
>
> Nor I'm seeing any pull request for them. Did you send it?
> I'll only merge the driver upstream after seeing such pull request.

>>> Sorry, I am not familiar with how to upstream firmware.
>>> Do you mean we need to upstream vpu firmware first before merge encoder
>>> driver upstream?
>>
>> Please look at this page:
>>   
>> https://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches#Firmware_submission
>>
>> The information here can also be useful:
>>   https://www.kernel.org/doc/readme/firmware-README.AddingFirmware
>>
>> In summary, you need to provide redistribution rights for the
>> firmware blob. You can either submit it to me or directly to
>> linux-firmware. In the latter, please c/c me on such patch.
>
> Tiffany, what is the status of the firmware submission?
>
> Regards,
>
> Hans
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] cec: fix Kconfig dependency problems

2016-07-01 Thread Hans Verkuil

- Use IS_REACHABLE(RC_CORE) instead of IS_ENABLED: if cec is built-in and
  RC_CORE is a module, then CEC can't reach the RC symbols.
- Both cec and cec-edid should be bool and use the same build 'mode' as
  MEDIA_SUPPORT (just as is done for the media controller code).
- Add a note to staging that this should be changed once the cec framework
  is moved out of staging.

Signed-off-by: Hans Verkuil 
Reported-by: Arnd Bergmann 
---
 drivers/media/Kconfig|  2 +-
 drivers/media/Makefile   |  4 +++-
 drivers/staging/media/cec/Kconfig|  2 +-
 drivers/staging/media/cec/Makefile   |  4 +++-
 drivers/staging/media/cec/TODO   |  5 +
 drivers/staging/media/cec/cec-adap.c |  4 ++--
 drivers/staging/media/cec/cec-core.c | 10 +-
 7 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 052dcf7..962f2a9 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -81,7 +81,7 @@ config MEDIA_RC_SUPPORT
  Say Y when you have a TV or an IR device.

 config MEDIA_CEC_EDID
-   tristate
+   bool

 #
 # Media controller
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index b56f013..081a786 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -2,7 +2,9 @@
 # Makefile for the kernel multimedia device drivers.
 #

-obj-$(CONFIG_MEDIA_CEC_EDID) += cec-edid.o
+ifeq ($(CONFIG_MEDIA_CEC_EDID),y)
+  obj-$(CONFIG_MEDIA_SUPPORT) += cec-edid.o
+endif

 media-objs := media-device.o media-devnode.o media-entity.o

diff --git a/drivers/staging/media/cec/Kconfig 
b/drivers/staging/media/cec/Kconfig
index cd52359..21457a1 100644
--- a/drivers/staging/media/cec/Kconfig
+++ b/drivers/staging/media/cec/Kconfig
@@ -1,5 +1,5 @@
 config MEDIA_CEC
-   tristate "CEC API (EXPERIMENTAL)"
+   bool "CEC API (EXPERIMENTAL)"
depends on MEDIA_SUPPORT
select MEDIA_CEC_EDID
---help---
diff --git a/drivers/staging/media/cec/Makefile 
b/drivers/staging/media/cec/Makefile
index 426ef73..bd7f3c5 100644
--- a/drivers/staging/media/cec/Makefile
+++ b/drivers/staging/media/cec/Makefile
@@ -1,3 +1,5 @@
 cec-objs := cec-core.o cec-adap.o cec-api.o

-obj-$(CONFIG_MEDIA_CEC) += cec.o
+ifeq ($(CONFIG_MEDIA_CEC),y)
+  obj-$(CONFIG_MEDIA_SUPPORT) += cec.o
+endif
diff --git a/drivers/staging/media/cec/TODO b/drivers/staging/media/cec/TODO
index a8f4b7d..8221d44 100644
--- a/drivers/staging/media/cec/TODO
+++ b/drivers/staging/media/cec/TODO
@@ -23,5 +23,10 @@ Other TODOs:
   And also TYPE_SWITCH and TYPE_CDC_ONLY in addition to the TYPE_UNREGISTERED?
   This should give the framework more information about the device type
   since SPECIFIC and UNREGISTERED give no useful information.
+- Once this is out of staging this should no longer be a separate
+  config option, instead it should be selected by drivers that want it.
+- Revisit the IS_REACHABLE(RC_CORE): perhaps the RC_CORE support should
+  be enabled through a separate config option in drivers/media/Kconfig
+  or rc/Kconfig?

 Hans Verkuil 
diff --git a/drivers/staging/media/cec/cec-adap.c 
b/drivers/staging/media/cec/cec-adap.c
index 307af43..7df6187 100644
--- a/drivers/staging/media/cec/cec-adap.c
+++ b/drivers/staging/media/cec/cec-adap.c
@@ -1456,7 +1456,7 @@ static int cec_receive_notify(struct cec_adapter *adap, 
struct cec_msg *msg,
if (!(adap->capabilities & CEC_CAP_RC))
break;

-#if IS_ENABLED(CONFIG_RC_CORE)
+#if IS_REACHABLE(CONFIG_RC_CORE)
switch (msg->msg[2]) {
/*
 * Play function, this message can have variable length
@@ -1492,7 +1492,7 @@ static int cec_receive_notify(struct cec_adapter *adap, 
struct cec_msg *msg,
case CEC_MSG_USER_CONTROL_RELEASED:
if (!(adap->capabilities & CEC_CAP_RC))
break;
-#if IS_ENABLED(CONFIG_RC_CORE)
+#if IS_REACHABLE(CONFIG_RC_CORE)
rc_keyup(adap->rc);
 #endif
break;
diff --git a/drivers/staging/media/cec/cec-core.c 
b/drivers/staging/media/cec/cec-core.c
index 61a1e69..112a5fa 100644
--- a/drivers/staging/media/cec/cec-core.c
+++ b/drivers/staging/media/cec/cec-core.c
@@ -239,7 +239,7 @@ struct cec_adapter *cec_allocate_adapter(const struct 
cec_adap_ops *ops,
if (!(caps & CEC_CAP_RC))
return adap;

-#if IS_ENABLED(CONFIG_RC_CORE)
+#if IS_REACHABLE(CONFIG_RC_CORE)
/* Prepare the RC input device */
adap->rc = rc_allocate_device();
if (!adap->rc) {
@@ -282,7 +282,7 @@ int cec_register_adapter(struct cec_adapter *adap)
if (IS_ERR_OR_NULL(adap))
return 0;

-#if IS_ENABLED(CONFIG_RC_CORE)
+#if IS_REACHABLE(CONFIG_RC_CORE)
if (adap->capabilities & CEC_CAP_RC) {
res = rc_register_device(adap->rc);

@@ -298,7 +298,7 @@ int cec_register_adapter(struct cec_adapter *adap)

Re: [PATCH v3 0/9] Add MT8173 Video Decoder Driver

2016-07-01 Thread Hans Verkuil

On 06/16/2016 12:54 PM, Mauro Carvalho Chehab wrote:
> Em Tue, 14 Jun 2016 19:08:08 +0800
> tiffany lin  escreveu:
> 
>> Hi Mauro,
>>
>>
>> On Wed, 2016-06-08 at 07:13 +0900, Hans Verkuil wrote:
>>>
>>> On 06/07/2016 11:22 PM, Mauro Carvalho Chehab wrote:  
 Em Mon, 30 May 2016 20:29:14 +0800
 Tiffany Lin  escreveu:
  
> ==
>   Introduction
> ==
>
> The purpose of this series is to add the driver for video codec hw 
> embedded in the Mediatek's MT8173 SoCs.
> Mediatek Video Codec is able to handle video decoding of in a range of 
> formats.
>
> This patch series add Mediatek block format V4L2_PIX_FMT_MT21, the 
> decoder driver will decoded bitstream to
> V4L2_PIX_FMT_MT21 format.
>
> This patch series rely on MTK VPU driver in patch series "Add MT8173 
> Video Encoder Driver and VPU Driver"[1]
> and patch "CHROMIUM: v4l: Add V4L2_PIX_FMT_VP9 definition"[2] for VP9 
> support.
> Mediatek Video Decoder driver rely on VPU driver to load, communicate 
> with VPU.
>
> Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI 
> both have been merged in v4.6-rc1.
>
> [1]https://patchwork.linuxtv.org/patch/33734/
> [2]https://chromium-review.googlesource.com/#/c/245241/  

 Hmm... I'm not seeing the firmware for this driver at the
 linux-firmware tree:

 https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/log/

 Nor I'm seeing any pull request for them. Did you send it?
 I'll only merge the driver upstream after seeing such pull request.  
>>>   
>> Sorry, I am not familiar with how to upstream firmware.
>> Do you mean we need to upstream vpu firmware first before merge encoder
>> driver upstream?
> 
> Please look at this page:
>   
> https://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches#Firmware_submission
> 
> The information here can also be useful:
>   https://www.kernel.org/doc/readme/firmware-README.AddingFirmware
> 
> In summary, you need to provide redistribution rights for the
> firmware blob. You can either submit it to me or directly to
> linux-firmware. In the latter, please c/c me on such patch.

Tiffany, what is the status of the firmware submission?

Regards,

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

[PATCHv5 05/13] media/pci: convert drivers to use the new vb2_queue dev field

2016-07-01 Thread Hans Verkuil

>From 62ddd1aabe5672541055bc6de3c80ca1e3635729 Mon Sep 17 00:00:00 2001
From: Hans Verkuil 
Date: Mon, 15 Feb 2016 15:37:15 +0100
Subject: [PATCH 05/13] media/pci: convert drivers to use the new vb2_queue dev
 field

Stop using alloc_ctx and just fill in the device pointer.

Signed-off-by: Hans Verkuil 
Cc: Federico Vaga 
Cc: Mauro Carvalho Chehab 
---
After rebasing the vb2: replace allocation context by device pointer patch 
series I discovered
that newly committed changes to tw686x required that driver to be updated as 
well.
This is the patch for that.
---
diff --git a/drivers/media/pci/tw686x/tw686x-video.c 
b/drivers/media/pci/tw686x/tw686x-video.c
index 0e839f6..d380a8d 100644
--- a/drivers/media/pci/tw686x/tw686x-video.c
+++ b/drivers/media/pci/tw686x/tw686x-video.c
@@ -177,24 +177,7 @@ static void tw686x_contig_buf_refill(struct 
tw686x_video_channel *vc,
vc->curr_bufs[pb] = NULL;
 }

-static void tw686x_contig_cleanup(struct tw686x_dev *dev)
-{
-   vb2_dma_contig_cleanup_ctx(dev->alloc_ctx);
-}
-
-static int tw686x_contig_setup(struct tw686x_dev *dev)
-{
-   dev->alloc_ctx = vb2_dma_contig_init_ctx(>pci_dev->dev);
-   if (IS_ERR(dev->alloc_ctx)) {
-   dev_err(>pci_dev->dev, "unable to init DMA context\n");
-   return PTR_ERR(dev->alloc_ctx);
-   }
-   return 0;
-}
-
 const struct tw686x_dma_ops contig_dma_ops = {
-   .setup  = tw686x_contig_setup,
-   .cleanup= tw686x_contig_cleanup,
.buf_refill = tw686x_contig_buf_refill,
.mem_ops= _dma_contig_memops,
.hw_dma_mode= TW686X_FRAME_MODE,
@@ -316,21 +299,10 @@ static int tw686x_sg_dma_alloc(struct 
tw686x_video_channel *vc,
return 0;
 }

-static void tw686x_sg_cleanup(struct tw686x_dev *dev)
-{
-   vb2_dma_sg_cleanup_ctx(dev->alloc_ctx);
-}
-
 static int tw686x_sg_setup(struct tw686x_dev *dev)
 {
unsigned int sg_table_size, pb, ch, channels;

-   dev->alloc_ctx = vb2_dma_sg_init_ctx(>pci_dev->dev);
-   if (IS_ERR(dev->alloc_ctx)) {
-   dev_err(>pci_dev->dev, "unable to init DMA context\n");
-   return PTR_ERR(dev->alloc_ctx);
-   }
-
if (is_second_gen(dev)) {
/*
 * TW6865/TW6869: each channel needs a pair of
@@ -360,7 +332,6 @@ static int tw686x_sg_setup(struct tw686x_dev *dev)

 const struct tw686x_dma_ops sg_dma_ops = {
.setup  = tw686x_sg_setup,
-   .cleanup= tw686x_sg_cleanup,
.alloc  = tw686x_sg_dma_alloc,
.free   = tw686x_sg_dma_free,
.buf_refill = tw686x_sg_buf_refill,
@@ -449,7 +420,6 @@ static int tw686x_queue_setup(struct vb2_queue *vq,
return 0;
}

-   alloc_ctxs[0] = vc->dev->alloc_ctx;
sizes[0] = szimage;
*nplanes = 1;
return 0;
@@ -1063,9 +1033,6 @@ void tw686x_video_free(struct tw686x_dev *dev)
for (pb = 0; pb < 2; pb++)
dev->dma_ops->free(vc, pb);
}
-
-   if (dev->dma_ops->cleanup)
-   dev->dma_ops->cleanup(dev);
 }

 int tw686x_video_init(struct tw686x_dev *dev)
@@ -1135,6 +1102,7 @@ int tw686x_video_init(struct tw686x_dev *dev)
vc->vidq.min_buffers_needed = 2;
vc->vidq.lock = >vb_mutex;
vc->vidq.gfp_flags = GFP_DMA32;
+   vc->vidq.dev = >pci_dev->dev;

err = vb2_queue_init(>vidq);
if (err) {
diff --git a/drivers/media/pci/tw686x/tw686x.h 
b/drivers/media/pci/tw686x/tw686x.h
index 35d7bc9..f24a2a9 100644
--- a/drivers/media/pci/tw686x/tw686x.h
+++ b/drivers/media/pci/tw686x/tw686x.h
@@ -106,7 +106,6 @@ struct tw686x_video_channel {

 struct tw686x_dma_ops {
int (*setup)(struct tw686x_dev *dev);
-   void (*cleanup)(struct tw686x_dev *dev);
int (*alloc)(struct tw686x_video_channel *vc, unsigned int pb);
void (*free)(struct tw686x_video_channel *vc, unsigned int pb);
void (*buf_refill)(struct tw686x_video_channel *vc, unsigned int pb);
@@ -132,8 +131,6 @@ struct tw686x_dev {
struct pci_dev *pci_dev;
__u32 __iomem *mmio;

-   void *alloc_ctx;
-
const struct tw686x_dma_ops *dma_ops;
struct tw686x_video_channel *video_channels;
struct tw686x_audio_channel *audio_channels;
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] rc: ir-spi: add support for IR LEDs connected with SPI

2016-07-01 Thread Sean Young

On Fri, Jul 01, 2016 at 05:33:42PM +0900, Andi Shyti wrote:
> The ir-spi is a simple device driver which supports the
> connection between an IR LED and the MOSI line of an SPI device.
> 
> The driver, indeed, uses the SPI framework to stream the raw data
> provided by userspace through a character device. The chardev is
> handled by the LIRC framework and its functionality basically
> provides:
> 
>  - raw write: data to be sent to the SPI and then streamed to the
>MOSI line;
>  - set frequency: sets the frequency whith which the data should
>be sent;
>  - set length: sets the data length. This information is
>optional, if the length is set, then userspace should send raw
>data only with that length; while if the length is set to '0',
>then the driver will figure out himself the length of the data
>based on the length of the data written on the character
>device.
>The latter is not recommended, though, as the driver, at
>any write, allocates and deallocates a buffer where the data
>from userspace are stored.
> 
> The driver provides three feedback commands:
> 
>  - get length: reads the length set and (as mentioned), if the
>length is '0' it will be calculated at any write
>  - get frequency: the driver reports the frequency. If userpace
>doesn't set the frequency, the driver will use a default value
>of 38000Hz.

This interface is not compatible with other lirc devices; there is no
way of determining whether this is a regular lirc device or this new
flavour you've invented.

Also I don't see what justifies this new interface. This can be 
implemented in rc-core in less lines of code and it will be entirely 
compatible with existing user-space.


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

Re: [PATCH v2 15/15] [media] include: lirc: add LIRC_GET_LENGTH command

2016-07-01 Thread Sean Young

On Fri, Jul 01, 2016 at 05:01:38PM +0900, Andi Shyti wrote:
> Added the get length command to allow userspace users to check on
> the data length.

So what does LIRC_GET_LENGTH do? If you want to add an ioctl, it
need justification, documenting in 
Documentatoin/DocBook/media/v4l/lirc_device_interface.xml and there
should be at least one driver using it.

If you want to write a new driver which does IR transmit, it's best
to use the rc-core interface like the existing drivers and do 
not use the lirc interface. Most of the other drivers which implement
IR transmit use rc-core too.

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

[PATCH v2 09/15] [media] lirc_dev: merge three if statements in only one

2016-07-01 Thread Andi Shyti

The three if statements check the same thing, merge them in only
one statement.

Signed-off-by: Andi Shyti 
---
 drivers/media/rc/lirc_dev.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 2643336..d98a9f1 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -270,15 +270,10 @@ static int lirc_allocate_driver(struct lirc_driver *d)
dev_err(d->dev, "add_to_buf not set\n");
return -EBADRQC;
}
-   } else if (!(d->fops && d->fops->read) && !d->rbuf) {
-   dev_err(d->dev, "fops->read and rbuf are NULL!\n");
+   } else if (!d->rbuf && !(d->fops && d->fops->read &&
+   d->fops->poll && d->fops->unlocked_ioctl)) {
+   dev_err(d->dev, "undefined read, poll, ioctl\n");
return -EBADRQC;
-   } else if (!d->rbuf) {
-   if (!(d->fops && d->fops->read && d->fops->poll &&
- d->fops->unlocked_ioctl)) {
-   dev_err(d->dev, "undefined read, poll, ioctl\n");
-   return -EBADRQC;
-   }
}
 
mutex_lock(_dev_lock);
-- 
2.8.1

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

Re: [PATCH v6 10/11] Input: synaptics-rmi4 - add support for F54 diagnostics

2016-07-01 Thread Nick Dyer

On Thu, Jun 30, 2016 at 06:38:53PM +0100, Nick Dyer wrote:
> Function 54 implements access to various RMI4 diagnostic features.
> 
> This patch adds support for retrieving this data. It registers a V4L2
> device to output the data to user space.
> 
> Signed-off-by: Nick Dyer 
> ---
>  drivers/input/rmi4/Kconfig  |  11 +
>  drivers/input/rmi4/Makefile |   1 +
>  drivers/input/rmi4/rmi_bus.c|   3 +
>  drivers/input/rmi4/rmi_driver.h |   1 +
>  drivers/input/rmi4/rmi_f54.c| 754 
> 
>  5 files changed, 770 insertions(+)
>  create mode 100644 drivers/input/rmi4/rmi_f54.c
[...]
> index 000..2361157
> --- /dev/null
> +++ b/drivers/input/rmi4/rmi_f54.c
[...]
> +static int rmi_f54_vidioc_querycap(struct file *file, void *priv,
> +struct v4l2_capability *cap)
> +{
> + struct f54_data *f54 = video_drvdata(file);
> +
> + strlcpy(cap->driver, F54_NAME, sizeof(cap->driver));
> + strlcpy(cap->card, SYNAPTICS_INPUT_DEVICE_NAME, sizeof(cap->card));
> + strlcpy(cap->bus_info, dev_name(>fn->dev), sizeof(cap->bus_info));

I need to correct this to prefix the bus. RMI4 registers its own bus, so
devices appear under eg /sys/bus/rmi4/devices/rmi4-00.fn54

So I will change to:
snprintf(cap->bus_info, sizeof(cap->bus_info), "rmi4:%s", 
dev_name(>fn->dev));

And I will need to add rmi4 to the valid prefixes in v4l2-complaince as well.

> +
> + return 0;
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: square-only image on Nokia N900 camera -- pipeline setup in python (was Re: [RFC PATCH 00/24] Make Nokia N900 cameras working)

2016-07-01 Thread Pavel Machek

Hi!

> On gitlab is the latest version of pipeline setup if python. I also
> got fcam to work (slowly) on the camera, with autofocus and
> autogain. Capturing from preview modes works fine, but image quality
> is not good, as expected. Capturing raw GRBG10 images works, but
> images are square, with values being outside square being 0.
> 
> Same problem is there with yavta and fcam-dev capture, so I suspect
> there's something in kernel. If you have an idea what could be wrong /
> what to try, let me know. If omap3isp works for you in v4.6, and
> produces expected rectangular images, that would be useful to know,
> too.
> 
> Python capture script is at
> 
> https://gitlab.com/tui/tui/commit/266b6eb302dcf1481e3e90a05bf98180e5759168

I switched to the front camera (vs6555 pixel array 2-0010 + vs6555
binner 2-0010) and got same effect: preview image works fine, raw
image is square. Still kernel v4.6.

Ideas welcome,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [media] rc: ir-spi: add support for IR LEDs connected with SPI

2016-07-01 Thread Andi Shyti

The ir-spi is a simple device driver which supports the
connection between an IR LED and the MOSI line of an SPI device.

The driver, indeed, uses the SPI framework to stream the raw data
provided by userspace through a character device. The chardev is
handled by the LIRC framework and its functionality basically
provides:

 - raw write: data to be sent to the SPI and then streamed to the
   MOSI line;
 - set frequency: sets the frequency whith which the data should
   be sent;
 - set length: sets the data length. This information is
   optional, if the length is set, then userspace should send raw
   data only with that length; while if the length is set to '0',
   then the driver will figure out himself the length of the data
   based on the length of the data written on the character
   device.
   The latter is not recommended, though, as the driver, at
   any write, allocates and deallocates a buffer where the data
   from userspace are stored.

The driver provides three feedback commands:

 - get length: reads the length set and (as mentioned), if the
   length is '0' it will be calculated at any write
 - get frequency: the driver reports the frequency. If userpace
   doesn't set the frequency, the driver will use a default value
   of 38000Hz.

The character device is created under /dev/lircX name, where X is
and ID assigned by the LIRC framework.

Example of usage:

int fd, ret;
ssize_t n;
uint32_t val = 0;

fd = open("/dev/lirc0", O_RDWR);
if (fd < 0) {
fprintf(stderr, "unable to open the device\n");
return -1;
}

/* ioctl set frequency and length parameters */
val = 6430;
ret = ioctl(fd, LIRC_SET_LENGTH, );
if (ret < 0)
fprintf(stderr, "LIRC_SET_LENGTH failed\n");
val = 608000;
ret = ioctl(fd, LIRC_SET_FREQUENCY, );
if (ret < 0)
fprintf(stderr, "LIRC_SET_FREQUENCY failed\n");

/* read back length and frequency parameters */
ret = ioctl(fd, LIRC_GET_LENGTH, );
if (ret < 0)
fprintf(stderr, "LIRC_GET_LENGTH failed\n");
else
fprintf(stdout, "legnth = %u\n", val);

ret = ioctl(fd, LIRC_GET_FREQUENCY, );
if (ret < 0)
fprintf(stderr, "LIRC_GET_FREQUENCY failed\n");
else
fprintf(stdout, "frequency = %u\n", val);

/* write data to device */
n = write(fd, b, 6430);
if (n < 0) {
fprintf(stderr, "unable to write to the device\n");
ret = -1;
} else if (n != 6430) {
fprintf(stderr, "failed to write everything, wrote %ld 
instead\n", n);
ret = -1;
} else {
fprintf(stdout, "written all the %ld data\n", n);
}

close(fd);

The driver supports multi task access, but all the processes
which hold the driver should use the same length and frequency
parameters.

Change-Id: I323d7dd4a56d6dcf48f2c695293822eb04bdb85f
Signed-off-by: Andi Shyti 
---
 Documentation/devicetree/bindings/media/spi-ir.txt |  24 ++
 drivers/media/rc/Kconfig   |   9 +
 drivers/media/rc/Makefile  |   1 +
 drivers/media/rc/ir-spi.c  | 301 +
 4 files changed, 335 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/spi-ir.txt
 create mode 100644 drivers/media/rc/ir-spi.c

diff --git a/Documentation/devicetree/bindings/media/spi-ir.txt 
b/Documentation/devicetree/bindings/media/spi-ir.txt
new file mode 100644
index 000..2232d92
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi-ir.txt
@@ -0,0 +1,24 @@
+Device tree bindings for IR LED connected through SPI bus which is used as
+remote controller.
+
+The IR LED switch is connected to the MOSI line of the SPI device and the data
+are delivered thourgh that.
+
+Required properties:
+   - compatible: should be "ir-spi"
+
+Optional properties:
+   - irled,switch: specifies the gpio switch which enables the irled
+
+Example:
+
+irled@0 {
+compatible = "ir-spi";
+reg = <0x0>;
+spi-max-frequency = <500>;
+irled,switch = < 3 0>;
+
+controller-data {
+samsung,spi-feedback-delay = <0>;
+};
+};
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index bd4d685..dacaa29 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -261,6 +261,15 @@ config IR_REDRAT3
   To compile this driver as a module, choose M here: the
   module will be called redrat3.
 
+config IR_SPI
+   tristate "SPI connected IR LED"
+   depends on SPI && LIRC
+   ---help---
+ Say Y if you want to use an IR LED connected through SPI bus.
+
+ To compile this driver

[PATCH v2 11/15] [media] lirc_dev: fix variable constant comparisons

2016-07-01 Thread Andi Shyti

When comparing a variable with a constant, the comparison should
start from the variable and not from the constant. It's also
written in the human DNA.

Swap the terms of comparisons whenever the constant comes first
and fix the following checkpatch warning:

  WARNING: Comparisons should place the constant on the right side of the test

Signed-off-by: Andi Shyti 
---
 drivers/media/rc/lirc_dev.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 16cca46..689e369 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -246,13 +246,13 @@ static int lirc_allocate_driver(struct lirc_driver *d)
return -EINVAL;
}
 
-   if (MAX_IRCTL_DEVICES <= d->minor) {
+   if (d->minor >= MAX_IRCTL_DEVICES) {
dev_err(d->dev, "minor must be between 0 and %d!\n",
MAX_IRCTL_DEVICES - 1);
return -EBADRQC;
}
 
-   if (1 > d->code_length || (BUFLEN * 8) < d->code_length) {
+   if (d->code_length < 1 || d->code_length > (BUFLEN * 8)) {
dev_err(d->dev, "code length must be less than %d bits\n",
BUFLEN * 8);
return -EBADRQC;
@@ -283,7 +283,7 @@ static int lirc_allocate_driver(struct lirc_driver *d)
for (minor = 0; minor < MAX_IRCTL_DEVICES; minor++)
if (!irctls[minor])
break;
-   if (MAX_IRCTL_DEVICES == minor) {
+   if (minor == MAX_IRCTL_DEVICES) {
dev_err(d->dev, "no free slots for drivers!\n");
err = -ENOMEM;
goto out_lock;
-- 
2.8.1

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

[PATCH v2 12/15] [media] lirc_dev: fix error return value

2016-07-01 Thread Andi Shyti

If ioctl is called, it cannot be a case of invalid system call
number (ENOSYS), that is an operation not permitted (EPERM).
Replace ENOSYS with EPERM.

Signed-off-by: Andi Shyti 
---
 drivers/media/rc/lirc_dev.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 689e369..99d1f98 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -587,7 +587,7 @@ long lirc_dev_fop_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
break;
case LIRC_GET_REC_MODE:
if (!(ir->d.features & LIRC_CAN_REC_MASK)) {
-   result = -ENOSYS;
+   result = -EPERM;
break;
}
 
@@ -597,7 +597,7 @@ long lirc_dev_fop_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
break;
case LIRC_SET_REC_MODE:
if (!(ir->d.features & LIRC_CAN_REC_MASK)) {
-   result = -ENOSYS;
+   result = -EPERM;
break;
}
 
@@ -615,7 +615,7 @@ long lirc_dev_fop_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
case LIRC_GET_MIN_TIMEOUT:
if (!(ir->d.features & LIRC_CAN_SET_REC_TIMEOUT) ||
ir->d.min_timeout == 0) {
-   result = -ENOSYS;
+   result = -EPERM;
break;
}
 
@@ -624,7 +624,7 @@ long lirc_dev_fop_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
case LIRC_GET_MAX_TIMEOUT:
if (!(ir->d.features & LIRC_CAN_SET_REC_TIMEOUT) ||
ir->d.max_timeout == 0) {
-   result = -ENOSYS;
+   result = -EPERM;
break;
}
 
-- 
2.8.1

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

[PATCH] cec: use same build config mode as MEDIA_SUPPORT

2016-07-01 Thread Hans Verkuil

The cec framework should not be build as a module if MEDIA_SUPPORT is set to
built-in. Otherwise drivers that are built-in would not be able to reference
the exported cec functions.

So do the same as is done for the media controller in drivers/media/Makefile:
make MEDIA_CEC a bool and use the same build mode as CONFIG_MEDIA_SUPPORT.

Signed-off-by: Hans Verkuil 
Reported-by: Arnd Bergmann 
---
diff --git a/drivers/staging/media/cec/Kconfig 
b/drivers/staging/media/cec/Kconfig
index b83b4d8..c623bd3 100644
--- a/drivers/staging/media/cec/Kconfig
+++ b/drivers/staging/media/cec/Kconfig
@@ -1,5 +1,5 @@
 config MEDIA_CEC
-   tristate "CEC API (EXPERIMENTAL)"
+   bool "CEC API (EXPERIMENTAL)"
depends on MEDIA_SUPPORT
depends on RC_CORE || !RC_CORE
select MEDIA_CEC_EDID
diff --git a/drivers/staging/media/cec/Makefile 
b/drivers/staging/media/cec/Makefile
index 426ef73..bd7f3c5 100644
--- a/drivers/staging/media/cec/Makefile
+++ b/drivers/staging/media/cec/Makefile
@@ -1,3 +1,5 @@
 cec-objs := cec-core.o cec-adap.o cec-api.o

-obj-$(CONFIG_MEDIA_CEC) += cec.o
+ifeq ($(CONFIG_MEDIA_CEC),y)
+  obj-$(CONFIG_MEDIA_SUPPORT) += cec.o
+endif
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 14/15] [media] lirc_dev: fix potential segfault

2016-07-01 Thread Andi Shyti

When opening or closing a lirc character device, the framework
provides to the user the possibility to keep track of opening or
closing of the device by calling two functions:

 - set_use_inc() when opening the device
 - set_use_dec() when closing the device

if those are not set by the lirc user, the system segfaults.
Check the pointer value before calling the above functions.

Signed-off-by: Andi Shyti 
---
 drivers/media/rc/lirc_dev.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 4b3efcf..634779a 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -413,7 +413,10 @@ int lirc_unregister_driver(int minor)
ir->d.name, ir->d.minor);
wake_up_interruptible(>buf->wait_poll);
mutex_lock(>irctl_lock);
-   ir->d.set_use_dec(ir->d.data);
+
+   if (ir->d.set_use_dec)
+   ir->d.set_use_dec(ir->d.data);
+
module_put(cdev->owner);
mutex_unlock(>irctl_lock);
} else {
@@ -471,7 +474,8 @@ int lirc_dev_fop_open(struct inode *inode, struct file 
*file)
cdev = ir->cdev;
if (try_module_get(cdev->owner)) {
ir->open++;
-   retval = ir->d.set_use_inc(ir->d.data);
+   if (ir->d.set_use_inc)
+   retval = ir->d.set_use_inc(ir->d.data);
 
if (retval) {
module_put(cdev->owner);
@@ -512,7 +516,8 @@ int lirc_dev_fop_close(struct inode *inode, struct file 
*file)
 
ir->open--;
if (ir->attached) {
-   ir->d.set_use_dec(ir->d.data);
+   if (ir->d.set_use_dec)
+   ir->d.set_use_dec(ir->d.data);
module_put(cdev->owner);
} else {
lirc_irctl_cleanup(ir);
-- 
2.8.1

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

[PATCH v2 00/15] lirc_dev fixes and beautification

2016-07-01 Thread Andi Shyti

Hi,

After applying Joe's suggestion, the next patches had some
conflicts, therefore I have to send all the 15 patches again.

This is a collection of fixes, added functionality, coding rework
and trivial coding style fixes.

The first patch is preparatory to the second, which allows the
user to create a lirc driver without receiver buffer, which is
obvious for transmitters. Besides, even though that buffer could
have been used also by transmitters, drivers might have the need
to handle it separately.

The rest of the patches is a series of coding style and code
rework, as I said, some of them are very trivial, but I sent them
anyway because I was on fire.

Patch 14 is a segfault fix, while the last patch adds the
possibility to send to ioctl the set frequency, get frequency and
set length command.

Changelog: V1->V2

 - As Joe recommended, in patch 4 I added the pr_fmt definition
   and removed all the hardcoded prefixes from the pr_*
   functions.

 - In Patch 15, after Sean's review, I removed the definitions of
   the GET/SET_FREQUENCY, I will use GET/SET_SEND_CARRIER
   instead, even though I find the name a bit confusing.

 - In patch 6 I did a better refactoring

Thanks,
Andi

Andi Shyti (15):
  [media] lirc_dev: place buffer allocation on separate function
  [media] lirc_dev: allow bufferless driver registration
  [media] lirc_dev: remove unnecessary debug prints
  [media] lirc_dev: replace printk with pr_* or dev_*
  [media] lirc_dev: simplify goto paths
  [media] lirc_dev: do not use goto to create loops
  [media] lirc_dev: simplify if statement in lirc_add_to_buf
  [media] lirc_dev: remove double if ... else statement
  [media] lirc_dev: merge three if statements in only one
  [media] lirc_dev: remove CONFIG_COMPAT precompiler check
  [media] lirc_dev: fix variable constant comparisons
  [media] lirc_dev: fix error return value
  [media] lirc_dev: extremely trivial comment style fix
  [media] lirc_dev: fix potential segfault
  [media] include: lirc: add LIRC_GET_LENGTH command

 drivers/media/rc/lirc_dev.c | 301 +---
 include/media/lirc_dev.h|  12 ++
 include/uapi/linux/lirc.h   |   1 +
 3 files changed, 155 insertions(+), 159 deletions(-)

-- 
2.8.1

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

[PATCH v2 01/15] [media] lirc_dev: place buffer allocation on separate function

2016-07-01 Thread Andi Shyti

During the driver registration, move the buffer allocation on a
separate function.

Signed-off-by: Andi Shyti 
---
 drivers/media/rc/lirc_dev.c | 57 +++--
 1 file changed, 34 insertions(+), 23 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 92ae190..5716978 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -203,13 +203,41 @@ err_out:
return retval;
 }
 
-int lirc_register_driver(struct lirc_driver *d)
+static int lirc_allocate_buffer(struct irctl *ir)
 {
-   struct irctl *ir;
-   int minor;
+   int err;
int bytes_in_key;
unsigned int chunk_size;
unsigned int buffer_size;
+   struct lirc_driver *d = >d;
+
+   bytes_in_key = BITS_TO_LONGS(d->code_length) +
+   (d->code_length % 8 ? 1 : 0);
+   buffer_size = d->buffer_size ? d->buffer_size : BUFLEN / bytes_in_key;
+   chunk_size  = d->chunk_size  ? d->chunk_size  : bytes_in_key;
+
+   if (d->rbuf) {
+   ir->buf = d->rbuf;
+   } else {
+   ir->buf = kmalloc(sizeof(struct lirc_buffer), GFP_KERNEL);
+   if (!ir->buf)
+   return -ENOMEM;
+
+   err = lirc_buffer_init(ir->buf, chunk_size, buffer_size);
+   if (err) {
+   kfree(ir->buf);
+   return err;
+   }
+   }
+   ir->chunk_size = ir->buf->chunk_size;
+
+   return 0;
+}
+
+int lirc_register_driver(struct lirc_driver *d)
+{
+   struct irctl *ir;
+   int minor;
int err;
 
if (!d) {
@@ -314,26 +342,9 @@ int lirc_register_driver(struct lirc_driver *d)
/* some safety check 8-) */
d->name[sizeof(d->name)-1] = '\0';
 
-   bytes_in_key = BITS_TO_LONGS(d->code_length) +
-   (d->code_length % 8 ? 1 : 0);
-   buffer_size = d->buffer_size ? d->buffer_size : BUFLEN / bytes_in_key;
-   chunk_size  = d->chunk_size  ? d->chunk_size  : bytes_in_key;
-
-   if (d->rbuf) {
-   ir->buf = d->rbuf;
-   } else {
-   ir->buf = kmalloc(sizeof(struct lirc_buffer), GFP_KERNEL);
-   if (!ir->buf) {
-   err = -ENOMEM;
-   goto out_lock;
-   }
-   err = lirc_buffer_init(ir->buf, chunk_size, buffer_size);
-   if (err) {
-   kfree(ir->buf);
-   goto out_lock;
-   }
-   }
-   ir->chunk_size = ir->buf->chunk_size;
+   err = lirc_allocate_buffer(ir);
+   if (err)
+   goto out_lock;
 
if (d->features == 0)
d->features = LIRC_CAN_REC_LIRCCODE;
-- 
2.8.1

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

[PATCH v2 08/15] [media] lirc_dev: remove double if ... else statement

2016-07-01 Thread Andi Shyti

There are two if ... else which check the same thing in different
part of the code, they can be merged in a single check.

Signed-off-by: Andi Shyti 
---
 drivers/media/rc/lirc_dev.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 2468849..2643336 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -310,13 +310,6 @@ static int lirc_allocate_driver(struct lirc_driver *d)
irctls[minor] = ir;
d->minor = minor;
 
-   if (d->sample_rate) {
-   ir->jiffies_to_wait = HZ / d->sample_rate;
-   } else {
-   /* it means - wait for external event in task queue */
-   ir->jiffies_to_wait = 0;
-   }
-
/* some safety check 8-) */
d->name[sizeof(d->name)-1] = '\0';
 
@@ -330,6 +323,8 @@ static int lirc_allocate_driver(struct lirc_driver *d)
  "lirc%u", ir->d.minor);
 
if (d->sample_rate) {
+   ir->jiffies_to_wait = HZ / d->sample_rate;
+
/* try to fire up polling thread */
ir->task = kthread_run(lirc_thread, (void *)ir, "lirc_dev");
if (IS_ERR(ir->task)) {
@@ -338,6 +333,9 @@ static int lirc_allocate_driver(struct lirc_driver *d)
err = -ECHILD;
goto out_sysfs;
}
+   } else {
+   /* it means - wait for external event in task queue */
+   ir->jiffies_to_wait = 0;
}
 
err = lirc_cdev_add(ir);
-- 
2.8.1

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

[PATCH v2 03/15] [media] lirc_dev: remove unnecessary debug prints

2016-07-01 Thread Andi Shyti

Signed-off-by: Andi Shyti 
---
 drivers/media/rc/lirc_dev.c | 25 -
 1 file changed, 25 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index fa562a3..ee997ab 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -80,8 +80,6 @@ static void lirc_irctl_init(struct irctl *ir)
 
 static void lirc_irctl_cleanup(struct irctl *ir)
 {
-   dev_dbg(ir->d.dev, LOGHEAD "cleaning up\n", ir->d.name, ir->d.minor);
-
device_destroy(lirc_class, MKDEV(MAJOR(lirc_base_dev), ir->d.minor));
 
if (ir->buf != ir->d.rbuf) {
@@ -127,9 +125,6 @@ static int lirc_thread(void *irctl)
 {
struct irctl *ir = irctl;
 
-   dev_dbg(ir->d.dev, LOGHEAD "poll thread started\n",
-   ir->d.name, ir->d.minor);
-
do {
if (ir->open) {
if (ir->jiffies_to_wait) {
@@ -146,9 +141,6 @@ static int lirc_thread(void *irctl)
}
} while (!kthread_should_stop());
 
-   dev_dbg(ir->d.dev, LOGHEAD "poll thread ended\n",
-   ir->d.name, ir->d.minor);
-
return 0;
 }
 
@@ -277,8 +269,6 @@ static int lirc_allocate_driver(struct lirc_driver *d)
goto out;
}
 
-   dev_dbg(d->dev, "lirc_dev: lirc_register_driver: sample_rate: %d\n",
-   d->sample_rate);
if (d->sample_rate) {
if (2 > d->sample_rate || HZ < d->sample_rate) {
dev_err(d->dev, "lirc_dev: lirc_register_driver: "
@@ -525,10 +515,6 @@ int lirc_dev_fop_open(struct inode *inode, struct file 
*file)
}
 
 error:
-   if (ir)
-   dev_dbg(ir->d.dev, LOGHEAD "open result = %d\n",
-   ir->d.name, ir->d.minor, retval);
-
mutex_unlock(_dev_lock);
 
nonseekable_open(inode, file);
@@ -550,8 +536,6 @@ int lirc_dev_fop_close(struct inode *inode, struct file 
*file)
 
cdev = ir->cdev;
 
-   dev_dbg(ir->d.dev, LOGHEAD "close called\n", ir->d.name, ir->d.minor);
-
ret = mutex_lock_killable(_dev_lock);
WARN_ON(ret);
 
@@ -586,8 +570,6 @@ unsigned int lirc_dev_fop_poll(struct file *file, 
poll_table *wait)
return POLLERR;
}
 
-   dev_dbg(ir->d.dev, LOGHEAD "poll called\n", ir->d.name, ir->d.minor);
-
if (!ir->attached)
return POLLERR;
 
@@ -683,9 +665,6 @@ long lirc_dev_fop_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
result = -EINVAL;
}
 
-   dev_dbg(ir->d.dev, LOGHEAD "ioctl result = %d\n",
-   ir->d.name, ir->d.minor, result);
-
mutex_unlock(>irctl_lock);
 
return result;
@@ -790,8 +769,6 @@ out_locked:
 
 out_unlocked:
kfree(buf);
-   dev_dbg(ir->d.dev, LOGHEAD "read result = %s (%d)\n",
-   ir->d.name, ir->d.minor, ret ? "" : "", ret);
 
return ret ? ret : written;
 }
@@ -814,8 +791,6 @@ ssize_t lirc_dev_fop_write(struct file *file, const char 
__user *buffer,
return -ENODEV;
}
 
-   dev_dbg(ir->d.dev, LOGHEAD "write called\n", ir->d.name, ir->d.minor);
-
if (!ir->attached)
return -ENODEV;
 
-- 
2.8.1

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

[PATCH v2 05/15] [media] lirc_dev: simplify goto paths

2016-07-01 Thread Andi Shyti

The code can be rearranged so that some goto paths can be removed

Signed-off-by: Andi Shyti 
---
 drivers/media/rc/lirc_dev.c | 34 --
 1 file changed, 12 insertions(+), 22 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 212ea77..0d988c9 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -243,52 +243,44 @@ static int lirc_allocate_driver(struct lirc_driver *d)
 
if (!d) {
pr_err("driver pointer must be not NULL!\n");
-   err = -EBADRQC;
-   goto out;
+   return -EBADRQC;
}
 
if (!d->dev) {
pr_err("dev pointer not filled in!\n");
-   err = -EINVAL;
-   goto out;
+   return -EINVAL;
}
 
if (MAX_IRCTL_DEVICES <= d->minor) {
dev_err(d->dev, "minor must be between 0 and %d!\n",
MAX_IRCTL_DEVICES - 1);
-   err = -EBADRQC;
-   goto out;
+   return -EBADRQC;
}
 
if (1 > d->code_length || (BUFLEN * 8) < d->code_length) {
dev_err(d->dev, "code length must be less than %d bits\n",
BUFLEN * 8);
-   err = -EBADRQC;
-   goto out;
+   return -EBADRQC;
}
 
if (d->sample_rate) {
if (2 > d->sample_rate || HZ < d->sample_rate) {
dev_err(d->dev, "invalid %d sample rate\n",
d->sample_rate);
-   err = -EBADRQC;
-   goto out;
+   return -EBADRQC;
}
if (!d->add_to_buf) {
dev_err(d->dev, "add_to_buf not set\n");
-   err = -EBADRQC;
-   goto out;
+   return -EBADRQC;
}
} else if (!(d->fops && d->fops->read) && !d->rbuf) {
dev_err(d->dev, "fops->read and rbuf are NULL!\n");
-   err = -EBADRQC;
-   goto out;
+   return -EBADRQC;
} else if (!d->rbuf) {
if (!(d->fops && d->fops->read && d->fops->poll &&
  d->fops->unlocked_ioctl)) {
dev_err(d->dev, "undefined read, poll, ioctl\n");
-   err = -EBADRQC;
-   goto out;
+   return -EBADRQC;
}
}
 
@@ -366,7 +358,7 @@ out_sysfs:
device_destroy(lirc_class, MKDEV(MAJOR(lirc_base_dev), ir->d.minor));
 out_lock:
mutex_unlock(_dev_lock);
-out:
+
return err;
 }
 
@@ -794,9 +786,8 @@ static int __init lirc_dev_init(void)
 
lirc_class = class_create(THIS_MODULE, "lirc");
if (IS_ERR(lirc_class)) {
-   retval = PTR_ERR(lirc_class);
pr_err("class_create failed\n");
-   goto error;
+   return PTR_ERR(lirc_class);
}
 
retval = alloc_chrdev_region(_base_dev, 0, MAX_IRCTL_DEVICES,
@@ -804,15 +795,14 @@ static int __init lirc_dev_init(void)
if (retval) {
class_destroy(lirc_class);
pr_err("alloc_chrdev_region failed\n");
-   goto error;
+   return retval;
}
 
 
pr_info("IR Remote Control driver registered, major %d\n",
MAJOR(lirc_base_dev));
 
-error:
-   return retval;
+   return 0;
 }
 
 
-- 
2.8.1

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

[PATCH v2 06/15] [media] lirc_dev: do not use goto to create loops

2016-07-01 Thread Andi Shyti

... use "do .. while" instead.

Signed-off-by: Andi Shyti 
---
 drivers/media/rc/lirc_dev.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 0d988c9..da1777c 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -99,18 +99,16 @@ static int lirc_add_to_buf(struct irctl *ir)
 {
if (ir->d.add_to_buf) {
int res = -ENODATA;
-   int got_data = 0;
+   int got_data = -1;
 
/*
 * service the device as long as it is returning
 * data and we have space
 */
-get_data:
-   res = ir->d.add_to_buf(ir->d.data, ir->buf);
-   if (res == 0) {
+   do {
got_data++;
-   goto get_data;
-   }
+   res = ir->d.add_to_buf(ir->d.data, ir->buf);
+   } while (!res);
 
if (res == -ENODEV)
kthread_stop(ir->task);
-- 
2.8.1

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

[PATCH v2 13/15] [media] lirc_dev: extremely trivial comment style fix

2016-07-01 Thread Andi Shyti

Signed-off-by: Andi Shyti 
---
 drivers/media/rc/lirc_dev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 99d1f98..4b3efcf 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -692,7 +692,8 @@ ssize_t lirc_dev_fop_read(struct file *file,
/* According to the read(2) man page, 'written' can be
 * returned as less than 'length', instead of blocking
 * again, returning -EWOULDBLOCK, or returning
-* -ERESTARTSYS */
+* -ERESTARTSYS
+*/
if (written)
break;
if (file->f_flags & O_NONBLOCK) {
-- 
2.8.1

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

[PATCH v2 15/15] [media] include: lirc: add LIRC_GET_LENGTH command

2016-07-01 Thread Andi Shyti

Added the get length command to allow userspace users to check on
the data length.

Signed-off-by: Andi Shyti 
---
 include/uapi/linux/lirc.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/lirc.h b/include/uapi/linux/lirc.h
index 4b3ab29..801e5f8 100644
--- a/include/uapi/linux/lirc.h
+++ b/include/uapi/linux/lirc.h
@@ -106,6 +106,7 @@
 
 /* code length in bits, currently only for LIRC_MODE_LIRCCODE */
 #define LIRC_GET_LENGTH_IOR('i', 0x000f, __u32)
+#define LIRC_SET_LENGTH_IOW('i', 0x0010, __u32)
 
 #define LIRC_SET_SEND_MODE _IOW('i', 0x0011, __u32)
 #define LIRC_SET_REC_MODE  _IOW('i', 0x0012, __u32)
-- 
2.8.1

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

[PATCH v2 10/15] [media] lirc_dev: remove CONFIG_COMPAT precompiler check

2016-07-01 Thread Andi Shyti

There is no need to check in precompilation whether the ioctl is
compat or unlocked, depending on the configuration it will be
called the correct one.

Signed-off-by: Andi Shyti 
---
 drivers/media/rc/lirc_dev.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index d98a9f1..16cca46 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -150,9 +150,7 @@ static const struct file_operations lirc_dev_fops = {
.write  = lirc_dev_fop_write,
.poll   = lirc_dev_fop_poll,
.unlocked_ioctl = lirc_dev_fop_ioctl,
-#ifdef CONFIG_COMPAT
.compat_ioctl   = lirc_dev_fop_ioctl,
-#endif
.open   = lirc_dev_fop_open,
.release= lirc_dev_fop_close,
.llseek = noop_llseek,
-- 
2.8.1

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

[PATCH v2 02/15] [media] lirc_dev: allow bufferless driver registration

2016-07-01 Thread Andi Shyti

Some drivers don't necessarily need to have a FIFO managed buffer
for their transfers. Drivers now should call
lirc_register_bufferless_driver in order to handle the buffer
themselves.

The function works exaclty like lirc_register_driver except of
the buffer allocation.

Signed-off-by: Andi Shyti 
---
 drivers/media/rc/lirc_dev.c | 44 ++--
 include/media/lirc_dev.h| 12 
 2 files changed, 46 insertions(+), 10 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 5716978..fa562a3 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -205,12 +205,14 @@ err_out:
 
 static int lirc_allocate_buffer(struct irctl *ir)
 {
-   int err;
+   int err = 0;
int bytes_in_key;
unsigned int chunk_size;
unsigned int buffer_size;
struct lirc_driver *d = >d;
 
+   mutex_lock(_dev_lock);
+
bytes_in_key = BITS_TO_LONGS(d->code_length) +
(d->code_length % 8 ? 1 : 0);
buffer_size = d->buffer_size ? d->buffer_size : BUFLEN / bytes_in_key;
@@ -220,21 +222,26 @@ static int lirc_allocate_buffer(struct irctl *ir)
ir->buf = d->rbuf;
} else {
ir->buf = kmalloc(sizeof(struct lirc_buffer), GFP_KERNEL);
-   if (!ir->buf)
-   return -ENOMEM;
+   if (!ir->buf) {
+   err = -ENOMEM;
+   goto out;
+   }
 
err = lirc_buffer_init(ir->buf, chunk_size, buffer_size);
if (err) {
kfree(ir->buf);
-   return err;
+   goto out;
}
}
ir->chunk_size = ir->buf->chunk_size;
 
-   return 0;
+out:
+   mutex_unlock(_dev_lock);
+
+   return err;
 }
 
-int lirc_register_driver(struct lirc_driver *d)
+static int lirc_allocate_driver(struct lirc_driver *d)
 {
struct irctl *ir;
int minor;
@@ -342,10 +349,6 @@ int lirc_register_driver(struct lirc_driver *d)
/* some safety check 8-) */
d->name[sizeof(d->name)-1] = '\0';
 
-   err = lirc_allocate_buffer(ir);
-   if (err)
-   goto out_lock;
-
if (d->features == 0)
d->features = LIRC_CAN_REC_LIRCCODE;
 
@@ -385,8 +388,29 @@ out_lock:
 out:
return err;
 }
+
+int lirc_register_driver(struct lirc_driver *d)
+{
+   int err, minor;
+
+   minor = lirc_allocate_driver(d);
+   if (minor < 0)
+   return minor;
+
+   err = lirc_allocate_buffer(irctls[minor]);
+   if (err)
+   lirc_unregister_driver(minor);
+
+   return err ? err : minor;
+}
 EXPORT_SYMBOL(lirc_register_driver);
 
+int lirc_register_bufferless_driver(struct lirc_driver *d)
+{
+   return lirc_allocate_driver(d);
+}
+EXPORT_SYMBOL(lirc_register_bufferless_driver);
+
 int lirc_unregister_driver(int minor)
 {
struct irctl *ir;
diff --git a/include/media/lirc_dev.h b/include/media/lirc_dev.h
index 0ab59a5..8bed57a 100644
--- a/include/media/lirc_dev.h
+++ b/include/media/lirc_dev.h
@@ -214,6 +214,18 @@ struct lirc_driver {
  */
 extern int lirc_register_driver(struct lirc_driver *d);
 
+/* int lirc_register_bufferless_driver - allocates a lirc bufferless driver
+ * @d: reference to the lirc_driver to initialize
+ *
+ * The difference between lirc_register_driver and
+ * lirc_register_bufferless_driver is that the latter doesn't allocate any
+ * buffer, which means that the driver using the lirc_driver should take care 
of
+ * it by itself.
+ *
+ * returns 0 on success or a the negative errno number in case of failure.
+ */
+extern int lirc_register_bufferless_driver(struct lirc_driver *d);
+
 /* returns negative value on error or 0 if success
 */
 extern int lirc_unregister_driver(int minor);
-- 
2.8.1

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

[PATCH v2 04/15] [media] lirc_dev: replace printk with pr_* or dev_*

2016-07-01 Thread Andi Shyti

This patch mutes also all the checkpatch warnings related to
printk.

Reword all the printouts so that the string doesn't need to be
split, which fixes the following checkpatch warning:

  WARNING: quoted string split across lines

Signed-off-by: Andi Shyti 
---
 drivers/media/rc/lirc_dev.c | 79 +++--
 1 file changed, 34 insertions(+), 45 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index ee997ab..212ea77 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -19,6 +19,8 @@
  *
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -240,59 +242,51 @@ static int lirc_allocate_driver(struct lirc_driver *d)
int err;
 
if (!d) {
-   printk(KERN_ERR "lirc_dev: lirc_register_driver: "
-  "driver pointer must be not NULL!\n");
+   pr_err("driver pointer must be not NULL!\n");
err = -EBADRQC;
goto out;
}
 
if (!d->dev) {
-   printk(KERN_ERR "%s: dev pointer not filled in!\n", __func__);
+   pr_err("dev pointer not filled in!\n");
err = -EINVAL;
goto out;
}
 
if (MAX_IRCTL_DEVICES <= d->minor) {
-   dev_err(d->dev, "lirc_dev: lirc_register_driver: "
-   "\"minor\" must be between 0 and %d (%d)!\n",
-   MAX_IRCTL_DEVICES - 1, d->minor);
+   dev_err(d->dev, "minor must be between 0 and %d!\n",
+   MAX_IRCTL_DEVICES - 1);
err = -EBADRQC;
goto out;
}
 
if (1 > d->code_length || (BUFLEN * 8) < d->code_length) {
-   dev_err(d->dev, "lirc_dev: lirc_register_driver: "
-   "code length in bits for minor (%d) "
-   "must be less than %d!\n",
-   d->minor, BUFLEN * 8);
+   dev_err(d->dev, "code length must be less than %d bits\n",
+   BUFLEN * 8);
err = -EBADRQC;
goto out;
}
 
if (d->sample_rate) {
if (2 > d->sample_rate || HZ < d->sample_rate) {
-   dev_err(d->dev, "lirc_dev: lirc_register_driver: "
-   "sample_rate must be between 2 and %d!\n", HZ);
+   dev_err(d->dev, "invalid %d sample rate\n",
+   d->sample_rate);
err = -EBADRQC;
goto out;
}
if (!d->add_to_buf) {
-   dev_err(d->dev, "lirc_dev: lirc_register_driver: "
-   "add_to_buf cannot be NULL when "
-   "sample_rate is set\n");
+   dev_err(d->dev, "add_to_buf not set\n");
err = -EBADRQC;
goto out;
}
} else if (!(d->fops && d->fops->read) && !d->rbuf) {
-   dev_err(d->dev, "lirc_dev: lirc_register_driver: "
-   "fops->read and rbuf cannot all be NULL!\n");
+   dev_err(d->dev, "fops->read and rbuf are NULL!\n");
err = -EBADRQC;
goto out;
} else if (!d->rbuf) {
if (!(d->fops && d->fops->read && d->fops->poll &&
  d->fops->unlocked_ioctl)) {
-   dev_err(d->dev, "lirc_dev: lirc_register_driver: "
-   "neither read, poll nor unlocked_ioctl can be 
NULL!\n");
+   dev_err(d->dev, "undefined read, poll, ioctl\n");
err = -EBADRQC;
goto out;
}
@@ -308,14 +302,12 @@ static int lirc_allocate_driver(struct lirc_driver *d)
if (!irctls[minor])
break;
if (MAX_IRCTL_DEVICES == minor) {
-   dev_err(d->dev, "lirc_dev: lirc_register_driver: "
-   "no free slots for drivers!\n");
+   dev_err(d->dev, "no free slots for drivers!\n");
err = -ENOMEM;
goto out_lock;
}
} else if (irctls[minor]) {
-   dev_err(d->dev, "lirc_dev: lirc_register_driver: "
-   "minor (%d) just registered!\n", minor);
+   dev_err(d->dev, "minor (%d) just registered!\n", minor);
err = -EBUSY;
goto out_lock;
}
@@ -352,9 +344,8 @@ static int lirc_allocate_driver(struct lirc_driver *d)
/* try to fire up polling thread */
ir->task = kthread_run(lirc_thread, (void *)ir, "lirc_dev");

[PATCH v2 07/15] [media] lirc_dev: simplify if statement in lirc_add_to_buf

2016-07-01 Thread Andi Shyti

The whole function is inside an 'if' statement
("if (ir->d.add_to_buf)").

Check the opposite of that statement at the beginning and exit,
this way we can have one level less of indentation.

Signed-off-by: Andi Shyti 
---
 drivers/media/rc/lirc_dev.c | 31 +++
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index da1777c..2468849 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -97,26 +97,25 @@ static void lirc_irctl_cleanup(struct irctl *ir)
  */
 static int lirc_add_to_buf(struct irctl *ir)
 {
-   if (ir->d.add_to_buf) {
-   int res = -ENODATA;
-   int got_data = -1;
+   int res;
+   int got_data = -1;
 
-   /*
-* service the device as long as it is returning
-* data and we have space
-*/
-   do {
-   got_data++;
-   res = ir->d.add_to_buf(ir->d.data, ir->buf);
-   } while (!res);
+   if (!ir->d.add_to_buf)
+   return 0;
 
-   if (res == -ENODEV)
-   kthread_stop(ir->task);
+   /*
+* service the device as long as it is returning
+* data and we have space
+*/
+   do {
+   got_data++;
+   res = ir->d.add_to_buf(ir->d.data, ir->buf);
+   } while (!res);
 
-   return got_data ? 0 : res;
-   }
+   if (res == -ENODEV)
+   kthread_stop(ir->task);
 
-   return 0;
+   return got_data ? 0 : res;
 }
 
 /* main function of the polling thread
-- 
2.8.1

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

Re: [RFC] [PATCH 0/3] media: an attempt to refresh omap1_camera driver

2016-07-01 Thread Hans Verkuil

On 06/17/2016 09:04 AM, Hans Verkuil wrote:
> Hi Janusz,
> 
> On 06/16/2016 07:21 PM, Janusz Krzysztofik wrote:
>> As requested by media subsystem maintainers, here is an attempt to 
>> convert the omap1_camera driver to the vb2 framework. Also, conversion 
>> to the dmaengine framework, long awaited by ARM/OMAP maintainers, is 
>> done.
>>
>> Next, I'm going to approach removal of soc-camera dependency. Please 
>> let me know how much time I have for that, i.e., when the soc-camera
>> framework is going to be depreciated.
> 
> Well, it is already deprecated (i.e. new drivers cannot use it), but it won't
> be removed any time soon. There are still drivers depending on it, and some
> aren't easy to rewrite.
> 
> I have to say that it is totally unexpected to see that this omap1 driver is 
> still
> used. In fact, we've already merged a patch that removed it for the upcoming
> 4.8 kernel. Based on this new development I'll revert that for the omap1
> driver.

Actually, I decided not to revert it. So it will be removed in 4.8. However, 
that
does not affect you. Just bring it back once it is in shape.

Regards,

Hans

> 
> Out of curiosity: is supporting the Amstrad Delta something you do as a hobby
> or are there other reasons?
> 
> A final note: once you've managed to drop the soc-camera dependency you should
> run the v4l2-compliance test over the video node 
> (https://git.linuxtv.org/v4l-utils.git/).
> 
> If that passes without failures, then this driver is in good shape and can be
> moved out of staging again.
> 
> Regards,
> 
>   Hans
> 
>>
>> Thanks,
>> Janusz
>>
>>
>> Janusz Krzysztofik (3):
>>   staging: media: omap1: drop videobuf-dma-sg mode
>>   staging: media: omap1: convert to videobuf2
>>   staging: media: omap1: use dmaengine
>>
>>  drivers/staging/media/omap1/Kconfig  |   5 +-
>>  drivers/staging/media/omap1/omap1_camera.c   | 948 
>> +--
>>  include/linux/platform_data/media/omap1_camera.h |   9 -
>>  3 files changed, 217 insertions(+), 745 deletions(-)
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

square-only image on Nokia N900 camera -- pipeline setup in python (was Re: [RFC PATCH 00/24] Make Nokia N900 cameras working)

2016-07-01 Thread Pavel Machek

Hi!

On gitlab is the latest version of pipeline setup if python. I also
got fcam to work (slowly) on the camera, with autofocus and
autogain. Capturing from preview modes works fine, but image quality
is not good, as expected. Capturing raw GRBG10 images works, but
images are square, with values being outside square being 0.

Same problem is there with yavta and fcam-dev capture, so I suspect
there's something in kernel. If you have an idea what could be wrong /
what to try, let me know. If omap3isp works for you in v4.6, and
produces expected rectangular images, that would be useful to know,
too.

Python capture script is at

https://gitlab.com/tui/tui/commit/266b6eb302dcf1481e3e90a05bf98180e5759168

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 28/38] v4l: Add signal lock status to source change events

2016-07-01 Thread Hans Verkuil

On 06/15/2016 12:49 AM, Steve Longerbeam wrote:
> Add a signal lock status change to the source changes bitmask.
> This indicates there was a signal lock or unlock event detected
> at the input of a video decoder.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 12 ++--
>  include/uapi/linux/videodev2.h |  1 +
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml 
> b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
> index c9c3c77..7758ad7 100644
> --- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
> +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
> @@ -233,8 +233,9 @@
>   
> This event is triggered when a source parameter change is
>  detected during runtime by the video device. It can be a
> -runtime resolution change triggered by a video decoder or the
> -format change happening on an input connector.
> +runtime resolution change or signal lock status change
> +triggered by a video decoder, or the format change happening
> +on an input connector.
>  This event requires that the id
>  matches the input index (when used with a video device node)
>  or the pad index (when used with a subdevice node) from which
> @@ -461,6 +462,13 @@
>   from a video decoder.
>   
> 
> +   
> + V4L2_EVENT_SRC_CH_LOCK_STATUS
> + 0x0002
> + This event gets triggered when there is a signal lock or
> + unlock detected at the input of a video decoder.
> + 
> +   

I'm not entirely sure I like this. Typically losing lock means that this event
is triggered with the V4L2_EVENT_SRC_CH_RESOLUTION flag set, and userspace has
to check the new timings etc., which will fail if there is no lock anymore.

This information is also available through ENUMINPUT.

I would need to know more about why you think this is needed, because I don't
see what this adds.

Regards,

Hans

>   
>
>  
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 8f95191..2eba5da 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -2076,6 +2076,7 @@ struct v4l2_event_frame_sync {
>  };
>  
>  #define V4L2_EVENT_SRC_CH_RESOLUTION (1 << 0)
> +#define V4L2_EVENT_SRC_CH_LOCK_STATUS(1 << 1)
>  
>  struct v4l2_event_src_change {
>   __u32 changes;
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/38] i.MX5/6 Video Capture

2016-07-01 Thread Hans Verkuil

On 06/28/2016 10:10 PM, Hans Verkuil wrote:
> On 06/28/2016 08:54 PM, Tim Harvey wrote:
>> On Tue, Jun 14, 2016 at 3:48 PM, Steve Longerbeam  
>> wrote:
>>> Tested on imx6q SabreAuto with ADV7180, and imx6q SabreSD with
>>> mipi-csi2 OV5640. There is device-tree support also for imx6qdl
>>> SabreLite, but that is not tested. Also, this driver should
>>> theoretically work on i.MX5 targets, but that is also untested.
>>>
>>> Not run through v4l2-compliance yet, but that is in my queue.
>>>
>>>
>>
>> Steve,
>>
>> I've tested this series successfully with a Gateworks Ventana GW5300
>> which has an IMX6Q and an adv7180 attached to IPU2_CSI1.
>>
>> First of all, a big 'thank you' for taking the time to rebase and
>> re-submit this series!
>>
>> However based on the lack of feedback of the individual patches as
> 
> It's on my TODO list, but the series was a lot larger than I expected (and
> touched on a lot of subsystems as well), so I postponed looking at this
> until I have a bit more time.

I scanned through it and the only thing I won't accept in staging is the
adv7180 driver. I also have a question about patch 28, but I'll ask that
separately. The ov5642 is also a duplicate, but the mainline version is tied
to soc_camera, so I have no problem with adding a non-soc-camera driver.

>> well as the fact they touch varied subsystems I think we are going to
>> have better luck getting this functionality accepted if you broke it
>> into separate series.
>>
>> Here are my thoughts:
>>
>>>   gpu: ipu-v3: Add Video Deinterlacer unit
>>>   gpu: ipu-cpmem: Add ipu_cpmem_set_uv_offset()
>>>   gpu: ipu-cpmem: Add ipu_cpmem_get_burstsize()
>>>   gpu: ipu-v3: Add ipu_get_num()
>>>   gpu: ipu-v3: Add IDMA channel linking support
>>>   gpu: ipu-v3: Add ipu_set_vdi_src_mux()
>>>   gpu: ipu-v3: Add VDI input IDMAC channels
>>>   gpu: ipu-v3: Add ipu_csi_set_src()
>>>   gpu: ipu-v3: Add ipu_ic_set_src()
>>>   gpu: ipu-v3: set correct full sensor frame for PAL/NTSC
>>>   gpu: ipu-v3: Fix CSI data format for 16-bit media bus formats
>>>   gpu: ipu-v3: Fix IRT usage
>>>   gpu: ipu-v3: Fix CSI0 blur in NTSC format
>>>   gpu: ipu-ic: Add complete image conversion support with tiling
>>>   gpu: ipu-ic: allow multiple handles to ic
>>>   gpu: ipu-v3: rename CSI client device
>>
>> These are all enhancements to the ipu-v3 driver shared by DRM and
>> maintained by Philipp Zabel and there is no way to 'stage' them.
>> Philipp, these have bee submitted previously with little to no changes
>> or feedback - can we get sign-off or comment on these from you?
> 
> I'd like to know the status of this as well. If this can't go in, then
> accepting the v4l2 driver in staging will likely be very difficult if not
> impossible.

This is the first thing that needs to happen. Philipp, please take a look at 
this!

Thanks,

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

72 matches

Mail list logo