[PATCH v9 0/2] media: ov7740: Add a V4L2 sensor-level driver

[Wenyou Yang]

Add a Video4Linux2 sensor-level driver for the OmniVision OV7740
VGA camera image sensor.

Changes in v9:
 - Use the new SPDX ids.

Changes in v8:
 - As the registers are written at stream start, remove the written
   code from the set fmt function.

Changes in v7:
 - Add Acked-by tag.
 - Fix the wrong handle of default register configuration.
 - Add the missed assignment of ov7740->frmsize.

Changes in v6:
 - Remove unnecessary #include .
 - Remove unnecessary comments and extra newline.
 - Add const for some structures.
 - Add the check of the return value from regmap_write().
 - Simplify the calling of __v4l2_ctrl_handler_setup().
 - Add the default format initialization function.
 - Integrate the set_power() and enable/disable the clock into
   one function.

Changes in v5:
 - Squash the driver and MAINTAINERS entry patches to one.
 - Precede the driver patch with the bindings patch.

Changes in v4:
 - Assign 'val' a initial value to avoid warning: 'val' may be
   used uninitialized.
 - Rename REG_REG15 to avoid warning: "REG_REG15" redefined.

Changes in v3:
 - Explicitly document the "remote-endpoint" property.
 - Put the MAINTAINERS change to a separate patch.

Changes in v2:
 - Split off the bindings into a separate patch.
 - Add a new entry to the MAINTAINERS file.

Wenyou Yang (2):
  media: ov7740: Document device tree bindings
  media: i2c: Add the ov7740 image sensor driver

 .../devicetree/bindings/media/i2c/ov7740.txt   |   47 +
 MAINTAINERS|8 +
 drivers/media/i2c/Kconfig  |8 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov7740.c | 1216 
 5 files changed, 1280 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7740.txt
 create mode 100644 drivers/media/i2c/ov7740.c

-- 
2.15.0

[PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver

[Wenyou Yang]

The ov7740 (color) image sensor is a high performance VGA CMOS
image snesor, which supports for output formats: RAW RGB and YUV
and image sizes: VGA, and QVGA, CIF and any size smaller.

Signed-off-by: Songjun Wu 
Signed-off-by: Wenyou Yang 
---

Changes in v9:
 - Use the new SPDX ids.

Changes in v8:
 - As the registers are written at stream start, remove the written
   code from the set fmt function.

Changes in v7:
 - Fix the wrong handle of default register configuration.
 - Add the missed assignment of ov7740->frmsize.

Changes in v6:
 - Remove unnecessary #include .
 - Remove unnecessary comments and extra newline.
 - Add const for some structures.
 - Add the check of the return value from regmap_write().
 - Simplify the calling of __v4l2_ctrl_handler_setup().
 - Add the default format initialization function.
 - Integrate the set_power() and enable/disable the clock into
   one function.

Changes in v5:
 - Squash the driver and MAINTAINERS entry patches to one.
 - Precede the driver patch with the bindings patch.

Changes in v4:
 - Assign 'val' a initial value to avoid warning: 'val' may be
   used uninitialized.
 - Rename REG_REG15 to avoid warning: "REG_REG15" redefined.

Changes in v3:
 - Put the MAINTAINERS change to a separate patch.

Changes in v2:
 - Split off the bindings into a separate patch.
 - Add a new entry to the MAINTAINERS file.

 MAINTAINERS|8 +
 drivers/media/i2c/Kconfig  |8 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov7740.c | 1216 
 4 files changed, 1233 insertions(+)
 create mode 100644 drivers/media/i2c/ov7740.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7a52a66aa991..1de965009b13 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10053,6 +10053,14 @@ S: Maintained
 F: drivers/media/i2c/ov7670.c
 F: Documentation/devicetree/bindings/media/i2c/ov7670.txt
 
+OMNIVISION OV7740 SENSOR DRIVER
+M: Wenyou Yang 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/ov7740.c
+F: Documentation/devicetree/bindings/media/i2c/ov7740.txt
+
 ONENAND FLASH DRIVER
 M: Kyungmin Park 
 L: linux-...@lists.infradead.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cb5d7ff82915..00b1c4c031d4 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -665,6 +665,14 @@ config VIDEO_OV7670
  OV7670 VGA camera.  It currently only works with the M88ALP01
  controller.
 
+config VIDEO_OV7740
+   tristate "OmniVision OV7740 sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV7740 VGA camera sensor.
+
 config VIDEO_OV9650
tristate "OmniVision OV9650/OV9652 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9efce966..9b19ec7fcaf4 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
 obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
 obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
 obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
new file mode 100644
index ..0308ba437bbb
--- /dev/null
+++ b/drivers/media/i2c/ov7740.c
@@ -0,0 +1,1216 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017 Microchip Corporation.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_OUTSIZE_LSB 0x34
+
+/* OV7740 register tables */
+#define REG_GAIN   0x00/* Gain lower 8 bits (rest in vref) */
+#define REG_BGAIN  0x01/* blue gain */
+#define REG_RGAIN  0x02/* red gain */
+#define REG_GGAIN  0x03/* green gain */
+#define REG_REG04  0x04/* analog setting, dont change*/
+#define REG_BAVG   0x05/* b channel average */
+#define REG_GAVG   0x06/* g channel average */
+#define REG_RAVG   0x07/* r channel average */
+
+#define REG_REG0C  0x0C/* filp enable */
+#define REG0C_IMG_FLIP 0x80
+#define REG0C_IMG_MIRROR   0x40
+
+#define REG_REG0E  0x0E/* blc line */
+#define REG_HAEC   0x0F/* auto exposure cntrl */
+#define REG_AEC0x10/* auto exposure cntrl */
+
+#define REG_CLK0x11/* Clock control */
+#define REG_REG55  0x55/* Clock PLL DIV/PreDiv */
+
+#define REG_REG12  0x12
+
+#define REG_REG13  0x13/* 

[PATCH v9 1/2] media: ov7740: Document device tree bindings

[Wenyou Yang]

Add the device tree binding documentation for the ov7740 sensor driver.

Signed-off-by: Wenyou Yang 
Acked-by: Rob Herring 
---

Changes in v9: None
Changes in v8: None
Changes in v7:
 - Add Acked-by tag.

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
 - Explicitly document the "remote-endpoint" property.

Changes in v2: None

 .../devicetree/bindings/media/i2c/ov7740.txt   | 47 ++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7740.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov7740.txt 
b/Documentation/devicetree/bindings/media/i2c/ov7740.txt
new file mode 100644
index ..af781c3a5f0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov7740.txt
@@ -0,0 +1,47 @@
+* Omnivision OV7740 CMOS image sensor
+
+The Omnivision OV7740 image sensor supports multiple output image
+size, such as VGA, and QVGA, CIF and any size smaller. It also
+supports the RAW RGB and YUV output formats.
+
+The common video interfaces bindings (see video-interfaces.txt) should
+be used to specify link to the image data receiver. The OV7740 device
+node should contain one 'port' child node with an 'endpoint' subnode.
+
+Required Properties:
+- compatible:  "ovti,ov7740".
+- reg: I2C slave address of the sensor.
+- clocks:  Reference to the xvclk input clock.
+- clock-names: "xvclk".
+
+Optional Properties:
+- reset-gpios: Rreference to the GPIO connected to the reset_b pin,
+  if any. Active low with pull-ip resistor.
+- powerdown-gpios: Reference to the GPIO connected to the pwdn pin,
+  if any. Active high with pull-down resistor.
+
+Endpoint node mandatory properties:
+- remote-endpoint: A phandle to the bus receiver's endpoint node.
+
+Example:
+
+   i2c1: i2c@fc028000 {
+   ov7740: camera@21 {
+   compatible = "ovti,ov7740";
+   reg = <0x21>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_sensor_power 
_sensor_reset>;
+   clocks = <>;
+   clock-names = "xvclk";
+   assigned-clocks = <>;
+   assigned-clock-rates = <2400>;
+   reset-gpios = < 43 GPIO_ACTIVE_LOW>;
+   powerdown-gpios = < 44 GPIO_ACTIVE_HIGH>;
+
+   port {
+   ov7740_0: endpoint {
+   remote-endpoint = <_0>;
+   };
+   };
+   };
+   };
-- 
2.15.0

cron job: media_tree daily build: WARNINGS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Mon Dec 11 05:00:15 CET 2017
media-tree git hash:0393e735649dc41358adb7b603bd57dad1ed3260
media_build git hash:   f5a5e5e470d834f9843fee7a7c2ce3e4be610ca7
v4l-utils git hash: 58803000a99c22dceabfb45bec402e746ce966c3
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: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.12.67-i686: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9.26-i686: OK
linux-4.10.14-i686: OK
linux-4.11-i686: OK
linux-4.12.1-i686: OK
linux-4.13-i686: OK
linux-4.14-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
linux-4.13-x86_64: OK
linux-4.14-x86_64: OK
apps: OK
spec-git: OK
smatch: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH v8 2/2] media: i2c: Add the ov7740 image sensor driver

[Yang, Wenyou]

Hi Philippe,


On 2017/12/8 21:14, Philippe Ombredanne wrote:

Wenyou,

On Fri, Dec 8, 2017 at 2:55 AM, Wenyou Yang  wrote:

The ov7740 (color) image sensor is a high performance VGA CMOS
image snesor, which supports for output formats: RAW RGB and YUV
and image sizes: VGA, and QVGA, CIF and any size smaller.

Signed-off-by: Songjun Wu 
Signed-off-by: Wenyou Yang 

[]

--- /dev/null
+++ b/drivers/media/i2c/ov7740.c
@@ -0,0 +1,1226 @@
+/*
+ * Copyright (c) 2017 Microchip Corporation.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */

Have you considered using the new SPDX ids instead of this fine legalese?
e.g.:

// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2017 Microchip Corporation.

Short and neat! Check also Thomas doc patches and Linus comments on
why he prefers the C++ comment style for these.

Thank you for your suggestion and information.


Best Regards,
Wenyou Yang

Re: [PATCH] build: Remove patch v3.13_ddbridge_pcimsi

[Jasmin J.]

Hi!

> The real problem is another, which I will fix soon.
I mixed up some branches, so there is no problem and there is nothing to fix.
Please delete this patch from Patchwork!

BR,
   Jasmin

Re: [PATCH] build: Revert 41e33085284dd2bc6b6180d8381ff8a509b9d8ba for < 3.19

[Jasmin J.]

Hi!

With this patch it compiles back to kernel 2.6.36.
I tested it with 3.13, 3.4 and 2.6.36.
Don't forget to merge also my "READ_ONCE" patch.

BR,
   Jasmin

Re: [PATCH] build: Remove patch v3.13_ddbridge_pcimsi

[Jasmin J.]

Hi!

Please ignore this patch!
The real problem is another, which I will fix soon.

BR,
   Jasmin

[PATCH] build: Revert 41e33085284dd2bc6b6180d8381ff8a509b9d8ba for < 3.19

[Jasmin J.]

From: Jasmin Jessich 

I tried to to define "ktime_get_real_seconds" in "v4l/compat.h", but it is
using static variables from "kernel/time/timekeeping.c". So there is no other
way than reverting 41e33085284dd2bc6b6180d8381ff8a509b9d8ba for Kernels
older than 3.19.

Signed-off-by: Jasmin Jessich 
---
 backports/backports.txt  |  1 +
 backports/v3.18_ktime_get_real_seconds.patch | 26 ++
 2 files changed, 27 insertions(+)
 create mode 100644 backports/v3.18_ktime_get_real_seconds.patch

diff --git a/backports/backports.txt b/backports/backports.txt
index 2911023..c30ccf0 100644
--- a/backports/backports.txt
+++ b/backports/backports.txt
@@ -83,6 +83,7 @@ add v3.19_get_user_pages_locked.patch
 
 [3.18.255]
 add v3.18_drop_property_h.patch
+add v3.18_ktime_get_real_seconds.patch
 
 [3.17.255]
 add v3.17_fix_clamp.patch
diff --git a/backports/v3.18_ktime_get_real_seconds.patch 
b/backports/v3.18_ktime_get_real_seconds.patch
new file mode 100644
index 000..97ed081
--- /dev/null
+++ b/backports/v3.18_ktime_get_real_seconds.patch
@@ -0,0 +1,26 @@
+diff --git a/drivers/media/platform/vivid/vivid-rds-gen.c 
b/drivers/media/platform/vivid/vivid-rds-gen.c
+index 996e35e..53c 100644
+--- a/drivers/media/platform/vivid/vivid-rds-gen.c
 b/drivers/media/platform/vivid/vivid-rds-gen.c
+@@ -103,7 +103,7 @@ void vivid_rds_generate(struct vivid_rds_gen *rds)
+* EN 50067:1998 to convert a UTC date to an RDS 
Modified
+* Julian Day.
+*/
+-  time64_to_tm(ktime_get_real_seconds(), 0, );
++  time_to_tm(get_seconds(), 0, );
+   l = tm.tm_mon <= 1;
+   date = 14956 + tm.tm_mday + ((tm.tm_year - l) * 1461) / 
4 +
+   ((tm.tm_mon + 2 + l * 12) * 306001) / 1;
+diff --git a/drivers/media/platform/vivid/vivid-vbi-gen.c 
b/drivers/media/platform/vivid/vivid-vbi-gen.c
+index 02c79d7..a2159de 100644
+--- a/drivers/media/platform/vivid/vivid-vbi-gen.c
 b/drivers/media/platform/vivid/vivid-vbi-gen.c
+@@ -190,7 +190,7 @@ static void vivid_vbi_gen_set_time_of_day(u8 *packet)
+   struct tm tm;
+   u8 checksum, i;
+ 
+-  time64_to_tm(ktime_get_real_seconds(), 0, );
++  time_to_tm(get_seconds(), 0, );
+   packet[0] = calc_parity(0x07);
+   packet[1] = calc_parity(0x01);
+   packet[2] = calc_parity(0x40 | tm.tm_min);
-- 
2.7.4

Re: [PATCH] build: Added missing timer_setup_on_stack

[Jasmin J.]

Hello Hans!

In one of my eMails I added a debug patch for linux/Makefile.
Patchwork interpreted this as a new version of the timer_setup_on_stack
patch. Please remove that from Patchwork.

BR,
   Jasmin

Re: [PATCH v4 3/5] staging: Introduce NVIDIA Tegra video decoder driver

[Nicolas Dufresne]

Le dimanche 10 décembre 2017 à 21:56 +0300, Dmitry Osipenko a écrit :
> > I've CC-ed Maxime and Giulio as well: they are looking into adding support 
> > for
> > the stateless allwinner codec based on this code as well. There may well be
> > opportunities for you to work together, esp. on the userspace side. Note 
> > that
> > Rockchip has the same issue, they too have a stateless HW codec.
> 
> IIUC, we will have to define video decoder parameters in V4L API and then 
> make a
> V4L driver / userspace prototype (ffmpeg for example) that will use the 
> requests
> API for video decoding in order to upstream the requests API. Does it sound 
> good?

Chromium/Chrome already have support for that type of decoder in their
tree. In theory, it should just work.

Nicolas

Re: [PATCH 09/45] drivers: media: remove duplicate includes

[Pravin Shedge]

On Thu, Dec 7, 2017 at 7:05 PM, Sakari Ailus  wrote:
> Hi Pravin,
>
> On Wed, Dec 06, 2017 at 10:22:02PM +0530, Pravin Shedge wrote:
>> These duplicate includes have been found with scripts/checkincludes.pl but
>> they have been removed manually to avoid removing false positives.
>>
>> Signed-off-by: Pravin Shedge 
>
> While at it, how about ordering the headers alphabetically as well? Having
> such a large number of headers there unordered may well be the reason why
> they're included more than once...
>
> --
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi


Hi Sakari,

Sorry for the late reply.

Ordering the header files alphabetically helps to avoid problems such
as inclusion of duplicate header files.
My personal preference is to go from local to global, each subsection
in alphabetical order.
Ideally, all header files should be self-contained, and inclusion
order should not matter.
Simple reordering the headers should not break build.

Reordering header files aways helpful for big projects like Linux-Kernel.
But this requires changes tree wide and modifies lots of files.
Such change requires huge audience to be participated in discussion &
take a final call.

With this patch I just handled inclusion of header file multiple times
to avoid code duplication after preprocessing.

Thanks & Regards,
   PraviN

Dear Friend

[Mrs Alice Walton]

my name is Mrs. Alice Walton, a business woman an America Citizen and the 
heiress to the fortune of Walmart stores, born October 7, 1949. I have a 
mission for you worth $100,000,000.00(Hundred Million United State Dollars) 
which I intend using for CHARITY

Re: [PATCH v4 3/5] staging: Introduce NVIDIA Tegra video decoder driver

[Dmitry Osipenko]

On 05.12.2017 16:03, Hans Verkuil wrote:
> On 12/05/17 13:17, Dmitry Osipenko wrote:
>> Hi Hans,
>>
>> On 04.12.2017 17:04, Hans Verkuil wrote:
>>> Hi Dmitry,
>>>
>>> As you already mention in the TODO, this should become a v4l2 codec driver.
>>>
>>> Good existing examples are the coda, qcom/venus and mtk-vcodec drivers.
>>>
>>> One thing that is not clear from this code is if the tegra hardware is a
>>> stateful or stateless codec, i.e. does it keep track of the decoder state
>>> in the hardware, or does the application have to keep track of the state and
>>> provide the state information together with the video data?
>>>
>>> I ask because at the moment only stateful codecs are supported. Work is 
>>> ongoing
>>> to support stateless codecs, but we don't support that for now.
>>>
>>
>> It is stateless. Is there anything ready to try out? If yes, could you please
>> give a reference to that work?
> 
> I rebased my two year old 'requests2' branch to the latest mainline version 
> and
> gave it the imaginative name 'requests3':
> 
> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=requests3
> 
> (Note: only compile tested!)

Thank you very much.

> This is what ChromeOS has been using (actually they use a slightly older 
> version)
> and the new version that is currently being developed will be similar, so any 
> work
> you do on top of this will carry over to the final version without too much 
> effort.
> 
> At least, that's the intention :-)
> 
> I've CC-ed Maxime and Giulio as well: they are looking into adding support for
> the stateless allwinner codec based on this code as well. There may well be
> opportunities for you to work together, esp. on the userspace side. Note that
> Rockchip has the same issue, they too have a stateless HW codec.

IIUC, we will have to define video decoder parameters in V4L API and then make a
V4L driver / userspace prototype (ffmpeg for example) that will use the requests
API for video decoding in order to upstream the requests API. Does it sound 
good?

>>
>>> Anyway, I'm OK with merging this in staging. Although I think it should go
>>> to staging/media since we want to keep track of it.
>>>
>>
>> Awesome, I'll move driver to staging/media in V5. Thanks!
> 
> Nice, thanks!

Re: [PATCH v4 3/5] staging: Introduce NVIDIA Tegra video decoder driver

[Dmitry Osipenko]

On 10.12.2017 22:29, Nicolas Dufresne wrote:
> Le dimanche 10 décembre 2017 à 21:56 +0300, Dmitry Osipenko a écrit :
>>> I've CC-ed Maxime and Giulio as well: they are looking into adding support 
>>> for
>>> the stateless allwinner codec based on this code as well. There may well be
>>> opportunities for you to work together, esp. on the userspace side. Note 
>>> that
>>> Rockchip has the same issue, they too have a stateless HW codec.
>>
>> IIUC, we will have to define video decoder parameters in V4L API and then 
>> make a
>> V4L driver / userspace prototype (ffmpeg for example) that will use the 
>> requests
>> API for video decoding in order to upstream the requests API. Does it sound 
>> good?
> 
> Chromium/Chrome already have support for that type of decoder in their
> tree. In theory, it should just work.

Everything is possible, in theory ;)