cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Wed Jan 10 05:00:15 CET 2018
media-tree git hash:e3ee691dbf24096ea51b3200946b11d68ce75361
media_build git hash:   46c9dc0a08499791cedfc7ee0df387e475f075a2
v4l-utils git hash: 8aa401d119afaeb1b4fe4d2994789cd3e9396554
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3911-g6f737e1f
smatch version: v0.5.0-3911-g6f737e1f
host hardware:  x86_64
host os:4.13.0-164

linux-git-arm-at91: ERRORS
linux-git-arm-davinci: OK
linux-git-arm-multi: ERRORS
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-blackfin-bf561: ERRORS
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: ERRORS
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.4.22-i686: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.7.5-i686: ERRORS
linux-4.8-i686: ERRORS
linux-4.9.26-i686: ERRORS
linux-4.10.14-i686: WARNINGS
linux-4.11-i686: WARNINGS
linux-4.12.1-i686: WARNINGS
linux-4.13-i686: WARNINGS
linux-4.14-i686: WARNINGS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.22-x86_64: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.5-x86_64: ERRORS
linux-4.8-x86_64: ERRORS
linux-4.9.26-x86_64: ERRORS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
linux-4.13-x86_64: WARNINGS
linux-4.14-x86_64: WARNINGS
apps: OK
spec-git: OK
smatch: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: dvb usb issues since kernel 4.9

[Mike Galbraith]

On Tue, 2018-01-09 at 22:26 +0100, Jesper Dangaard Brouer wrote:
> 
> I've previously experienced that you can be affected by the scheduler
> granularity, which is adjustable (with CONFIG_SCHED_DEBUG=y):
> 
>  $ grep -H . /proc/sys/kernel/sched_*_granularity_ns
>  /proc/sys/kernel/sched_min_granularity_ns:225
>  /proc/sys/kernel/sched_wakeup_granularity_ns:300
> 
> The above numbers were confirmed on the RPi2 (see[2]). With commit
> 4cd13c21b207 ("softirq: Let ksoftirqd do its job"), I expect/assume that
> softirq processing latency is bounded by the sched_wakeup_granularity_ns,
> which with 3 ms is not good enough for their use-case.

Note of caution wrt twiddling sched_wakeup_granularity_ns: it must
remain < sched_latency_ns/2 else you effectively disable wakeup
preemption completely, turning CFS into a tick granularity scheduler.

-Mike

[PATCH v5 4/4] media: ov2685: add support for OV2685 sensor

[Shunqian Zheng]

This patch adds driver for Omnivision's ov2685 sensor.
Though the ov2685 can output yuv data, this driver only
supports the raw bayer format, including the following features:
  - output 1600x1200 at 30fps
  - test patterns
  - manual exposure/gain control
  - vblank and hblank
  - media controller
  - runtime pm

Signed-off-by: Shunqian Zheng 
---
 MAINTAINERS|   7 +
 drivers/media/i2c/Kconfig  |  12 +
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/ov2685.c | 842 +
 4 files changed, 862 insertions(+)
 create mode 100644 drivers/media/i2c/ov2685.c

diff --git a/MAINTAINERS b/MAINTAINERS
index cca5b1c..32afc69 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10032,6 +10032,13 @@ T: git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/i2c/ov13858.c
 
+OMNIVISION OV2685 SENSOR DRIVER
+M: Shunqian Zheng 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/ov2685.c
+
 OMNIVISION OV5640 SENSOR DRIVER
 M: Steve Longerbeam 
 L: linux-media@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 55b37c8..63a175d 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -586,6 +586,18 @@ config VIDEO_OV2659
  To compile this driver as a module, choose M here: the
  module will be called ov2659.
 
+config VIDEO_OV2685
+   tristate "OmniVision OV2685 sensor support"
+   depends on VIDEO_V4L2 && I2C && MEDIA_CONTROLLER
+   depends on MEDIA_CAMERA_SUPPORT
+   select V4L2_FWNODE
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV2685 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov2685.
+
 config VIDEO_OV5640
tristate "OmniVision OV5640 sensor support"
depends on OF
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index a063030..3054c69 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
 obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
 obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
 obj-$(CONFIG_VIDEO_OV2640) += ov2640.o
+obj-$(CONFIG_VIDEO_OV2685) += ov2685.o
 obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
 obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
 obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
diff --git a/drivers/media/i2c/ov2685.c b/drivers/media/i2c/ov2685.c
new file mode 100644
index 000..e9339e2
--- /dev/null
+++ b/drivers/media/i2c/ov2685.c
@@ -0,0 +1,842 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ov2685 driver
+ *
+ * Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CHIP_ID0x2685
+#define OV2685_REG_CHIP_ID 0x300a
+
+#define OV2685_XVCLK_FREQ  2400
+
+#define REG_SC_CTRL_MODE   0x0100
+#define SC_CTRL_MODE_STANDBY   0x0
+#define SC_CTRL_MODE_STREAMING BIT(0)
+
+#define OV2685_REG_EXPOSURE0x3500
+#defineOV2685_EXPOSURE_MIN 4
+#defineOV2685_EXPOSURE_STEP1
+
+#define OV2685_REG_VTS 0x380e
+#define OV2685_VTS_MAX 0x7fff
+
+#define OV2685_REG_GAIN0x350a
+#define OV2685_GAIN_MIN0
+#define OV2685_GAIN_MAX0x07ff
+#define OV2685_GAIN_STEP   0x1
+#define OV2685_GAIN_DEFAULT0x0036
+
+#define OV2685_REG_TEST_PATTERN0x5080
+#define OV2685_TEST_PATTERN_DISABLED   0x00
+#define OV2685_TEST_PATTERN_COLOR_BAR  0x80
+#define OV2685_TEST_PATTERN_RANDOM 0x81
+#define OV2685_TEST_PATTERN_COLOR_BAR_FADE 0x88
+#define OV2685_TEST_PATTERN_BW_SQUARE  0x92
+#define OV2685_TEST_PATTERN_COLOR_SQUARE   0x82
+
+#define REG_NULL   0x
+
+#define OV2685_REG_VALUE_08BIT 1
+#define OV2685_REG_VALUE_16BIT 2
+#define OV2685_REG_VALUE_24BIT 3
+
+#define OV2685_LANES   1
+#define OV2685_BITS_PER_SAMPLE 10
+
+static const char * const ov2685_supply_names[] = {
+   "avdd", /* Analog power */
+   "dovdd",/* Digital I/O power */
+   "dvdd", /* Digital core power */
+};
+
+#define OV2685_NUM_SUPPLIES ARRAY_SIZE(ov2685_supply_names)
+
+struct regval {
+   u16 addr;
+   u8 val;
+};
+
+struct ov2685_mode {
+   u32 width;
+   u32 height;
+   u32 exp_def;
+   u32 hts_def;
+   u32 vts_def;
+   const struct regval *reg_list;
+};
+
+struct ov2685 {
+   struct i2c_client   *client;
+  

[PATCH v5 3/4] dt-bindings: media: Add bindings for OV2685

[Shunqian Zheng]

Add device tree binding documentation for the OV2685 sensor.

Signed-off-by: Shunqian Zheng 
---
 .../devicetree/bindings/media/i2c/ov2685.txt   | 41 ++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2685.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov2685.txt 
b/Documentation/devicetree/bindings/media/i2c/ov2685.txt
new file mode 100644
index 000..f1586a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2685.txt
@@ -0,0 +1,41 @@
+* Omnivision OV2685 MIPI CSI-2 sensor
+
+Required Properties:
+- compatible: shall be "ovti,ov2685"
+- clocks: reference to the xvclk input clock
+- clock-names: shall be "xvclk"
+- avdd-supply: Analog voltage supply, 2.8 volts
+- dovdd-supply: Digital I/O voltage supply, 1.8 volts
+- dvdd-supply: Digital core voltage supply, 1.8 volts
+- reset-gpios: Low active reset gpio
+
+The device node shall contain one 'port' child node with an
+'endpoint' subnode for its digital output video port,
+in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+The endpoint optional property 'data-lanes' shall be "<1>".
+
+Example:
+ {
+   camera-sensor: ov2685@3c {
+   compatible = "ovti,ov2685";
+   reg = <0x3c>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_24m_cam>;
+
+   clocks = < SCLK_TESTCLKOUT1>;
+   clock-names = "xvclk";
+
+   avdd-supply = <_cam>;
+   dovdd-supply = <>;
+   dvdd-supply = <>;
+   reset-gpios = < 3 GPIO_ACTIVE_LOW>;
+
+   port {
+   ucam_out: endpoint {
+   remote-endpoint = <_in_ucam>;
+   data-lanes = <1>;
+   };
+   };
+   };
+};
-- 
1.9.1

[PATCH v5 0/4] Add supports for OV2685 and OV5695 sensors

[Shunqian Zheng]

This adds the OV2685 and OV5695 sensor supports.

Changes of v5,
 - Squash the MAINTAINERS entry to driver patch

Mainly changes of v4 are addressing the comments from Sakari,
including,
 - Put dt binding before driver in series
 - Add MAINTAINERS entries
 - Use regulator_bulk_*()
 - Fix the pm_runtime_* in probe()
 - Fix the typo of 2685 0x3008/0x3010 regs

Shunqian Zheng (4):
  dt-bindings: media: Add bindings for OV5695
  media: ov5695: add support for OV5695 sensor
  dt-bindings: media: Add bindings for OV2685
  media: ov2685: add support for OV2685 sensor

 .../devicetree/bindings/media/i2c/ov2685.txt   |   41 +
 .../devicetree/bindings/media/i2c/ov5695.txt   |   41 +
 MAINTAINERS|   14 +
 drivers/media/i2c/Kconfig  |   23 +
 drivers/media/i2c/Makefile |2 +
 drivers/media/i2c/ov2685.c |  842 
 drivers/media/i2c/ov5695.c | 1396 
 7 files changed, 2359 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2685.txt
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5695.txt
 create mode 100644 drivers/media/i2c/ov2685.c
 create mode 100644 drivers/media/i2c/ov5695.c

-- 
1.9.1

[PATCH v5 1/4] dt-bindings: media: Add bindings for OV5695

[Shunqian Zheng]

Add device tree binding documentation for the OV5695 sensor.

Signed-off-by: Shunqian Zheng 
---
 .../devicetree/bindings/media/i2c/ov5695.txt   | 41 ++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5695.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov5695.txt 
b/Documentation/devicetree/bindings/media/i2c/ov5695.txt
new file mode 100644
index 000..2f2f698
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5695.txt
@@ -0,0 +1,41 @@
+* Omnivision OV5695 MIPI CSI-2 sensor
+
+Required Properties:
+- compatible: shall be "ovti,ov5695"
+- clocks: reference to the xvclk input clock
+- clock-names: shall be "xvclk"
+- avdd-supply: Analog voltage supply, 2.8 volts
+- dovdd-supply: Digital I/O voltage supply, 1.8 volts
+- dvdd-supply: Digital core voltage supply, 1.2 volts
+- reset-gpios: Low active reset gpio
+
+The device node shall contain one 'port' child node with an
+'endpoint' subnode for its digital output video port,
+in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+The endpoint optional property 'data-lanes' shall be "<1 2>".
+
+Example:
+ {
+   camera-sensor: ov5695@36 {
+   compatible = "ovti,ov5695";
+   reg = <0x36>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_24m_cam>;
+
+   clocks = < SCLK_TESTCLKOUT1>;
+   clock-names = "xvclk";
+
+   avdd-supply = <_cam>;
+   dovdd-supply = <>;
+   dvdd-supply = <_cam>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>;
+
+   port {
+   wcam_out: endpoint {
+   remote-endpoint = <_in_wcam>;
+   data-lanes = <1 2>;
+   };
+   };
+   };
+};
-- 
1.9.1

[PATCH v5 2/4] media: ov5695: add support for OV5695 sensor

[Shunqian Zheng]

This patch adds driver for Omnivision's ov5695 sensor,
the driver supports following features:
 - supported resolutions
   + 2592x1944 at 30fps
   + 1920x1080 at 30fps
   + 1296x972 at 60fps
   + 1280x720 at 30fps
   + 640x480 at 120fps
 - test patterns
 - manual exposure/gain(analog and digital) control
 - vblank and hblank
 - media controller
 - runtime pm

Signed-off-by: Shunqian Zheng 
---
 MAINTAINERS|7 +
 drivers/media/i2c/Kconfig  |   11 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov5695.c | 1396 
 4 files changed, 1415 insertions(+)
 create mode 100644 drivers/media/i2c/ov5695.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 85773bf..cca5b1c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10046,6 +10046,13 @@ T: git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/i2c/ov5647.c
 
+OMNIVISION OV5695 SENSOR DRIVER
+M: Shunqian Zheng 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/ov5695.c
+
 OMNIVISION OV7670 SENSOR DRIVER
 M: Jonathan Corbet 
 L: linux-media@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 3c6d642..55b37c8 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -645,6 +645,17 @@ config VIDEO_OV5670
  To compile this driver as a module, choose M here: the
  module will be called ov5670.
 
+config VIDEO_OV5695
+   tristate "OmniVision OV5695 sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV5695 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov5695.
+
 config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9ef..a063030 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
 obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
 obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
 obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
+obj-$(CONFIG_VIDEO_OV5695) += ov5695.o
 obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
diff --git a/drivers/media/i2c/ov5695.c b/drivers/media/i2c/ov5695.c
new file mode 100644
index 000..c2e0462
--- /dev/null
+++ b/drivers/media/i2c/ov5695.c
@@ -0,0 +1,1396 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ov5695 driver
+ *
+ * Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef V4L2_CID_DIGITAL_GAIN
+#define V4L2_CID_DIGITAL_GAIN  V4L2_CID_GAIN
+#endif
+
+/* 45Mhz * 4 Binning */
+#define OV5695_PIXEL_RATE  (45 * 1000 * 1000 * 4)
+#define OV5695_XVCLK_FREQ  2400
+
+#define CHIP_ID0x005695
+#define OV5695_REG_CHIP_ID 0x300a
+
+#define OV5695_REG_CTRL_MODE   0x0100
+#define OV5695_MODE_SW_STANDBY 0x0
+#define OV5695_MODE_STREAMING  BIT(0)
+
+#define OV5695_REG_EXPOSURE0x3500
+#defineOV5695_EXPOSURE_MIN 4
+#defineOV5695_EXPOSURE_STEP1
+#define OV5695_VTS_MAX 0x7fff
+
+#define OV5695_REG_ANALOG_GAIN 0x3509
+#defineANALOG_GAIN_MIN 0x10
+#defineANALOG_GAIN_MAX 0xf8
+#defineANALOG_GAIN_STEP1
+#defineANALOG_GAIN_DEFAULT 0xf8
+
+#define OV5695_REG_DIGI_GAIN_H 0x350a
+#define OV5695_REG_DIGI_GAIN_L 0x350b
+#define OV5695_DIGI_GAIN_L_MASK0x3f
+#define OV5695_DIGI_GAIN_H_SHIFT   6
+#define OV5695_DIGI_GAIN_MIN   0
+#define OV5695_DIGI_GAIN_MAX   (0x4000 - 1)
+#define OV5695_DIGI_GAIN_STEP  1
+#define OV5695_DIGI_GAIN_DEFAULT   1024
+
+#define OV5695_REG_TEST_PATTERN0x4503
+#defineOV5695_TEST_PATTERN_ENABLE  0x80
+#defineOV5695_TEST_PATTERN_DISABLE 0x0
+
+#define OV5695_REG_VTS 0x380e
+
+#define REG_NULL   0x
+
+#define OV5695_REG_VALUE_08BIT 1
+#define OV5695_REG_VALUE_16BIT 2
+#define OV5695_REG_VALUE_24BIT 3
+
+#define OV5695_LANES   2
+#define OV5695_BITS_PER_SAMPLE 10
+
+static const char * const ov5695_supply_names[] = {
+   "avdd", /* Analog power */
+   "dovdd",/* Digital I/O power */
+   "dvdd", /* Digital core power */
+};
+
+#define 

Re: [PATCH 2/2] MAINTAINERS: mtd/nand: update Microchip nand entry

[Yang, Wenyou]

On 2018/1/9 21:46, Nicolas Ferre wrote:

Update Wenyou Yang email address.
Take advantage of this update to move this entry to the MICROCHIP / ATMEL
location and add the DT binding documentation link.

Signed-off-by: Nicolas Ferre <nicolas.fe...@microchip.com>

Acked-by: Wenyou Yang <wenyou.y...@microchip.com>

---
Hi,

Patch against next-20180109.
This patch is somehow dependent on the previous one in the series
("MAINTAINERS: linux-media: update Microchip ISI and ISC entries") but can be
rebased easily.

I don't know if it's better to have them added at the end of the development
cycle or just after rc1: let me know if you plan to take them or if I need to
rebase them for next cycle.

Best regards,
   Nicolas


  MAINTAINERS | 15 ---
  1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 65c4b59b582f..b48e217d41fb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2373,13 +2373,6 @@ F:   
Documentation/devicetree/bindings/input/atmel,maxtouch.txt
  F:drivers/input/touchscreen/atmel_mxt_ts.c
  F:include/linux/platform_data/atmel_mxt_ts.h
  
-ATMEL NAND DRIVER

-M: Wenyou Yang <wenyou.y...@atmel.com>
-M: Josh Wu <rainyfeel...@outlook.com>
-L: linux-...@lists.infradead.org
-S: Supported
-F: drivers/mtd/nand/atmel/*
-
  ATMEL SAMA5D2 ADC DRIVER
  M:Ludovic Desroches <ludovic.desroc...@microchip.com>
  L:linux-...@vger.kernel.org
@@ -9110,6 +9103,14 @@ F:   drivers/media/platform/atmel/atmel-isi.c
  F:include/media/atmel-isi.h
  F:Documentation/devicetree/bindings/media/atmel-isi.txt
  
+MICROCHIP / ATMEL NAND DRIVER

+M: Wenyou Yang <wenyou.y...@microchip.com>
+M: Josh Wu <rainyfeel...@outlook.com>
+L: linux-...@lists.infradead.org
+S: Supported
+F: drivers/mtd/nand/atmel/*
+F: Documentation/devicetree/bindings/mtd/atmel-nand.txt
+
  MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
  M:Woojung Huh <woojung@microchip.com>
  M:Microchip Linux Driver Support <unglinuxdri...@microchip.com>


Best Regards,
Wenyou Yang

Re: [PATCH 1/2] MAINTAINERS: linux-media: update Microchip ISI and ISC entries

[Yang, Wenyou]

On 2018/1/9 21:46, Nicolas Ferre wrote:

These two image capture interface drivers are now handled
by Wenyou Yang.
I benefit from this change to update the two entries by correcting the
binding documentation link for ISC and moving the ISI to the new
MICROCHIP / ATMEL location.

Signed-off-by: Nicolas Ferre <nicolas.fe...@microchip.com>

Acked-by: Wenyou Yang <wenyou.y...@microchip.com>

---
Hi,

Patch against next-20180109.
Note that I didn't find it useful to have several patches for these changes.
Tell me if you feel differently.

I would like to have the Ack from Ludovic and Wenyou obviously. I don't know if
Songjun can answer as he's not with Microchip anymore.

Best regards,
   Nicolas

  MAINTAINERS | 19 ++-
  1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a7d10a2bb980..65c4b59b582f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2353,13 +2353,6 @@ L:   linux-...@vger.kernel.org
  S:Supported
  F:drivers/i2c/busses/i2c-at91.c
  
-ATMEL ISI DRIVER

-M: Ludovic Desroches <ludovic.desroc...@microchip.com>
-L: linux-media@vger.kernel.org
-S: Supported
-F: drivers/media/platform/atmel/atmel-isi.c
-F: include/media/atmel-isi.h
-
  ATMEL LCDFB DRIVER
  M:Nicolas Ferre <nicolas.fe...@microchip.com>
  L:linux-fb...@vger.kernel.org
@@ -9102,12 +9095,20 @@ S:  Maintained
  F:drivers/crypto/atmel-ecc.*
  
  MICROCHIP / ATMEL ISC DRIVER

-M: Songjun Wu <songjun...@microchip.com>
+M: Wenyou Yang <wenyou.y...@microchip.com>
  L:linux-media@vger.kernel.org
  S:Supported
  F:drivers/media/platform/atmel/atmel-isc.c
  F:drivers/media/platform/atmel/atmel-isc-regs.h
-F: devicetree/bindings/media/atmel-isc.txt
+F: Documentation/devicetree/bindings/media/atmel-isc.txt
+
+MICROCHIP / ATMEL ISI DRIVER
+M: Wenyou Yang <wenyou.y...@microchip.com>
+L: linux-media@vger.kernel.org
+S: Supported
+F: drivers/media/platform/atmel/atmel-isi.c
+F: include/media/atmel-isi.h
+F: Documentation/devicetree/bindings/media/atmel-isi.txt
  
  MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER

  M:Woojung Huh <woojung@microchip.com>

Best Regards,
Wenyou Yang

Re: [PATCH v4 2/5] media: ov5695: add support for OV5695 sensor

[Shunqian Zheng]

Hi Baruch,


On 2018年01月10日 00:54, Baruch Siach wrote:

Hi Shunqian Zheng,

On Tue, Jan 09, 2018 at 10:48:21PM +0800, Shunqian Zheng wrote:

+static int ov5695_write_array(struct i2c_client *client,
+ const struct regval *regs)
+{
+   u32 i;
+   int ret = 0;
+
+   for (i = 0; ret == 0 && regs[i].addr != REG_NULL; i++)
+   ret = ov5695_write_reg(client, regs[i].addr,
+  OV5695_REG_VALUE_08BIT, regs[i].val);

This loop should stop on first failure, and return the error value. With
current code a register write failure is masked by following writes.

This loop will stop once ret != 0 as in for loop condition

Thanks,



+
+   return ret;
+}

baruch

Re: [PATCH 3/3] pci-dma-compat: remove handling of NULL pdev arguments

[Bjorn Helgaas]

s/pci-dma-compat: remove handling of NULL pdev
 /PCI: Remove NULL device handling from DMA API/

On Tue, Jan 09, 2018 at 09:39:39PM +0100, Christoph Hellwig wrote:
> Historically some ISA drivers used the old pci DMA API with a NULL pdev
> argument, but these days this isn't used and not too useful due to the
> per-device DMA ops, so remove it.

s/pci/PCI/

I like this a lot, thanks!

It looks like "pci_free_consistent(NULL" is still used in
drivers/net/ethernet/tundra/tsi108_eth.c.

> Signed-off-by: Christoph Hellwig 

With Mauro's ack on the media/ttusb-dev patches, I could merge the
whole series via the PCI tree?

> ---
>  include/linux/pci-dma-compat.h | 27 +--
>  1 file changed, 13 insertions(+), 14 deletions(-)
> 
> diff --git a/include/linux/pci-dma-compat.h b/include/linux/pci-dma-compat.h
> index d1f9fdade1e0..0dd1a3f7b309 100644
> --- a/include/linux/pci-dma-compat.h
> +++ b/include/linux/pci-dma-compat.h
> @@ -17,91 +17,90 @@ static inline void *
>  pci_alloc_consistent(struct pci_dev *hwdev, size_t size,
>dma_addr_t *dma_handle)
>  {
> - return dma_alloc_coherent(hwdev == NULL ? NULL : >dev, size, 
> dma_handle, GFP_ATOMIC);
> + return dma_alloc_coherent(>dev, size, dma_handle, GFP_ATOMIC);
>  }
>  
>  static inline void *
>  pci_zalloc_consistent(struct pci_dev *hwdev, size_t size,
> dma_addr_t *dma_handle)
>  {
> - return dma_zalloc_coherent(hwdev == NULL ? NULL : >dev,
> -size, dma_handle, GFP_ATOMIC);
> + return dma_zalloc_coherent(>dev, size, dma_handle, GFP_ATOMIC);
>  }
>  
>  static inline void
>  pci_free_consistent(struct pci_dev *hwdev, size_t size,
>   void *vaddr, dma_addr_t dma_handle)
>  {
> - dma_free_coherent(hwdev == NULL ? NULL : >dev, size, vaddr, 
> dma_handle);
> + dma_free_coherent(>dev, size, vaddr, dma_handle);
>  }
>  
>  static inline dma_addr_t
>  pci_map_single(struct pci_dev *hwdev, void *ptr, size_t size, int direction)
>  {
> - return dma_map_single(hwdev == NULL ? NULL : >dev, ptr, size, 
> (enum dma_data_direction)direction);
> + return dma_map_single(>dev, ptr, size, (enum 
> dma_data_direction)direction);
>  }
>  
>  static inline void
>  pci_unmap_single(struct pci_dev *hwdev, dma_addr_t dma_addr,
>size_t size, int direction)
>  {
> - dma_unmap_single(hwdev == NULL ? NULL : >dev, dma_addr, size, 
> (enum dma_data_direction)direction);
> + dma_unmap_single(>dev, dma_addr, size, (enum 
> dma_data_direction)direction);
>  }
>  
>  static inline dma_addr_t
>  pci_map_page(struct pci_dev *hwdev, struct page *page,
>unsigned long offset, size_t size, int direction)
>  {
> - return dma_map_page(hwdev == NULL ? NULL : >dev, page, offset, 
> size, (enum dma_data_direction)direction);
> + return dma_map_page(>dev, page, offset, size, (enum 
> dma_data_direction)direction);
>  }
>  
>  static inline void
>  pci_unmap_page(struct pci_dev *hwdev, dma_addr_t dma_address,
>  size_t size, int direction)
>  {
> - dma_unmap_page(hwdev == NULL ? NULL : >dev, dma_address, size, 
> (enum dma_data_direction)direction);
> + dma_unmap_page(>dev, dma_address, size, (enum 
> dma_data_direction)direction);
>  }
>  
>  static inline int
>  pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg,
>  int nents, int direction)
>  {
> - return dma_map_sg(hwdev == NULL ? NULL : >dev, sg, nents, (enum 
> dma_data_direction)direction);
> + return dma_map_sg(>dev, sg, nents, (enum 
> dma_data_direction)direction);
>  }
>  
>  static inline void
>  pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg,
>int nents, int direction)
>  {
> - dma_unmap_sg(hwdev == NULL ? NULL : >dev, sg, nents, (enum 
> dma_data_direction)direction);
> + dma_unmap_sg(>dev, sg, nents, (enum 
> dma_data_direction)direction);
>  }
>  
>  static inline void
>  pci_dma_sync_single_for_cpu(struct pci_dev *hwdev, dma_addr_t dma_handle,
>   size_t size, int direction)
>  {
> - dma_sync_single_for_cpu(hwdev == NULL ? NULL : >dev, dma_handle, 
> size, (enum dma_data_direction)direction);
> + dma_sync_single_for_cpu(>dev, dma_handle, size, (enum 
> dma_data_direction)direction);
>  }
>  
>  static inline void
>  pci_dma_sync_single_for_device(struct pci_dev *hwdev, dma_addr_t dma_handle,
>   size_t size, int direction)
>  {
> - dma_sync_single_for_device(hwdev == NULL ? NULL : >dev, 
> dma_handle, size, (enum dma_data_direction)direction);
> + dma_sync_single_for_device(>dev, dma_handle, size, (enum 
> dma_data_direction)direction);
>  }
>  
>  static inline void
>  pci_dma_sync_sg_for_cpu(struct pci_dev *hwdev, struct scatterlist *sg,
>   int nelems, int direction)
>  {
> - dma_sync_sg_for_cpu(hwdev == NULL ? NULL : >dev, sg, nelems, 
> (enum dma_data_direction)direction);
> + 

Re: [PATCH 1/3] media/ttusb-budget: remove pci_zalloc_coherent abuse

[Bjorn Helgaas]

On Tue, Jan 09, 2018 at 09:39:37PM +0100, Christoph Hellwig wrote:
> Switch to a plain kzalloc instea of pci_zalloc_coherent to allocate
> memory for the USB DMA.

s/instea/instead/

> 
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c | 13 +++--
>  1 file changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c 
> b/drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c
> index a142b9dc0feb..b8619fb23351 100644
> --- a/drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c
> +++ b/drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c
> @@ -102,7 +102,6 @@ struct ttusb {
>   unsigned int isoc_in_pipe;
>  
>   void *iso_buffer;
> - dma_addr_t iso_dma_handle;
>  
>   struct urb *iso_urb[ISO_BUF_COUNT];
>  
> @@ -792,21 +791,15 @@ static void ttusb_free_iso_urbs(struct ttusb *ttusb)
>  
>   for (i = 0; i < ISO_BUF_COUNT; i++)
>   usb_free_urb(ttusb->iso_urb[i]);
> -
> - pci_free_consistent(NULL,
> - ISO_FRAME_SIZE * FRAMES_PER_ISO_BUF *
> - ISO_BUF_COUNT, ttusb->iso_buffer,
> - ttusb->iso_dma_handle);
> + kfree(ttusb->iso_buffer);
>  }
>  
>  static int ttusb_alloc_iso_urbs(struct ttusb *ttusb)
>  {
>   int i;
>  
> - ttusb->iso_buffer = pci_zalloc_consistent(NULL,
> -   ISO_FRAME_SIZE * 
> FRAMES_PER_ISO_BUF * ISO_BUF_COUNT,
> -   >iso_dma_handle);
> -
> + ttusb->iso_buffer = kzalloc(ISO_FRAME_SIZE * FRAMES_PER_ISO_BUF *
> + ISO_BUF_COUNT, GFP_KERNEL);
>   if (!ttusb->iso_buffer) {
>   dprintk("%s: pci_alloc_consistent - not enough memory\n",
>   __func__);
> -- 
> 2.14.2
> 

[PATCH v1 2/2] [media] cxusb: restore RC_MAP for MyGica T230

[Stefan Brüns]

Commit f8585ce655e9cdeabc38e8e2580b05735110e4a5 ("[media] dvb-usb-cxusb:
Geniatech T230C support") sneaked in an unrelated change for the older
T230 (not C) model. As the commit was reverted this change was reverted
too, although likely correct.

Signed-off-by: Stefan Brüns 

---

 drivers/media/usb/dvb-usb/cxusb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb/cxusb.c 
b/drivers/media/usb/dvb-usb/cxusb.c
index edb7cd2e43d9..75f44b534007 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -2165,7 +2165,7 @@ static struct dvb_usb_device_properties 
cxusb_mygica_t230_properties = {
 
.rc.core = {
.rc_interval= 100,
-   .rc_codes   = RC_MAP_D680_DMB,
+   .rc_codes   = RC_MAP_TOTAL_MEDIA_IN_HAND_02,
.module_name= KBUILD_MODNAME,
.rc_query   = cxusb_d680_dmb_rc_query,
.allowed_protos = RC_PROTO_BIT_UNKNOWN,
-- 
2.15.1

[PATCH v1 1/2] Revert "[media] dvb-usb-cxusb: Geniatech T230C support"

[Stefan Brüns]

From: Evgeny Plehov 

This reverts commit f8585ce655e9cdeabc38e8e2580b05735110e4a5.

The T230C is handled by the dvb-usb-v2/dvbsky.c driver, which should
be preferred over a dvb-usb (v1) driver.

Signed-off-by: Stefan Brüns 
---

 drivers/media/usb/dvb-usb/cxusb.c | 139 +-
 1 file changed, 1 insertion(+), 138 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/cxusb.c 
b/drivers/media/usb/dvb-usb/cxusb.c
index 37dea0adc695..edb7cd2e43d9 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -1239,82 +1239,6 @@ static int cxusb_mygica_t230_frontend_attach(struct 
dvb_usb_adapter *adap)
return 0;
 }
 
-static int cxusb_mygica_t230c_frontend_attach(struct dvb_usb_adapter *adap)
-{
-   struct dvb_usb_device *d = adap->dev;
-   struct cxusb_state *st = d->priv;
-   struct i2c_adapter *adapter;
-   struct i2c_client *client_demod;
-   struct i2c_client *client_tuner;
-   struct i2c_board_info info;
-   struct si2168_config si2168_config;
-   struct si2157_config si2157_config;
-
-   /* Select required USB configuration */
-   if (usb_set_interface(d->udev, 0, 0) < 0)
-   err("set interface failed");
-
-   /* Unblock all USB pipes */
-   usb_clear_halt(d->udev,
-   usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint));
-   usb_clear_halt(d->udev,
-   usb_rcvbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint));
-   usb_clear_halt(d->udev,
-   usb_rcvbulkpipe(d->udev, 
d->props.adapter[0].fe[0].stream.endpoint));
-
-   /* attach frontend */
-   memset(_config, 0, sizeof(si2168_config));
-   si2168_config.i2c_adapter = 
-   si2168_config.fe = >fe_adap[0].fe;
-   si2168_config.ts_mode = SI2168_TS_PARALLEL;
-   si2168_config.ts_clock_inv = 1;
-   memset(, 0, sizeof(struct i2c_board_info));
-   strlcpy(info.type, "si2168", I2C_NAME_SIZE);
-   info.addr = 0x64;
-   info.platform_data = _config;
-   request_module(info.type);
-   client_demod = i2c_new_device(>i2c_adap, );
-   if (client_demod == NULL || client_demod->dev.driver == NULL)
-   return -ENODEV;
-
-   if (!try_module_get(client_demod->dev.driver->owner)) {
-   i2c_unregister_device(client_demod);
-   return -ENODEV;
-   }
-
-   /* attach tuner */
-   memset(_config, 0, sizeof(si2157_config));
-   si2157_config.fe = adap->fe_adap[0].fe;
-   memset(, 0, sizeof(struct i2c_board_info));
-   strlcpy(info.type, "si2141", I2C_NAME_SIZE);
-   info.addr = 0x60;
-   info.platform_data = _config;
-   request_module("si2157");
-   client_tuner = i2c_new_device(adapter, );
-   if (client_tuner == NULL || client_tuner->dev.driver == NULL) {
-   module_put(client_demod->dev.driver->owner);
-   i2c_unregister_device(client_demod);
-   return -ENODEV;
-   }
-   if (!try_module_get(client_tuner->dev.driver->owner)) {
-   i2c_unregister_device(client_tuner);
-   module_put(client_demod->dev.driver->owner);
-   i2c_unregister_device(client_demod);
-   return -ENODEV;
-   }
-
-   st->i2c_client_demod = client_demod;
-   st->i2c_client_tuner = client_tuner;
-
-   /* hook fe: need to resync the slave fifo when signal locks. */
-   mutex_init(>stream_mutex);
-   st->last_lock = 0;
-   st->fe_read_status = adap->fe_adap[0].fe->ops.read_status;
-   adap->fe_adap[0].fe->ops.read_status = cxusb_read_status;
-
-   return 0;
-}
-
 /*
  * DViCO has shipped two devices with the same USB ID, but only one of them
  * needs a firmware download.  Check the device class details to see if they
@@ -1397,7 +1321,6 @@ static struct dvb_usb_device_properties 
cxusb_aver_a868r_properties;
 static struct dvb_usb_device_properties cxusb_d680_dmb_properties;
 static struct dvb_usb_device_properties cxusb_mygica_d689_properties;
 static struct dvb_usb_device_properties cxusb_mygica_t230_properties;
-static struct dvb_usb_device_properties cxusb_mygica_t230c_properties;
 
 static int cxusb_probe(struct usb_interface *intf,
   const struct usb_device_id *id)
@@ -1430,8 +1353,6 @@ static int cxusb_probe(struct usb_interface *intf,
 THIS_MODULE, NULL, adapter_nr) ||
0 == dvb_usb_device_init(intf, _mygica_t230_properties,
 THIS_MODULE, NULL, adapter_nr) ||
-   0 == dvb_usb_device_init(intf, _mygica_t230c_properties,
-THIS_MODULE, NULL, adapter_nr) ||
0)
return 0;
 
@@ -1483,7 +1404,6 @@ enum cxusb_table_index {
CONEXANT_D680_DMB,
MYGICA_D689,
MYGICA_T230,
-   MYGICA_T230C,
NR__cxusb_table_index
 };
 

[PATCH v1 0/2] Remove duplicate driver for MyGica T230C

[Stefan Brüns]

In 2017-02, two drivers for the T230C where submitted, but until now
only the one based on the older dvb-usb/cxusb.c driver has been part
of the mainline kernel. As a dvb-usb-v2 driver is preferable, remove
the other driver.

The cxusb.c patch also contained an unrelated change for the T230,
i.e. a correction of the RC model. As this change apparently is
correct, restore it. This has not been tested due to lack of hardware.


Evgeny Plehov (1):
  Revert "[media] dvb-usb-cxusb: Geniatech T230C support"

Stefan Brüns (1):
  [media] cxusb: restore RC_MAP for MyGica T230

 drivers/media/usb/dvb-usb/cxusb.c | 137 --
 1 file changed, 137 deletions(-)

-- 
2.15.1

Re: [PATCH 2/2] media: staging: atomisp: cleanup whitespaces

[Sakari Ailus]

Hi Alan,

On Mon, Jan 08, 2018 at 02:26:39PM +, Alan Cox wrote:
> On Mon, 8 Jan 2018 16:21:21 +0200
> Sakari Ailus  wrote:
> 
> > Hi Mauro,
> > 
> > On Thu, Jan 04, 2018 at 02:44:41PM -0500, Mauro Carvalho Chehab wrote:
> > > There are lots of bad whitespaces at atomisp driver.
> > > 
> > > Fix them.
> > > 
> > > Signed-off-by: Mauro Carvalho Chehab 
> > > ---
> > > 
> > > Sakari/Alan,
> > > 
> > > This is a script-generated patch that can be re-generated anytime.
> > > If you prefer to not touch on it now, i'm perfectly fine.
> > > 
> > > I'm sending it just as completeness, as I'm doing a similar
> > > cleanup under drivers/media, where  a number of 
> > > sequences accumulated over the time.   
> > 
> > Thanks for the patch.
> > 
> > In principle this is a worthwhile patch; I'd postpone it for the time being
> > though: I understand that a few people are bisecting and / or applying
> > out-of-tree patches to the driver to debug it on a few different hardware
> > platforms. Let's wait until that work is done, and then apply this.
> 
> Given the kind of debug going on and the amount of time it's taking (plus
> AtomISP for reasons people now know got mostly dropped from my work queue
> since June) I'm happy if they get applied.
> 
> Can we apply the core ISP2401 merge from Vincent first though ?

I'm not sure which patches do you mean here --- there are no recent atomisp
patches from Vincent I'm aware of.

-- 
Regards,

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

[GIT PULL for 4.16] dw9714 PM fix, cleanups

[Sakari Ailus]

Hi Mauro,

Here's a PM fix and a small cleanup for the dw9714 driver.

Please pull.


The following changes since commit e3ee691dbf24096ea51b3200946b11d68ce75361:

  media: ov5640: add support of RGB565 and YUYV formats (2018-01-05 12:54:14 
-0500)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git dw9714

for you to fetch changes up to 973c0145c2b5ea837cdad467c928be653c6a5872:

  dw9714: Remove client field in driver's struct (2018-01-10 00:44:09 +0200)


Sakari Ailus (2):
  dw9714: Call pm_runtime_idle() at the end of probe()
  dw9714: Remove client field in driver's struct

 drivers/media/i2c/dw9714.c | 20 ++--
 1 file changed, 6 insertions(+), 14 deletions(-)

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

[GIT PULL for 4.16] CIO2 compiler warning fix

[Sakari Ailus]

Hi Mauro,

Here's compile warning fix for the Intel IPU3 CIO2 driver from Arnd.

Please pull.


The following changes since commit e3ee691dbf24096ea51b3200946b11d68ce75361:

  media: ov5640: add support of RGB565 and YUYV formats (2018-01-05 12:54:14 
-0500)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git ipu3

for you to fetch changes up to 0bf3352560b82c12380823f035f5fb2171683f23:

  media: intel-ipu3: cio2: mark more PM functions as __maybe_unused (2018-01-09 
13:16:07 +0200)


Arnd Bergmann (1):
  media: intel-ipu3: cio2: mark more PM functions as __maybe_unused

 drivers/media/pci/intel/ipu3/ipu3-cio2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

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

Re: [PATCH v4 5/5] [media] MAINTAINERS: add entries for OV2685/OV5695 sensor drivers

[Sakari Ailus]

On Tue, Jan 09, 2018 at 10:48:24PM +0800, Shunqian Zheng wrote:
> Add maintainer entries for the OV2685 and OV5695 V4L2 sensor drivers.
> 
> Signed-off-by: Shunqian Zheng 

Same patch with the driver, please.

Other than that seems good to me.

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

Re: [PATCH 1/1] media: entity: Add a nop variant of media_entity_cleanupr

[Sakari Ailus]

Hi Arnd,

On Tue, Jan 09, 2018 at 03:26:38PM +0100, Arnd Bergmann wrote:
> On Tue, Jan 9, 2018 at 2:58 PM, Sakari Ailus
>  wrote:
> > Add nop variant of media_entity_cleanup. This allows calling
> > media_entity_cleanup whether or not Media controller is enabled,
> > simplifying driver code.
> >
> > Also drop #ifdefs on a few drivers around media_entity_cleanup() and drop
> > the extra semicolon from media_entity_cleanup prototype.
> >
> > Signed-off-by: Sakari Ailus 
> > ---
> > Hi Arnd,
> >
> > I thought about doing something similar with media_entity_pads_init which is
> > equally commonly used in drivers that support MC/non-MC cases. The trouble
> > with that is that the drivers set up the struct first before calling
> > media_entity_pads_init, requiring the #ifdefs in any case. So the benefit
> > would be questionable at least. So just media_entity_cleanup this time.
> 
> Looks good overall, just two thoughts:
> 
> > diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> > index d7a669058b5e..a732af1dbba0 100644
> > --- a/include/media/media-entity.h
> > +++ b/include/media/media-entity.h
> > @@ -634,7 +634,11 @@ int media_entity_pads_init(struct media_entity 
> > *entity, u16 num_pads,
> >   * This function must be called during the cleanup phase after 
> > unregistering
> >   * the entity (currently, it does nothing).
> >   */
> > -static inline void media_entity_cleanup(struct media_entity *entity) {};
> > +#if IS_ENABLED(CONFIG_MEDIA_CONTROLLER)
> > +static inline void media_entity_cleanup(struct media_entity *entity) {}
> > +#else
> > +#define media_entity_cleanup(entity) do { } while (false)
> > +#endif
> 
> This might cause a harmless warning about an unused variable in case
> we have a driver that does:
> 
>  void f(struct i2c_client *client)
> {
> struct v4l2_subdev *sd = to_subdev(client);
> media_entity_cleanup(sd);

That'd be:

media_entity_cleanup(>entity);

> }
> 
> None of the drivers you changed would have an unused variable after
> your change (otherwise they would already have it before your change),
> so it's probably fine.

I thought of that, too. There are drivers that define the entity (as in
struct v4l2_subdev) only if CONFIG_MEDIA_CONTROLLER is enabled. As the
entity field isn't there, this won't compile; that's actually why I turned
it into a macro. This should be actually mentioned in the commit message.

I guess that could be changed, too, but the purpose, I believe, is to avoid
wasting memory on things that aren't there. I didn't see compiler warnings
from those drivers by disabling MC either, so presume that should be a
change for better...

> 
> and second, I'm trying the patch below on top of yours now, will
> see how far that gets us ;-)
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 03cf3a1a1e06..6421da7cb58a 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -310,14 +310,14 @@ config VIDEO_ML86V7667
> 
>  config VIDEO_AD5820
> tristate "AD5820 lens voice coil support"
> -   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> +   depends on I2C && VIDEO_V4L2
> ---help---
>   This is a driver for the AD5820 camera lens voice coil.
>   It is used for example in Nokia N900 (RX-51).
> 
>  config VIDEO_DW9714
> tristate "DW9714 lens voice coil support"
> -   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> +   depends on I2C && VIDEO_V4L2

Both drivers call media_entity_pads_init() unconditionally.

> depends on VIDEO_V4L2_SUBDEV_API
> ---help---
>   This is a driver for the DW9714 camera lens voice coil.
> @@ -636,7 +636,6 @@ config VIDEO_OV5670
> tristate "OmniVision OV5670 sensor support"
> depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> depends on MEDIA_CAMERA_SUPPORT
> -   depends on MEDIA_CONTROLLER

ov5670 does depend on MC at least right now. I guess it might not take much
to make it optional. But it's more than this patch. :-)

> select V4L2_FWNODE
> ---help---
>   This is a Video4Linux2 sensor-level driver for the OmniVision
> @@ -667,7 +666,7 @@ config VIDEO_OV7670
> 
>  config VIDEO_OV7740
> tristate "OmniVision OV7740 sensor support"
> -   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> +   depends on I2C && VIDEO_V4L2

Hmm. In here the ov7740 driver doesn't seem to depend on MC.

> depends on MEDIA_CAMERA_SUPPORT
> ---help---
>   This is a Video4Linux2 sensor-level driver for the OmniVision
> @@ -815,7 +814,7 @@ comment "Flash devices"
> 
>  config VIDEO_ADP1653
> tristate "ADP1653 flash support"
> -   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> +   depends on I2C && VIDEO_V4L2
> depends on MEDIA_CAMERA_SUPPORT
> ---help---
>   This is a driver for the ADP1653 flash 

Re: [PATCH v3 1/4] media: ov5695: add support for OV5695 sensor

[Sakari Ailus]

Hi Shunqian,

On Tue, Jan 09, 2018 at 10:52:30PM +0800, Shunqian Zheng wrote:
> Hi Sakari,
> 
> 
> On 2018年01月09日 06:20, Sakari Ailus wrote:
> > Hi Shunqian,
> > 
> > Could you next time add a cover page to the patchset that details the
> > changes from the previous version?
> > 
> > Please also add a MAINTAINERS entry. DT binding files should also precede
> > the driver.
> Done.
> By the way, why DT binding files should precede the driver?

DT bindings are independent of the driver but the driver depends on the
properties defined in the device's DT bindings.

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

Re: Re: dvb usb issues since kernel 4.9

[Eric Dumazet]

On Tue, Jan 9, 2018 at 10:58 AM, Linus Torvalds
 wrote:
> On Tue, Jan 9, 2018 at 9:57 AM, Eric Dumazet  wrote:
>>
>> Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate
>> handling', but TCP Small queues heavily use TASKLET,
>> so as far as I am concerned a revert would have the same effect.
>
> Does it actually?
>
> TCP ends up dropping packets outside of the window etc, so flooding a
> machine with TCP packets and causing some further processing up the
> stack sounds very different from the basic packet flooding thing that
> happens with NET_RX_SOFTIRQ.
>
> Also, honestly, the kinds of people who really worry about flooding
> tend to have packet filtering in the receive path etc.
>
> So I really think "you can use up 90% of CPU time with a UDP packet
> flood from the same network" is very very very different - and
> honestly not at all as important - as "you want to be able to use a
> USB DVB receiver and watch/record TV".
>
> Because that whole "UDP packet flood from the same network" really is
> something you _fundamentally_ have other mitigations for.
>
> I bet that whole commit was introduced because of a benchmark test,
> rather than real life. No?
>
> In contrast, now people are complaining about real loads not working.
>
>  Linus

I said that a revert was fine, maybe I was not clear.
Clearly we can not touch anything scheduler related without breaking
someone workload/assumptions on how system behaved at some point.

Your patch wont solve other workloads that might have been impacted by my patch,
so in one year (or next week), we will have to cope with another device driver
not using tasklet but still relying on immediate softirq processing.
Apparently, we have to live with softirq model forever, or switch to RT kernels.

Note that we have no mitigation for something that involve flood of
valid packets that no firewall can drop
(without dropping legitimate packets).
The 'benchmark' here is not really the trigger, only a tool validating
an idea/patch.

Re: dvb usb issues since kernel 4.9

[Jesper Dangaard Brouer]

On Tue, 9 Jan 2018 15:42:35 -0200 Mauro Carvalho Chehab 
 wrote:
> Em Mon, 8 Jan 2018 11:51:04 -0800 Linus Torvalds 
>  escreveu:
> 
[...]
> Patch makes sense to me, although I was not able to test it myself.
 
The patch also make sense to me.  I've done some basic testing with it
on my high-end Broadwell system (that I use for 100Gbit/s testing). As
expected the network overload case still works, as NET_RX_SOFTIRQ is
not matched. 

> I set a RPi3 machine here with vanilla Kernel 4.14.11 running a
> standard raspbian distribution (with elevator=deadline).

I found a Raspberry Pi Model B+ (I think, BCM2835), that I loaded the
LibreELEC distro on.  One of the guys even created an image for me with
a specific kernel[1] (that I just upgraded the system with).

[1] 
https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=77031#post77031
 
> My plan is to do more tests along this week, and try to tweak a little
> bit both userspace and kernelspace, in order to see if I can get
> better results.
 
I've previously experienced that you can be affected by the scheduler
granularity, which is adjustable (with CONFIG_SCHED_DEBUG=y):

 $ grep -H . /proc/sys/kernel/sched_*_granularity_ns
 /proc/sys/kernel/sched_min_granularity_ns:225
 /proc/sys/kernel/sched_wakeup_granularity_ns:300

The above numbers were confirmed on the RPi2 (see[2]). With commit
4cd13c21b207 ("softirq: Let ksoftirqd do its job"), I expect/assume that
softirq processing latency is bounded by the sched_wakeup_granularity_ns,
which with 3 ms is not good enough for their use-case.

Thus, if you manage to reproduce the case, try to see if adjusting this
can mitigate the issue...


Their system have non-preempt kernel, should they use PREEMPT?

 LibreELEC:~ # uname -a
 Linux LibreELEC 4.14.10 #1 SMP Tue Jan 9 17:35:03 GMT 2018 armv7l GNU/Linux

[2] 
https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=76999#post76999
-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

[Josh Poimboeuf]

On Tue, Jan 09, 2018 at 11:44:05AM -0800, Dan Williams wrote:
> On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina  wrote:
> > On Fri, 5 Jan 2018, Dan Williams wrote:
> >
> > [ ... snip ... ]
> >> Andi Kleen (1):
> >>   x86, barrier: stop speculation for failed access_ok
> >>
> >> Dan Williams (13):
> >>   x86: implement nospec_barrier()
> >>   [media] uvcvideo: prevent bounds-check bypass via speculative 
> >> execution
> >>   carl9170: prevent bounds-check bypass via speculative execution
> >>   p54: prevent bounds-check bypass via speculative execution
> >>   qla2xxx: prevent bounds-check bypass via speculative execution
> >>   cw1200: prevent bounds-check bypass via speculative execution
> >>   Thermal/int340x: prevent bounds-check bypass via speculative 
> >> execution
> >>   ipv6: prevent bounds-check bypass via speculative execution
> >>   ipv4: prevent bounds-check bypass via speculative execution
> >>   vfs, fdtable: prevent bounds-check bypass via speculative execution
> >>   net: mpls: prevent bounds-check bypass via speculative execution
> >>   udf: prevent bounds-check bypass via speculative execution
> >>   userns: prevent bounds-check bypass via speculative execution
> >>
> >> Mark Rutland (4):
> >>   asm-generic/barrier: add generic nospec helpers
> >>   Documentation: document nospec helpers
> >>   arm64: implement nospec_ptr()
> >>   arm: implement nospec_ptr()
> >
> > So considering the recent publication of [1], how come we all of a sudden
> > don't need the barriers in ___bpf_prog_run(), namely for LD_IMM_DW and
> > LDX_MEM_##SIZEOP, and something comparable for eBPF JIT?
> >
> > Is this going to be handled in eBPF in some other way?
> >
> > Without that in place, and considering Jann Horn's paper, it would seem
> > like PTI doesn't really lock it down fully, right?
> 
> Here is the latest (v3) bpf fix:
> 
> https://patchwork.ozlabs.org/patch/856645/
> 
> I currently have v2 on my 'nospec' branch and will move that to v3 for
> the next update, unless it goes upstream before then.

That patch seems specific to CONFIG_BPF_SYSCALL.  Is the bpf() syscall
the only attack vector?  Or are there other ways to run bpf programs
that we should be worried about?

-- 
Josh

Re: [PATCH 1/3] media/ttusb-budget: remove pci_zalloc_coherent abuse

[Joe Perches]

On Tue, 2018-01-09 at 21:39 +0100, Christoph Hellwig wrote:
> Switch to a plain kzalloc instea of pci_zalloc_coherent to allocate
> memory for the USB DMA.
[]
> diff --git a/drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c 
> b/drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c
[]
> @@ -792,21 +791,15 @@ static void ttusb_free_iso_urbs(struct ttusb *ttusb)
> []
>  static int ttusb_alloc_iso_urbs(struct ttusb *ttusb)
>  {
>   int i;
>  
> - ttusb->iso_buffer = pci_zalloc_consistent(NULL,
> -   ISO_FRAME_SIZE * 
> FRAMES_PER_ISO_BUF * ISO_BUF_COUNT,
> -   >iso_dma_handle);
> -
> + ttusb->iso_buffer = kzalloc(ISO_FRAME_SIZE * FRAMES_PER_ISO_BUF *
> + ISO_BUF_COUNT, GFP_KERNEL);
>   if (!ttusb->iso_buffer) {
>   dprintk("%s: pci_alloc_consistent - not enough memory\n",
>   __func__);

This message doesn't make sense anymore and it might as well
be deleted.

And it might be better to use kcalloc

ttusb->iso_buffer = kcalloc(FRAMES_PER_ISO_BUF * ISO_BUF_COUNT,
ISO_FRAME_SIZE, GFP_KERNEL);

[PATCH 2/3] media/ttusb-dev: remove pci_zalloc_coherent abuse

[Christoph Hellwig]

Switch to a plain kzalloc instea of pci_zalloc_coherent to allocate
memory for the USB DMA.

Signed-off-by: Christoph Hellwig 
---
 drivers/media/usb/ttusb-dec/ttusb_dec.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/media/usb/ttusb-dec/ttusb_dec.c 
b/drivers/media/usb/ttusb-dec/ttusb_dec.c
index cdefb5dfbbdc..794ea8a78181 100644
--- a/drivers/media/usb/ttusb-dec/ttusb_dec.c
+++ b/drivers/media/usb/ttusb-dec/ttusb_dec.c
@@ -127,7 +127,6 @@ struct ttusb_dec {
struct urb  *irq_urb;
dma_addr_t  irq_dma_handle;
void*iso_buffer;
-   dma_addr_t  iso_dma_handle;
struct urb  *iso_urb[ISO_BUF_COUNT];
int iso_stream_count;
struct mutexiso_mutex;
@@ -1185,11 +1184,7 @@ static void ttusb_dec_free_iso_urbs(struct ttusb_dec 
*dec)
 
for (i = 0; i < ISO_BUF_COUNT; i++)
usb_free_urb(dec->iso_urb[i]);
-
-   pci_free_consistent(NULL,
-   ISO_FRAME_SIZE * (FRAMES_PER_ISO_BUF *
- ISO_BUF_COUNT),
-   dec->iso_buffer, dec->iso_dma_handle);
+   kfree(dec->iso_buffer);
 }
 
 static int ttusb_dec_alloc_iso_urbs(struct ttusb_dec *dec)
@@ -1198,10 +1193,8 @@ static int ttusb_dec_alloc_iso_urbs(struct ttusb_dec 
*dec)
 
dprintk("%s\n", __func__);
 
-   dec->iso_buffer = pci_zalloc_consistent(NULL,
-   ISO_FRAME_SIZE * 
(FRAMES_PER_ISO_BUF * ISO_BUF_COUNT),
-   >iso_dma_handle);
-
+   dec->iso_buffer = kzalloc(ISO_FRAME_SIZE *
+   (FRAMES_PER_ISO_BUF * ISO_BUF_COUNT), GFP_KERNEL);
if (!dec->iso_buffer) {
dprintk("%s: pci_alloc_consistent - not enough memory\n",
__func__);
-- 
2.14.2

[PATCH 1/3] media/ttusb-budget: remove pci_zalloc_coherent abuse

[Christoph Hellwig]

Switch to a plain kzalloc instea of pci_zalloc_coherent to allocate
memory for the USB DMA.

Signed-off-by: Christoph Hellwig 
---
 drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c 
b/drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c
index a142b9dc0feb..b8619fb23351 100644
--- a/drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c
+++ b/drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c
@@ -102,7 +102,6 @@ struct ttusb {
unsigned int isoc_in_pipe;
 
void *iso_buffer;
-   dma_addr_t iso_dma_handle;
 
struct urb *iso_urb[ISO_BUF_COUNT];
 
@@ -792,21 +791,15 @@ static void ttusb_free_iso_urbs(struct ttusb *ttusb)
 
for (i = 0; i < ISO_BUF_COUNT; i++)
usb_free_urb(ttusb->iso_urb[i]);
-
-   pci_free_consistent(NULL,
-   ISO_FRAME_SIZE * FRAMES_PER_ISO_BUF *
-   ISO_BUF_COUNT, ttusb->iso_buffer,
-   ttusb->iso_dma_handle);
+   kfree(ttusb->iso_buffer);
 }
 
 static int ttusb_alloc_iso_urbs(struct ttusb *ttusb)
 {
int i;
 
-   ttusb->iso_buffer = pci_zalloc_consistent(NULL,
- ISO_FRAME_SIZE * 
FRAMES_PER_ISO_BUF * ISO_BUF_COUNT,
- >iso_dma_handle);
-
+   ttusb->iso_buffer = kzalloc(ISO_FRAME_SIZE * FRAMES_PER_ISO_BUF *
+   ISO_BUF_COUNT, GFP_KERNEL);
if (!ttusb->iso_buffer) {
dprintk("%s: pci_alloc_consistent - not enough memory\n",
__func__);
-- 
2.14.2

[PATCH 3/3] pci-dma-compat: remove handling of NULL pdev arguments

[Christoph Hellwig]

Historically some ISA drivers used the old pci DMA API with a NULL pdev
argument, but these days this isn't used and not too useful due to the
per-device DMA ops, so remove it.

Signed-off-by: Christoph Hellwig 
---
 include/linux/pci-dma-compat.h | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/include/linux/pci-dma-compat.h b/include/linux/pci-dma-compat.h
index d1f9fdade1e0..0dd1a3f7b309 100644
--- a/include/linux/pci-dma-compat.h
+++ b/include/linux/pci-dma-compat.h
@@ -17,91 +17,90 @@ static inline void *
 pci_alloc_consistent(struct pci_dev *hwdev, size_t size,
 dma_addr_t *dma_handle)
 {
-   return dma_alloc_coherent(hwdev == NULL ? NULL : >dev, size, 
dma_handle, GFP_ATOMIC);
+   return dma_alloc_coherent(>dev, size, dma_handle, GFP_ATOMIC);
 }
 
 static inline void *
 pci_zalloc_consistent(struct pci_dev *hwdev, size_t size,
  dma_addr_t *dma_handle)
 {
-   return dma_zalloc_coherent(hwdev == NULL ? NULL : >dev,
-  size, dma_handle, GFP_ATOMIC);
+   return dma_zalloc_coherent(>dev, size, dma_handle, GFP_ATOMIC);
 }
 
 static inline void
 pci_free_consistent(struct pci_dev *hwdev, size_t size,
void *vaddr, dma_addr_t dma_handle)
 {
-   dma_free_coherent(hwdev == NULL ? NULL : >dev, size, vaddr, 
dma_handle);
+   dma_free_coherent(>dev, size, vaddr, dma_handle);
 }
 
 static inline dma_addr_t
 pci_map_single(struct pci_dev *hwdev, void *ptr, size_t size, int direction)
 {
-   return dma_map_single(hwdev == NULL ? NULL : >dev, ptr, size, 
(enum dma_data_direction)direction);
+   return dma_map_single(>dev, ptr, size, (enum 
dma_data_direction)direction);
 }
 
 static inline void
 pci_unmap_single(struct pci_dev *hwdev, dma_addr_t dma_addr,
 size_t size, int direction)
 {
-   dma_unmap_single(hwdev == NULL ? NULL : >dev, dma_addr, size, 
(enum dma_data_direction)direction);
+   dma_unmap_single(>dev, dma_addr, size, (enum 
dma_data_direction)direction);
 }
 
 static inline dma_addr_t
 pci_map_page(struct pci_dev *hwdev, struct page *page,
 unsigned long offset, size_t size, int direction)
 {
-   return dma_map_page(hwdev == NULL ? NULL : >dev, page, offset, 
size, (enum dma_data_direction)direction);
+   return dma_map_page(>dev, page, offset, size, (enum 
dma_data_direction)direction);
 }
 
 static inline void
 pci_unmap_page(struct pci_dev *hwdev, dma_addr_t dma_address,
   size_t size, int direction)
 {
-   dma_unmap_page(hwdev == NULL ? NULL : >dev, dma_address, size, 
(enum dma_data_direction)direction);
+   dma_unmap_page(>dev, dma_address, size, (enum 
dma_data_direction)direction);
 }
 
 static inline int
 pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg,
   int nents, int direction)
 {
-   return dma_map_sg(hwdev == NULL ? NULL : >dev, sg, nents, (enum 
dma_data_direction)direction);
+   return dma_map_sg(>dev, sg, nents, (enum 
dma_data_direction)direction);
 }
 
 static inline void
 pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg,
 int nents, int direction)
 {
-   dma_unmap_sg(hwdev == NULL ? NULL : >dev, sg, nents, (enum 
dma_data_direction)direction);
+   dma_unmap_sg(>dev, sg, nents, (enum 
dma_data_direction)direction);
 }
 
 static inline void
 pci_dma_sync_single_for_cpu(struct pci_dev *hwdev, dma_addr_t dma_handle,
size_t size, int direction)
 {
-   dma_sync_single_for_cpu(hwdev == NULL ? NULL : >dev, dma_handle, 
size, (enum dma_data_direction)direction);
+   dma_sync_single_for_cpu(>dev, dma_handle, size, (enum 
dma_data_direction)direction);
 }
 
 static inline void
 pci_dma_sync_single_for_device(struct pci_dev *hwdev, dma_addr_t dma_handle,
size_t size, int direction)
 {
-   dma_sync_single_for_device(hwdev == NULL ? NULL : >dev, 
dma_handle, size, (enum dma_data_direction)direction);
+   dma_sync_single_for_device(>dev, dma_handle, size, (enum 
dma_data_direction)direction);
 }
 
 static inline void
 pci_dma_sync_sg_for_cpu(struct pci_dev *hwdev, struct scatterlist *sg,
int nelems, int direction)
 {
-   dma_sync_sg_for_cpu(hwdev == NULL ? NULL : >dev, sg, nelems, 
(enum dma_data_direction)direction);
+   dma_sync_sg_for_cpu(>dev, sg, nelems, (enum 
dma_data_direction)direction);
 }
 
 static inline void
 pci_dma_sync_sg_for_device(struct pci_dev *hwdev, struct scatterlist *sg,
int nelems, int direction)
 {
-   dma_sync_sg_for_device(hwdev == NULL ? NULL : >dev, sg, nelems, 
(enum dma_data_direction)direction);
+   dma_sync_sg_for_device(>dev, sg, nelems, (enum 
dma_data_direction)direction);
 }
 
 static inline int
-- 
2.14.2

remove pci_dma_* abuses and workarounds

[Christoph Hellwig]

Back before the dawn of time pci_dma_* with a NULL pci_dev argument
was used for all kinds of things, e.g. dma mapping for non-PCI
devices.  All this has been long removed, but it turns out we
still care for a NULL pci_dev in the wrappers, and we still have
two odd USB drivers that use pci_dma_alloc_consistent for allocating
memory while ignoring the dma_addr_t entirely.

This series switches the two drivers to use plain kzalloc and then
removes the handling of the NULL pci_dev in the pci_dma_* wrappers.

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

[Jiri Kosina]

On Fri, 5 Jan 2018, Dan Williams wrote:

[ ... snip ... ]
> Andi Kleen (1):
>   x86, barrier: stop speculation for failed access_ok
> 
> Dan Williams (13):
>   x86: implement nospec_barrier()
>   [media] uvcvideo: prevent bounds-check bypass via speculative execution
>   carl9170: prevent bounds-check bypass via speculative execution
>   p54: prevent bounds-check bypass via speculative execution
>   qla2xxx: prevent bounds-check bypass via speculative execution
>   cw1200: prevent bounds-check bypass via speculative execution
>   Thermal/int340x: prevent bounds-check bypass via speculative execution
>   ipv6: prevent bounds-check bypass via speculative execution
>   ipv4: prevent bounds-check bypass via speculative execution
>   vfs, fdtable: prevent bounds-check bypass via speculative execution
>   net: mpls: prevent bounds-check bypass via speculative execution
>   udf: prevent bounds-check bypass via speculative execution
>   userns: prevent bounds-check bypass via speculative execution
> 
> Mark Rutland (4):
>   asm-generic/barrier: add generic nospec helpers
>   Documentation: document nospec helpers
>   arm64: implement nospec_ptr()
>   arm: implement nospec_ptr()

So considering the recent publication of [1], how come we all of a sudden 
don't need the barriers in ___bpf_prog_run(), namely for LD_IMM_DW and 
LDX_MEM_##SIZEOP, and something comparable for eBPF JIT?

Is this going to be handled in eBPF in some other way?

Without that in place, and considering Jann Horn's paper, it would seem 
like PTI doesn't really lock it down fully, right?

[1] https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=287305

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

[Dan Williams]

On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina  wrote:
> On Fri, 5 Jan 2018, Dan Williams wrote:
>
> [ ... snip ... ]
>> Andi Kleen (1):
>>   x86, barrier: stop speculation for failed access_ok
>>
>> Dan Williams (13):
>>   x86: implement nospec_barrier()
>>   [media] uvcvideo: prevent bounds-check bypass via speculative execution
>>   carl9170: prevent bounds-check bypass via speculative execution
>>   p54: prevent bounds-check bypass via speculative execution
>>   qla2xxx: prevent bounds-check bypass via speculative execution
>>   cw1200: prevent bounds-check bypass via speculative execution
>>   Thermal/int340x: prevent bounds-check bypass via speculative execution
>>   ipv6: prevent bounds-check bypass via speculative execution
>>   ipv4: prevent bounds-check bypass via speculative execution
>>   vfs, fdtable: prevent bounds-check bypass via speculative execution
>>   net: mpls: prevent bounds-check bypass via speculative execution
>>   udf: prevent bounds-check bypass via speculative execution
>>   userns: prevent bounds-check bypass via speculative execution
>>
>> Mark Rutland (4):
>>   asm-generic/barrier: add generic nospec helpers
>>   Documentation: document nospec helpers
>>   arm64: implement nospec_ptr()
>>   arm: implement nospec_ptr()
>
> So considering the recent publication of [1], how come we all of a sudden
> don't need the barriers in ___bpf_prog_run(), namely for LD_IMM_DW and
> LDX_MEM_##SIZEOP, and something comparable for eBPF JIT?
>
> Is this going to be handled in eBPF in some other way?
>
> Without that in place, and considering Jann Horn's paper, it would seem
> like PTI doesn't really lock it down fully, right?

Here is the latest (v3) bpf fix:

https://patchwork.ozlabs.org/patch/856645/

I currently have v2 on my 'nospec' branch and will move that to v3 for
the next update, unless it goes upstream before then.

Re: Re: dvb usb issues since kernel 4.9

[Linus Torvalds]

On Tue, Jan 9, 2018 at 9:57 AM, Eric Dumazet  wrote:
>
> Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate
> handling', but TCP Small queues heavily use TASKLET,
> so as far as I am concerned a revert would have the same effect.

Does it actually?

TCP ends up dropping packets outside of the window etc, so flooding a
machine with TCP packets and causing some further processing up the
stack sounds very different from the basic packet flooding thing that
happens with NET_RX_SOFTIRQ.

Also, honestly, the kinds of people who really worry about flooding
tend to have packet filtering in the receive path etc.

So I really think "you can use up 90% of CPU time with a UDP packet
flood from the same network" is very very very different - and
honestly not at all as important - as "you want to be able to use a
USB DVB receiver and watch/record TV".

Because that whole "UDP packet flood from the same network" really is
something you _fundamentally_ have other mitigations for.

I bet that whole commit was introduced because of a benchmark test,
rather than real life. No?

In contrast, now people are complaining about real loads not working.

 Linus

Re: [PATCH v5 0/5] Add OV5640 parallel interface and RGB565/YUYV support

[Maxime Ripard]

Hi Hugues,

On Mon, Jan 08, 2018 at 05:13:39PM +, Hugues FRUCHET wrote:
> I'm using a ST board with OV5640 wired in parallel bus output in order 
> to interface to my STM32 DCMI parallel interface.
> Perhaps could you describe your setup so I could help on understanding 
> the problem on your side. From my past experience with this sensor 
> module, you can first check hsync/vsync polarities, the datasheet is 
> buggy on VSYNC polarity as documented in patch 4/5.

I'm testing using the driver, using a parallel interface:
https://patchwork.kernel.org/patch/10129463/

The bus is 8-bits wide, and like I was saying, we had a separate
driver for the ov5640 that is working fine with that driver, so the
hardware setup works, and the capture driver should be mostly ok too.

By dumping the registers, I've seen some differences on the clock
setup, I'll try to hack something tomorrow and let you know :)

Thanks!
Maxime

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


signature.asc
Description: PGP signature

Re: Re: dvb usb issues since kernel 4.9

[Eric Dumazet]

On Tue, Jan 9, 2018 at 9:48 AM, Linus Torvalds
 wrote:
> On Tue, Jan 9, 2018 at 9:27 AM, Eric Dumazet  wrote:
>>
>> So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has
>> shown up multiple times in various 'regressions'
>> simply because it could surface the problem more often.
>> But even if you revert it, you can still make the faulty
>> driver/subsystem misbehave by adding more stress to the cpu handling
>> the IRQ.
>
> ..but that's always true. People sometimes live on the edge - often by
> design (ie hardware has been designed/selected to be the crappiest
> possible that still work).
>
> That doesn't change anything. A patch that takes "bad things can
> happen" to "bad things DO happen" is a bad patch.

I was expecting that people could get a chance to fix the root cause,
instead of trying to keep status quo.

Strangely, it took 18 months for someone to complain enough and
'bisect to this commit'

Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate
handling', but TCP Small queues heavily use TASKLET,
so as far as I am concerned a revert would have the same effect.

Re: dvb usb issues since kernel 4.9

[Linus Torvalds]

On Tue, Jan 9, 2018 at 9:42 AM, Mauro Carvalho Chehab
 wrote:
>
> On my preliminar tests, writing to a file on an ext4 partition at a
> USB stick loses data up to the point to make it useless (1/4 of the data
> is lost!). However, writing to a class 10 microSD card is doable.

Note that most USB sticks are horrible crap. They can have write
latencies counted in _seconds_.

You can cause VM issues and various other non-hardware stalls with
them, simply because something gets stuck waiting for a page writeout
that should take a few ms on any reasonable hardware, but ends up
talking half a second or more.

For example, even really well-written software that tries to do things
like threaded write-behind to smooth out the IO will be _totally_
screwed by the USB stick behavior (where you might write a few MB at
high speeds, and then the next write - however small - takes a second
because the stupid USB stick does a synchronous garbage collection.
Suddenly all that clever software that tried to keep things moving
along smoothly without any hiccups, and tried hard to make the USB bus
have a nice constant loadm can't do anything at all about the crap
hardware.

So when testing writes to USB sticks, I'm not convinced you're
actually testing any USB bus limitations or even really any other
hardware limitations than the USB stick itself.

  Linus

Re: Re: dvb usb issues since kernel 4.9

[Linus Torvalds]

On Tue, Jan 9, 2018 at 9:27 AM, Eric Dumazet  wrote:
>
> So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has
> shown up multiple times in various 'regressions'
> simply because it could surface the problem more often.
> But even if you revert it, you can still make the faulty
> driver/subsystem misbehave by adding more stress to the cpu handling
> the IRQ.

..but that's always true. People sometimes live on the edge - often by
design (ie hardware has been designed/selected to be the crappiest
possible that still work).

That doesn't change anything. A patch that takes "bad things can
happen" to "bad things DO happen" is a bad patch.

> Maybe the answer is to tune the kernel for small latencies at the
> price of small throughput (situation before the patch)

Generally we always want to tune for latency. Throughput is "easy",
but almost never interesting.

Sure, people do batch jobs. And yes, people often _benchmark_
throughput, because it's easy to benchmark. It's much harder to
benchmark latency, even when it's often much more important.

A prime example is the SSD benchmarks in the last few years - they
improved _dramatically_ when people noticed that the real problem was
latency, not the idiotic maximum big-block bandwidth numbers that have
almost zero impact on most people.

Put another way: we already have a very strong implicit bias towards
bandwidth just because it's easier to see and measure.

That means that we generally should strive to have a explicit bias
towards optimizing for latency when that choice comes up.  Just to
balance things out (and just to not take the easy way out: bandwidth
can often be improved by adding more layers of buffering and bigger
buffers, and that often ends up really hurting latency).

> 1) Revert the patch

Well, we can revert it only partially - limiting it to just networking
for example.

Just saying "act the way you used to for tasklets" already seems to
have fixed the issue in DVB.

> 2) get rid of ksoftirqd since it adds unexpected latencies.

We can't get rid of it entirely, since the synchronous softirq code
can cause problems too. It's why we have that "maximum of ten
synchronous events" in __do_softirq().

And we don't *want* to get rid of it.

We've _always_ had that small-scale "at some point we can't do it
synchronously any more".

That is a small-scale "don't have horrible latency for _other_ things"
protection. So it's about latency too, it's just about protecting
latency of the rest of the system.

The problem with commit 4cd13c21b207 is that it turns the small-scale
latency issues in softirq handling (they get larger latencies for lots
of hardware interrupts or even from non-preemptible kernel code) into
the _huge_ scale latency of scheduling, and does so in a racy way too.

> 3) Let applications that expect to have high throughput make sure to
> pin their threads on cpus that are not processing IRQ.
> (And make sure to not use irqbalance, and setup IRQ cpu affinities)

The only people that really deal in "thoughput only" tend to be the
HPC people, and they already do things like this.

(The other end of the spectrum is the realtime people that have
extreme latency requirements, who do things like that for the reverse
reason: keeping one or more CPU's reserved for the particular
low-latency realtime job).

   Linus

Re: dvb usb issues since kernel 4.9

[Mauro Carvalho Chehab]

Em Mon, 8 Jan 2018 11:51:04 -0800
Linus Torvalds  escreveu:

> On Mon, Jan 8, 2018 at 11:15 AM, Alan Stern  wrote:
> >
> > Both dwc2_hsotg and ehci-hcd use the tasklets embedded in the
> > giveback_urb_bh member of struct usb_hcd.  See usb_hcd_giveback_urb()
> > in drivers/usb/core/hcd.c; the calls are
> >
> > else if (high_prio_bh)
> > tasklet_hi_schedule(>bh);
> > else
> > tasklet_schedule(>bh);
> >
> > As it turns out, high_prio_bh gets set for interrupt and isochronous
> > URBs but not for bulk and control URBs.  The DVB driver in question
> > uses bulk transfers.  
> 
> Ok, so we could try out something like the appended?
> 
> NOTE! I have not tested this at all. It LooksObvious(tm), but...
> 
> Linus



>  kernel/softirq.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/softirq.c b/kernel/softirq.c
> index 2f5e87f1bae2..97b080956fea 100644
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
> @@ -79,12 +79,16 @@ static void wakeup_softirqd(void)
>  
>  /*
>   * If ksoftirqd is scheduled, we do not want to process pending softirqs
> - * right now. Let ksoftirqd handle this at its own rate, to get fairness.
> + * right now. Let ksoftirqd handle this at its own rate, to get fairness,
> + * unless we're doing some of the synchronous softirqs.
>   */
> -static bool ksoftirqd_running(void)
> +#define SOFTIRQ_NOW_MASK ((1 << HI_SOFTIRQ) | (1 << TASKLET_SOFTIRQ))
> +static bool ksoftirqd_running(unsigned long pending)
>  {
>   struct task_struct *tsk = __this_cpu_read(ksoftirqd);
>  
> + if (pending & SOFTIRQ_NOW_MASK)
> + return false;
>   return tsk && (tsk->state == TASK_RUNNING);
>  }
>  
> @@ -325,7 +329,7 @@ asmlinkage __visible void do_softirq(void)
>  
>   pending = local_softirq_pending();
>  
> - if (pending && !ksoftirqd_running())
> + if (pending && !ksoftirqd_running(pending))
>   do_softirq_own_stack();
>  
>   local_irq_restore(flags);
> @@ -352,7 +356,7 @@ void irq_enter(void)
>  
>  static inline void invoke_softirq(void)
>  {
> - if (ksoftirqd_running())
> + if (ksoftirqd_running(local_softirq_pending()))
>   return;
>  
>   if (!force_irqthreads) {


Hi Linus,

Patch makes sense to me, although I was not able to test it myself.

I set a RPi3 machine here with vanilla Kernel 4.14.11 running a standard
raspbian distribution (with elevator=deadline). Right now, I'm trying to
reproduce the bug with dvbv5-zap. I may eventually do more tests on 
some other slow machines.

Usually, applications like tvheadend records just one channel. So, instead
of a ~58 Mbits/s payload, it uses, typically, ~11 Mbits/s for a HD channel.
This is usually filtered by hardware. Here, I'm forcing to record the
entire TS, in order to make easier to reproduce the issue. So, I'm forcing
a condition that it is usually worse than real usecases (at last for HD - I
I don't have any DVB stream here with a 4K channel).

>From what I checked so far, with vanila upstream Kernel on RPi3, just
receiving a DVB stream - or receiving it and writing to /dev/null works
with or without your patch.

The problem starts to happen when there are concurrency with writes.

On my preliminar tests, writing to a file on an ext4 partition at a
USB stick loses data up to the point to make it useless (1/4 of the data
is lost!). However, writing to a class 10 microSD card is doable.

If you're curious enough, this is what I'm doing (that are the results
while using class 10 microSD card):

$ FILE=/tmp/out.ts; for i in $(seq 1 6); do echo "step $i"; rm $FILE 
2>/dev/null; dvbv5-zap -l universal -c ~/vivo-channels.conf NBR -o $FILE -P 
-t60 2>&1|grep -E "(buffer|received)"; du $FILE 2>/dev/null; done 
step 1
  Setting buffer length to 725
buffer overrun
buffer overrun
buffer overrun
buffer overrun
buffer overrun
buffer overrun
buffer overrun
received 347504652 bytes (5656 Kbytes/sec)
339368  /tmp/out.ts
step 2
  Setting buffer length to 725
buffer overrun
received 408995880 bytes (6656 Kbytes/sec)
399416  /tmp/out.ts
step 3
  Setting buffer length to 725
received 412999716 bytes (6722 Kbytes/sec)
403328  /tmp/out.ts
step 4
  Setting buffer length to 725
buffer overrun
received 415564788 bytes (6763 Kbytes/sec)
405832  /tmp/out.ts
step 5
  Setting buffer length to 725
received 412999716 bytes (6722 Kbytes/sec)
403324  /tmp/out.ts
step 6
  Setting buffer length to 725
received 408366080 bytes (6646 Kbytes/sec)
398796  /tmp/out.ts

My plan is to do more tests along this week, and try to tweak a little
bit both userspace and kernelspace, in order to see if I can get better
results.

Thanks,
Mauro

Re: Re: dvb usb issues since kernel 4.9

[Eric Dumazet]

On Tue, Jan 9, 2018 at 8:51 AM, Josef Griebichler
 wrote:
> Hi Linus,
>
> your patch works very good for me and others (please see 
> https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=77006#post77006).
>  No errors in recordings any more.
> The patch was also tested on x86_64 (Revo 3700) with positive effect.
> I agree with the forum poster, that there's still an issue when recording and 
> watching livetv at same time. I also get audio dropouts and audio is out of 
> sync.
> According to user smp kernel 4.9.73 with your patch on rpi and according to 
> user jahutchi kernel 4.11.12 on x86_64 have no such issues.
> I don't know if this dropouts are related to this topic.
>
> If of any help I could provide perf output on raspberry with libreelec and 
> tvheadend.
>

Sorry to come late to the party.

It seems problem comes from some piece of hardware/driver having some
precise timing prereq, and opportunistic use of softirq/tasklet
(instead maybe of hard irq handlers )

While it is true that softirq might do the job in most cases, we
already have cases where this can be easily defeated,
say if one cpu has suddenly to handle multiple sources of interrupts
for various devices.
NET_RX can easily lock the cpu for 10ms (on HZ=100 builds)

So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has
shown up multiple times in various 'regressions'
simply because it could surface the problem more often.
But even if you revert it, you can still make the faulty
driver/subsystem misbehave by adding more stress to the cpu handling
the IRQ.

Note that networking lacks fine control of its softirq processing.
Some people found/complained that relying more on ksoftirqd was
potentially adding tail latencies.

Maybe the answer is to tune the kernel for small latencies at the
price of small throughput (situation before the patch)

1) Revert the patch
2) get rid of ksoftirqd since it adds unexpected latencies.
3) Let applications that expect to have high throughput make sure to
pin their threads on cpus that are not processing IRQ.
(And make sure to not use irqbalance, and setup IRQ cpu affinities)

Re: [PATCH v4 2/5] media: ov5695: add support for OV5695 sensor

[Baruch Siach]

Hi Shunqian Zheng,

On Tue, Jan 09, 2018 at 10:48:21PM +0800, Shunqian Zheng wrote:
> +static int ov5695_write_array(struct i2c_client *client,
> +   const struct regval *regs)
> +{
> + u32 i;
> + int ret = 0;
> +
> + for (i = 0; ret == 0 && regs[i].addr != REG_NULL; i++)
> + ret = ov5695_write_reg(client, regs[i].addr,
> +OV5695_REG_VALUE_08BIT, regs[i].val);

This loop should stop on first failure, and return the error value. With 
current code a register write failure is masked by following writes.

> +
> + return ret;
> +}

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Aw: Re: dvb usb issues since kernel 4.9

[Josef Griebichler]

Hi Linus,

your patch works very good for me and others (please see 
https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=77006#post77006).
 No errors in recordings any more.
The patch was also tested on x86_64 (Revo 3700) with positive effect.
I agree with the forum poster, that there's still an issue when recording and 
watching livetv at same time. I also get audio dropouts and audio is out of 
sync.
According to user smp kernel 4.9.73 with your patch on rpi and according to 
user jahutchi kernel 4.11.12 on x86_64 have no such issues.
I don't know if this dropouts are related to this topic.

If of any help I could provide perf output on raspberry with libreelec and 
tvheadend.

Regards,
Josef 
 

Gesendet: Montag, 08. Januar 2018 um 23:16 Uhr
Von: "Jesper Dangaard Brouer" 
An: "Peter Zijlstra" 
Cc: "Josef Griebichler" , "Mauro Carvalho Chehab" 
, "Alan Stern" , "Greg 
Kroah-Hartman" , linux-...@vger.kernel.org, "Eric 
Dumazet" , "Rik van Riel" , "Paolo Abeni" 
, "Hannes Frederic Sowa" , linux-kernel 
, netdev , "Jonathan 
Corbet" , LMML , "David Miller" 
, torva...@linux-foundation.org
Betreff: Re: dvb usb issues since kernel 4.9
On Mon, 8 Jan 2018 22:44:27 +0100
Peter Zijlstra  wrote:

> On Mon, Jan 08, 2018 at 10:31:09PM +0100, Jesper Dangaard Brouer wrote:
> > I did expected the issue to get worse, when you load the Pi with
> > network traffic, as now the softirq time-budget have to be shared
> > between networking and USB/DVB. Thus, I guess you are running TCP and
> > USB/mpeg2ts on the same CPU (why when you have 4 CPUs?...)
>
> Isn't networking also over USB on the Pi ?

Darn, that is true. Looking at the dmesg output in http://ix.io/DOg:

[ 0.405942] usbcore: registered new interface driver smsc95xx
[ 5.821104] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1

I don't know enough about USB... is it possible to control which CPU
handles the individual USB ports, or on some other level (than ports)?

--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer[http://www.linkedin.com/in/brouer]

[PATCH v2 2/2] cx231xx: Add support for Hauppauge HVR-975

[Brad Love]

Hauppauge HVR-975 is hybrid NTSC/PAL, QAM/ATSC, and DVB-C/T/T2 usb device.

Only ATSC/QAM front end is initially active. Second frontend support is
work in progress.

CX23102 + LG3306A/Si2168(WiP) + Si2157

Changes since v1:
- removed double semicolon


Signed-off-by: Brad Love 
---
 drivers/media/usb/cx231xx/cx231xx-cards.c | 42 ++
 drivers/media/usb/cx231xx/cx231xx-dvb.c   | 74 +++
 drivers/media/usb/cx231xx/cx231xx.h   |  1 +
 3 files changed, 117 insertions(+)

diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c 
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index c2efbff..8582568 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -961,6 +961,45 @@ struct cx231xx_board cx231xx_boards[] = {
.gpio = NULL,
} },
},
+   [CX231XX_BOARD_HAUPPAUGE_975] = {
+   .name = "Hauppauge WinTV-HVR-975",
+   .tuner_type = TUNER_ABSENT,
+   .tuner_addr = 0x60,
+   .tuner_gpio = RDE250_XCV_TUNER,
+   .tuner_sif_gpio = 0x05,
+   .tuner_scl_gpio = 0x1a,
+   .tuner_sda_gpio = 0x1b,
+   .decoder = CX231XX_AVDECODER,
+   .output_mode = OUT_MODE_VIP11,
+   .demod_xfer_mode = 0,
+   .ctl_pin_status_mask = 0xFFC4,
+   .agc_analog_digital_select_gpio = 0x0c,
+   .gpio_pin_status_mask = 0x4001000,
+   .tuner_i2c_master = I2C_1_MUX_3,
+   .demod_i2c_master = I2C_1_MUX_3,
+   .has_dvb = 1,
+   .demod_addr = 0x59, /* 0xb2 >> 1 */
+   .norm = V4L2_STD_ALL,
+
+   .input = {{
+   .type = CX231XX_VMUX_TELEVISION,
+   .vmux = CX231XX_VIN_3_1,
+   .amux = CX231XX_AMUX_VIDEO,
+   .gpio = NULL,
+   }, {
+   .type = CX231XX_VMUX_COMPOSITE1,
+   .vmux = CX231XX_VIN_2_1,
+   .amux = CX231XX_AMUX_LINE_IN,
+   .gpio = NULL,
+   }, {
+   .type = CX231XX_VMUX_SVIDEO,
+   .vmux = CX231XX_VIN_1_1 |
+   (CX231XX_VIN_1_2 << 8) |
+   CX25840_SVIDEO_ON,
+   .amux = CX231XX_AMUX_LINE_IN,
+   .gpio = NULL,
+   } },
+   },
 };
 const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
 
@@ -994,6 +1033,8 @@ struct usb_device_id cx231xx_id_table[] = {
 .driver_info = CX231XX_BOARD_HAUPPAUGE_955Q},
{USB_DEVICE(0x2040, 0xb151),
 .driver_info = CX231XX_BOARD_HAUPPAUGE_935C},
+   {USB_DEVICE(0x2040, 0xb150),
+.driver_info = CX231XX_BOARD_HAUPPAUGE_975},
{USB_DEVICE(0x2040, 0xb130),
 .driver_info = CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx},
{USB_DEVICE(0x2040, 0xb131),
@@ -1253,6 +1294,7 @@ void cx231xx_card_setup(struct cx231xx *dev)
case CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx:
case CX231XX_BOARD_HAUPPAUGE_955Q:
case CX231XX_BOARD_HAUPPAUGE_935C:
+   case CX231XX_BOARD_HAUPPAUGE_975:
{
struct eeprom {
struct tveeprom tvee;
diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index 2e6bb09..cb8e90a 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -1143,6 +1143,80 @@ static int dvb_init(struct cx231xx *dev)
dev->dvb->i2c_client_tuner = client;
break;
}
+   case CX231XX_BOARD_HAUPPAUGE_975:
+   {
+   struct i2c_client *client;
+   struct i2c_adapter *adapter;
+   struct i2c_board_info info = {};
+   struct si2157_config si2157_config = {};
+   struct lgdt3306a_config lgdt3306a_config = {};
+
+   /* attach demodulator chip */
+   lgdt3306a_config = hauppauge_955q_lgdt3306a_config;
+   lgdt3306a_config.fe = >dvb->frontend;
+   lgdt3306a_config.i2c_adapter = 
+
+   strlcpy(info.type, "lgdt3306a", sizeof(info.type));
+   info.addr = dev->board.demod_addr;
+   info.platform_data = _config;
+
+   request_module(info.type);
+   client = i2c_new_device(demod_i2c, );
+   if (client == NULL || client->dev.driver == NULL) {
+   result = -ENODEV;
+   goto out_free;
+   }
+
+   if (!try_module_get(client->dev.driver->owner)) {
+   dev_err(dev->dev,
+   "Failed to attach %s frontend.\n", info.type);
+   i2c_unregister_device(client);
+

[PATCH 1/2] cx231xx: Add support for Hauppauge HVR-935C

[Brad Love]

HVR-935C is hybrid PAL, DVB-C/T/T2 usb device.

CX23102 + Si2168 + Si2157

Signed-off-by: Brad Love 
---
 drivers/media/usb/cx231xx/cx231xx-cards.c | 42 +
 drivers/media/usb/cx231xx/cx231xx-dvb.c   | 75 +++
 drivers/media/usb/cx231xx/cx231xx.h   |  1 +
 3 files changed, 118 insertions(+)

diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c 
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index f9ec7fe..c2efbff 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -922,6 +922,45 @@ struct cx231xx_board cx231xx_boards[] = {
.gpio = NULL,
} },
},
+   [CX231XX_BOARD_HAUPPAUGE_935C] = {
+   .name = "Hauppauge WinTV-HVR-935C",
+   .tuner_type = TUNER_ABSENT,
+   .tuner_addr = 0x60,
+   .tuner_gpio = RDE250_XCV_TUNER,
+   .tuner_sif_gpio = 0x05,
+   .tuner_scl_gpio = 0x1a,
+   .tuner_sda_gpio = 0x1b,
+   .decoder = CX231XX_AVDECODER,
+   .output_mode = OUT_MODE_VIP11,
+   .demod_xfer_mode = 0,
+   .ctl_pin_status_mask = 0xFFC4,
+   .agc_analog_digital_select_gpio = 0x0c,
+   .gpio_pin_status_mask = 0x4001000,
+   .tuner_i2c_master = I2C_1_MUX_3,
+   .demod_i2c_master = I2C_1_MUX_3,
+   .has_dvb = 1,
+   .demod_addr = 0x64, /* 0xc8 >> 1 */
+   .norm = V4L2_STD_PAL,
+
+   .input = {{
+   .type = CX231XX_VMUX_TELEVISION,
+   .vmux = CX231XX_VIN_3_1,
+   .amux = CX231XX_AMUX_VIDEO,
+   .gpio = NULL,
+   }, {
+   .type = CX231XX_VMUX_COMPOSITE1,
+   .vmux = CX231XX_VIN_2_1,
+   .amux = CX231XX_AMUX_LINE_IN,
+   .gpio = NULL,
+   }, {
+   .type = CX231XX_VMUX_SVIDEO,
+   .vmux = CX231XX_VIN_1_1 |
+   (CX231XX_VIN_1_2 << 8) |
+   CX25840_SVIDEO_ON,
+   .amux = CX231XX_AMUX_LINE_IN,
+   .gpio = NULL,
+   } },
+   },
 };
 const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
 
@@ -953,6 +992,8 @@ struct usb_device_id cx231xx_id_table[] = {
 .driver_info = CX231XX_BOARD_HAUPPAUGE_EXETER},
{USB_DEVICE(0x2040, 0xb123),
 .driver_info = CX231XX_BOARD_HAUPPAUGE_955Q},
+   {USB_DEVICE(0x2040, 0xb151),
+.driver_info = CX231XX_BOARD_HAUPPAUGE_935C},
{USB_DEVICE(0x2040, 0xb130),
 .driver_info = CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx},
{USB_DEVICE(0x2040, 0xb131),
@@ -1211,6 +1252,7 @@ void cx231xx_card_setup(struct cx231xx *dev)
case CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx:
case CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx:
case CX231XX_BOARD_HAUPPAUGE_955Q:
+   case CX231XX_BOARD_HAUPPAUGE_935C:
{
struct eeprom {
struct tveeprom tvee;
diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index fb56540..2e6bb09 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -1068,6 +1068,81 @@ static int dvb_init(struct cx231xx *dev)
   _t2hybrid_r820t_config);
break;
}
+   case CX231XX_BOARD_HAUPPAUGE_935C:
+   {
+   struct i2c_client *client;
+   struct i2c_adapter *adapter;
+   struct i2c_board_info info = {};
+   struct si2157_config si2157_config = {};
+   struct si2168_config si2168_config = {};
+
+   /* attach demodulator chip */
+   si2168_config.ts_mode = SI2168_TS_SERIAL;
+   si2168_config.fe = >dvb->frontend;
+   si2168_config.i2c_adapter = 
+   si2168_config.ts_clock_inv = true;
+
+   strlcpy(info.type, "si2168", sizeof(info.type));
+   info.addr = dev->board.demod_addr;
+   info.platform_data = _config;
+
+   request_module(info.type);
+   client = i2c_new_device(demod_i2c, );
+   if (client == NULL || client->dev.driver == NULL) {
+   result = -ENODEV;
+   goto out_free;
+   }
+
+   if (!try_module_get(client->dev.driver->owner)) {
+   dev_err(dev->dev,
+   "Failed to attach %s frontend.\n", info.type);
+   i2c_unregister_device(client);
+   result = -ENODEV;
+   goto out_free;
+   }
+
+   dvb->i2c_client_demod = 

[PATCH 2/2] cx231xx: Add support for Hauppauge HVR-975

[Brad Love]

Hauppauge HVR-975 is hybrid NTSC/PAL, QAM/ATSC, and DVB-C/T/T2 usb device.

Only ATSC/QAM front end is initially active. Second frontend support is
work in progress.

CX23102 + LG3306A/Si2168(WiP) + Si2157

Signed-off-by: Brad Love 
---
 drivers/media/usb/cx231xx/cx231xx-cards.c | 42 ++
 drivers/media/usb/cx231xx/cx231xx-dvb.c   | 74 +++
 drivers/media/usb/cx231xx/cx231xx.h   |  1 +
 3 files changed, 117 insertions(+)

diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c 
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index c2efbff..8582568 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -961,6 +961,45 @@ struct cx231xx_board cx231xx_boards[] = {
.gpio = NULL,
} },
},
+   [CX231XX_BOARD_HAUPPAUGE_975] = {
+   .name = "Hauppauge WinTV-HVR-975",
+   .tuner_type = TUNER_ABSENT,
+   .tuner_addr = 0x60,
+   .tuner_gpio = RDE250_XCV_TUNER,
+   .tuner_sif_gpio = 0x05,
+   .tuner_scl_gpio = 0x1a,
+   .tuner_sda_gpio = 0x1b,
+   .decoder = CX231XX_AVDECODER,
+   .output_mode = OUT_MODE_VIP11,
+   .demod_xfer_mode = 0,
+   .ctl_pin_status_mask = 0xFFC4,
+   .agc_analog_digital_select_gpio = 0x0c,
+   .gpio_pin_status_mask = 0x4001000,
+   .tuner_i2c_master = I2C_1_MUX_3,
+   .demod_i2c_master = I2C_1_MUX_3,
+   .has_dvb = 1,
+   .demod_addr = 0x59, /* 0xb2 >> 1 */
+   .norm = V4L2_STD_ALL,
+
+   .input = {{
+   .type = CX231XX_VMUX_TELEVISION,
+   .vmux = CX231XX_VIN_3_1,
+   .amux = CX231XX_AMUX_VIDEO,
+   .gpio = NULL,
+   }, {
+   .type = CX231XX_VMUX_COMPOSITE1,
+   .vmux = CX231XX_VIN_2_1,
+   .amux = CX231XX_AMUX_LINE_IN,
+   .gpio = NULL,
+   }, {
+   .type = CX231XX_VMUX_SVIDEO,
+   .vmux = CX231XX_VIN_1_1 |
+   (CX231XX_VIN_1_2 << 8) |
+   CX25840_SVIDEO_ON,
+   .amux = CX231XX_AMUX_LINE_IN,
+   .gpio = NULL,
+   } },
+   },
 };
 const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
 
@@ -994,6 +1033,8 @@ struct usb_device_id cx231xx_id_table[] = {
 .driver_info = CX231XX_BOARD_HAUPPAUGE_955Q},
{USB_DEVICE(0x2040, 0xb151),
 .driver_info = CX231XX_BOARD_HAUPPAUGE_935C},
+   {USB_DEVICE(0x2040, 0xb150),
+.driver_info = CX231XX_BOARD_HAUPPAUGE_975},
{USB_DEVICE(0x2040, 0xb130),
 .driver_info = CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx},
{USB_DEVICE(0x2040, 0xb131),
@@ -1253,6 +1294,7 @@ void cx231xx_card_setup(struct cx231xx *dev)
case CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx:
case CX231XX_BOARD_HAUPPAUGE_955Q:
case CX231XX_BOARD_HAUPPAUGE_935C:
+   case CX231XX_BOARD_HAUPPAUGE_975:
{
struct eeprom {
struct tveeprom tvee;
diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index 2e6bb09..cb8e90a 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -1143,6 +1143,80 @@ static int dvb_init(struct cx231xx *dev)
dev->dvb->i2c_client_tuner = client;
break;
}
+   case CX231XX_BOARD_HAUPPAUGE_975:
+   {
+   struct i2c_client *client;
+   struct i2c_adapter *adapter;
+   struct i2c_board_info info = {};
+   struct si2157_config si2157_config = {};
+   struct lgdt3306a_config lgdt3306a_config = {};
+
+   /* attach demodulator chip */
+   lgdt3306a_config = hauppauge_955q_lgdt3306a_config;
+   lgdt3306a_config.fe = >dvb->frontend;
+   lgdt3306a_config.i2c_adapter = 
+
+   strlcpy(info.type, "lgdt3306a", sizeof(info.type));
+   info.addr = dev->board.demod_addr;;
+   info.platform_data = _config;
+
+   request_module(info.type);
+   client = i2c_new_device(demod_i2c, );
+   if (client == NULL || client->dev.driver == NULL) {
+   result = -ENODEV;
+   goto out_free;
+   }
+
+   if (!try_module_get(client->dev.driver->owner)) {
+   dev_err(dev->dev,
+   "Failed to attach %s frontend.\n", info.type);
+   i2c_unregister_device(client);
+   result = -ENODEV;
+

[PATCH 0/2] New Hauppauge USB devices

[Brad Love]

Included is support for the following two USB devices:
- Hauppauge USB HVR935C - DVB-C/T/T2 + analog
- Hauppauge USB HVR975 - ATSC/QAM + analog

Brad Love (2):
  cx231xx: Add support for Hauppauge HVR-935
  cx231xx: Add support for Hauppauge HVR-975

 drivers/media/usb/cx231xx/cx231xx-cards.c |  84 ++
 drivers/media/usb/cx231xx/cx231xx-dvb.c   | 136 ++
 drivers/media/usb/cx231xx/cx231xx.h   |   2 +
 3 files changed, 222 insertions(+)

-- 
2.7.4

[PATCH v4 1/9] dt-bindings: media: Add Renesas CEU bindings

[Jacopo Mondi]

Add bindings documentation for Renesas Capture Engine Unit (CEU).

Signed-off-by: Jacopo Mondi 
---
 .../devicetree/bindings/media/renesas,ceu.txt  | 81 ++
 1 file changed, 81 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt

diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
b/Documentation/devicetree/bindings/media/renesas,ceu.txt
new file mode 100644
index 000..590ee27
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
@@ -0,0 +1,81 @@
+Renesas Capture Engine Unit (CEU)
+--
+
+The Capture Engine Unit is the image capture interface found in the Renesas
+SH Mobile and RZ SoCs.
+
+The interface supports a single parallel input with data bus width of 8 or 16
+bits.
+
+Required properties:
+- compatible: Shall be "renesas,r7s72100-ceu" for CEU units found in RZ/A1-H
+  and RZ/A1-M SoCs.
+- reg: Registers address base and size.
+- interrupts: The interrupt specifier.
+
+The CEU supports a single parallel input and should contain a single 'port'
+subnode with a single 'endpoint'. Connection to input devices are modeled
+according to the video interfaces OF bindings specified in:
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Optional endpoint properties applicable to parallel input bus described in
+the above mentioned "video-interfaces.txt" file are supported.
+
+- hsync-active: Active state of the HSYNC signal, 0/1 for LOW/HIGH 
respectively.
+  If property is not present, default is active high.
+- vsync-active: Active state of the VSYNC signal, 0/1 for LOW/HIGH 
respectively.
+  If property is not present, default is active high.
+
+Example:
+
+The example describes the connection between the Capture Engine Unit and an
+OV7670 image sensor connected to i2c1 interface.
+
+ceu: ceu@e821 {
+   reg = <0xe821 0x209c>;
+   compatible = "renesas,r7s72100-ceu";
+   interrupts = ;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   status = "okay";
+
+   port {
+   ceu_in: endpoint {
+   remote-endpoint = <_out>;
+
+   hsync-active = <1>;
+   vsync-active = <0>;
+   };
+   };
+};
+
+i2c1: i2c@fcfee400 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   status = "okay";
+
+   clock-frequency = <10>;
+
+   ov7670: camera@21 {
+   compatible = "ovti,ov7670";
+   reg = <0x21>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   reset-gpios = < 11 GPIO_ACTIVE_LOW>;
+   powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
+
+   port {
+   ov7670_out: endpoint {
+   remote-endpoint = <_in>;
+
+   hsync-active = <1>;
+   vsync-active = <0>;
+   };
+   };
+   };
+};
-- 
2.7.4

[PATCH v4 2/9] include: media: Add Renesas CEU driver interface

[Jacopo Mondi]

Add renesas-ceu header file.

Do not remove the existing sh_mobile_ceu.h one as long as the original
driver does not go away.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Laurent Pinchart 
---
 include/media/drv-intf/renesas-ceu.h | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 include/media/drv-intf/renesas-ceu.h

diff --git a/include/media/drv-intf/renesas-ceu.h 
b/include/media/drv-intf/renesas-ceu.h
new file mode 100644
index 000..52841d1
--- /dev/null
+++ b/include/media/drv-intf/renesas-ceu.h
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * renesas-ceu.h - Renesas CEU driver interface
+ *
+ * Copyright 2017-2018 Jacopo Mondi 
+ */
+
+#ifndef __MEDIA_DRV_INTF_RENESAS_CEU_H__
+#define __MEDIA_DRV_INTF_RENESAS_CEU_H__
+
+#define CEU_MAX_SUBDEVS2
+
+struct ceu_async_subdev {
+   unsigned long flags;
+   unsigned char bus_width;
+   unsigned char bus_shift;
+   unsigned int i2c_adapter_id;
+   unsigned int i2c_address;
+};
+
+struct ceu_platform_data {
+   unsigned int num_subdevs;
+   struct ceu_async_subdev subdevs[CEU_MAX_SUBDEVS];
+};
+
+#endif /* ___MEDIA_DRV_INTF_RENESAS_CEU_H__ */
-- 
2.7.4

[PATCH v4 3/9] v4l: platform: Add Renesas CEU driver

[Jacopo Mondi]

Add driver for Renesas Capture Engine Unit (CEU).

The CEU interface supports capturing 'data' (YUV422) and 'images'
(NV[12|21|16|61]).

This driver aims to replace the soc_camera-based sh_mobile_ceu one.

Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
platform GR-Peach.

Tested with ov7725 camera sensor on SH4 platform Migo-R.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/platform/Kconfig   |9 +
 drivers/media/platform/Makefile  |1 +
 drivers/media/platform/renesas-ceu.c | 1648 ++
 3 files changed, 1658 insertions(+)
 create mode 100644 drivers/media/platform/renesas-ceu.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index fd0c998..fe7bd26 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -144,6 +144,15 @@ config VIDEO_STM32_DCMI
  To compile this driver as a module, choose M here: the module
  will be called stm32-dcmi.
 
+config VIDEO_RENESAS_CEU
+   tristate "Renesas Capture Engine Unit (CEU) driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
+   depends on ARCH_SHMOBILE || ARCH_R7S72100 || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_FWNODE
+   ---help---
+ This is a v4l2 driver for the Renesas CEU Interface
+
 source "drivers/media/platform/soc_camera/Kconfig"
 source "drivers/media/platform/exynos4-is/Kconfig"
 source "drivers/media/platform/am437x/Kconfig"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 003b0bb..6580a6b 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_VIDEO_SH_VOU)+= sh_vou.o
 obj-$(CONFIG_SOC_CAMERA)   += soc_camera/
 
 obj-$(CONFIG_VIDEO_RCAR_DRIF)  += rcar_drif.o
+obj-$(CONFIG_VIDEO_RENESAS_CEU)+= renesas-ceu.o
 obj-$(CONFIG_VIDEO_RENESAS_FCP)+= rcar-fcp.o
 obj-$(CONFIG_VIDEO_RENESAS_FDP1)   += rcar_fdp1.o
 obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
diff --git a/drivers/media/platform/renesas-ceu.c 
b/drivers/media/platform/renesas-ceu.c
new file mode 100644
index 000..d261704
--- /dev/null
+++ b/drivers/media/platform/renesas-ceu.c
@@ -0,0 +1,1648 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * V4L2 Driver for Renesas Capture Engine Unit (CEU) interface
+ * Copyright (C) 2017-2018 Jacopo Mondi 
+ *
+ * Based on soc-camera driver "soc_camera/sh_mobile_ceu_camera.c"
+ * Copyright (C) 2008 Magnus Damm
+ *
+ * Based on V4L2 Driver for PXA camera host - "pxa_camera.c",
+ * Copyright (C) 2006, Sascha Hauer, Pengutronix
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define DRIVER_NAME"renesas-ceu"
+
+/* CEU registers offsets and masks. */
+#define CEU_CAPSR  0x00 /* Capture start register  */
+#define CEU_CAPCR  0x04 /* Capture control register*/
+#define CEU_CAMCR  0x08 /* Capture interface control register  */
+#define CEU_CAMOR  0x10 /* Capture interface offset register   */
+#define CEU_CAPWR  0x14 /* Capture interface width register*/
+#define CEU_CAIFR  0x18 /* Capture interface input format register */
+#define CEU_CRCNTR 0x28 /* CEU register control register   */
+#define CEU_CRCMPR 0x2c /* CEU register forcible control register  */
+#define CEU_CFLCR  0x30 /* Capture filter control register */
+#define CEU_CFSZR  0x34 /* Capture filter size clip register   */
+#define CEU_CDWDR  0x38 /* Capture destination width register  */
+#define CEU_CDAYR  0x3c /* Capture data address Y register */
+#define CEU_CDACR  0x40 /* Capture data address C register */
+#define CEU_CFWCR  0x5c /* Firewall operation control register */
+#define CEU_CDOCR  0x64 /* Capture data output control register*/
+#define CEU_CEIER  0x70 /* Capture event interrupt enable register */
+#define CEU_CETCR  0x74 /* Capture event flag clear register   */
+#define CEU_CSTSR  0x7c /* Capture status register */
+#define CEU_CSRTR  0x80 /* Capture software reset register */
+
+/* Data synchronous fetch mode. */
+#define CEU_CAMCR_JPEG BIT(4)
+
+/* Input components ordering: CEU_CAMCR.DTARY field. */
+#define CEU_CAMCR_DTARY_8_UYVY (0x00 << 8)
+#define CEU_CAMCR_DTARY_8_VYUY (0x01 << 8)
+#define CEU_CAMCR_DTARY_8_YUYV (0x02 << 8)
+#define CEU_CAMCR_DTARY_8_YVYU (0x03 << 8)
+/* TODO: input 

[PATCH v4 6/9] media: i2c: ov772x: Remove soc_camera dependencies

[Jacopo Mondi]

Remove soc_camera framework dependencies from ov772x sensor driver.
- Handle clock and gpios
- Register async subdevice
- Remove soc_camera specific g/s_mbus_config operations
- Change image format colorspace from JPEG to SRGB as the two use the
  same colorspace information but JPEG makes assumptions on color
  components quantization that do not apply to the sensor
- Remove sizes crop from get_selection as driver can't scale
- Add kernel doc to driver interface header file
- Adjust build system

This commit does not remove the original soc_camera based driver as long
as other platforms depends on soc_camera-based CEU driver.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/i2c/Kconfig  |  11 +++
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/ov772x.c | 177 ++---
 include/media/i2c/ov772x.h |   6 +-
 4 files changed, 133 insertions(+), 62 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cb5d7ff..a61d7f4 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -645,6 +645,17 @@ config VIDEO_OV5670
  To compile this driver as a module, choose M here: the
  module will be called ov5670.
 
+config VIDEO_OV772X
+   tristate "OmniVision OV772x sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV772x camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov772x.
+
 config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9ef..fb99293 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
 obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
 obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
 obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
+obj-$(CONFIG_VIDEO_OV772X) += ov772x.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
index 8063835..df2516c 100644
--- a/drivers/media/i2c/ov772x.c
+++ b/drivers/media/i2c/ov772x.c
@@ -1,6 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * ov772x Camera Driver
  *
+ * Copyright (C) 2017 Jacopo Mondi 
+ *
  * Copyright (C) 2008 Renesas Solutions Corp.
  * Kuninori Morimoto 
  *
@@ -9,27 +12,25 @@
  * Copyright 2006-7 Jonathan Corbet 
  * Copyright (C) 2008 Magnus Damm
  * Copyright (C) 2008, Guennadi Liakhovetski 
- *
- * 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 
 #include 
 
 #include 
-#include 
-#include 
+
 #include 
-#include 
+#include 
 #include 
+#include 
 
 /*
  * register offset
@@ -393,8 +394,10 @@ struct ov772x_win_size {
 struct ov772x_priv {
struct v4l2_subdevsubdev;
struct v4l2_ctrl_handler  hdl;
-   struct v4l2_clk  *clk;
+   struct clk   *clk;
struct ov772x_camera_info*info;
+   struct gpio_desc *pwdn_gpio;
+   struct gpio_desc *rstb_gpio;
const struct ov772x_color_format *cfmt;
const struct ov772x_win_size *win;
unsigned shortflag_vflip:1;
@@ -409,7 +412,7 @@ struct ov772x_priv {
 static const struct ov772x_color_format ov772x_cfmts[] = {
{
.code   = MEDIA_BUS_FMT_YUYV8_2X8,
-   .colorspace = V4L2_COLORSPACE_JPEG,
+   .colorspace = V4L2_COLORSPACE_SRGB,
.dsp3   = 0x0,
.dsp4   = DSP_OFMT_YUV,
.com3   = SWAP_YUV,
@@ -417,7 +420,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
},
{
.code   = MEDIA_BUS_FMT_YVYU8_2X8,
-   .colorspace = V4L2_COLORSPACE_JPEG,
+   .colorspace = V4L2_COLORSPACE_SRGB,
.dsp3   = UV_ON,
.dsp4   = DSP_OFMT_YUV,
.com3   = SWAP_YUV,
@@ -425,7 +428,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
},
{
.code   = MEDIA_BUS_FMT_UYVY8_2X8,
-   .colorspace = V4L2_COLORSPACE_JPEG,
+   .colorspace = 

[PATCH v4 4/9] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

[Jacopo Mondi]

Add Capture Engine Unit (CEU) node to device tree.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r7s72100.dtsi | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index ab9645a..5fe62f9 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -135,9 +135,9 @@
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks", 
"renesas,cpg-mstp-clocks";
reg = <0xfcfe042c 4>;
-   clocks = <_clk>;
-   clock-indices = ;
-   clock-output-names = "rtc";
+   clocks = <_clk>, <_clk>;
+   clock-indices = ;
+   clock-output-names = "ceu", "rtc";
};
 
mstp7_clks: mstp7_clks@fcfe0430 {
@@ -667,4 +667,13 @@
power-domains = <_clocks>;
status = "disabled";
};
+
+   ceu: ceu@e821 {
+   reg = <0xe821 0x3000>;
+   compatible = "renesas,r7s72100-ceu";
+   interrupts = ;
+   clocks = <_clks R7S72100_CLK_CEU>;
+   power-domains = <_clocks>;
+   status = "disabled";
+   };
 };
-- 
2.7.4

[PATCH v4 5/9] v4l: i2c: Copy ov772x soc_camera sensor driver

[Jacopo Mondi]

Copy the soc_camera based driver in v4l2 sensor driver directory.
This commit just copies the original file without modifying it.
No modification to KConfig and Makefile as soc_camera framework
dependencies need to be removed first in next commit.

Signed-off-by: Jacopo Mondi 
Acked-by: Laurent Pinchart 
---
 drivers/media/i2c/ov772x.c | 1124 
 1 file changed, 1124 insertions(+)
 create mode 100644 drivers/media/i2c/ov772x.c

diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
new file mode 100644
index 000..8063835
--- /dev/null
+++ b/drivers/media/i2c/ov772x.c
@@ -0,0 +1,1124 @@
+/*
+ * ov772x Camera Driver
+ *
+ * Copyright (C) 2008 Renesas Solutions Corp.
+ * Kuninori Morimoto 
+ *
+ * Based on ov7670 and soc_camera_platform driver,
+ *
+ * Copyright 2006-7 Jonathan Corbet 
+ * Copyright (C) 2008 Magnus Damm
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ *
+ * 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 
+#include 
+#include 
+#include 
+
+/*
+ * register offset
+ */
+#define GAIN0x00 /* AGC - Gain control gain setting */
+#define BLUE0x01 /* AWB - Blue channel gain setting */
+#define RED 0x02 /* AWB - Red   channel gain setting */
+#define GREEN   0x03 /* AWB - Green channel gain setting */
+#define COM10x04 /* Common control 1 */
+#define BAVG0x05 /* U/B Average Level */
+#define GAVG0x06 /* Y/Gb Average Level */
+#define RAVG0x07 /* V/R Average Level */
+#define AECH0x08 /* Exposure Value - AEC MSBs */
+#define COM20x09 /* Common control 2 */
+#define PID 0x0A /* Product ID Number MSB */
+#define VER 0x0B /* Product ID Number LSB */
+#define COM30x0C /* Common control 3 */
+#define COM40x0D /* Common control 4 */
+#define COM50x0E /* Common control 5 */
+#define COM60x0F /* Common control 6 */
+#define AEC 0x10 /* Exposure Value */
+#define CLKRC   0x11 /* Internal clock */
+#define COM70x12 /* Common control 7 */
+#define COM80x13 /* Common control 8 */
+#define COM90x14 /* Common control 9 */
+#define COM10   0x15 /* Common control 10 */
+#define REG16   0x16 /* Register 16 */
+#define HSTART  0x17 /* Horizontal sensor size */
+#define HSIZE   0x18 /* Horizontal frame (HREF column) end high 8-bit */
+#define VSTART  0x19 /* Vertical frame (row) start high 8-bit */
+#define VSIZE   0x1A /* Vertical sensor size */
+#define PSHFT   0x1B /* Data format - pixel delay select */
+#define MIDH0x1C /* Manufacturer ID byte - high */
+#define MIDL0x1D /* Manufacturer ID byte - low  */
+#define LAEC0x1F /* Fine AEC value */
+#define COM11   0x20 /* Common control 11 */
+#define BDBASE  0x22 /* Banding filter Minimum AEC value */
+#define DBSTEP  0x23 /* Banding filter Maximum Setp */
+#define AEW 0x24 /* AGC/AEC - Stable operating region (upper limit) */
+#define AEB 0x25 /* AGC/AEC - Stable operating region (lower limit) */
+#define VPT 0x26 /* AGC/AEC Fast mode operating region */
+#define REG28   0x28 /* Register 28 */
+#define HOUTSIZE0x29 /* Horizontal data output size MSBs */
+#define EXHCH   0x2A /* Dummy pixel insert MSB */
+#define EXHCL   0x2B /* Dummy pixel insert LSB */
+#define VOUTSIZE0x2C /* Vertical data output size MSBs */
+#define ADVFL   0x2D /* LSB of insert dummy lines in Vertical direction */
+#define ADVFH   0x2E /* MSG of insert dummy lines in Vertical direction */
+#define YAVE0x2F /* Y/G Channel Average value */
+#define LUMHTH  0x30 /* Histogram AEC/AGC Luminance high level threshold */
+#define LUMLTH  0x31 /* Histogram AEC/AGC Luminance low  level threshold */
+#define HREF0x32 /* Image start and size control */
+#define DM_LNL  0x33 /* Dummy line low  8 bits */
+#define DM_LNH  0x34 /* Dummy line high 8 bits */
+#define ADOFF_B 0x35 /* AD offset compensation value for B  channel */
+#define ADOFF_R 0x36 /* AD offset compensation value for R  channel */
+#define ADOFF_GB0x37 /* AD offset compensation value for Gb channel */
+#define ADOFF_GR0x38 /* AD offset compensation value for Gr channel */
+#define OFF_B   0x39 /* Analog process B  channel offset value */
+#define OFF_R   0x3A /* Analog process R  channel offset value */
+#define OFF_GB  0x3B /* Analog process Gb channel offset value */
+#define OFF_GR  0x3C /* Analog process Gr channel offset value */
+#define COM12   0x3D 

[PATCH v4 8/9] media: i2c: tw9910: Remove soc_camera dependencies

[Jacopo Mondi]

Remove soc_camera framework dependencies from tw9910 sensor driver.
- Handle clock and gpios
- Register async subdevice
- Remove soc_camera specific g/s_mbus_config operations
- Add kernel doc to driver interface header file
- Adjust build system

This commit does not remove the original soc_camera based driver as long
as other platforms depends on soc_camera-based CEU driver.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/i2c/Kconfig  |   9 +++
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/tw9910.c | 162 -
 include/media/i2c/tw9910.h |   9 +++
 4 files changed, 120 insertions(+), 61 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index a61d7f4..804a1bf 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -423,6 +423,15 @@ config VIDEO_TW9906
  To compile this driver as a module, choose M here: the
  module will be called tw9906.
 
+config VIDEO_TW9910
+   tristate "Techwell TW9910 video decoder"
+   depends on VIDEO_V4L2 && I2C
+   ---help---
+ Support for Techwell TW9910 NTSC/PAL/SECAM video decoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tw9910.
+
 config VIDEO_VPX3220
tristate "vpx3220a, vpx3216b & vpx3214c video decoders"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index fb99293..e26544f 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o
 obj-$(CONFIG_VIDEO_TW2804) += tw2804.o
 obj-$(CONFIG_VIDEO_TW9903) += tw9903.o
 obj-$(CONFIG_VIDEO_TW9906) += tw9906.o
+obj-$(CONFIG_VIDEO_TW9910) += tw9910.o
 obj-$(CONFIG_VIDEO_CS3308) += cs3308.o
 obj-$(CONFIG_VIDEO_CS5345) += cs5345.o
 obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o
diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c
index bdb5e0a..96792df 100644
--- a/drivers/media/i2c/tw9910.c
+++ b/drivers/media/i2c/tw9910.c
@@ -1,6 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * tw9910 Video Driver
  *
+ * Copyright (C) 2017 Jacopo Mondi 
+ *
  * Copyright (C) 2008 Renesas Solutions Corp.
  * Kuninori Morimoto 
  *
@@ -10,12 +13,10 @@
  * Copyright 2006-7 Jonathan Corbet 
  * Copyright (C) 2008 Magnus Damm
  * Copyright (C) 2008, Guennadi Liakhovetski 
- *
- * 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 
@@ -25,9 +26,7 @@
 #include 
 #include 
 
-#include 
 #include 
-#include 
 #include 
 
 #define GET_ID(val)  ((val & 0xF8) >> 3)
@@ -228,8 +227,10 @@ struct tw9910_scale_ctrl {
 
 struct tw9910_priv {
struct v4l2_subdev  subdev;
-   struct v4l2_clk *clk;
+   struct clk  *clk;
struct tw9910_video_info*info;
+   struct gpio_desc*pdn_gpio;
+   struct gpio_desc*rstb_gpio;
const struct tw9910_scale_ctrl  *scale;
v4l2_std_id norm;
u32 revision;
@@ -582,13 +583,66 @@ static int tw9910_s_register(struct v4l2_subdev *sd,
 }
 #endif
 
+static int tw9910_power_on(struct tw9910_priv *priv)
+{
+   struct i2c_client *client = v4l2_get_subdevdata(>subdev);
+   int ret;
+
+   if (priv->clk) {
+   ret = clk_prepare_enable(priv->clk);
+   if (ret)
+   return ret;
+   }
+
+   if (priv->pdn_gpio) {
+   gpiod_set_value(priv->pdn_gpio, 0);
+   usleep_range(500, 1000);
+   }
+
+   /*
+* FIXME: The reset signal is connected to a shared GPIO on some
+* platforms (namely the SuperH Migo-R). Until a framework becomes
+* available to handle this cleanly, request the GPIO temporarily
+* to avoid conflicts.
+*/
+   priv->rstb_gpio = gpiod_get_optional(>dev, "rstb",
+GPIOD_OUT_LOW);
+   if (IS_ERR(priv->rstb_gpio)) {
+   dev_info(>dev, "Unable to get GPIO \"rstb\"");
+   return PTR_ERR(priv->rstb_gpio);
+   }
+
+   if (priv->rstb_gpio) {
+   gpiod_set_value(priv->rstb_gpio, 1);
+   usleep_range(500, 1000);
+   gpiod_set_value(priv->rstb_gpio, 0);
+   usleep_range(500, 1000);
+
+   gpiod_put(priv->rstb_gpio);
+   }
+
+   return 0;
+}
+
+static int tw9910_power_off(struct tw9910_priv *priv)
+{
+   clk_disable_unprepare(priv->clk);
+
+   if (priv->pdn_gpio) {
+ 

[PATCH v4 7/9] v4l: i2c: Copy tw9910 soc_camera sensor driver

[Jacopo Mondi]

Copy the soc_camera based driver in v4l2 sensor driver directory.
This commit just copies the original file without modifying it.
No modification to KConfig and Makefile as soc_camera framework
dependencies need to be removed first in next commit.

Signed-off-by: Jacopo Mondi 
Acked-by: Laurent Pinchart 
---
 drivers/media/i2c/tw9910.c | 999 +
 1 file changed, 999 insertions(+)
 create mode 100644 drivers/media/i2c/tw9910.c

diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c
new file mode 100644
index 000..bdb5e0a
--- /dev/null
+++ b/drivers/media/i2c/tw9910.c
@@ -0,0 +1,999 @@
+/*
+ * tw9910 Video Driver
+ *
+ * Copyright (C) 2008 Renesas Solutions Corp.
+ * Kuninori Morimoto 
+ *
+ * Based on ov772x driver,
+ *
+ * Copyright (C) 2008 Kuninori Morimoto 
+ * Copyright 2006-7 Jonathan Corbet 
+ * Copyright (C) 2008 Magnus Damm
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ *
+ * 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 
+#include 
+
+#define GET_ID(val)  ((val & 0xF8) >> 3)
+#define GET_REV(val) (val & 0x07)
+
+/*
+ * register offset
+ */
+#define ID 0x00 /* Product ID Code Register */
+#define STATUS10x01 /* Chip Status Register I */
+#define INFORM 0x02 /* Input Format */
+#define OPFORM 0x03 /* Output Format Control Register */
+#define DLYCTR 0x04 /* Hysteresis and HSYNC Delay Control */
+#define OUTCTR10x05 /* Output Control I */
+#define ACNTL1 0x06 /* Analog Control Register 1 */
+#define CROP_HI0x07 /* Cropping Register, High */
+#define VDELAY_LO  0x08 /* Vertical Delay Register, Low */
+#define VACTIVE_LO 0x09 /* Vertical Active Register, Low */
+#define HDELAY_LO  0x0A /* Horizontal Delay Register, Low */
+#define HACTIVE_LO 0x0B /* Horizontal Active Register, Low */
+#define CNTRL1 0x0C /* Control Register I */
+#define VSCALE_LO  0x0D /* Vertical Scaling Register, Low */
+#define SCALE_HI   0x0E /* Scaling Register, High */
+#define HSCALE_LO  0x0F /* Horizontal Scaling Register, Low */
+#define BRIGHT 0x10 /* BRIGHTNESS Control Register */
+#define CONTRAST   0x11 /* CONTRAST Control Register */
+#define SHARPNESS  0x12 /* SHARPNESS Control Register I */
+#define SAT_U  0x13 /* Chroma (U) Gain Register */
+#define SAT_V  0x14 /* Chroma (V) Gain Register */
+#define HUE0x15 /* Hue Control Register */
+#define CORING10x17
+#define CORING20x18 /* Coring and IF compensation */
+#define VBICNTL0x19 /* VBI Control Register */
+#define ACNTL2 0x1A /* Analog Control 2 */
+#define OUTCTR20x1B /* Output Control 2 */
+#define SDT0x1C /* Standard Selection */
+#define SDTR   0x1D /* Standard Recognition */
+#define TEST   0x1F /* Test Control Register */
+#define CLMPG  0x20 /* Clamping Gain */
+#define IAGC   0x21 /* Individual AGC Gain */
+#define AGCGAIN0x22 /* AGC Gain */
+#define PEAKWT 0x23 /* White Peak Threshold */
+#define CLMPL  0x24 /* Clamp level */
+#define SYNCT  0x25 /* Sync Amplitude */
+#define MISSCNT0x26 /* Sync Miss Count Register */
+#define PCLAMP 0x27 /* Clamp Position Register */
+#define VCNTL1 0x28 /* Vertical Control I */
+#define VCNTL2 0x29 /* Vertical Control II */
+#define CKILL  0x2A /* Color Killer Level Control */
+#define COMB   0x2B /* Comb Filter Control */
+#define LDLY   0x2C /* Luma Delay and H Filter Control */
+#define MISC1  0x2D /* Miscellaneous Control I */
+#define LOOP   0x2E /* LOOP Control Register */
+#define MISC2  0x2F /* Miscellaneous Control II */
+#define MVSN   0x30 /* Macrovision Detection */
+#define STATUS20x31 /* Chip STATUS II */
+#define HFREF  0x32 /* H monitor */
+#define CLMD   0x33 /* CLAMP MODE */
+#define IDCNTL 0x34 /* ID Detection Control */
+#define CLCNTL10x35 /* Clamp Control I */
+#define ANAPLLCTL  0x4C
+#define VBIMIN 0x4D
+#define HSLOWCTL   0x4E
+#define WSS3   0x4F
+#define FILLDATA   0x50
+#define SDID   0x51
+#define DID0x52
+#define WSS1   0x53
+#define WSS2   0x54
+#define VVBI   0x55
+#define LCTL6  0x56
+#define LCTL7  0x57
+#define LCTL8  0x58
+#define LCTL9   

[PATCH v4 9/9] arch: sh: migor: Use new renesas-ceu camera driver

[Jacopo Mondi]

Migo-R platform uses sh_mobile_ceu camera driver, which is now being
replaced by a proper V4L2 camera driver named 'renesas-ceu'.

Move Migo-R platform to use the v4l2 renesas-ceu camera driver
interface and get rid of soc_camera defined components used to register
sensor drivers and of platform specific enable/disable routines.

Register clock source and GPIOs for sensor drivers, so they can use
clock and gpio APIs.

Also, memory for CEU video buffers is now reserved with membocks APIs,
and need to be declared as dma_coherent during machine initialization to
remove that architecture specific part from CEU driver.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Laurent Pinchart 
---
 arch/sh/boards/mach-migor/setup.c  | 225 +++--
 arch/sh/kernel/cpu/sh4a/clock-sh7722.c |   2 +-
 2 files changed, 101 insertions(+), 126 deletions(-)

diff --git a/arch/sh/boards/mach-migor/setup.c 
b/arch/sh/boards/mach-migor/setup.c
index 0bcbe58..ae4a786 100644
--- a/arch/sh/boards/mach-migor/setup.c
+++ b/arch/sh/boards/mach-migor/setup.c
@@ -1,17 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Renesas System Solutions Asia Pte. Ltd - Migo-R
  *
  * Copyright (C) 2008 Magnus Damm
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
  */
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -23,10 +22,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -45,6 +45,9 @@
  * 0x1800   8GB8   NAND Flash (K9K8G08U0A)
  */
 
+#define CEU_BUFFER_MEMORY_SIZE (4 << 20)
+static phys_addr_t ceu_dma_membase;
+
 static struct smc91x_platdata smc91x_info = {
.flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
 };
@@ -301,65 +304,24 @@ static struct platform_device migor_lcdc_device = {
},
 };
 
-static struct clk *camera_clk;
-static DEFINE_MUTEX(camera_lock);
-
-static void camera_power_on(int is_tw)
-{
-   mutex_lock(_lock);
-
-   /* Use 10 MHz VIO_CKO instead of 24 MHz to work
-* around signal quality issues on Panel Board V2.1.
-*/
-   camera_clk = clk_get(NULL, "video_clk");
-   clk_set_rate(camera_clk, 1000);
-   clk_enable(camera_clk); /* start VIO_CKO */
-
-   /* use VIO_RST to take camera out of reset */
-   mdelay(10);
-   if (is_tw) {
-   gpio_set_value(GPIO_PTT2, 0);
-   gpio_set_value(GPIO_PTT0, 0);
-   } else {
-   gpio_set_value(GPIO_PTT0, 1);
-   }
-   gpio_set_value(GPIO_PTT3, 0);
-   mdelay(10);
-   gpio_set_value(GPIO_PTT3, 1);
-   mdelay(10); /* wait to let chip come out of reset */
-}
-
-static void camera_power_off(void)
-{
-   clk_disable(camera_clk); /* stop VIO_CKO */
-   clk_put(camera_clk);
-
-   gpio_set_value(GPIO_PTT3, 0);
-   mutex_unlock(_lock);
-}
-
-static int ov7725_power(struct device *dev, int mode)
-{
-   if (mode)
-   camera_power_on(0);
-   else
-   camera_power_off();
-
-   return 0;
-}
-
-static int tw9910_power(struct device *dev, int mode)
-{
-   if (mode)
-   camera_power_on(1);
-   else
-   camera_power_off();
-
-   return 0;
-}
-
-static struct sh_mobile_ceu_info sh_mobile_ceu_info = {
-   .flags = SH_CEU_FLAG_USE_8BIT_BUS,
+static const struct ceu_platform_data ceu_pdata = {
+   .num_subdevs= 2,
+   .subdevs = {
+   { /* [0] = ov772x */
+   .flags  = 0,
+   .bus_width  = 8,
+   .bus_shift  = 0,
+   .i2c_adapter_id = 0,
+   .i2c_address= 0x21,
+   },
+   { /* [1] = tw9910 */
+   .flags  = 0,
+   .bus_width  = 8,
+   .bus_shift  = 0,
+   .i2c_adapter_id = 0,
+   .i2c_address= 0x45,
+   },
+   },
 };
 
 static struct resource migor_ceu_resources[] = {
@@ -373,18 +335,32 @@ static struct resource migor_ceu_resources[] = {
.start  = evt2irq(0x880),
.flags  = IORESOURCE_IRQ,
},
-   [2] = {
-   /* place holder for contiguous memory */
-   },
 };
 
 static struct platform_device migor_ceu_device = {
-   .name   = "sh_mobile_ceu",
-   .id = 0, /* "ceu0" clock */
+   .name   = "renesas-ceu",
+   .id = 0, /* ceu.0 */
.num_resources  = ARRAY_SIZE(migor_ceu_resources),
.resource   = migor_ceu_resources,
.dev= {
-   .platform_data  = 

[PATCH v4 0/9] Renesas Capture Engine Unit (CEU) V4L2 driver

[Jacopo Mondi]

Hello,
   fourth round for Renesas CEU unit.

The only notable change compared to v3 is that we have dropped the generic
fallback compatible string "renesas,ceu" from bindings and CEU driver.

Apart from that a few minor changes in driver code as reported by Laurent and
below listed.

Most of the patches now have the Reviewed-by tag, so I hope we're very close
to merge this.

Thanks
   j

v3->v4:
- Drop generic fallback compatible string "renesas,ceu"
- Addressed Laurent's comments on [3/9]
  - Fix error messages on irq get/request
  - Do not leak ceudev if irq_get fails
  - Make irq_mask a const field

v2->v3:
- Improved DT bindings removing standard properties (pinctrl- ones and
  remote-endpoint) not specific to this driver and improved description of
  compatible strings
- Remove ov772x's xlkc_rate property and set clock rate in Migo-R board file
- Made 'xclk' clock private to ov772x driver in Migo-R board file
- Change 'rstb' GPIO active output level and changed ov772x and tw9910 drivers
  accordingly as suggested by Fabio
- Minor changes in CEU driver to address Laurent's comments
- Moved Migo-R setup patch to the end of the series to silence 0-day bot
- Renamed tw9910 clock to 'xti' as per video decoder manual
- Changed all SPDX identifiers to GPL-2.0 from previous GPL-2.0+

v1->v2:
 - DT
 -- Addressed Geert's comments and added clocks for CEU to mstp6 clock source
 -- Specified supported generic video iterfaces properties in dt-bindings and
simplified example

 - CEU driver
 -- Re-worked interrupt handler, interrupt management, reset(*) and capture
start operation
 -- Re-worked querycap/enum_input/enum_frameintervals to fix some
v4l2_compliance failures
 -- Removed soc_camera legacy operations g/s_mbus_format
 -- Update to new notifier implementation
 -- Fixed several comments from Hans, Laurent and Sakari

 - Migo-R
 -- Register clocks and gpios for sensor drivers in Migo-R setup
 -- Updated sensors (tw9910 and ov772x) drivers headers and drivers to close
remarks from Hans and Laurent:
 --- Removed platform callbacks and handle clocks and gpios from sensor drivers
 --- Remove g/s_mbus_config operations

Jacopo Mondi (9):
  dt-bindings: media: Add Renesas CEU bindings
  include: media: Add Renesas CEU driver interface
  v4l: platform: Add Renesas CEU driver
  ARM: dts: r7s72100: Add Capture Engine Unit (CEU)
  v4l: i2c: Copy ov772x soc_camera sensor driver
  media: i2c: ov772x: Remove soc_camera dependencies
  v4l: i2c: Copy tw9910 soc_camera sensor driver
  media: i2c: tw9910: Remove soc_camera dependencies
  arch: sh: migor: Use new renesas-ceu camera driver

 .../devicetree/bindings/media/renesas,ceu.txt  |   81 +
 arch/arm/boot/dts/r7s72100.dtsi|   15 +-
 arch/sh/boards/mach-migor/setup.c  |  225 ++-
 arch/sh/kernel/cpu/sh4a/clock-sh7722.c |2 +-
 drivers/media/i2c/Kconfig  |   20 +
 drivers/media/i2c/Makefile |2 +
 drivers/media/i2c/ov772x.c | 1181 ++
 drivers/media/i2c/tw9910.c | 1039 
 drivers/media/platform/Kconfig |9 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/renesas-ceu.c   | 1648 
 include/media/drv-intf/renesas-ceu.h   |   26 +
 include/media/i2c/ov772x.h |6 +-
 include/media/i2c/tw9910.h |9 +
 14 files changed, 4133 insertions(+), 131 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
 create mode 100644 drivers/media/i2c/ov772x.c
 create mode 100644 drivers/media/i2c/tw9910.c
 create mode 100644 drivers/media/platform/renesas-ceu.c
 create mode 100644 include/media/drv-intf/renesas-ceu.h

--
2.7.4

Re: [PATCH v3 1/4] media: ov5695: add support for OV5695 sensor

[Shunqian Zheng]

Hi Sakari,


On 2018年01月09日 06:20, Sakari Ailus wrote:

Hi Shunqian,

Could you next time add a cover page to the patchset that details the
changes from the previous version?

Please also add a MAINTAINERS entry. DT binding files should also precede
the driver.

Done.
By the way, why DT binding files should precede the driver?


On Mon, Jan 08, 2018 at 09:36:04PM +0800, Shunqian Zheng wrote:

This patch adds driver for Omnivision's ov5695 sensor,
the driver supports following features:
  - supported resolutions
+ 2592x1944 at 30fps
+ 1920x1080 at 30fps
+ 1296x972 at 60fps
+ 1280x720 at 30fps
+ 640x480 at 120fps
  - test patterns
  - manual exposure/gain(analog and digital) control
  - vblank and hblank
  - media controller
  - runtime pm

Signed-off-by: Shunqian Zheng 
---
  drivers/media/i2c/Kconfig  |   11 +
  drivers/media/i2c/Makefile |1 +
  drivers/media/i2c/ov5695.c | 1392 
  3 files changed, 1404 insertions(+)
  create mode 100644 drivers/media/i2c/ov5695.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 3c6d642..55b37c8 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -645,6 +645,17 @@ config VIDEO_OV5670
  To compile this driver as a module, choose M here: the
  module will be called ov5670.
  
+config VIDEO_OV5695

+   tristate "OmniVision OV5695 sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV5695 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov5695.
+
  config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9ef..a063030 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
  obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
  obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
  obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
+obj-$(CONFIG_VIDEO_OV5695) += ov5695.o
  obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
diff --git a/drivers/media/i2c/ov5695.c b/drivers/media/i2c/ov5695.c
new file mode 100644
index 000..7e8bd82
--- /dev/null
+++ b/drivers/media/i2c/ov5695.c
@@ -0,0 +1,1392 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ov5695 driver
+ *
+ * Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef V4L2_CID_DIGITAL_GAIN
+#define V4L2_CID_DIGITAL_GAIN  V4L2_CID_GAIN
+#endif
+
+/* 45Mhz * 4 Binning */
+#define OV5695_PIXEL_RATE  (45 * 1000 * 1000 * 4)
+#define CHIP_ID0x005695
+#define OV5695_REG_CHIP_ID 0x300a
+
+#define OV5695_REG_CTRL_MODE   0x0100
+#define OV5695_MODE_SW_STANDBY 0x0
+#define OV5695_MODE_STREAMING  BIT(0)
+
+#define OV5695_REG_EXPOSURE0x3500
+#defineOV5695_EXPOSURE_MIN 4
+#defineOV5695_EXPOSURE_STEP1
+#define OV5695_VTS_MAX 0x7fff
+
+#define OV5695_REG_ANALOG_GAIN 0x3509
+#defineANALOG_GAIN_MIN 0x10
+#defineANALOG_GAIN_MAX 0xf8
+#defineANALOG_GAIN_STEP1
+#defineANALOG_GAIN_DEFAULT 0xf8
+
+#define OV5695_REG_DIGI_GAIN_H 0x350a
+#define OV5695_REG_DIGI_GAIN_L 0x350b
+#define OV5695_DIGI_GAIN_L_MASK0x3f
+#define OV5695_DIGI_GAIN_H_SHIFT   6
+#define OV5695_DIGI_GAIN_MIN   0
+#define OV5695_DIGI_GAIN_MAX   (0x4000 - 1)
+#define OV5695_DIGI_GAIN_STEP  1
+#define OV5695_DIGI_GAIN_DEFAULT   1024
+
+#define OV5695_REG_TEST_PATTERN0x4503
+#defineOV5695_TEST_PATTERN_ENABLE  0x80
+#defineOV5695_TEST_PATTERN_DISABLE 0x0
+
+#define OV5695_REG_VTS 0x380e
+
+#define REG_NULL   0x
+
+#define OV5695_REG_VALUE_08BIT 1
+#define OV5695_REG_VALUE_16BIT 2
+#define OV5695_REG_VALUE_24BIT 3
+
+#define OV5695_LANES   2
+#define OV5695_BITS_PER_SAMPLE 10
+
+struct regval {
+   u16 addr;
+   u8 val;
+};
+
+struct ov5695_mode {
+   u32 width;
+   u32 height;
+   u32 max_fps;
+   u32 hts_def;
+   u32 vts_def;
+   u32 exp_def;
+   const struct regval *reg_list;
+};
+
+struct ov5695 {
+   struct i2c_client   *client;
+   struct clk  *xvclk;
+   struct regulator*avdd_regulator;
+   struct regulator

[PATCH v4 0/5] Add supports for OV2685 and OV5695 sensors

[Shunqian Zheng]

This adds the OV2685 and OV5695 sensor supports.

Mainly changes of v4 are addressing the comments from Sakari,
including,
 - Put dt binding before driver in series
 - Add MAINTAINERS entries
 - Use regulator_bulk_*()
 - Fix the pm_runtime_* in probe()
 - Fix the typo of 2685 0x3008/0x3010 regs

Shunqian Zheng (5):
  dt-bindings: media: Add bindings for OV5695
  media: ov5695: add support for OV5695 sensor
  dt-bindings: media: Add bindings for OV2685
  media: ov2685: add support for OV2685 sensor
  [media] MAINTAINERS: add entries for OV2685/OV5695 sensor drivers

 .../devicetree/bindings/media/i2c/ov2685.txt   |   41 +
 .../devicetree/bindings/media/i2c/ov5695.txt   |   41 +
 MAINTAINERS|   14 +
 drivers/media/i2c/Kconfig  |   23 +
 drivers/media/i2c/Makefile |2 +
 drivers/media/i2c/ov2685.c |  842 
 drivers/media/i2c/ov5695.c | 1396 
 7 files changed, 2359 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2685.txt
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5695.txt
 create mode 100644 drivers/media/i2c/ov2685.c
 create mode 100644 drivers/media/i2c/ov5695.c

-- 
1.9.1

[PATCH v4 1/5] dt-bindings: media: Add bindings for OV5695

[Shunqian Zheng]

Add device tree binding documentation for the OV5695 sensor.

Signed-off-by: Shunqian Zheng 
---
 .../devicetree/bindings/media/i2c/ov5695.txt   | 41 ++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5695.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov5695.txt 
b/Documentation/devicetree/bindings/media/i2c/ov5695.txt
new file mode 100644
index 000..2f2f698
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5695.txt
@@ -0,0 +1,41 @@
+* Omnivision OV5695 MIPI CSI-2 sensor
+
+Required Properties:
+- compatible: shall be "ovti,ov5695"
+- clocks: reference to the xvclk input clock
+- clock-names: shall be "xvclk"
+- avdd-supply: Analog voltage supply, 2.8 volts
+- dovdd-supply: Digital I/O voltage supply, 1.8 volts
+- dvdd-supply: Digital core voltage supply, 1.2 volts
+- reset-gpios: Low active reset gpio
+
+The device node shall contain one 'port' child node with an
+'endpoint' subnode for its digital output video port,
+in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+The endpoint optional property 'data-lanes' shall be "<1 2>".
+
+Example:
+ {
+   camera-sensor: ov5695@36 {
+   compatible = "ovti,ov5695";
+   reg = <0x36>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_24m_cam>;
+
+   clocks = < SCLK_TESTCLKOUT1>;
+   clock-names = "xvclk";
+
+   avdd-supply = <_cam>;
+   dovdd-supply = <>;
+   dvdd-supply = <_cam>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>;
+
+   port {
+   wcam_out: endpoint {
+   remote-endpoint = <_in_wcam>;
+   data-lanes = <1 2>;
+   };
+   };
+   };
+};
-- 
1.9.1

[PATCH v4 2/5] media: ov5695: add support for OV5695 sensor

[Shunqian Zheng]

This patch adds driver for Omnivision's ov5695 sensor,
the driver supports following features:
 - supported resolutions
   + 2592x1944 at 30fps
   + 1920x1080 at 30fps
   + 1296x972 at 60fps
   + 1280x720 at 30fps
   + 640x480 at 120fps
 - test patterns
 - manual exposure/gain(analog and digital) control
 - vblank and hblank
 - media controller
 - runtime pm

Signed-off-by: Shunqian Zheng 
---
 drivers/media/i2c/Kconfig  |   11 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov5695.c | 1396 
 3 files changed, 1408 insertions(+)
 create mode 100644 drivers/media/i2c/ov5695.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 3c6d642..55b37c8 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -645,6 +645,17 @@ config VIDEO_OV5670
  To compile this driver as a module, choose M here: the
  module will be called ov5670.
 
+config VIDEO_OV5695
+   tristate "OmniVision OV5695 sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV5695 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov5695.
+
 config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9ef..a063030 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
 obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
 obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
 obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
+obj-$(CONFIG_VIDEO_OV5695) += ov5695.o
 obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
diff --git a/drivers/media/i2c/ov5695.c b/drivers/media/i2c/ov5695.c
new file mode 100644
index 000..c2e0462
--- /dev/null
+++ b/drivers/media/i2c/ov5695.c
@@ -0,0 +1,1396 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ov5695 driver
+ *
+ * Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef V4L2_CID_DIGITAL_GAIN
+#define V4L2_CID_DIGITAL_GAIN  V4L2_CID_GAIN
+#endif
+
+/* 45Mhz * 4 Binning */
+#define OV5695_PIXEL_RATE  (45 * 1000 * 1000 * 4)
+#define OV5695_XVCLK_FREQ  2400
+
+#define CHIP_ID0x005695
+#define OV5695_REG_CHIP_ID 0x300a
+
+#define OV5695_REG_CTRL_MODE   0x0100
+#define OV5695_MODE_SW_STANDBY 0x0
+#define OV5695_MODE_STREAMING  BIT(0)
+
+#define OV5695_REG_EXPOSURE0x3500
+#defineOV5695_EXPOSURE_MIN 4
+#defineOV5695_EXPOSURE_STEP1
+#define OV5695_VTS_MAX 0x7fff
+
+#define OV5695_REG_ANALOG_GAIN 0x3509
+#defineANALOG_GAIN_MIN 0x10
+#defineANALOG_GAIN_MAX 0xf8
+#defineANALOG_GAIN_STEP1
+#defineANALOG_GAIN_DEFAULT 0xf8
+
+#define OV5695_REG_DIGI_GAIN_H 0x350a
+#define OV5695_REG_DIGI_GAIN_L 0x350b
+#define OV5695_DIGI_GAIN_L_MASK0x3f
+#define OV5695_DIGI_GAIN_H_SHIFT   6
+#define OV5695_DIGI_GAIN_MIN   0
+#define OV5695_DIGI_GAIN_MAX   (0x4000 - 1)
+#define OV5695_DIGI_GAIN_STEP  1
+#define OV5695_DIGI_GAIN_DEFAULT   1024
+
+#define OV5695_REG_TEST_PATTERN0x4503
+#defineOV5695_TEST_PATTERN_ENABLE  0x80
+#defineOV5695_TEST_PATTERN_DISABLE 0x0
+
+#define OV5695_REG_VTS 0x380e
+
+#define REG_NULL   0x
+
+#define OV5695_REG_VALUE_08BIT 1
+#define OV5695_REG_VALUE_16BIT 2
+#define OV5695_REG_VALUE_24BIT 3
+
+#define OV5695_LANES   2
+#define OV5695_BITS_PER_SAMPLE 10
+
+static const char * const ov5695_supply_names[] = {
+   "avdd", /* Analog power */
+   "dovdd",/* Digital I/O power */
+   "dvdd", /* Digital core power */
+};
+
+#define OV5695_NUM_SUPPLIES ARRAY_SIZE(ov5695_supply_names)
+
+struct regval {
+   u16 addr;
+   u8 val;
+};
+
+struct ov5695_mode {
+   u32 width;
+   u32 height;
+   u32 max_fps;
+   u32 hts_def;
+   u32 vts_def;
+   u32 exp_def;
+   const struct regval *reg_list;
+};
+
+struct ov5695 {
+   struct i2c_client   *client;
+   struct clk  *xvclk;
+   struct gpio_desc*reset_gpio;
+   struct regulator_bulk_data supplies[OV5695_NUM_SUPPLIES];
+
+   struct v4l2_subdev  subdev;
+   struct media_padpad;
+   

[PATCH v4 4/5] media: ov2685: add support for OV2685 sensor

[Shunqian Zheng]

This patch adds driver for Omnivision's ov2685 sensor.
Though the ov2685 can output yuv data, this driver only
supports the raw bayer format, including the following features:
  - output 1600x1200 at 30fps
  - test patterns
  - manual exposure/gain control
  - vblank and hblank
  - media controller
  - runtime pm

Signed-off-by: Shunqian Zheng 
---
 drivers/media/i2c/Kconfig  |  12 +
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/ov2685.c | 842 +
 3 files changed, 855 insertions(+)
 create mode 100644 drivers/media/i2c/ov2685.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 55b37c8..63a175d 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -586,6 +586,18 @@ config VIDEO_OV2659
  To compile this driver as a module, choose M here: the
  module will be called ov2659.
 
+config VIDEO_OV2685
+   tristate "OmniVision OV2685 sensor support"
+   depends on VIDEO_V4L2 && I2C && MEDIA_CONTROLLER
+   depends on MEDIA_CAMERA_SUPPORT
+   select V4L2_FWNODE
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV2685 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov2685.
+
 config VIDEO_OV5640
tristate "OmniVision OV5640 sensor support"
depends on OF
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index a063030..3054c69 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
 obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
 obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
 obj-$(CONFIG_VIDEO_OV2640) += ov2640.o
+obj-$(CONFIG_VIDEO_OV2685) += ov2685.o
 obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
 obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
 obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
diff --git a/drivers/media/i2c/ov2685.c b/drivers/media/i2c/ov2685.c
new file mode 100644
index 000..e9339e2
--- /dev/null
+++ b/drivers/media/i2c/ov2685.c
@@ -0,0 +1,842 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ov2685 driver
+ *
+ * Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CHIP_ID0x2685
+#define OV2685_REG_CHIP_ID 0x300a
+
+#define OV2685_XVCLK_FREQ  2400
+
+#define REG_SC_CTRL_MODE   0x0100
+#define SC_CTRL_MODE_STANDBY   0x0
+#define SC_CTRL_MODE_STREAMING BIT(0)
+
+#define OV2685_REG_EXPOSURE0x3500
+#defineOV2685_EXPOSURE_MIN 4
+#defineOV2685_EXPOSURE_STEP1
+
+#define OV2685_REG_VTS 0x380e
+#define OV2685_VTS_MAX 0x7fff
+
+#define OV2685_REG_GAIN0x350a
+#define OV2685_GAIN_MIN0
+#define OV2685_GAIN_MAX0x07ff
+#define OV2685_GAIN_STEP   0x1
+#define OV2685_GAIN_DEFAULT0x0036
+
+#define OV2685_REG_TEST_PATTERN0x5080
+#define OV2685_TEST_PATTERN_DISABLED   0x00
+#define OV2685_TEST_PATTERN_COLOR_BAR  0x80
+#define OV2685_TEST_PATTERN_RANDOM 0x81
+#define OV2685_TEST_PATTERN_COLOR_BAR_FADE 0x88
+#define OV2685_TEST_PATTERN_BW_SQUARE  0x92
+#define OV2685_TEST_PATTERN_COLOR_SQUARE   0x82
+
+#define REG_NULL   0x
+
+#define OV2685_REG_VALUE_08BIT 1
+#define OV2685_REG_VALUE_16BIT 2
+#define OV2685_REG_VALUE_24BIT 3
+
+#define OV2685_LANES   1
+#define OV2685_BITS_PER_SAMPLE 10
+
+static const char * const ov2685_supply_names[] = {
+   "avdd", /* Analog power */
+   "dovdd",/* Digital I/O power */
+   "dvdd", /* Digital core power */
+};
+
+#define OV2685_NUM_SUPPLIES ARRAY_SIZE(ov2685_supply_names)
+
+struct regval {
+   u16 addr;
+   u8 val;
+};
+
+struct ov2685_mode {
+   u32 width;
+   u32 height;
+   u32 exp_def;
+   u32 hts_def;
+   u32 vts_def;
+   const struct regval *reg_list;
+};
+
+struct ov2685 {
+   struct i2c_client   *client;
+   struct clk  *xvclk;
+   struct gpio_desc*reset_gpio;
+   struct regulator_bulk_data supplies[OV2685_NUM_SUPPLIES];
+
+   boolstreaming;
+   struct mutexmutex;
+   struct v4l2_subdev  subdev;
+   struct media_padpad;
+   struct v4l2_ctrl*anal_gain;
+   struct v4l2_ctrl*exposure;
+   struct v4l2_ctrl*hblank;
+   struct v4l2_ctrl*vblank;
+   struct v4l2_ctrl*test_pattern;
+   struct v4l2_ctrl_handler ctrl_handler;
+
+   const struct 

[PATCH v4 3/5] dt-bindings: media: Add bindings for OV2685

[Shunqian Zheng]

Add device tree binding documentation for the OV2685 sensor.

Signed-off-by: Shunqian Zheng 
---
 .../devicetree/bindings/media/i2c/ov2685.txt   | 41 ++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2685.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov2685.txt 
b/Documentation/devicetree/bindings/media/i2c/ov2685.txt
new file mode 100644
index 000..f1586a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2685.txt
@@ -0,0 +1,41 @@
+* Omnivision OV2685 MIPI CSI-2 sensor
+
+Required Properties:
+- compatible: shall be "ovti,ov2685"
+- clocks: reference to the xvclk input clock
+- clock-names: shall be "xvclk"
+- avdd-supply: Analog voltage supply, 2.8 volts
+- dovdd-supply: Digital I/O voltage supply, 1.8 volts
+- dvdd-supply: Digital core voltage supply, 1.8 volts
+- reset-gpios: Low active reset gpio
+
+The device node shall contain one 'port' child node with an
+'endpoint' subnode for its digital output video port,
+in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+The endpoint optional property 'data-lanes' shall be "<1>".
+
+Example:
+ {
+   camera-sensor: ov2685@3c {
+   compatible = "ovti,ov2685";
+   reg = <0x3c>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_24m_cam>;
+
+   clocks = < SCLK_TESTCLKOUT1>;
+   clock-names = "xvclk";
+
+   avdd-supply = <_cam>;
+   dovdd-supply = <>;
+   dvdd-supply = <>;
+   reset-gpios = < 3 GPIO_ACTIVE_LOW>;
+
+   port {
+   ucam_out: endpoint {
+   remote-endpoint = <_in_ucam>;
+   data-lanes = <1>;
+   };
+   };
+   };
+};
-- 
1.9.1

[PATCH v4 5/5] [media] MAINTAINERS: add entries for OV2685/OV5695 sensor drivers

[Shunqian Zheng]

Add maintainer entries for the OV2685 and OV5695 V4L2 sensor drivers.

Signed-off-by: Shunqian Zheng 
---
 MAINTAINERS | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 85773bf..32afc69 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10032,6 +10032,13 @@ T: git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/i2c/ov13858.c
 
+OMNIVISION OV2685 SENSOR DRIVER
+M: Shunqian Zheng 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/ov2685.c
+
 OMNIVISION OV5640 SENSOR DRIVER
 M: Steve Longerbeam 
 L: linux-media@vger.kernel.org
@@ -10046,6 +10053,13 @@ T: git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/i2c/ov5647.c
 
+OMNIVISION OV5695 SENSOR DRIVER
+M: Shunqian Zheng 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/ov5695.c
+
 OMNIVISION OV7670 SENSOR DRIVER
 M: Jonathan Corbet 
 L: linux-media@vger.kernel.org
-- 
1.9.1

Re: [PATCH 07/18] [media] uvcvideo: prevent bounds-check bypass via speculative execution

[Greg KH]

On Tue, Jan 09, 2018 at 04:26:28PM +0200, Laurent Pinchart wrote:
> Hi Greg,
> 
> On Tuesday, 9 January 2018 12:04:10 EET Greg KH wrote:
> > On Tue, Jan 09, 2018 at 10:40:21AM +0200, Laurent Pinchart wrote:
> > > On Saturday, 6 January 2018 11:40:26 EET Greg KH wrote:
> > >> On Sat, Jan 06, 2018 at 10:09:07AM +0100, Greg KH wrote:
> > >> 
> > >> While I'm all for fixing this type of thing, I feel like we need to do
> > >> something "else" for this as playing whack-a-mole for this pattern is
> > >> going to be a never-ending battle for all drivers for forever.
> > > 
> > > That's my concern too, as even if we managed to find and fix all the
> > > occurrences of the problematic patterns (and we won't), new ones will keep
> > > being merged all the time.
> > 
> > And what about the millions of lines of out-of-tree drivers that we all
> > rely on every day in our devices?  What about the distro kernels that
> > add random new drivers?
> 
> Of course, even though the out-of-tree drivers probably come with lots of 
> security issues worse than this one.

Sure, but I have worked with some teams that have used coverity to find
and fix all of the reported bugs it founds.  So some companies are
trying to fix their problems here, let's not make it impossible for them :)

> > We need some sort of automated way to scan for this.
> 
> Is there any initiative to implement such a scan in an open-source tool ?

Sure, if you want to, but I have no such initiative...

> We also need to educate developers. An automatic scanner could help there, 
> but 
> in the end the information has to spread to all our brains. It won't be easy, 
> and is likely not fully feasible, but it's no different than how developers 
> have to be educated about race conditions and locking for instance. It's a 
> mind set.

Agreed.

> > Intel, any chance we can get your coverity rules?  Given that the date
> > of this original patchset was from last August, has anyone looked at
> > what is now in Linus's tree?  What about linux-next?  I just added 3
> > brand-new driver subsystems to the kernel tree there, how do we know
> > there isn't problems in them?
> > 
> > And what about all of the other ways user-data can be affected?  Again,
> > as Peter pointed out, USB devices.  I want some chance to be able to at
> > least audit the codebase we have to see if that path is an issue.
> > Without any hint of how to do this in an automated manner, we are all
> > in deep shit for forever.
> 
> Or at least until the hardware architecture evolves. Let's drop the x86 
> instruction set, expose the µops, and have gcc handle the scheduling. Sure, 
> it 
> will mean recompiling everything for every x86 CPU model out there, but we 
> have source-based distros to the rescue :-D

Then we are back at the itanium mess, where all of the hardware issues
were supposed be fixed by the compiler writers.  We all remember how
well that worked out...

> > >> Either we need some way to mark this data path to make it easy for tools
> > >> like sparse to flag easily, or we need to catch the issue in the driver
> > >> subsystems, which unfortunatly, would harm the drivers that don't have
> > >> this type of issue (like here.)
> > > 
> > > But how would you do so ?
> > 
> > I do not know, it all depends on the access pattern, right?
> 
> Any data coming from userspace could trigger such accesses. If we want 
> complete coverage the only way I can think of is starting from syscalls and 
> tainting data down the call stacks (__user could help to some extend), but 
> we'll likely be drowned in false positives. I don't see how we could mark 
> paths manually.

I agree, which is why I want to see how someone did this work
originally.  We have no idea as no one is telling us anything :(

How do we "know" that these are the only problem areas?  When was the
last scan run?  On what tree?  And so on...

thanks,

greg k-h

Re: [PATCH 1/1] media: entity: Add a nop variant of media_entity_cleanupr

[Arnd Bergmann]

On Tue, Jan 9, 2018 at 2:58 PM, Sakari Ailus
 wrote:
> Add nop variant of media_entity_cleanup. This allows calling
> media_entity_cleanup whether or not Media controller is enabled,
> simplifying driver code.
>
> Also drop #ifdefs on a few drivers around media_entity_cleanup() and drop
> the extra semicolon from media_entity_cleanup prototype.
>
> Signed-off-by: Sakari Ailus 
> ---
> Hi Arnd,
>
> I thought about doing something similar with media_entity_pads_init which is
> equally commonly used in drivers that support MC/non-MC cases. The trouble
> with that is that the drivers set up the struct first before calling
> media_entity_pads_init, requiring the #ifdefs in any case. So the benefit
> would be questionable at least. So just media_entity_cleanup this time.

Looks good overall, just two thoughts:

> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> index d7a669058b5e..a732af1dbba0 100644
> --- a/include/media/media-entity.h
> +++ b/include/media/media-entity.h
> @@ -634,7 +634,11 @@ int media_entity_pads_init(struct media_entity *entity, 
> u16 num_pads,
>   * This function must be called during the cleanup phase after unregistering
>   * the entity (currently, it does nothing).
>   */
> -static inline void media_entity_cleanup(struct media_entity *entity) {};
> +#if IS_ENABLED(CONFIG_MEDIA_CONTROLLER)
> +static inline void media_entity_cleanup(struct media_entity *entity) {}
> +#else
> +#define media_entity_cleanup(entity) do { } while (false)
> +#endif

This might cause a harmless warning about an unused variable in case
we have a driver that does:

 void f(struct i2c_client *client)
{
struct v4l2_subdev *sd = to_subdev(client);
media_entity_cleanup(sd);
}

None of the drivers you changed would have an unused variable after
your change (otherwise they would already have it before your change),
so it's probably fine.

and second, I'm trying the patch below on top of yours now, will
see how far that gets us ;-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 03cf3a1a1e06..6421da7cb58a 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -310,14 +310,14 @@ config VIDEO_ML86V7667

 config VIDEO_AD5820
tristate "AD5820 lens voice coil support"
-   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+   depends on I2C && VIDEO_V4L2
---help---
  This is a driver for the AD5820 camera lens voice coil.
  It is used for example in Nokia N900 (RX-51).

 config VIDEO_DW9714
tristate "DW9714 lens voice coil support"
-   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+   depends on I2C && VIDEO_V4L2
depends on VIDEO_V4L2_SUBDEV_API
---help---
  This is a driver for the DW9714 camera lens voice coil.
@@ -636,7 +636,6 @@ config VIDEO_OV5670
tristate "OmniVision OV5670 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
depends on MEDIA_CAMERA_SUPPORT
-   depends on MEDIA_CONTROLLER
select V4L2_FWNODE
---help---
  This is a Video4Linux2 sensor-level driver for the OmniVision
@@ -667,7 +666,7 @@ config VIDEO_OV7670

 config VIDEO_OV7740
tristate "OmniVision OV7740 sensor support"
-   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+   depends on I2C && VIDEO_V4L2
depends on MEDIA_CAMERA_SUPPORT
---help---
  This is a Video4Linux2 sensor-level driver for the OmniVision
@@ -815,7 +814,7 @@ comment "Flash devices"

 config VIDEO_ADP1653
tristate "ADP1653 flash support"
-   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+   depends on I2C && VIDEO_V4L2
depends on MEDIA_CAMERA_SUPPORT
---help---
  This is a driver for the ADP1653 flash controller. It is used for
@@ -823,7 +822,7 @@ config VIDEO_ADP1653

 config VIDEO_LM3560
tristate "LM3560 dual flash driver support"
-   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+   depends on I2C && VIDEO_V4L2
depends on MEDIA_CAMERA_SUPPORT
select REGMAP_I2C
---help---
@@ -832,7 +831,7 @@ config VIDEO_LM3560

 config VIDEO_LM3646
tristate "LM3646 dual flash driver support"
-   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+   depends on I2C && VIDEO_V4L2
depends on MEDIA_CAMERA_SUPPORT
select REGMAP_I2C
---help---


   Arnd

Re: [PATCH 07/18] [media] uvcvideo: prevent bounds-check bypass via speculative execution

[Laurent Pinchart]

Hi Greg,

On Tuesday, 9 January 2018 12:04:10 EET Greg KH wrote:
> On Tue, Jan 09, 2018 at 10:40:21AM +0200, Laurent Pinchart wrote:
> > On Saturday, 6 January 2018 11:40:26 EET Greg KH wrote:
> >> On Sat, Jan 06, 2018 at 10:09:07AM +0100, Greg KH wrote:
> >> 
> >> While I'm all for fixing this type of thing, I feel like we need to do
> >> something "else" for this as playing whack-a-mole for this pattern is
> >> going to be a never-ending battle for all drivers for forever.
> > 
> > That's my concern too, as even if we managed to find and fix all the
> > occurrences of the problematic patterns (and we won't), new ones will keep
> > being merged all the time.
> 
> And what about the millions of lines of out-of-tree drivers that we all
> rely on every day in our devices?  What about the distro kernels that
> add random new drivers?

Of course, even though the out-of-tree drivers probably come with lots of 
security issues worse than this one.

> We need some sort of automated way to scan for this.

Is there any initiative to implement such a scan in an open-source tool ?

We also need to educate developers. An automatic scanner could help there, but 
in the end the information has to spread to all our brains. It won't be easy, 
and is likely not fully feasible, but it's no different than how developers 
have to be educated about race conditions and locking for instance. It's a 
mind set.

> Intel, any chance we can get your coverity rules?  Given that the date
> of this original patchset was from last August, has anyone looked at
> what is now in Linus's tree?  What about linux-next?  I just added 3
> brand-new driver subsystems to the kernel tree there, how do we know
> there isn't problems in them?
> 
> And what about all of the other ways user-data can be affected?  Again,
> as Peter pointed out, USB devices.  I want some chance to be able to at
> least audit the codebase we have to see if that path is an issue.
> Without any hint of how to do this in an automated manner, we are all
> in deep shit for forever.

Or at least until the hardware architecture evolves. Let's drop the x86 
instruction set, expose the µops, and have gcc handle the scheduling. Sure, it 
will mean recompiling everything for every x86 CPU model out there, but we 
have source-based distros to the rescue :-D

> >> Either we need some way to mark this data path to make it easy for tools
> >> like sparse to flag easily, or we need to catch the issue in the driver
> >> subsystems, which unfortunatly, would harm the drivers that don't have
> >> this type of issue (like here.)
> > 
> > But how would you do so ?
> 
> I do not know, it all depends on the access pattern, right?

Any data coming from userspace could trigger such accesses. If we want 
complete coverage the only way I can think of is starting from syscalls and 
tainting data down the call stacks (__user could help to some extend), but 
we'll likely be drowned in false positives. I don't see how we could mark 
paths manually.

> >> I'm guessing that other operating systems, which don't have the luxury
> >> of auditing all of their drivers are going for the "big hammer in the
> >> subsystem" type of fix, right?
> > 
> > Other operating systems that ship closed-source drivers authored by
> > hardware vendors and not reviewed by third parties will likely stay
> > vulnerable forever. That's a small concern though as I expect those
> > drivers to contain much large security holes anyway.
> 
> Well yes, but odds are those operating systems are doing something to
> mitigate this, right?  Slowing down all user/kernel data paths?
> Targeted code analysis tools?  Something else?  I doubt they just don't
> care at all about it.  At the least, I would think Coverity would be
> trying to sell licenses for this :(

Given their track record of security issues in drivers (and I won't even 
mention the ones that are present by design, such as root kits in game copy 
protection systems for instance) I doubt they will do much beside sprinkling a 
bit of PR dust, at least for the consumer market. On the server market it 
might be different as there's less hardware variation, and thus less drivers 
to handle.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/2] MAINTAINERS: linux-media: update Microchip ISI and ISC entries

[Ludovic Desroches]

On Tue, Jan 09, 2018 at 02:46:39PM +0100, Nicolas Ferre wrote:
> These two image capture interface drivers are now handled
> by Wenyou Yang.
> I benefit from this change to update the two entries by correcting the
> binding documentation link for ISC and moving the ISI to the new
> MICROCHIP / ATMEL location.
> 
> Signed-off-by: Nicolas Ferre <nicolas.fe...@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroc...@microchip.com>

> ---
> Hi,
> 
> Patch against next-20180109.
> Note that I didn't find it useful to have several patches for these changes.
> Tell me if you feel differently.
> 
> I would like to have the Ack from Ludovic and Wenyou obviously. I don't know 
> if
> Songjun can answer as he's not with Microchip anymore.
> 
> Best regards,
>   Nicolas
> 
>  MAINTAINERS | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a7d10a2bb980..65c4b59b582f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2353,13 +2353,6 @@ L: linux-...@vger.kernel.org
>  S:   Supported
>  F:   drivers/i2c/busses/i2c-at91.c
>  
> -ATMEL ISI DRIVER
> -M:   Ludovic Desroches <ludovic.desroc...@microchip.com>
> -L:   linux-media@vger.kernel.org
> -S:   Supported
> -F:   drivers/media/platform/atmel/atmel-isi.c
> -F:   include/media/atmel-isi.h
> -
>  ATMEL LCDFB DRIVER
>  M:   Nicolas Ferre <nicolas.fe...@microchip.com>
>  L:   linux-fb...@vger.kernel.org
> @@ -9102,12 +9095,20 @@ S:Maintained
>  F:   drivers/crypto/atmel-ecc.*
>  
>  MICROCHIP / ATMEL ISC DRIVER
> -M:   Songjun Wu <songjun...@microchip.com>
> +M:   Wenyou Yang <wenyou.y...@microchip.com>
>  L:   linux-media@vger.kernel.org
>  S:   Supported
>  F:   drivers/media/platform/atmel/atmel-isc.c
>  F:   drivers/media/platform/atmel/atmel-isc-regs.h
> -F:   devicetree/bindings/media/atmel-isc.txt
> +F:   Documentation/devicetree/bindings/media/atmel-isc.txt
> +
> +MICROCHIP / ATMEL ISI DRIVER
> +M:   Wenyou Yang <wenyou.y...@microchip.com>
> +L:   linux-media@vger.kernel.org
> +S:   Supported
> +F:   drivers/media/platform/atmel/atmel-isi.c
> +F:   include/media/atmel-isi.h
> +F:   Documentation/devicetree/bindings/media/atmel-isi.txt
>  
>  MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
>  M:   Woojung Huh <woojung@microchip.com>
> -- 
> 2.9.0
> 

[PATCH 1/1] media: entity: Add a nop variant of media_entity_cleanupr

[Sakari Ailus]

Add nop variant of media_entity_cleanup. This allows calling
media_entity_cleanup whether or not Media controller is enabled,
simplifying driver code.

Also drop #ifdefs on a few drivers around media_entity_cleanup() and drop
the extra semicolon from media_entity_cleanup prototype.

Signed-off-by: Sakari Ailus 
---
Hi Arnd,

I thought about doing something similar with media_entity_pads_init which is
equally commonly used in drivers that support MC/non-MC cases. The trouble
with that is that the drivers set up the struct first before calling
media_entity_pads_init, requiring the #ifdefs in any case. So the benefit
would be questionable at least. So just media_entity_cleanup this time.

 drivers/media/i2c/mt9m111.c  | 2 --
 drivers/media/i2c/ov2640.c   | 4 
 drivers/media/i2c/ov2659.c   | 4 
 drivers/media/i2c/ov7670.c   | 4 
 drivers/media/i2c/ov7740.c   | 2 --
 drivers/media/i2c/tvp514x.c  | 4 
 include/media/media-entity.h | 6 +-
 7 files changed, 5 insertions(+), 21 deletions(-)

diff --git a/drivers/media/i2c/mt9m111.c b/drivers/media/i2c/mt9m111.c
index d74f254db661..efda1aa95ca0 100644
--- a/drivers/media/i2c/mt9m111.c
+++ b/drivers/media/i2c/mt9m111.c
@@ -1046,9 +1046,7 @@ static int mt9m111_remove(struct i2c_client *client)
struct mt9m111 *mt9m111 = to_mt9m111(client);
 
v4l2_async_unregister_subdev(>subdev);
-#ifdef CONFIG_MEDIA_CONTROLLER
media_entity_cleanup(>subdev.entity);
-#endif
v4l2_clk_put(mt9m111->clk);
v4l2_ctrl_handler_free(>hdl);
 
diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index 518868388d65..4c3b92763243 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -1147,9 +1147,7 @@ static int ov2640_probe(struct i2c_client *client,
return 0;
 
 err_videoprobe:
-#if defined(CONFIG_MEDIA_CONTROLLER)
media_entity_cleanup(>subdev.entity);
-#endif
 err_hdl:
v4l2_ctrl_handler_free(>hdl);
 err_clk:
@@ -1163,9 +1161,7 @@ static int ov2640_remove(struct i2c_client *client)
 
v4l2_async_unregister_subdev(>subdev);
v4l2_ctrl_handler_free(>hdl);
-#if defined(CONFIG_MEDIA_CONTROLLER)
media_entity_cleanup(>subdev.entity);
-#endif
v4l2_device_unregister_subdev(>subdev);
clk_disable_unprepare(priv->clk);
return 0;
diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
index 122dd6c5eb38..4715edc8ca33 100644
--- a/drivers/media/i2c/ov2659.c
+++ b/drivers/media/i2c/ov2659.c
@@ -1474,9 +1474,7 @@ static int ov2659_probe(struct i2c_client *client,
 
 error:
v4l2_ctrl_handler_free(>ctrls);
-#if defined(CONFIG_MEDIA_CONTROLLER)
media_entity_cleanup(>entity);
-#endif
mutex_destroy(>lock);
return ret;
 }
@@ -1488,9 +1486,7 @@ static int ov2659_remove(struct i2c_client *client)
 
v4l2_ctrl_handler_free(>ctrls);
v4l2_async_unregister_subdev(sd);
-#if defined(CONFIG_MEDIA_CONTROLLER)
media_entity_cleanup(>entity);
-#endif
mutex_destroy(>lock);
 
return 0;
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index fd229bc8a0e5..28571de1c2f6 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1846,9 +1846,7 @@ static int ov7670_probe(struct i2c_client *client,
return 0;
 
 entity_cleanup:
-#if defined(CONFIG_MEDIA_CONTROLLER)
media_entity_cleanup(>sd.entity);
-#endif
 hdl_free:
v4l2_ctrl_handler_free(>hdl);
 power_off:
@@ -1867,9 +1865,7 @@ static int ov7670_remove(struct i2c_client *client)
v4l2_async_unregister_subdev(sd);
v4l2_ctrl_handler_free(>hdl);
clk_disable_unprepare(info->clk);
-#if defined(CONFIG_MEDIA_CONTROLLER)
media_entity_cleanup(>sd.entity);
-#endif
ov7670_s_power(sd, 0);
return 0;
 }
diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
index 0308ba437bbb..576ce0640297 100644
--- a/drivers/media/i2c/ov7740.c
+++ b/drivers/media/i2c/ov7740.c
@@ -1148,9 +1148,7 @@ static int ov7740_remove(struct i2c_client *client)
 
mutex_destroy(>mutex);
v4l2_ctrl_handler_free(ov7740->subdev.ctrl_handler);
-#if defined(CONFIG_MEDIA_CONTROLLER)
media_entity_cleanup(>subdev.entity);
-#endif
v4l2_async_unregister_subdev(sd);
ov7740_free_controls(ov7740);
 
diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
index d575b3e7e835..8b0aa9297bde 100644
--- a/drivers/media/i2c/tvp514x.c
+++ b/drivers/media/i2c/tvp514x.c
@@ -1131,9 +1131,7 @@ tvp514x_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
 done:
if (ret < 0) {
v4l2_ctrl_handler_free(>hdl);
-#if defined(CONFIG_MEDIA_CONTROLLER)
media_entity_cleanup(>sd.entity);
-#endif
}
return ret;
 }
@@ -1151,9 +1149,7 @@ static int tvp514x_remove(struct i2c_client *client)
struct tvp514x_decoder *decoder = to_decoder(sd);
 
 

[PATCH 1/2] MAINTAINERS: linux-media: update Microchip ISI and ISC entries

[Nicolas Ferre]

These two image capture interface drivers are now handled
by Wenyou Yang.
I benefit from this change to update the two entries by correcting the
binding documentation link for ISC and moving the ISI to the new
MICROCHIP / ATMEL location.

Signed-off-by: Nicolas Ferre <nicolas.fe...@microchip.com>
---
Hi,

Patch against next-20180109.
Note that I didn't find it useful to have several patches for these changes.
Tell me if you feel differently.

I would like to have the Ack from Ludovic and Wenyou obviously. I don't know if
Songjun can answer as he's not with Microchip anymore.

Best regards,
  Nicolas

 MAINTAINERS | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a7d10a2bb980..65c4b59b582f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2353,13 +2353,6 @@ L:   linux-...@vger.kernel.org
 S: Supported
 F: drivers/i2c/busses/i2c-at91.c
 
-ATMEL ISI DRIVER
-M: Ludovic Desroches <ludovic.desroc...@microchip.com>
-L: linux-media@vger.kernel.org
-S: Supported
-F: drivers/media/platform/atmel/atmel-isi.c
-F: include/media/atmel-isi.h
-
 ATMEL LCDFB DRIVER
 M: Nicolas Ferre <nicolas.fe...@microchip.com>
 L: linux-fb...@vger.kernel.org
@@ -9102,12 +9095,20 @@ S:  Maintained
 F: drivers/crypto/atmel-ecc.*
 
 MICROCHIP / ATMEL ISC DRIVER
-M: Songjun Wu <songjun...@microchip.com>
+M: Wenyou Yang <wenyou.y...@microchip.com>
 L: linux-media@vger.kernel.org
 S: Supported
 F: drivers/media/platform/atmel/atmel-isc.c
 F: drivers/media/platform/atmel/atmel-isc-regs.h
-F: devicetree/bindings/media/atmel-isc.txt
+F: Documentation/devicetree/bindings/media/atmel-isc.txt
+
+MICROCHIP / ATMEL ISI DRIVER
+M: Wenyou Yang <wenyou.y...@microchip.com>
+L: linux-media@vger.kernel.org
+S: Supported
+F: drivers/media/platform/atmel/atmel-isi.c
+F: include/media/atmel-isi.h
+F: Documentation/devicetree/bindings/media/atmel-isi.txt
 
 MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
 M: Woojung Huh <woojung@microchip.com>
-- 
2.9.0

[PATCH 2/2] MAINTAINERS: mtd/nand: update Microchip nand entry

[Nicolas Ferre]

Update Wenyou Yang email address.
Take advantage of this update to move this entry to the MICROCHIP / ATMEL
location and add the DT binding documentation link.

Signed-off-by: Nicolas Ferre <nicolas.fe...@microchip.com>
---
Hi,

Patch against next-20180109.
This patch is somehow dependent on the previous one in the series
("MAINTAINERS: linux-media: update Microchip ISI and ISC entries") but can be
rebased easily.

I don't know if it's better to have them added at the end of the development
cycle or just after rc1: let me know if you plan to take them or if I need to
rebase them for next cycle.

Best regards,
  Nicolas


 MAINTAINERS | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 65c4b59b582f..b48e217d41fb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2373,13 +2373,6 @@ F:   
Documentation/devicetree/bindings/input/atmel,maxtouch.txt
 F: drivers/input/touchscreen/atmel_mxt_ts.c
 F: include/linux/platform_data/atmel_mxt_ts.h
 
-ATMEL NAND DRIVER
-M: Wenyou Yang <wenyou.y...@atmel.com>
-M: Josh Wu <rainyfeel...@outlook.com>
-L: linux-...@lists.infradead.org
-S: Supported
-F: drivers/mtd/nand/atmel/*
-
 ATMEL SAMA5D2 ADC DRIVER
 M: Ludovic Desroches <ludovic.desroc...@microchip.com>
 L: linux-...@vger.kernel.org
@@ -9110,6 +9103,14 @@ F:   drivers/media/platform/atmel/atmel-isi.c
 F: include/media/atmel-isi.h
 F: Documentation/devicetree/bindings/media/atmel-isi.txt
 
+MICROCHIP / ATMEL NAND DRIVER
+M: Wenyou Yang <wenyou.y...@microchip.com>
+M: Josh Wu <rainyfeel...@outlook.com>
+L: linux-...@lists.infradead.org
+S: Supported
+F: drivers/mtd/nand/atmel/*
+F: Documentation/devicetree/bindings/mtd/atmel-nand.txt
+
 MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
 M: Woojung Huh <woojung@microchip.com>
 M: Microchip Linux Driver Support <unglinuxdri...@microchip.com>
-- 
2.9.0

[RFT PATCH v2 1/6] uvcvideo: Refactor URB descriptors

[Kieran Bingham]

We currently store three separate arrays for each URB reference we hold.

Objectify the data needed to track URBs into a single uvc_urb structure,
allowing better object management and tracking of the URB.

All accesses to the data pointers through stream, are converted to use a
uvc_urb pointer for consistency.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 

---
v2:
 - Re-describe URB context structure
 - Re-name uvc_urb->{urb_buffer,urb_dma}{buffer,dma}

 drivers/media/usb/uvc/uvc_video.c | 49 +++-
 drivers/media/usb/uvc/uvcvideo.h  | 18 ++--
 2 files changed, 45 insertions(+), 22 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_video.c 
b/drivers/media/usb/uvc/uvc_video.c
index 73cd44e8bd81..e57c5f52c73b 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1357,14 +1357,16 @@ static void uvc_free_urb_buffers(struct uvc_streaming 
*stream)
unsigned int i;
 
for (i = 0; i < UVC_URBS; ++i) {
-   if (stream->urb_buffer[i]) {
+   struct uvc_urb *uvc_urb = >uvc_urb[i];
+
+   if (uvc_urb->buffer) {
 #ifndef CONFIG_DMA_NONCOHERENT
usb_free_coherent(stream->dev->udev, stream->urb_size,
-   stream->urb_buffer[i], stream->urb_dma[i]);
+   uvc_urb->buffer, uvc_urb->dma);
 #else
-   kfree(stream->urb_buffer[i]);
+   kfree(uvc_urb->buffer);
 #endif
-   stream->urb_buffer[i] = NULL;
+   uvc_urb->buffer = NULL;
}
}
 
@@ -1402,16 +1404,18 @@ static int uvc_alloc_urb_buffers(struct uvc_streaming 
*stream,
/* Retry allocations until one succeed. */
for (; npackets > 1; npackets /= 2) {
for (i = 0; i < UVC_URBS; ++i) {
+   struct uvc_urb *uvc_urb = >uvc_urb[i];
+
stream->urb_size = psize * npackets;
 #ifndef CONFIG_DMA_NONCOHERENT
-   stream->urb_buffer[i] = usb_alloc_coherent(
+   uvc_urb->buffer = usb_alloc_coherent(
stream->dev->udev, stream->urb_size,
-   gfp_flags | __GFP_NOWARN, >urb_dma[i]);
+   gfp_flags | __GFP_NOWARN, _urb->dma);
 #else
-   stream->urb_buffer[i] =
+   uvc_urb->buffer =
kmalloc(stream->urb_size, gfp_flags | __GFP_NOWARN);
 #endif
-   if (!stream->urb_buffer[i]) {
+   if (!uvc_urb->buffer) {
uvc_free_urb_buffers(stream);
break;
}
@@ -1441,13 +1445,15 @@ static void uvc_uninit_video(struct uvc_streaming 
*stream, int free_buffers)
uvc_video_stats_stop(stream);
 
for (i = 0; i < UVC_URBS; ++i) {
-   urb = stream->urb[i];
+   struct uvc_urb *uvc_urb = >uvc_urb[i];
+
+   urb = uvc_urb->urb;
if (urb == NULL)
continue;
 
usb_kill_urb(urb);
usb_free_urb(urb);
-   stream->urb[i] = NULL;
+   uvc_urb->urb = NULL;
}
 
if (free_buffers)
@@ -1502,6 +1508,8 @@ static int uvc_init_video_isoc(struct uvc_streaming 
*stream,
size = npackets * psize;
 
for (i = 0; i < UVC_URBS; ++i) {
+   struct uvc_urb *uvc_urb = >uvc_urb[i];
+
urb = usb_alloc_urb(npackets, gfp_flags);
if (urb == NULL) {
uvc_uninit_video(stream, 1);
@@ -1514,12 +1522,12 @@ static int uvc_init_video_isoc(struct uvc_streaming 
*stream,
ep->desc.bEndpointAddress);
 #ifndef CONFIG_DMA_NONCOHERENT
urb->transfer_flags = URB_ISO_ASAP | URB_NO_TRANSFER_DMA_MAP;
-   urb->transfer_dma = stream->urb_dma[i];
+   urb->transfer_dma = uvc_urb->dma;
 #else
urb->transfer_flags = URB_ISO_ASAP;
 #endif
urb->interval = ep->desc.bInterval;
-   urb->transfer_buffer = stream->urb_buffer[i];
+   urb->transfer_buffer = uvc_urb->buffer;
urb->complete = uvc_video_complete;
urb->number_of_packets = npackets;
urb->transfer_buffer_length = size;
@@ -1529,7 +1537,7 @@ static int uvc_init_video_isoc(struct uvc_streaming 
*stream,
urb->iso_frame_desc[j].length = psize;
}
 
-   stream->urb[i] = urb;
+   uvc_urb->urb = urb;
}
 
return 0;
@@ -1568,21 +1576,22 @@ static int uvc_init_video_bulk(struct uvc_streaming 
*stream,
size = 0;
 
for (i = 0; i < UVC_URBS; ++i) {
+ 

[RFT PATCH v2 5/6] uvcvideo: queue: Support asynchronous buffer handling

[Kieran Bingham]

The buffer queue interface currently operates sequentially, processing
buffers after they have fully completed.

In preparation for supporting parallel tasks operating on the buffers,
we will need to support buffers being processed on multiple CPUs.

Adapt the uvc_queue_next_buffer() such that a reference count tracks the
active use of the buffer, returning the buffer to the VB2 stack at
completion.

Signed-off-by: Kieran Bingham 
---
 drivers/media/usb/uvc/uvc_queue.c | 61 ++--
 drivers/media/usb/uvc/uvcvideo.h  |  4 ++-
 2 files changed, 54 insertions(+), 11 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_queue.c 
b/drivers/media/usb/uvc/uvc_queue.c
index ddac4d89a291..5a9987e547d3 100644
--- a/drivers/media/usb/uvc/uvc_queue.c
+++ b/drivers/media/usb/uvc/uvc_queue.c
@@ -131,6 +131,7 @@ static void uvc_buffer_queue(struct vb2_buffer *vb)
 
spin_lock_irqsave(>irqlock, flags);
if (likely(!(queue->flags & UVC_QUEUE_DISCONNECTED))) {
+   kref_init(>ref);
list_add_tail(>queue, >irqqueue);
} else {
/* If the device is disconnected return the buffer to userspace
@@ -424,28 +425,66 @@ struct uvc_buffer *uvc_queue_get_current_buffer(struct 
uvc_video_queue *queue)
return nextbuf;
 }
 
-struct uvc_buffer *uvc_queue_next_buffer(struct uvc_video_queue *queue,
+/*
+ * uvc_queue_requeue: Requeue a buffer on our internal irqqueue
+ *
+ * Reuse a buffer through our internal queue without the need to 'prepare'
+ * The buffer will be returned to userspace through the uvc_buffer_queue call 
if
+ * the device has been disconnected
+ */
+static void uvc_queue_requeue(struct uvc_video_queue *queue,
struct uvc_buffer *buf)
 {
-   struct uvc_buffer *nextbuf;
-   unsigned long flags;
+   buf->error = 0;
+   buf->state = UVC_BUF_STATE_QUEUED;
+   buf->bytesused = 0;
+   vb2_set_plane_payload(>buf.vb2_buf, 0, 0);
+
+   uvc_buffer_queue(>buf.vb2_buf);
+}
+
+static void uvc_queue_buffer_complete(struct kref *ref)
+{
+   struct uvc_buffer *buf = container_of(ref, struct uvc_buffer, ref);
+   struct vb2_buffer *vb = >buf.vb2_buf;
+   struct uvc_video_queue *queue = vb2_get_drv_priv(vb->vb2_queue);
 
if ((queue->flags & UVC_QUEUE_DROP_CORRUPTED) && buf->error) {
-   buf->error = 0;
-   buf->state = UVC_BUF_STATE_QUEUED;
-   buf->bytesused = 0;
-   vb2_set_plane_payload(>buf.vb2_buf, 0, 0);
-   return buf;
+   uvc_queue_requeue(queue, buf);
+   return;
}
 
+   buf->state = buf->error ? UVC_BUF_STATE_ERROR : UVC_BUF_STATE_DONE;
+   vb2_set_plane_payload(>buf.vb2_buf, 0, buf->bytesused);
+   vb2_buffer_done(>buf.vb2_buf, VB2_BUF_STATE_DONE);
+}
+
+/*
+ * Release a reference on the buffer. Complete the buffer when the last
+ * reference is released
+ */
+void uvc_queue_buffer_release(struct uvc_buffer *buf)
+{
+   kref_put(>ref, uvc_queue_buffer_complete);
+}
+
+/*
+ * Remove this buffer from the queue. Lifetime will persist while async actions
+ * are still running (if any), and uvc_queue_buffer_release will give the 
buffer
+ * back to VB2 when all users have completed.
+ */
+struct uvc_buffer *uvc_queue_next_buffer(struct uvc_video_queue *queue,
+   struct uvc_buffer *buf)
+{
+   struct uvc_buffer *nextbuf;
+   unsigned long flags;
+
spin_lock_irqsave(>irqlock, flags);
list_del(>queue);
nextbuf = __uvc_queue_get_current_buffer(queue);
spin_unlock_irqrestore(>irqlock, flags);
 
-   buf->state = buf->error ? UVC_BUF_STATE_ERROR : UVC_BUF_STATE_DONE;
-   vb2_set_plane_payload(>buf.vb2_buf, 0, buf->bytesused);
-   vb2_buffer_done(>buf.vb2_buf, VB2_BUF_STATE_DONE);
+   uvc_queue_buffer_release(buf);
 
return nextbuf;
 }
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 5caa1f4de3cb..6a18dbfc3e5b 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -404,6 +404,9 @@ struct uvc_buffer {
unsigned int bytesused;
 
u32 pts;
+
+   /* asynchronous buffer handling */
+   struct kref ref;
 };
 
 #define UVC_QUEUE_DISCONNECTED (1 << 0)
@@ -696,6 +699,7 @@ extern struct uvc_buffer *
uvc_queue_get_current_buffer(struct uvc_video_queue *queue);
 extern struct uvc_buffer *uvc_queue_next_buffer(struct uvc_video_queue *queue,
struct uvc_buffer *buf);
+extern void uvc_queue_buffer_release(struct uvc_buffer *buf);
 extern int uvc_queue_mmap(struct uvc_video_queue *queue,
struct vm_area_struct *vma);
 extern unsigned int uvc_queue_poll(struct uvc_video_queue *queue,
-- 
git-series 0.9.1

[RFT PATCH v2 6/6] uvcvideo: Move decode processing to process context

[Kieran Bingham]

Newer high definition cameras, and cameras with multiple lenses such as
the range of stereo-vision cameras now available have ever increasing
data rates.

The inclusion of a variable length packet header in URB packets mean
that we must memcpy the frame data out to our destination 'manually'.
This can result in data rates of up to 2 gigabits per second being
processed.

To improve efficiency, and maximise throughput, handle the URB decode
processing through a work queue to move it from interrupt context, and
allow multiple processors to work on URBs in parallel.

Signed-off-by: Kieran Bingham 

---
v2:
 - Lock full critical section of usb_submit_urb()

 drivers/media/usb/uvc/uvc_queue.c |  12 +++-
 drivers/media/usb/uvc/uvc_video.c | 111 +--
 drivers/media/usb/uvc/uvcvideo.h  |  24 +++-
 3 files changed, 129 insertions(+), 18 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_queue.c 
b/drivers/media/usb/uvc/uvc_queue.c
index 5a9987e547d3..598087eeb5c2 100644
--- a/drivers/media/usb/uvc/uvc_queue.c
+++ b/drivers/media/usb/uvc/uvc_queue.c
@@ -179,10 +179,22 @@ static void uvc_stop_streaming(struct vb2_queue *vq)
struct uvc_video_queue *queue = vb2_get_drv_priv(vq);
struct uvc_streaming *stream = uvc_queue_to_stream(queue);
 
+   /* Prevent new buffers coming in. */
+   spin_lock_irq(>irqlock);
+   queue->flags |= UVC_QUEUE_STOPPING;
+   spin_unlock_irq(>irqlock);
+
+   /*
+* All pending work should be completed before disabling the stream, as
+* all URBs will be free'd during uvc_video_enable(s, 0).
+*/
+   flush_workqueue(stream->async_wq);
+
uvc_video_enable(stream, 0);
 
spin_lock_irq(>irqlock);
uvc_queue_return_buffers(queue, UVC_BUF_STATE_ERROR);
+   queue->flags &= ~UVC_QUEUE_STOPPING;
spin_unlock_irq(>irqlock);
 }
 
diff --git a/drivers/media/usb/uvc/uvc_video.c 
b/drivers/media/usb/uvc/uvc_video.c
index 3878bec3276e..a9ddc4f27012 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1058,21 +1058,67 @@ static int uvc_video_decode_start(struct uvc_streaming 
*stream,
return data[0];
 }
 
-static void uvc_video_decode_data(struct uvc_streaming *stream,
-   struct uvc_buffer *buf, const __u8 *data, int len)
+/*
+ * uvc_video_decode_data_work: Asynchronous memcpy processing
+ *
+ * Perform memcpy tasks in process context, with completion handlers
+ * to return the URB, and buffer handles.
+ *
+ * The work submitter must pre-determine that the work is safe
+ */
+static void uvc_video_decode_data_work(struct work_struct *work)
 {
-   unsigned int maxlen, nbytes;
-   void *mem;
+   struct uvc_urb *uvc_urb = container_of(work, struct uvc_urb, work);
+   struct uvc_streaming *stream = uvc_urb->stream;
+   struct uvc_video_queue *queue = >queue;
+   unsigned int i;
+   int ret;
+
+   for (i = 0; i < uvc_urb->packets; i++) {
+   struct uvc_decode_op *op = _urb->decodes[i];
+
+   memcpy(op->dst, op->src, op->len);
+
+   /* Release reference taken on this buffer */
+   uvc_queue_buffer_release(op->buf);
+   }
+
+   /*
+* Prevent resubmitting URBs when shutting down to ensure that no new
+* work item will be scheduled after uvc_stop_streaming() flushes the
+* work queue.
+*/
+   spin_lock_irq(>irqlock);
+   if (!(queue->flags & UVC_QUEUE_STOPPING)) {
+   ret = usb_submit_urb(uvc_urb->urb, GFP_ATOMIC);
+   if (ret < 0)
+   uvc_printk(KERN_ERR,
+  "Failed to resubmit video URB (%d).\n",
+  ret);
+   }
+   spin_unlock_irq(>irqlock);
+}
+
+static void uvc_video_decode_data(struct uvc_decode_op *decode,
+   struct uvc_urb *uvc_urb, struct uvc_buffer *buf,
+   const __u8 *data, int len)
+{
+   unsigned int maxlen;
 
if (len <= 0)
return;
 
-   /* Copy the video data to the buffer. */
maxlen = buf->length - buf->bytesused;
-   mem = buf->mem + buf->bytesused;
-   nbytes = min((unsigned int)len, maxlen);
-   memcpy(mem, data, nbytes);
-   buf->bytesused += nbytes;
+
+   /* Take a buffer reference for async work */
+   kref_get(>ref);
+
+   decode->buf = buf;
+   decode->src = data;
+   decode->dst = buf->mem + buf->bytesused;
+   decode->len = min_t(unsigned int, len, maxlen);
+
+   buf->bytesused += decode->len;
 
/* Complete the current frame if the buffer size was exceeded. */
if (len > maxlen) {
@@ -1080,6 +1126,8 @@ static void uvc_video_decode_data(struct uvc_streaming 
*stream,
buf->error = 1;
buf->state = UVC_BUF_STATE_READY;
}
+
+   uvc_urb->packets++;
 }
 
 static void 

[RFT PATCH v2 2/6] uvcvideo: Convert decode functions to use new context structure

[Kieran Bingham]

The URB completion handlers currently reference the stream context.

Now that each URB has its own context structure, convert the decode (and
one encode) functions to utilise this context for URB management.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 

---
v2:
 - fix checkpatch warning (pre-existing in code)

 drivers/media/usb/uvc/uvc_isight.c |  4 +++-
 drivers/media/usb/uvc/uvc_video.c  | 32 ---
 drivers/media/usb/uvc/uvcvideo.h   |  8 
 3 files changed, 28 insertions(+), 16 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_isight.c 
b/drivers/media/usb/uvc/uvc_isight.c
index 8510e7259e76..433b8b4f96e2 100644
--- a/drivers/media/usb/uvc/uvc_isight.c
+++ b/drivers/media/usb/uvc/uvc_isight.c
@@ -99,9 +99,11 @@ static int isight_decode(struct uvc_video_queue *queue, 
struct uvc_buffer *buf,
return 0;
 }
 
-void uvc_video_decode_isight(struct urb *urb, struct uvc_streaming *stream,
+void uvc_video_decode_isight(struct uvc_urb *uvc_urb,
struct uvc_buffer *buf)
 {
+   struct urb *urb = uvc_urb->urb;
+   struct uvc_streaming *stream = uvc_urb->stream;
int ret, i;
 
for (i = 0; i < urb->number_of_packets; ++i) {
diff --git a/drivers/media/usb/uvc/uvc_video.c 
b/drivers/media/usb/uvc/uvc_video.c
index e57c5f52c73b..92bd0952a66e 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1153,9 +1153,11 @@ static void uvc_video_validate_buffer(const struct 
uvc_streaming *stream,
 /*
  * Completion handler for video URBs.
  */
-static void uvc_video_decode_isoc(struct urb *urb, struct uvc_streaming 
*stream,
-   struct uvc_buffer *buf)
+static void uvc_video_decode_isoc(struct uvc_urb *uvc_urb,
+   struct uvc_buffer *buf)
 {
+   struct urb *urb = uvc_urb->urb;
+   struct uvc_streaming *stream = uvc_urb->stream;
u8 *mem;
int ret, i;
 
@@ -1199,9 +1201,11 @@ static void uvc_video_decode_isoc(struct urb *urb, 
struct uvc_streaming *stream,
}
 }
 
-static void uvc_video_decode_bulk(struct urb *urb, struct uvc_streaming 
*stream,
-   struct uvc_buffer *buf)
+static void uvc_video_decode_bulk(struct uvc_urb *uvc_urb,
+   struct uvc_buffer *buf)
 {
+   struct urb *urb = uvc_urb->urb;
+   struct uvc_streaming *stream = uvc_urb->stream;
u8 *mem;
int len, ret;
 
@@ -1266,9 +1270,12 @@ static void uvc_video_decode_bulk(struct urb *urb, 
struct uvc_streaming *stream,
}
 }
 
-static void uvc_video_encode_bulk(struct urb *urb, struct uvc_streaming 
*stream,
-   struct uvc_buffer *buf)
+static void uvc_video_encode_bulk(struct uvc_urb *uvc_urb,
+   struct uvc_buffer *buf)
 {
+   struct urb *urb = uvc_urb->urb;
+   struct uvc_streaming *stream = uvc_urb->stream;
+
u8 *mem = urb->transfer_buffer;
int len = stream->urb_size, ret;
 
@@ -1311,7 +1318,8 @@ static void uvc_video_encode_bulk(struct urb *urb, struct 
uvc_streaming *stream,
 
 static void uvc_video_complete(struct urb *urb)
 {
-   struct uvc_streaming *stream = urb->context;
+   struct uvc_urb *uvc_urb = urb->context;
+   struct uvc_streaming *stream = uvc_urb->stream;
struct uvc_video_queue *queue = >queue;
struct uvc_buffer *buf = NULL;
unsigned long flags;
@@ -1341,7 +1349,7 @@ static void uvc_video_complete(struct urb *urb)
   queue);
spin_unlock_irqrestore(>irqlock, flags);
 
-   stream->decode(urb, stream, buf);
+   stream->decode(uvc_urb, buf);
 
if ((ret = usb_submit_urb(urb, GFP_ATOMIC)) < 0) {
uvc_printk(KERN_ERR, "Failed to resubmit video URB (%d).\n",
@@ -1419,6 +1427,8 @@ static int uvc_alloc_urb_buffers(struct uvc_streaming 
*stream,
uvc_free_urb_buffers(stream);
break;
}
+
+   uvc_urb->stream = stream;
}
 
if (i == UVC_URBS) {
@@ -1517,7 +1527,7 @@ static int uvc_init_video_isoc(struct uvc_streaming 
*stream,
}
 
urb->dev = stream->dev->udev;
-   urb->context = stream;
+   urb->context = uvc_urb;
urb->pipe = usb_rcvisocpipe(stream->dev->udev,
ep->desc.bEndpointAddress);
 #ifndef CONFIG_DMA_NONCOHERENT
@@ -1584,8 +1594,8 @@ static int uvc_init_video_bulk(struct uvc_streaming 
*stream,
return -ENOMEM;
}
 
-   usb_fill_bulk_urb(urb, stream->dev->udev, pipe, uvc_urb->buffer,
- size, uvc_video_complete, stream);
+   usb_fill_bulk_urb(urb, stream->dev->udev, pipe, uvc_urb->buffer,
+ size, uvc_video_complete, uvc_urb);
 #ifndef CONFIG_DMA_NONCOHERENT
   

[RFT PATCH v2 4/6] uvcvideo: queue: Simplify spin-lock usage

[Kieran Bingham]

Both uvc_start_streaming(), and uvc_stop_streaming() are called from
userspace context. As such, they do not need to save the IRQ state, and
can use spin_lock_irq() and spin_unlock_irq() respectively.

Signed-off-by: Kieran Bingham 
---
 drivers/media/usb/uvc/uvc_queue.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_queue.c 
b/drivers/media/usb/uvc/uvc_queue.c
index 4a581d631525..ddac4d89a291 100644
--- a/drivers/media/usb/uvc/uvc_queue.c
+++ b/drivers/media/usb/uvc/uvc_queue.c
@@ -158,7 +158,6 @@ static int uvc_start_streaming(struct vb2_queue *vq, 
unsigned int count)
 {
struct uvc_video_queue *queue = vb2_get_drv_priv(vq);
struct uvc_streaming *stream = uvc_queue_to_stream(queue);
-   unsigned long flags;
int ret;
 
queue->buf_used = 0;
@@ -167,9 +166,9 @@ static int uvc_start_streaming(struct vb2_queue *vq, 
unsigned int count)
if (ret == 0)
return 0;
 
-   spin_lock_irqsave(>irqlock, flags);
+   spin_lock_irq(>irqlock);
uvc_queue_return_buffers(queue, UVC_BUF_STATE_QUEUED);
-   spin_unlock_irqrestore(>irqlock, flags);
+   spin_unlock_irq(>irqlock);
 
return ret;
 }
@@ -178,13 +177,12 @@ static void uvc_stop_streaming(struct vb2_queue *vq)
 {
struct uvc_video_queue *queue = vb2_get_drv_priv(vq);
struct uvc_streaming *stream = uvc_queue_to_stream(queue);
-   unsigned long flags;
 
uvc_video_enable(stream, 0);
 
-   spin_lock_irqsave(>irqlock, flags);
+   spin_lock_irq(>irqlock);
uvc_queue_return_buffers(queue, UVC_BUF_STATE_ERROR);
-   spin_unlock_irqrestore(>irqlock, flags);
+   spin_unlock_irq(>irqlock);
 }
 
 static const struct vb2_ops uvc_queue_qops = {
-- 
git-series 0.9.1

[RFT PATCH v2 3/6] uvcvideo: Protect queue internals with helper

[Kieran Bingham]

The URB completion operation obtains the current buffer by reading
directly into the queue internal interface.

Protect this queue abstraction by providing a helper
uvc_queue_get_current_buffer() which can be used by both the decode
task, and the uvc_queue_next_buffer() functions.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 

---

v2:
 - Fix coding style of conditional statements

 drivers/media/usb/uvc/uvc_queue.c | 33 +++-
 drivers/media/usb/uvc/uvc_video.c |  7 +--
 drivers/media/usb/uvc/uvcvideo.h  |  2 ++-
 3 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_queue.c 
b/drivers/media/usb/uvc/uvc_queue.c
index c8d78b2f3de4..4a581d631525 100644
--- a/drivers/media/usb/uvc/uvc_queue.c
+++ b/drivers/media/usb/uvc/uvc_queue.c
@@ -399,6 +399,33 @@ void uvc_queue_cancel(struct uvc_video_queue *queue, int 
disconnect)
spin_unlock_irqrestore(>irqlock, flags);
 }
 
+/*
+ * uvc_queue_get_current_buffer: Obtain the current working output buffer
+ *
+ * Buffers may span multiple packets, and even URBs, therefore the active 
buffer
+ * remains on the queue until the EOF marker.
+ */
+static struct uvc_buffer *
+__uvc_queue_get_current_buffer(struct uvc_video_queue *queue)
+{
+   if (list_empty(>irqqueue))
+   return NULL;
+
+   return list_first_entry(>irqqueue, struct uvc_buffer, queue);
+}
+
+struct uvc_buffer *uvc_queue_get_current_buffer(struct uvc_video_queue *queue)
+{
+   struct uvc_buffer *nextbuf;
+   unsigned long flags;
+
+   spin_lock_irqsave(>irqlock, flags);
+   nextbuf = __uvc_queue_get_current_buffer(queue);
+   spin_unlock_irqrestore(>irqlock, flags);
+
+   return nextbuf;
+}
+
 struct uvc_buffer *uvc_queue_next_buffer(struct uvc_video_queue *queue,
struct uvc_buffer *buf)
 {
@@ -415,11 +442,7 @@ struct uvc_buffer *uvc_queue_next_buffer(struct 
uvc_video_queue *queue,
 
spin_lock_irqsave(>irqlock, flags);
list_del(>queue);
-   if (!list_empty(>irqqueue))
-   nextbuf = list_first_entry(>irqqueue, struct uvc_buffer,
-  queue);
-   else
-   nextbuf = NULL;
+   nextbuf = __uvc_queue_get_current_buffer(queue);
spin_unlock_irqrestore(>irqlock, flags);
 
buf->state = buf->error ? UVC_BUF_STATE_ERROR : UVC_BUF_STATE_DONE;
diff --git a/drivers/media/usb/uvc/uvc_video.c 
b/drivers/media/usb/uvc/uvc_video.c
index 92bd0952a66e..3878bec3276e 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1322,7 +1322,6 @@ static void uvc_video_complete(struct urb *urb)
struct uvc_streaming *stream = uvc_urb->stream;
struct uvc_video_queue *queue = >queue;
struct uvc_buffer *buf = NULL;
-   unsigned long flags;
int ret;
 
switch (urb->status) {
@@ -1343,11 +1342,7 @@ static void uvc_video_complete(struct urb *urb)
return;
}
 
-   spin_lock_irqsave(>irqlock, flags);
-   if (!list_empty(>irqqueue))
-   buf = list_first_entry(>irqqueue, struct uvc_buffer,
-  queue);
-   spin_unlock_irqrestore(>irqlock, flags);
+   buf = uvc_queue_get_current_buffer(queue);
 
stream->decode(uvc_urb, buf);
 
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 81a9a419a423..5caa1f4de3cb 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -692,6 +692,8 @@ extern int uvc_queue_streamon(struct uvc_video_queue *queue,
 extern int uvc_queue_streamoff(struct uvc_video_queue *queue,
   enum v4l2_buf_type type);
 extern void uvc_queue_cancel(struct uvc_video_queue *queue, int disconnect);
+extern struct uvc_buffer *
+   uvc_queue_get_current_buffer(struct uvc_video_queue *queue);
 extern struct uvc_buffer *uvc_queue_next_buffer(struct uvc_video_queue *queue,
struct uvc_buffer *buf);
 extern int uvc_queue_mmap(struct uvc_video_queue *queue,
-- 
git-series 0.9.1

[RFT PATCH v2 0/6] Asynchronous UVC

[Kieran Bingham]

The Linux UVC driver has long provided adequate performance capabilities for
web-cams and low data rate video devices in Linux while resolutions were low.

Modern USB cameras are now capable of high data rates thanks to USB3 with
1080p, and even 4k capture resolutions supported.

Cameras such as the Stereolabs ZED or the Logitech Brio can generate more data
than an embedded ARM core is able to process on a single core, resulting in
frame loss.

A large part of this performance impact is from the requirement to
‘memcpy’ frames out from URB packets to destination frames. This unfortunate
requirement is due to the UVC protocol allowing a variable length header, and
thus it is not possible to provide the target frame buffers directly.

Extra throughput is possible by moving the actual memcpy actions to a work
queue, and moving the memcpy out of interrupt context and allowing work tasks
to be scheduled across multiple cores.

This series has been tested on both the ZED and Brio cameras on arm64
platforms, however due to the intrinsic changes in the driver I would like to
see it tested with other devices and other platforms, so I'd appreciate if
anyone can test this on a range of USB cameras.

v2:
 - Fix up comments and issues raised by Guennadi

Kieran Bingham (6):
  uvcvideo: Refactor URB descriptors
  uvcvideo: Convert decode functions to use new context structure
  uvcvideo: Protect queue internals with helper
  uvcvideo: queue: Simplify spin-lock usage
  uvcvideo: queue: Support asynchronous buffer handling
  uvcvideo: Move decode processing to process context

 drivers/media/usb/uvc/uvc_isight.c |   4 +-
 drivers/media/usb/uvc/uvc_queue.c  | 114 ++
 drivers/media/usb/uvc/uvc_video.c  | 189 ++
 drivers/media/usb/uvc/uvcvideo.h   |  56 +++--
 4 files changed, 285 insertions(+), 78 deletions(-)

base-commit: 6f0e5fd39143a59c22d60e7befc4f33f22aeed2f
-- 
git-series 0.9.1

Re: [PATCH 7/9] lgdt3306a: Set fe ops.release to NULL if probed

[Michael Ira Krufky]

On Tue, Jan 9, 2018 at 12:17 AM, Matthias Schwarzott  wrote:
> Am 05.01.2018 um 01:19 schrieb Michael Ira Krufky:
>> On Thu, Jan 4, 2018 at 7:04 PM, Brad Love  wrote:
>>> If release is part of frontend ops then it is called in the
>>> course of dvb_frontend_detach. The process also decrements
>>> the module usage count. The problem is if the lgdt3306a
>>> driver is reached via i2c_new_device, then when it is
>>> eventually destroyed remove is called, which further
>>> decrements the module usage count to negative. After this
>>> occurs the driver is in a bad state and no longer works.
>>> Also fixed by NULLing out the release callback is a double
>>> kfree of state, which introduces arbitrary oopses/GPF.
>>> This problem is only currently reachable via the em28xx driver.
>>>
>>> On disconnect of Hauppauge SoloHD before:
>>>
>>> lsmod | grep lgdt3306a
>>> lgdt3306a  28672  -1
>>> i2c_mux16384  1 lgdt3306a
>>>
>>> On disconnect of Hauppauge SoloHD after:
>>>
>>> lsmod | grep lgdt3306a
>>> lgdt3306a  28672  0
>>> i2c_mux16384  1 lgdt3306a
>>>
>>> Signed-off-by: Brad Love 
>>> ---
>>>  drivers/media/dvb-frontends/lgdt3306a.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>
>> Brad,
>>
>> We won't be able to apply this one.  The symptom that you're trying to
>> fix is indicative of some other problem, probably in the em28xx
>> driver.  NULL'ing the release callback is not the right thing to do.
>>
>
> Hi Mike,
> Why do you nak this perfectly fine patch?
> Let me start to explain.
>
> dvb_attach style drivers have an attach function and for unloading a
> .release callback.
>
> i2c-style drivers have a probe and a remove function.
>
> Mixed style drivers must be constructed, that either release or remove
> is called, never both.
> They both do the same thing, but with different signature.
>
>
> Now checking lgdt3306a driver:
>
> dvb attach style:
> In lgdt3306a_attach the release callback is set to lgdt3306a_release and
> no remove exists. Fine.
>
> i2c style probe:
> struct i2c_driver contains lgdt3306a_probe and lgdt3306a_remove.
> lgdt3306a_probe shares code and calls lgdt3306a_attach, but afterwards
> the release callback field must be set to NULL.
>
> This is/was done exactly like this in multiple other drivers as long as
> they have been multiple style attachable.
>
> Regards
> Matthias
>
>>
>>> diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
>>> b/drivers/media/dvb-frontends/lgdt3306a.c
>>> index 6356815..d2477ed 100644
>>> --- a/drivers/media/dvb-frontends/lgdt3306a.c
>>> +++ b/drivers/media/dvb-frontends/lgdt3306a.c
>>> @@ -2177,6 +2177,7 @@ static int lgdt3306a_probe(struct i2c_client *client,
>>>
>>> i2c_set_clientdata(client, fe->demodulator_priv);
>>> state = fe->demodulator_priv;
>>> +   state->frontend.ops.release = NULL;
>>>
>>> /* create mux i2c adapter for tuner */
>>> state->muxc = i2c_mux_alloc(client->adapter, >dev,
>>> --
>>> 2.7.4
>>>
>>
>

Brad & Matthias,

It makes sense.  This is just a result of a transitional period where
there are multiple APIs for attaching the driver.  Hopefully we can
consolidate soon.

I will look at the other drivers when I have time later on, but you're
probably right, and we will likely end up merging this one after all.

I'll try to get a PR out to Mauro by the weekend.

-Mike

Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

[Hans Verkuil]

First of all a Happy New Year for all of you!

And secondly: can this v5 patch series be reviewed/merged? It's been waiting
for that for a very long time now...

Regards,

Hans

On 12/11/17 09:57, Hans Verkuil wrote:
> Ping again. Added a CC to Ville whom I inexplicably forgot to add when
> I sent the v5 patch series.
> 
> Regards,
> 
>   Hans
> 
> On 01/12/17 08:23, Hans Verkuil wrote:
>> Ping!
>>
>> I really like to get this in for 4.16 so I can move forward with hooking
>> this up for nouveau/amd.
>>
>> Regards,
>>
>>  Hans
>>
>> On 11/20/2017 12:42 PM, Hans Verkuil wrote:
>>> This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
>>> feature. This patch series is based on the 4.14 mainline release but applies
>>> as well to drm-next.
>>>
>>> This patch series has been tested with my NUC7i5BNK, a Samsung USB-C to 
>>> HDMI adapter and a Club 3D DisplayPort MST Hub + modified UpTab DP-to-HDMI
>>> adapter (where the CEC pin is wired up).
>>>
>>> Please note this comment at the start of drm_dp_cec.c:
>>>
>>> --
>>> Unfortunately it turns out that we have a chicken-and-egg situation
>>> here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
>>> have a converter chip that supports CEC-Tunneling-over-AUX (usually the
>>> Parade PS176 or MegaChips MCDP2900), but they do not wire up the CEC pin,
>>> thus making CEC useless.
>>>
>>> Sadly there is no way for this driver to know this. What happens is
>>> that a /dev/cecX device is created that is isolated and unable to see
>>> any of the other CEC devices. Quite literally the CEC wire is cut
>>> (or in this case, never connected in the first place).
>>>
>>> I suspect that the reason so few adapters support this is that this
>>> tunneling protocol was never supported by any OS. So there was no
>>> easy way of testing it, and no incentive to correctly wire up the
>>> CEC pin.
>>>
>>> Hopefully by creating this driver it will be easier for vendors to
>>> finally fix their adapters and test the CEC functionality.
>>>
>>> I keep a list of known working adapters here:
>>>
>>> https://hverkuil.home.xs4all.nl/cec-status.txt
>>>
>>> Please mail me (hverk...@xs4all.nl) if you find an adapter that works
>>> and is not yet listed there.
>>>
>>> Note that the current implementation does not support CEC over an MST hub.
>>> As far as I can see there is no mechanism defined in the DisplayPort
>>> standard to transport CEC interrupts over an MST device. It might be
>>> possible to do this through polling, but I have not been able to get that
>>> to work.
>>> --
>>>
>>> I really hope that this work will provide an incentive for vendors to
>>> finally connect the CEC pin. It's a shame that there are so few adapters
>>> that work (I found only two USB-C to HDMI adapters that work, and no
>>> (mini-)DP to HDMI adapters at all).
>>>
>>> Hopefully if this gets merged there will be an incentive for vendors
>>> to make adapters where this actually works. It is a very nice feature
>>> for HTPC boxes.
>>>
>>> The main reason why this v5 is delayed by 2 months is due to the fact
>>> that I needed some dedicated time to investigate what happens when an
>>> MST hub is in use. It turns out that this is not working. There is no
>>> mechanism defined in the DisplayPort standard to transport the CEC
>>> interrupt back up the MST chain. I was actually able to send a CEC
>>> message but the interrupt that tells when the transmit finished is
>>> unavailable.
>>>
>>> I attempted to implement this via polling, but I got weird errors
>>> and was not able to read the DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1
>>> register. I decided to give up on this for now and just disable CEC
>>> for DP-to-HDMI adapters after an MST hub. I plan to revisit this
>>> later since it would be neat to make this work as well. Although it
>>> might not be possible at all.
>>>
>>> If anyone is interested, work-in-progress for this is here:
>>>
>>> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=dp-cec-mst
>>>
>>> Note that I removed the Tested-by tag from Carlos Santa due to the
>>> almost complete rework of the third patch. Carlos, can you test this again?
>>>
>>> Regards,
>>>
>>> Hans
>>>
>>> Changes since v4:
>>>
>>> - Updated comment at the start of drm_dp_cec.c
>>> - Add edid pointer to drm_dp_cec_configure_adapter
>>> - Reworked the last patch (adding CEC to i915) based on Ville's comments
>>>   and my MST testing:
>>> - register/unregister CEC in intel_dp_connector_register/unregister
>>> - add comment and check if connector is registered in long_pulse
>>> - unregister CEC if an MST 'connector' is detected.
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-de...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>
>> 

RE: [PATCH v5 0/5] Add OV5640 parallel interface and RGB565/YUYV support

[Fabrizio Castro]

Hello Hugues,

thank you for getting back to me, I'll look into your suggestions in the next 
few days, I'll give you a feedback as soon as I know more.

Thanks,
Fab

> Subject: Re: [PATCH v5 0/5] Add OV5640 parallel interface and RGB565/YUYV 
> support
>
> Hi Fabrizio,
>
> Happy to see that this patch series is of interest ;)
>
> As you can see in mail thread, Maxime Ripard is also testing it:
> https://www.mail-archive.com/linux-media@vger.kernel.org/msg124322.html
>
> For BT656 support, it was not initially planned but it seems
> straightforward to code it, and anyway I have to add JPEG support, so I
> could add BT656 support in next patch series.
>
> For your symptom, I would say same as I said to Maxime, check first the
> polarity of sync signals (hysnc/vysnc/pclk) between ISP and OV5640.
> Note also that several frames are needed to get a non-black picture.
> You can also use the colorbar test to validate bus connection between
> ISP and sensor.
>
> Here are the yavta commands that I'm commonly using:
>
> * grab QVGA RGB565 raw frame (note the skip=10 to get a correct image)
> yavta -s 320x240 -n 3 --capture=13 --skip=10 --format=RGB565 /dev/video0
> --file=grab-320x240-rgb565-#.raw
>
> * grab QVGA YUV frame
> yavta -s 320x240 -n 3 --capture=13 --skip=10 --format=YUYV /dev/video0
> --file=grab-320x240-yuyv-#.raw
>
> * grab QVGA colorbar RGB565 raw frame
> yavta -s 320x240 -n 3 -w '0x009f0903 1' --capture=1 --format=RGB565
> /dev/video0 --file=grab-colorbar-320x240-rgb565-#.raw
>
> * disable colorbars
> yavta -s 320x240 -n 3 -w '0x009f0903 0' /dev/video0
>
>
> Hope this will help !
>
> Best regards,
> Hugues.
>
> On 01/08/2018 09:54 PM, Fabrizio Castro wrote:
> > Hello Hugues,
> >
> > thank you for the patch series.
> > I am having a go with your patches, and although they seem alright, I don't 
> > seem to be able to grab a non-black picture on the iWave
> iwg20d in plain DVP mode, but if I switch to BT656 just by setting register 
> 0x4730 to 0x01 (I know, it's a nasty hack...) I can get
> something sensible out.
> >
> > At the moment there is no proper BT656 support in the driver, I was 
> > wondering if you have any plans to enhance the ov5640 driver a
> little bit further to add proper BT656 support as it may be convenient.
> >
> > Do you know if someone else was able to get DVP to work by means of this 
> > patch series on a non-STM32 platform?
> >
> > Thanks,
> > Fabrizio
> >
> >
> >> Subject: [PATCH v5 0/5] Add OV5640 parallel interface and RGB565/YUYV 
> >> support
> >>
> >> Enhance OV5640 CSI driver to support also DVP parallel interface.
> >> Add RGB565 (LE & BE) and YUV422 YUYV format in addition to existing
> >> YUV422 UYVY format.
> >> Some other improvements on chip identifier check and removal
> >> of warnings in powering phase around gpio handling.
> >>
> >> ===
> >> = history =
> >> ===
> >> version 5:
> >>- Refine bindings as per Sakari suggestion:
> >>  
> >> https://www.mail-archive.com/linux-media@vger.kernel.org/msg124048.html
> >>
> >> version 4:
> >>- Refine bindings as per Sakari suggestion:
> >>  
> >> https://www.mail-archive.com/linux-media@vger.kernel.org/msg123609.html
> >>- Parallel port control lines polarity can now be configured through
> >>  devicetree
> >>
> >> version 3:
> >>- Move chip identifier check at probe according to Fabio Estevam 
> >> comment:
> >>  
> >> https://www.mail-archive.com/linux-media@vger.kernel.org/msg122575.html
> >>- Use 16 bits register read for this check as per Steve Longerbeam 
> >> comment:
> >>  
> >> https://www.mail-archive.com/linux-media@vger.kernel.org/msg122692.html
> >>- Update bindings to document parallel mode support as per Fabio 
> >> Estevam comment:
> >>  
> >> https://www.mail-archive.com/linux-media@vger.kernel.org/msg122576.html
> >>- Enable the whole 10 bits parallel output and document 8/10 bits 
> >> support
> >>  in ov5640_set_stream_dvp() to answer to Steve Longerbeam comment:
> >>  
> >> https://www.mail-archive.com/linux-media@vger.kernel.org/msg122693.html
> >>
> >> version 2:
> >>- Fix comments from Sakari Ailus:
> >>  
> >> https://www.mail-archive.com/linux-media@vger.kernel.org/msg122259.html
> >>- Revisit ov5640_set_stream_dvp() to only configure DVP at streamon
> >>- Revisit ov5640_set_stream_dvp() implementation with fewer register 
> >> settings
> >>
> >> version 1:
> >>- Initial submission
> >>
> >> Hugues Fruchet (5):
> >>media: ov5640: switch to gpiod_set_value_cansleep()
> >>media: ov5640: check chip id
> >>media: dt-bindings: ov5640: refine CSI-2 and add parallel interface
> >>media: ov5640: add support of DVP parallel interface
> >>media: ov5640: add support of RGB565 and YUYV formats
> >>
> >>   .../devicetree/bindings/media/i2c/ov5640.txt   |  46 ++-
> >>   drivers/media/i2c/ov5640.c | 325 
> >> ++---
> >>   2 files changed, 324 

Re: [PATCH] media: i2c: ov7740: add media-controller dependency

[Arnd Bergmann]

On Tue, Jan 9, 2018 at 11:13 AM, Sakari Ailus
 wrote:
> Hi Arnd,
>
> On Mon, Jan 08, 2018 at 01:52:28PM +0100, Arnd Bergmann wrote:
>> Without CONFIG_MEDIA_CONTROLLER, the new driver fails to build:
>>
>> drivers/perf/arm_dsu_pmu.c: In function 'dsu_pmu_probe_pmu':
>> drivers/perf/arm_dsu_pmu.c:661:2: error: implicit declaration of function 
>> 'bitmap_from_u32array'; did you mean 'bitmap_from_arr32'? 
>> [-Werror=implicit-function-declaration]
>
> There seems to be a build error with this driver if Media controller is
> disabled, but this is not the error message

Oops, bad copy-paste, sorry.

> nor adding a dependency to
> Media controller is a sound fix for it.

> drivers/media/i2c/ov7740.c: In function ‘ov7740_probe’:
> drivers/media/i2c/ov7740.c:1139:38: error: ‘struct v4l2_subdev’ has no member 
> named ‘entity’
>   media_entity_cleanup(>subdev.entity);
>
> I think it'd be worth adding nop variants for functions that are commonly
> used by drivers that can be built with or without the Media controller.
>
> I'll send a patch.

Fair enough.

In this case, the problem is not the lack of the wrapper, as we already
have a

static inline void media_entity_cleanup(struct media_entity *entity) {};

helper, but the fact that struct v4l2_subdev contains a struct media_entity
as an optional member that is disabled here.  Since the argument
to media_entity_cleanup is generally this member, we could have
a wrapper around it that takes a v4l2_subdev pointer, like

static inline void media_subdev_entity_cleanup(struct v4l2_subdev* sd)
{
#ifdef CONFIG_MEDIA_CONTROLLER
  media_entity_cleanup(sd->entity);
#endif
}

which seems nicer than making the relatively large media_entity structure
visible unconditionally, or hiding its members instead.

You may also want to revisit the other drivers that have dependencies
on MEDIA_CONTROLLER then:

drivers/media/Kconfig:  depends on MEDIA_CONTROLLER && DVB_CORE
drivers/media/Kconfig:  depends on VIDEO_DEV && MEDIA_CONTROLLER
drivers/media/i2c/Kconfig:  depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
drivers/media/i2c/Kconfig:  depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
drivers/media/i2c/Kconfig:  depends on MEDIA_CONTROLLER
drivers/media/i2c/Kconfig:  depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
drivers/media/i2c/Kconfig:  depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
drivers/media/i2c/Kconfig:  depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
drivers/media/i2c/Kconfig:  depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
drivers/media/pci/intel/ipu3/Kconfig:   depends on MEDIA_CONTROLLER
drivers/media/platform/Kconfig: depends on VIDEO_V4L2 && OF &&
VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER
drivers/media/platform/rcar-vin/Kconfig:depends on VIDEO_V4L2
&& VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && MEDIA_CONTROLLER
drivers/staging/media/atomisp/Kconfig:  depends on X86 && EFI &&
MEDIA_CONTROLLER && PCI && ACPI
drivers/staging/media/imx/Kconfig:  depends on MEDIA_CONTROLLER &&
VIDEO_V4L2 && ARCH_MXC && IMX_IPUV3_CORE

When you come up with a patch, I can throw it in my randconfig build
test machine
to see if that causes any unexpected build failures.

Thanks,

   Arnd

Re: [PATCH] media: i2c: ov7740: add media-controller dependency

[Sakari Ailus]

Hi Arnd,

On Mon, Jan 08, 2018 at 01:52:28PM +0100, Arnd Bergmann wrote:
> Without CONFIG_MEDIA_CONTROLLER, the new driver fails to build:
> 
> drivers/perf/arm_dsu_pmu.c: In function 'dsu_pmu_probe_pmu':
> drivers/perf/arm_dsu_pmu.c:661:2: error: implicit declaration of function 
> 'bitmap_from_u32array'; did you mean 'bitmap_from_arr32'? 
> [-Werror=implicit-function-declaration]

There seems to be a build error with this driver if Media controller is
disabled, but this is not the error message nor adding a dependency to
Media controller is a sound fix for it.

drivers/media/i2c/ov7740.c: In function ‘ov7740_probe’:
drivers/media/i2c/ov7740.c:1139:38: error: ‘struct v4l2_subdev’ has no member 
named ‘entity’
  media_entity_cleanup(>subdev.entity);

I think it'd be worth adding nop variants for functions that are commonly
used by drivers that can be built with or without the Media controller.

I'll send a patch.

> 
> This adds a dependency similar to what we have for other drivers
> like this.
> 
> Fixes: 39c5c4471b8d ("media: i2c: Add the ov7740 image sensor driver")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/media/i2c/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 9f18cd296841..03cf3a1a1e06 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -667,7 +667,7 @@ config VIDEO_OV7670
>  
>  config VIDEO_OV7740
>   tristate "OmniVision OV7740 sensor support"
> - depends on I2C && VIDEO_V4L2
> + depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
>   depends on MEDIA_CAMERA_SUPPORT
>   ---help---
> This is a Video4Linux2 sensor-level driver for the OmniVision

-- 
Kind regards,

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

Re: [PATCH 07/18] [media] uvcvideo: prevent bounds-check bypass via speculative execution

[Greg KH]

On Tue, Jan 09, 2018 at 10:40:21AM +0200, Laurent Pinchart wrote:
> On Saturday, 6 January 2018 11:40:26 EET Greg KH wrote:
> > On Sat, Jan 06, 2018 at 10:09:07AM +0100, Greg KH wrote:
> > 
> > While I'm all for fixing this type of thing, I feel like we need to do
> > something "else" for this as playing whack-a-mole for this pattern is
> > going to be a never-ending battle for all drivers for forever.
> 
> That's my concern too, as even if we managed to find and fix all the 
> occurrences of the problematic patterns (and we won't), new ones will keep 
> being merged all the time.

And what about the millions of lines of out-of-tree drivers that we all
rely on every day in our devices?  What about the distro kernels that
add random new drivers?

We need some sort of automated way to scan for this.

Intel, any chance we can get your coverity rules?  Given that the date
of this original patchset was from last August, has anyone looked at
what is now in Linus's tree?  What about linux-next?  I just added 3
brand-new driver subsystems to the kernel tree there, how do we know
there isn't problems in them?

And what about all of the other ways user-data can be affected?  Again,
as Peter pointed out, USB devices.  I want some chance to be able to at
least audit the codebase we have to see if that path is an issue.
Without any hint of how to do this in an automated manner, we are all
in deep shit for forever.

> > Either we need some way to mark this data path to make it easy for tools
> > like sparse to flag easily, or we need to catch the issue in the driver
> > subsystems, which unfortunatly, would harm the drivers that don't have
> > this type of issue (like here.)
> 
> But how would you do so ?

I do not know, it all depends on the access pattern, right?

> > I'm guessing that other operating systems, which don't have the luxury
> > of auditing all of their drivers are going for the "big hammer in the
> > subsystem" type of fix, right?
> 
> Other operating systems that ship closed-source drivers authored by hardware 
> vendors and not reviewed by third parties will likely stay vulnerable 
> forever. 
> That's a small concern though as I expect those drivers to contain much large 
> security holes anyway.

Well yes, but odds are those operating systems are doing something to
mitigate this, right?  Slowing down all user/kernel data paths?
Targeted code analysis tools?  Something else?  I doubt they just don't
care at all about it.  At the least, I would think Coverity would be
trying to sell licenses for this :(

thanks,

greg k-h

Re: [PATCH] media: i2c: ov7740: add media-controller dependency

[Yang, Wenyou]

Hello Arnd,


On 2018/1/8 20:52, Arnd Bergmann wrote:

Without CONFIG_MEDIA_CONTROLLER, the new driver fails to build:

drivers/perf/arm_dsu_pmu.c: In function 'dsu_pmu_probe_pmu':
drivers/perf/arm_dsu_pmu.c:661:2: error: implicit declaration of function 
'bitmap_from_u32array'; did you mean 'bitmap_from_arr32'? 
[-Werror=implicit-function-declaration]

This adds a dependency similar to what we have for other drivers
like this.

Fixes: 39c5c4471b8d ("media: i2c: Add the ov7740 image sensor driver")
Signed-off-by: Arnd Bergmann 
---

Indeed.
Thank you for your fix.

Acked-by: Wenyou Yang 


  drivers/media/i2c/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 9f18cd296841..03cf3a1a1e06 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -667,7 +667,7 @@ config VIDEO_OV7670
  
  config VIDEO_OV7740

tristate "OmniVision OV7740 sensor support"
-   depends on I2C && VIDEO_V4L2
+   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
depends on MEDIA_CAMERA_SUPPORT
---help---
  This is a Video4Linux2 sensor-level driver for the OmniVision


Best Regards,
Wenyou Yang

Re: [PATCH] media: mtk-vcodec: Always signal source change event on format change

[李務誠]

Reviewed-by: Wu-Cheng Li 

On Tue, Jan 9, 2018 at 4:42 PM, Tomasz Figa  wrote:
> Currently the driver signals the source change event only in case of
> a midstream resolution change, however the initial format detection
> is also defined as a source change by the V4L2 codec API specification.
> Fix this by signaling the event after the initial header is parsed as
> well.
>
> Signed-off-by: Tomasz Figa 
> ---
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> index 843510979ad8..86f0a7134365 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> @@ -1224,6 +1224,8 @@ static void vb2ops_vdec_buf_queue(struct vb2_buffer *vb)
> ctx->dpb_size = dpbsize;
> ctx->state = MTK_STATE_HEADER;
> mtk_v4l2_debug(1, "[%d] dpbsize=%d", ctx->id, ctx->dpb_size);
> +
> +   mtk_vdec_queue_res_chg_event(ctx);
>  }
>
>  static void vb2ops_vdec_buf_finish(struct vb2_buffer *vb)
> --
> 2.16.0.rc0.223.g4a4ac83678-goog
>

Re: [PATCH v5 0/5] Add OV5640 parallel interface and RGB565/YUYV support

[Hugues FRUCHET]

Hi Fabrizio,

Happy to see that this patch series is of interest ;)

As you can see in mail thread, Maxime Ripard is also testing it:
https://www.mail-archive.com/linux-media@vger.kernel.org/msg124322.html

For BT656 support, it was not initially planned but it seems 
straightforward to code it, and anyway I have to add JPEG support, so I 
could add BT656 support in next patch series.

For your symptom, I would say same as I said to Maxime, check first the 
polarity of sync signals (hysnc/vysnc/pclk) between ISP and OV5640.
Note also that several frames are needed to get a non-black picture.
You can also use the colorbar test to validate bus connection between 
ISP and sensor.

Here are the yavta commands that I'm commonly using:

* grab QVGA RGB565 raw frame (note the skip=10 to get a correct image)
yavta -s 320x240 -n 3 --capture=13 --skip=10 --format=RGB565 /dev/video0 
--file=grab-320x240-rgb565-#.raw

* grab QVGA YUV frame
yavta -s 320x240 -n 3 --capture=13 --skip=10 --format=YUYV /dev/video0 
--file=grab-320x240-yuyv-#.raw

* grab QVGA colorbar RGB565 raw frame
yavta -s 320x240 -n 3 -w '0x009f0903 1' --capture=1 --format=RGB565 
/dev/video0 --file=grab-colorbar-320x240-rgb565-#.raw

* disable colorbars
yavta -s 320x240 -n 3 -w '0x009f0903 0' /dev/video0


Hope this will help !

Best regards,
Hugues.

On 01/08/2018 09:54 PM, Fabrizio Castro wrote:
> Hello Hugues,
> 
> thank you for the patch series.
> I am having a go with your patches, and although they seem alright, I don't 
> seem to be able to grab a non-black picture on the iWave iwg20d in plain DVP 
> mode, but if I switch to BT656 just by setting register 0x4730 to 0x01 (I 
> know, it's a nasty hack...) I can get something sensible out.
> 
> At the moment there is no proper BT656 support in the driver, I was wondering 
> if you have any plans to enhance the ov5640 driver a little bit further to 
> add proper BT656 support as it may be convenient.
> 
> Do you know if someone else was able to get DVP to work by means of this 
> patch series on a non-STM32 platform?
> 
> Thanks,
> Fabrizio
> 
> 
>> Subject: [PATCH v5 0/5] Add OV5640 parallel interface and RGB565/YUYV support
>>
>> Enhance OV5640 CSI driver to support also DVP parallel interface.
>> Add RGB565 (LE & BE) and YUV422 YUYV format in addition to existing
>> YUV422 UYVY format.
>> Some other improvements on chip identifier check and removal
>> of warnings in powering phase around gpio handling.
>>
>> ===
>> = history =
>> ===
>> version 5:
>>- Refine bindings as per Sakari suggestion:
>>  https://www.mail-archive.com/linux-media@vger.kernel.org/msg124048.html
>>
>> version 4:
>>- Refine bindings as per Sakari suggestion:
>>  https://www.mail-archive.com/linux-media@vger.kernel.org/msg123609.html
>>- Parallel port control lines polarity can now be configured through
>>  devicetree
>>
>> version 3:
>>- Move chip identifier check at probe according to Fabio Estevam comment:
>>  https://www.mail-archive.com/linux-media@vger.kernel.org/msg122575.html
>>- Use 16 bits register read for this check as per Steve Longerbeam 
>> comment:
>>  https://www.mail-archive.com/linux-media@vger.kernel.org/msg122692.html
>>- Update bindings to document parallel mode support as per Fabio Estevam 
>> comment:
>>  https://www.mail-archive.com/linux-media@vger.kernel.org/msg122576.html
>>- Enable the whole 10 bits parallel output and document 8/10 bits support
>>  in ov5640_set_stream_dvp() to answer to Steve Longerbeam comment:
>>  https://www.mail-archive.com/linux-media@vger.kernel.org/msg122693.html
>>
>> version 2:
>>- Fix comments from Sakari Ailus:
>>  https://www.mail-archive.com/linux-media@vger.kernel.org/msg122259.html
>>- Revisit ov5640_set_stream_dvp() to only configure DVP at streamon
>>- Revisit ov5640_set_stream_dvp() implementation with fewer register 
>> settings
>>
>> version 1:
>>- Initial submission
>>
>> Hugues Fruchet (5):
>>media: ov5640: switch to gpiod_set_value_cansleep()
>>media: ov5640: check chip id
>>media: dt-bindings: ov5640: refine CSI-2 and add parallel interface
>>media: ov5640: add support of DVP parallel interface
>>media: ov5640: add support of RGB565 and YUYV formats
>>
>>   .../devicetree/bindings/media/i2c/ov5640.txt   |  46 ++-
>>   drivers/media/i2c/ov5640.c | 325 
>> ++---
>>   2 files changed, 324 insertions(+), 47 deletions(-)
>>
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
> Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
> No. 04586709.
> 

[PATCH] media: mtk-vcodec: Always signal source change event on format change

[Tomasz Figa]

Currently the driver signals the source change event only in case of
a midstream resolution change, however the initial format detection
is also defined as a source change by the V4L2 codec API specification.
Fix this by signaling the event after the initial header is parsed as
well.

Signed-off-by: Tomasz Figa 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 843510979ad8..86f0a7134365 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -1224,6 +1224,8 @@ static void vb2ops_vdec_buf_queue(struct vb2_buffer *vb)
ctx->dpb_size = dpbsize;
ctx->state = MTK_STATE_HEADER;
mtk_v4l2_debug(1, "[%d] dpbsize=%d", ctx->id, ctx->dpb_size);
+
+   mtk_vdec_queue_res_chg_event(ctx);
 }
 
 static void vb2ops_vdec_buf_finish(struct vb2_buffer *vb)
-- 
2.16.0.rc0.223.g4a4ac83678-goog

Re: [PATCH 07/18] [media] uvcvideo: prevent bounds-check bypass via speculative execution

[Laurent Pinchart]

Hi Greg,

On Saturday, 6 January 2018 11:40:26 EET Greg KH wrote:
> On Sat, Jan 06, 2018 at 10:09:07AM +0100, Greg KH wrote:
> > On Fri, Jan 05, 2018 at 05:10:32PM -0800, Dan Williams wrote:
> >> Static analysis reports that 'index' may be a user controlled value that
> >> is used as a data dependency to read 'pin' from the
> >> 'selector->baSourceID' array. In order to avoid potential leaks of
> >> kernel memory values, block speculative execution of the instruction
> >> stream that could issue reads based on an invalid value of 'pin'.
> >> 
> >> Based on an original patch by Elena Reshetova.
> >> 
> >> Cc: Laurent Pinchart 
> >> Cc: Mauro Carvalho Chehab 
> >> Cc: linux-media@vger.kernel.org
> >> Signed-off-by: Elena Reshetova 
> >> Signed-off-by: Dan Williams 
> >> ---
> >> 
> >>  drivers/media/usb/uvc/uvc_v4l2.c |7 +--
> >>  1 file changed, 5 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
> >> b/drivers/media/usb/uvc/uvc_v4l2.c index 3e7e283a44a8..7442626dc20e
> >> 100644
> >> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> >> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> >> @@ -22,6 +22,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >> 
> >>  #include 
> >>  #include 
> >> @@ -810,6 +811,7 @@ static int uvc_ioctl_enum_input(struct file *file,
> >> void *fh,
> >>struct uvc_entity *iterm = NULL;
> >>u32 index = input->index;
> >>int pin = 0;
> >> +  __u8 *elem;
> >> 
> >>if (selector == NULL ||
> >>(chain->dev->quirks & UVC_QUIRK_IGNORE_SELECTOR_UNIT)) {
> >> @@ -820,8 +822,9 @@ static int uvc_ioctl_enum_input(struct file *file,
> >> void *fh,
> >>break;
> >>}
> >>pin = iterm->id;
> >> -  } else if (index < selector->bNrInPins) {
> >> -  pin = selector->baSourceID[index];
> >> +  } else if ((elem = nospec_array_ptr(selector->baSourceID, index,
> >> +  selector->bNrInPins))) {
> >> +  pin = *elem;
> > 
> > I dug through this before, and I couldn't find where index came from
> > userspace, I think seeing the coverity rule would be nice.
> 
> Ok, I take it back, this looks correct.  Ugh, the v4l ioctl api is
> crazy complex (rightfully so), it's amazing that coverity could navigate
> that whole thing :)
> 
> While I'm all for fixing this type of thing, I feel like we need to do
> something "else" for this as playing whack-a-mole for this pattern is
> going to be a never-ending battle for all drivers for forever.

That's my concern too, as even if we managed to find and fix all the 
occurrences of the problematic patterns (and we won't), new ones will keep 
being merged all the time.

> Either we need some way to mark this data path to make it easy for tools
> like sparse to flag easily, or we need to catch the issue in the driver
> subsystems, which unfortunatly, would harm the drivers that don't have
> this type of issue (like here.)

But how would you do so ?

> I'm guessing that other operating systems, which don't have the luxury
> of auditing all of their drivers are going for the "big hammer in the
> subsystem" type of fix, right?

Other operating systems that ship closed-source drivers authored by hardware 
vendors and not reviewed by third parties will likely stay vulnerable forever. 
That's a small concern though as I expect those drivers to contain much large 
security holes anyway.

> I don't have a good answer for this, but if there was some better way to
> rewrite these types of patterns to just prevent the need for the
> nospec_array_ptr() type thing, that might be the best overall for
> everyone.  Much like ebpf did with their changes.  That way a simple
> coccinelle rule would be able to catch the pattern and rewrite it.
> 
> Or am I just dreaming?

Likely, but sometimes dreams come true :-) Do you have an idea how this could 
be done ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 0/6] arm: sunxi: IR support for A83T

[Philipp Rossak]

On 05.01.2018 15:59, Maxime Ripard wrote:

Hi,

On Fri, Jan 05, 2018 at 12:02:53PM +, Sean Young wrote:

On Tue, Dec 19, 2017 at 09:07:41AM +0100, Philipp Rossak wrote:

This patch series adds support for the sunxi A83T ir module and enhances
the sunxi-ir driver. Right now the base clock frequency for the ir driver
is a hard coded define and is set to 8 MHz.
This works for the most common ir receivers. On the Sinovoip Bananapi M3
the ir receiver needs, a 3 MHz base clock frequency to work without
problems with this driver.

This patch series adds support for an optinal property that makes it able
to override the default base clock frequency and enables the ir interface
on the a83t and the Bananapi M3.

changes since v2:
* reorder cir pin (alphabetical)
* fix typo in documentation

changes since v1:
* fix typos, reword Documentation
* initialize 'b_clk_freq' to 'SUNXI_IR_BASE_CLK' & remove if statement
* change dev_info() to dev_dbg()
* change naming to cir* in dts/dtsi
* Added acked Ackedi-by to related patch
* use whole memory block instead of registers needed + fix for h3/h5

changes since rfc:
* The property is now optinal. If the property is not available in
   the dtb the driver uses the default base clock frequency.
* the driver prints out the the selected base clock frequency.
* changed devicetree property from base-clk-frequency to clock-frequency

Regards,
Philipp


Philipp Rossak (6):
   media: rc: update sunxi-ir driver to get base clock frequency from
 devicetree
   media: dt: bindings: Update binding documentation for sunxi IR
 controller
   arm: dts: sun8i: a83t: Add the cir pin for the A83T
   arm: dts: sun8i: a83t: Add support for the cir interface
   arm: dts: sun8i: a83t: bananapi-m3: Enable IR controller
   arm: dts: sun8i: h3-h8: ir register size should be the whole memory
 block


I can take this series (through rc-core, i.e. linux-media), but I need an
maintainer Acked-by: for the sun[x8]i dts changes (all four patches).


We'll merge them through our tree. We usually have a rather big number
of patches around, so we'd be better off avoiding conflicts :)

Philipp, can you resubmit the DTs as soon as -rc1 is out?

Thanks!
Maxime


Yes, I can do this!

Regards,
Philipp

Re: [PATCH v2 2/2] media: dt-bindings: Add OF properties to ov7670

[jacopo mondi]

Hi Rob,
   thanks for comments

On Mon, Jan 08, 2018 at 09:35:55PM -0600, Rob Herring wrote:
> On Thu, Jan 04, 2018 at 10:52:33AM +0100, Jacopo Mondi wrote:
> > Describe newly introduced OF properties for ov7670 image sensor.
> > The driver supports two standard properties to configure synchronism
> > signals polarities and two custom properties already supported as
> > platform data options by the driver.
>
> Missing S-o-b.
>

Ups, that was trivial, sorry about that

> > ---
> >  Documentation/devicetree/bindings/media/i2c/ov7670.txt | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/media/i2c/ov7670.txt 
> > b/Documentation/devicetree/bindings/media/i2c/ov7670.txt
> > index 826b656..57ded18 100644
> > --- a/Documentation/devicetree/bindings/media/i2c/ov7670.txt
> > +++ b/Documentation/devicetree/bindings/media/i2c/ov7670.txt
> > @@ -9,11 +9,22 @@ Required Properties:
> >  - clocks: reference to the xclk input clock.
> >  - clock-names: should be "xclk".
> >
> > +The following properties, as defined by video interfaces OF bindings
> > +"Documentation/devicetree/bindings/media/video-interfaces.txt" are 
> > supported:
> > +
> > +- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH 
> > respectively.
> > +- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH 
> > respectively.
>
> Don't these go in the endpoint? Not sure offhand.
>

Yes they do. I will list them as "Optional endpoint properties", and

> > +
> > +Default is high active state for both vsync and hsync signals.
> > +
> >  Optional Properties:
> >  - reset-gpios: reference to the GPIO connected to the resetb pin, if any.
> >Active is low.
> >  - powerdown-gpios: reference to the GPIO connected to the pwdn pin, if any.
> >Active is high.
> > +- ov7670,pll-bypass: set to 1 to bypass PLL for pixel clock generation.
>
> Boolean instead?
>

Do we have booleans? I had a look at device tree specs and grep for
"true"/"false" in arch/arm*/boot/dts, and didn't find that much.
Seems like they're actually strings, am I wrong?

Thanks
   j

> > +- ov7670,pclk-hb-disable: set to 1 to suppress pixel clock output signal 
> > during
> > +  horizontal blankings.
>
> ditto
>
> >
> >  The device node must contain one 'port' child node for its digital output
> >  video port, in accordance with the video interface bindings defined in
> > @@ -34,6 +45,9 @@ Example:
> > assigned-clocks = <>;
> > assigned-clock-rates = <2500>;
> >
> > +   vsync-active = <0>;
> > +   ov7670,pclk-hb-disable = <1>;
> > +
> > port {
> > ov7670_0: endpoint {
> > remote-endpoint = <_0>;
> > --
> > 2.7.4
> >