[v4l-utils PATCH 1/1] dvbv5-zap.c: fix setting signal handlers

[Jemma Denson]

Signal handlers are currently out of order - SIGALRM is always set, and
SIGINT only set when timeout is set. These should be the other way round.

Signed-off-by: Jemma Denson 
---
 utils/dvb/dvbv5-zap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/utils/dvb/dvbv5-zap.c b/utils/dvb/dvbv5-zap.c
index e19d7c2..e927383 100644
--- a/utils/dvb/dvbv5-zap.c
+++ b/utils/dvb/dvbv5-zap.c
@@ -959,10 +959,10 @@ int main(int argc, char **argv)
goto err;
}
 
-   signal(SIGALRM, do_timeout);
signal(SIGTERM, do_timeout);
+   signal(SIGINT, do_timeout);
if (args.timeout > 0) {
-   signal(SIGINT, do_timeout);
+   signal(SIGALRM, do_timeout);
alarm(args.timeout);
}
 
-- 
2.1.0

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

Re: Automatic device driver back-porting with media_build

[Mauro Carvalho Chehab]

Em Thu, 17 Dec 2015 17:48:57 +0100
Mason  escreveu:

> On 17/12/2015 17:09, Mauro Carvalho Chehab wrote:
> > Em Thu, 17 Dec 2015 16:32:54 +0100
> > Mason  escreveu:
> > 
> >> I wanted to fix the NEED_WRITEL_RELAXED warning, but I don't know Perl.
> >>
> >> v4l/scripts/make_config_compat.pl
> >>
> >> check_files_for_func("writel_relaxed", "NEED_WRITEL_RELAXED", 
> >> "include/asm-generic/io.h");
> >> incorrectly outputs
> >> #define NEED_WRITEL_RELAXED 1
> >>
> >>
> >> In file included from :0:0:
> >> /tmp/sandbox/media_build/v4l/compat.h:1568:0: warning: "writel_relaxed" 
> >> redefined
> >>  #define writel_relaxed writel
> >>  ^
> >> In file included from include/linux/scatterlist.h:10:0,
> >>  from /tmp/sandbox/media_build/v4l/compat.h:1255,
> >>  from :0:
> >> /tmp/sandbox/custom-linux-3.4/arch/arm/include/asm/io.h:235:0: note: this 
> >> is the location of the previous definition
> >>  #define writel_relaxed(v,c) ((void)__raw_writel((__force u32) \
> >>  ^
> >>
> >> Shouldn't the script examine arch/$ARCH/include/asm/io.h instead of
> >> include/asm-generic/io.h ? (Or perhaps both?)
> >>
> >> Does make_config_compat.pl know about ARCH?
> > 
> > No to both. When you do a "make init" on the Kernel repository, it
> > will evaluate the ARCH vars.
> > 
> > This is also needed for the media build to work, as it needs to
> > check what CONFIG vars are enabled on the targeted Kernel.
> 
> I downloaded the vanilla version of my custom kernel: linux-3.4.39.tar.xz
> 
> Even then, NEED_WRITEL_RELAXED is incorrectly defined.

did you run a:
make allmodconfig
make init

for the vanilla version? Without that, the symlinks won't appear.

> How do you propose to fix this bug?
> 
> $ grep writel_relaxed arch/arm/include/asm/io.h
> #define writel_relaxed(v,c)   ((void)__raw_writel((__force u32) \
> #define writel(v,c)   ({ __iowmb(); writel_relaxed(v,c); })
> 
> $ grep writel_relaxed arch/x86/include/asm/io.h
> $ grep -r writel_relaxed include
> 
> > As I said before, heavily patched Kernel. It seems that the network stack
> > was updated to some newer version. The media_build backport considers
> > only the upstream Kernels. In the specific case of 3.4, it is known
> > to build fine with Kernel linux-3.4.27. See:
> > http://hverkuil.home.xs4all.nl/logs/Wednesday.log
> 
> I will keep trying to get something to compile.
> 
> Regards.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] Documentation: devicetree: add STI HVA binding

[Yannick Fertre]

This patch documents DT compatible string "st,st-hva".

Signed-off-by: Yannick Fertre 
---
 .../devicetree/bindings/media/st,sti-hva.txt   | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/st,sti-hva.txt

diff --git a/Documentation/devicetree/bindings/media/st,sti-hva.txt 
b/Documentation/devicetree/bindings/media/st,sti-hva.txt
new file mode 100644
index 000..3dc431d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st,sti-hva.txt
@@ -0,0 +1,26 @@
+==
+hva: hardware video encoder accelerator
+==
+
+Required properties:
+- compatible: should be "st,stih407-hva".
+- reg: HVA physical address location and length, esram address location and
+  length.
+- reg-names: names of the registers listed in registers property in the same
+  order.
+- interrupts: HVA interrupt number.
+- clocks: from common clock binding: handle hardware IP needed clocks, the
+  number of clocks may depend on the SoC type.
+  See ../clock/clock-bindings.txt for details.
+- clock-names: names of the clocks listed in clocks property in the same order.
+
+Example:
+
+hva@8c85000{
+   compatible = "st,stih407-hva";
+   reg= <0x8c85000 0x400>, <0x600 0x4>;
+   reg-names = "hva_registers", "hva_esram";
+   interrupts = <0 58 0>, <0 59 0>;
+   clock-names = "clk_hva";
+   clocks = <_S_C0_FLEXGEN 3>;
+};
-- 
1.9.1

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

[PATCH 0/3] support of v4l2 encoder for STMicroelectronics SOC.

[Yannick Fertre]

version 1:
- Initial submission.

Only one feature supported and tested:
- encode (RGB32, RGB24, RGB16, NV12, NV21, UYVY, VYUY) to h264 video format

The driver is mainly implemented across three files:
- hva-v4l2.c
- hva-h264.c
- hva-hw.c
hva-v4l2.c manages the V4L2 interface with the userland.
It calls the HW services that are implemented in hva-hw.c.
hva-h264.c manages specific part of h264 codec.

Below is the v4l2-compliance report for the sti hva driver.
Note: using patched v4l2-compliance:
"v4l2-compliance: test SELECTION only for the supported buf_type"

root@st-next:/# ./v4l2-compliance 
Driver Info:
Driver name   : 8c85000.hva
Card type : 8c85000.hva
Bus info  : platform:hva
Driver version: 4.4.0
Capabilities  : 0x84208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04208000
Video Memory-to-Memory
Streaming
Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
warn: 
/local/frq07647/views/opensdk-1.0.4/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(707):
 TRY_FMT cannot handle an invalid pixelformat
.
warn: 
/local/frq07647/views/opensdk-1.0.4/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(708):
 This may or may not be a problem. For more i
nformation see:
warn: 
/local/frq07647/views/opensdk-1.0.4/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(709):
 http://www.mail-archive.com/linux-media@vger
.kernel.org/msg56550.html
warn: 
/local/frq07647/views/opensdk-1.0.4/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(707):
 TRY_FMT cannot handle an invalid pixelformat
.
warn: 
/local/frq07647/views/opensdk-1.0.4/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(708):
 This may or may not be a problem. For more i
nformation see:
warn: 
/local/frq07647/views/opensdk-1.0.4/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(709):
 http://www.mail-archive.com/linux-media@vger
.kernel.org/msg56550.html
test VIDIOC_TRY_FMT: OK
warn: 
/local/frq07647/views/opensdk-1.0.4/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(923):
 S_FMT cannot handle an invalid pixelformat.
warn: 
/local/frq07647/views/opensdk-1.0.4/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(924):
 This may or may not be a problem. For more i
nformation see:
warn: 
/local/frq07647/views/opensdk-1.0.4/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(925):
 http://www.mail-archive.com/linux-media@vger
.kernel.org/msg56550.html
warn: 
/local/frq07647/views/opensdk-1.0.4/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(923):
 S_FMT cannot handle an invalid 

[PATCH 2/3] [media] hva: STiH41x multi-format video encoder V4L2 driver

[Yannick Fertre]

This patch adds HVA (Hardware Video Accelerator) support for STI platform.

Signed-off-by: Yannick Fertre 
---
 drivers/media/platform/Kconfig|   13 +
 drivers/media/platform/Makefile   |1 +
 drivers/media/platform/sti/hva/Makefile   |2 +
 drivers/media/platform/sti/hva/hva-hw.c   |  561 
 drivers/media/platform/sti/hva/hva-hw.h   |   76 ++
 drivers/media/platform/sti/hva/hva-mem.c  |   63 ++
 drivers/media/platform/sti/hva/hva-mem.h  |   20 +
 drivers/media/platform/sti/hva/hva-v4l2.c | 1404 +
 drivers/media/platform/sti/hva/hva.h  |  499 ++
 9 files changed, 2639 insertions(+)
 create mode 100644 drivers/media/platform/sti/hva/Makefile
 create mode 100644 drivers/media/platform/sti/hva/hva-hw.c
 create mode 100644 drivers/media/platform/sti/hva/hva-hw.h
 create mode 100644 drivers/media/platform/sti/hva/hva-mem.c
 create mode 100644 drivers/media/platform/sti/hva/hva-mem.h
 create mode 100644 drivers/media/platform/sti/hva/hva-v4l2.c
 create mode 100644 drivers/media/platform/sti/hva/hva.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 5263594..50b5f83 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -221,6 +221,19 @@ config VIDEO_STI_BDISP
help
  This v4l2 mem2mem driver is a 2D blitter for STMicroelectronics SoC.
 
+config VIDEO_STI_HVA
+   tristate "STMicroelectronics STiH41x HVA multi-format video encoder 
V4L2 driver"
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_STI || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   help
+ This V4L2 driver enables HVA multi-format video encoder of
+ STMicroelectronics SoC STiH41x series, allowing hardware encoding of 
raw
+ uncompressed formats in various compressed video & jpeg bitstreams 
format.
+
+ To compile this driver as a module, choose M here:
+ the module will be called hva.
+
 config VIDEO_SH_VEU
tristate "SuperH VEU mem2mem video processing driver"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index efa0295..d7740d8 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)   += s5p-g2d/
 obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/
 
 obj-$(CONFIG_VIDEO_STI_BDISP)  += sti/bdisp/
+obj-$(CONFIG_VIDEO_STI_HVA)+= sti/hva/
 obj-$(CONFIG_DVB_C8SECTPFE)+= sti/c8sectpfe/
 
 obj-$(CONFIG_BLACKFIN)  += blackfin/
diff --git a/drivers/media/platform/sti/hva/Makefile 
b/drivers/media/platform/sti/hva/Makefile
new file mode 100644
index 000..7022a33
--- /dev/null
+++ b/drivers/media/platform/sti/hva/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_VIDEO_STI_HVA) := hva.o
+hva-y := hva-v4l2.o hva-hw.o hva-mem.o
diff --git a/drivers/media/platform/sti/hva/hva-hw.c 
b/drivers/media/platform/sti/hva/hva-hw.c
new file mode 100644
index 000..00b915b
--- /dev/null
+++ b/drivers/media/platform/sti/hva/hva-hw.c
@@ -0,0 +1,561 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2015
+ * Authors: Yannick Fertre 
+ *  Hugues Fruchet 
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hva.h"
+#include "hva-hw.h"
+
+/* HVA register offsets */
+#define HVA_HIF_REG_RST 0x0100U
+#define HVA_HIF_REG_RST_ACK 0x0104U
+#define HVA_HIF_REG_MIF_CFG 0x0108U
+#define HVA_HIF_REG_HEC_MIF_CFG 0x010CU
+#define HVA_HIF_REG_CFL 0x0110U
+#define HVA_HIF_FIFO_CMD0x0114U
+#define HVA_HIF_FIFO_STS0x0118U
+#define HVA_HIF_REG_SFL 0x011CU
+#define HVA_HIF_REG_IT_ACK  0x0120U
+#define HVA_HIF_REG_ERR_IT_ACK  0x0124U
+#define HVA_HIF_REG_LMI_ERR 0x0128U
+#define HVA_HIF_REG_EMI_ERR 0x012CU
+#define HVA_HIF_REG_HEC_MIF_ERR 0x0130U
+#define HVA_HIF_REG_HEC_STS 0x0134U
+#define HVA_HIF_REG_HVC_STS 0x0138U
+#define HVA_HIF_REG_HJE_STS 0x013CU
+#define HVA_HIF_REG_CNT 0x0140U
+#define HVA_HIF_REG_HEC_CHKSYN_DIS  0x0144U
+#define HVA_HIF_REG_CLK_GATING  0x0148U
+#define HVA_HIF_REG_VERSION 0x014CU
+#define HVA_HIF_REG_BSM 0x0150U
+
+/* define value for version id register (HVA_HIF_REG_VERSION) */
+#define VERSION_ID_MASK0x
+
+/* define values for BSM register (HVA_HIF_REG_BSM) */
+#define BSM_CFG_VAL1   0x0003F000
+#define BSM_CFG_VAL2   0x003F
+
+/* define values for memory 

Re: Automatic device driver back-porting with media_build

[Mason]

On 17/12/2015 18:03, Mason wrote:

> The media_build process prints:
> 
> "Preparing to compile for kernel version 3.4.3913"
> 
> In fact, the custom kernel's Makefile contains:
> 
> VERSION = 3
> PATCHLEVEL = 4
> SUBLEVEL = 39
> EXTRAVERSION = 13
> NAME = Saber-toothed Squirrel
> 
> Is it possible that the build process gets confused by the EXTRAVERSION field?

Here's the problem:

v4l/Makefile writes to KERNELRELEASE and v4l/.version

-e 'printf 
("VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s%s\n",' \
-e '
$$version,$$level,$$sublevel,$$version,$$level,$$sublevel,$$extra);' \

$ cat v4l/.version 
VERSION=3
PATCHLEVEL:=4
SUBLEVEL:=39
KERNELRELEASE:=3.4.3913
SRCDIR:=/tmp/sandbox/custom-linux-3.4

Then $(MAKE) -C ../linux apply_patches calls
patches_for_kernel.pl 3.4.3913

which computes kernel_version
= 3 << 16 + 4 << 8 + 3913 = 0x031349

which is incorrectly interpreted as kernel 3.19.73
thus the correct patches are not applied.

Trivial patch follows. Will test right away.

Regards.

diff --git a/v4l/Makefile b/v4l/Makefile
index 1542092004fa..9147a98639b7 100644
--- a/v4l/Makefile
+++ b/v4l/Makefile
@@ -233,9 +233,9 @@ ifneq ($(DIR),)
-e 'elsif (/^EXTRAVERSION\s*=\s*(\S+)\n/){ $$extra=$$1; }' \
-e 'elsif (/^KERNELSRC\s*:=\s*(\S.*)\n/ || 
/^MAKEARGS\s*:=\s*-C\s*(\S.*)\n/)' \
-e '{ $$o=$$d; $$d=$$1; goto S; }' \
-e '};' \
-   -e 'printf 
("VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s%s\n",' \
+   -e 'printf 
("VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s.%s\n",' \
-e '
$$version,$$level,$$sublevel,$$version,$$level,$$sublevel,$$extra);' \
-e 'print "OUTDIR:=$$o\n" if($$o);' \
-e 'print "SRCDIR:=$$d\n";' > $(obj)/.version
@cat .version|grep KERNELRELEASE:|sed s,'KERNELRELEASE:=','Forcing 
compiling to version ',

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

[PATCH 3/3] [media] hva: add h264 support

[Yannick Fertre]

Signed-off-by: Yannick Fertre 
---
 drivers/media/platform/sti/hva/Makefile   |2 +-
 drivers/media/platform/sti/hva/hva-h264.c | 1225 +
 drivers/media/platform/sti/hva/hva-v4l2.c |  126 +++
 3 files changed, 1352 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/sti/hva/hva-h264.c

diff --git a/drivers/media/platform/sti/hva/Makefile 
b/drivers/media/platform/sti/hva/Makefile
index 7022a33..495894b 100644
--- a/drivers/media/platform/sti/hva/Makefile
+++ b/drivers/media/platform/sti/hva/Makefile
@@ -1,2 +1,2 @@
 obj-$(CONFIG_VIDEO_STI_HVA) := hva.o
-hva-y := hva-v4l2.o hva-hw.o hva-mem.o
+hva-y := hva-v4l2.o hva-hw.o hva-mem.o hva-h264.o
diff --git a/drivers/media/platform/sti/hva/hva-h264.c 
b/drivers/media/platform/sti/hva/hva-h264.c
new file mode 100644
index 000..ae57f4b
--- /dev/null
+++ b/drivers/media/platform/sti/hva/hva-h264.c
@@ -0,0 +1,1225 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2015
+ * Authors: Yannick Fertre 
+ *  Hugues Fruchet 
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include "hva.h"
+#include "hva-hw.h"
+#include "hva-mem.h"
+
+#define MAX_SPS_PPS_SIZE 128
+
+#define BITSTREAM_OFFSET_MASK 0x7F
+
+/* video max size*/
+#define H264_MAX_SIZE_W 1920
+#define H264_MAX_SIZE_H 1088
+
+/* macroBlocs number (width & height) */
+#define MB_W(w) ((w + 0xF)  / 0x10)
+#define MB_H(h) ((h + 0xF)  / 0x10)
+
+/* formula to get temporal or spatial data size */
+#define DATA_SIZE(w, h) (MB_W(w) * MB_H(h) * 16)
+
+#define SEARCH_WINDOW_BUFFER_MAX_SIZE(w) ((4 * MB_W(w) + 42) * 256 * 3 / 2)
+#define CABAC_CONTEXT_BUFFER_MAX_SIZE(w) (MB_W(w) * 16)
+#define CTX_MB_BUFFER_MAX_SIZE(w) (MB_W(w) * 16 * 8)
+#define SLICE_HEADER_SIZE (4 * 16)
+#define BRC_DATA_SIZE (5 * 16)
+
+/* source buffer copy in YUV 420 MB-tiled format with size=16*256*3/2 */
+#define CURRENT_WINDOW_BUFFER_MAX_SIZE (16 * 256 * 3 / 2)
+
+/*
+ * 4 lines of pixels (in Luma, Chroma blue and Chroma red) of top MB
+ * for deblocking with size=4*16*MBx*2
+ */
+#define LOCAL_RECONSTRUCTED_BUFFER_MAX_SIZE(w) (4 * 16 * MB_W(w) * 2)
+
+/* factor for bitrate and cpb buffer size max values if profile >= high */
+#define H264_FACTOR_HIGH 1200
+
+/* factor for bitrate and cpb buffer size max values if profile < high */
+#define H264_FACTOR_BASELINE 1000
+
+struct h264_profile {
+   enum v4l2_mpeg_video_h264_level level;
+   u32 max_mb_per_seconds;
+   u32 max_frame_size;
+   u32 max_bitrate;
+   u32 max_cpb_size;
+   u32 min_comp_ratio;
+};
+
+static const struct h264_profile h264_infos_list[] = {
+   {V4L2_MPEG_VIDEO_H264_LEVEL_1_0, 1485, 99, 64, 175, 2},
+   {V4L2_MPEG_VIDEO_H264_LEVEL_1B, 1485, 99, 128, 350, 2},
+   {V4L2_MPEG_VIDEO_H264_LEVEL_1_1, 3000, 396, 192, 500, 2},
+   {V4L2_MPEG_VIDEO_H264_LEVEL_1_2, 6000, 396, 384, 1000, 2},
+   {V4L2_MPEG_VIDEO_H264_LEVEL_1_3, 11880, 396, 768, 2000, 2},
+   {V4L2_MPEG_VIDEO_H264_LEVEL_2_0, 11880, 396, 2000, 2000, 2},
+   {V4L2_MPEG_VIDEO_H264_LEVEL_2_1, 19800, 792, 4000, 4000, 2},
+   {V4L2_MPEG_VIDEO_H264_LEVEL_2_2, 20250, 1620, 4000, 4000, 2},
+   {V4L2_MPEG_VIDEO_H264_LEVEL_3_0, 40500, 1620, 1, 1, 2},
+   {V4L2_MPEG_VIDEO_H264_LEVEL_3_1, 108000, 3600, 14000, 14000, 4},
+   {V4L2_MPEG_VIDEO_H264_LEVEL_3_2, 216000, 5120, 2, 2, 4},
+   {V4L2_MPEG_VIDEO_H264_LEVEL_4_0, 245760, 8192, 2, 25000, 4},
+   {V4L2_MPEG_VIDEO_H264_LEVEL_4_1, 245760, 8192, 5, 62500, 2},
+   {V4L2_MPEG_VIDEO_H264_LEVEL_4_2, 522240, 8704, 5, 62500, 2},
+   {V4L2_MPEG_VIDEO_H264_LEVEL_5_0, 589824, 22080, 135000, 135000, 2},
+   {V4L2_MPEG_VIDEO_H264_LEVEL_5_1, 983040, 36864, 24, 24, 2}
+};
+
+enum hva_brc_type {
+   BRC_TYPE_NONE = 0,
+   BRC_TYPE_CBR = 1,
+   BRC_TYPE_VBR = 2,
+   BRC_TYPE_VBR_LOW_DELAY = 3
+};
+
+enum hva_entropy_coding_mode {
+   CAVLC = 0,
+   CABAC = 1
+};
+
+enum hva_picture_coding_type {
+   PICTURE_CODING_TYPE_I = 0,
+   PICTURE_CODING_TYPE_P = 1,
+   PICTURE_CODING_TYPE_B = 2
+};
+
+enum hva_h264_sampling_mode {
+   SAMPLING_MODE_NV12 = 0,
+   SAMPLING_MODE_UYVY = 1,
+   SAMPLING_MODE_RGB3 = 3,
+   SAMPLING_MODE_XRGB4 = 4,
+   SAMPLING_MODE_NV21 = 8,
+   SAMPLING_MODE_VYUY = 9,
+   SAMPLING_MODE_BGR3 = 11,
+   SAMPLING_MODE_XBGR4 = 12,
+   SAMPLING_MODE_RGBX4 = 20,
+   SAMPLING_MODE_BGRX4 = 28
+};
+
+enum hva_h264_nalu_type {
+   NALU_TYPE_UNKNOWN = 0,
+   NALU_TYPE_SLICE = 1,
+   NALU_TYPE_SLICE_DPA = 2,
+   NALU_TYPE_SLICE_DPB = 3,
+   NALU_TYPE_SLICE_DPC = 4,
+   NALU_TYPE_SLICE_IDR = 5,
+   NALU_TYPE_SEI = 6,
+   NALU_TYPE_SPS = 7,
+   NALU_TYPE_PPS = 8,
+   NALU_TYPE_AU_DELIMITER = 9,
+   NALU_TYPE_SEQ_END = 10,
+   NALU_TYPE_STREAM_END = 11,
+   NALU_TYPE_FILLER_DATA = 12,
+   

Re: Preliminary HDCP code available in my tree

[Hans Verkuil]

On 12/18/2015 10:59 AM, Jean-Michel Hautbois wrote:
> Hi Hans,
> 
> 
> 2015-12-18 9:04 GMT+01:00 Hans Verkuil  >:
> 
> Hi all,
> 
> Two years ago Cisco did some work on HDCP support for HDMI receivers and 
> transmitters,
> but for one reason or another that work was never put into actual use. 
> Rather than
> letting that work go unnoticed I decided to put it up in my git tree:
> 
> http://git.linuxtv.org/hverkuil/media_tree.git/log/?h=hdcp
> 
> It's missing documentation, it's tested with HDCP 1.4 only (not 2.2), and 
> it needs some
> TLC, but it was working at the time. So this could be a good starting 
> point for someone.
> 
> If someone decides to work on this, please contact me first.
> 
> 
> I will give it a try soon, as I was about to implement it :).
> I have an ADV7611 and an ADV7604 so it will be interesting.
> I will keep you informed.

Well, as they say: timing is everything :-)

Let me know how it goes. I'm sure you'll have questions, just ask me and CC
Mikhail (the author of the code).

Regards,

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

Re: Automatic device driver back-porting with media_build

[Mason]

On 18/12/2015 11:37, Mauro Carvalho Chehab wrote:
> Em Thu, 17 Dec 2015 17:48:57 +0100
> Mason  escreveu:
> 
>> On 17/12/2015 17:09, Mauro Carvalho Chehab wrote:
>>> Em Thu, 17 Dec 2015 16:32:54 +0100
>>> Mason  escreveu:
>>>
 I wanted to fix the NEED_WRITEL_RELAXED warning, but I don't know Perl.

 v4l/scripts/make_config_compat.pl

 check_files_for_func("writel_relaxed", "NEED_WRITEL_RELAXED", 
 "include/asm-generic/io.h");
 incorrectly outputs
 #define NEED_WRITEL_RELAXED 1


 In file included from :0:0:
 /tmp/sandbox/media_build/v4l/compat.h:1568:0: warning: "writel_relaxed" 
 redefined
  #define writel_relaxed writel
  ^
 In file included from include/linux/scatterlist.h:10:0,
  from /tmp/sandbox/media_build/v4l/compat.h:1255,
  from :0:
 /tmp/sandbox/custom-linux-3.4/arch/arm/include/asm/io.h:235:0: note: this 
 is the location of the previous definition
  #define writel_relaxed(v,c) ((void)__raw_writel((__force u32) \
  ^

 Shouldn't the script examine arch/$ARCH/include/asm/io.h instead of
 include/asm-generic/io.h ? (Or perhaps both?)

 Does make_config_compat.pl know about ARCH?
>>>
>>> No to both. When you do a "make init" on the Kernel repository, it
>>> will evaluate the ARCH vars.
>>>
>>> This is also needed for the media build to work, as it needs to
>>> check what CONFIG vars are enabled on the targeted Kernel.
>>
>> I downloaded the vanilla version of my custom kernel: linux-3.4.39.tar.xz
>>
>> Even then, NEED_WRITEL_RELAXED is incorrectly defined.
> 
> did you run a:
>   make allmodconfig
>   make init
> 
> for the vanilla version? Without that, the symlinks won't appear.

/tmp/sandbox/linux-3.4.39$ make allmodconfig
scripts/kconfig/conf --allmodconfig Kconfig
#
# configuration written to .config
#
/tmp/sandbox/linux-3.4.39$ make menuconfig
scripts/kconfig/mconf Kconfig
.config:25:warning: symbol value '' invalid for PHYS_OFFSET
#
# configuration written to .config
#


*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.

/tmp/sandbox/linux-3.4.39$ make init
scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
CC kernel/bounds.s
GEN include/generated/bounds.h
CC arch/arm/kernel/asm-offsets.s
GEN include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CC scripts/mod/empty.o
MKELF scripts/mod/elfconfig.h
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/modpost.o
HOSTCC scripts/mod/sumversion.o
HOSTLD scripts/mod/modpost
HOSTCC scripts/selinux/genheaders/genheaders
HOSTCC scripts/selinux/mdp/mdp
CC init/main.o
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
CC init/do_mounts.o
CC init/do_mounts_initrd.o
LD init/mounts.o
CC init/initramfs.o
CC init/calibrate.o
LD init/built-in.o

cd ../media_build/linux
make tar DIR=/tmp/sandbox/media_tree
make untar
cd ..
make release DIR=/tmp/sandbox/linux-3.4.39
make

make -C ../linux apply_patches
make[2]: Entering directory `/tmp/sandbox/media_build/linux'
Patches for 3.4.39. already applied.
make[2]: Leaving directory `/tmp/sandbox/media_build/linux'
make -C /tmp/sandbox/linux-3.4.39 SUBDIRS=/tmp/sandbox/media_build/v4l  modules
make[2]: Entering directory `/tmp/sandbox/linux-3.4.39'
  CC [M]  /tmp/sandbox/media_build/v4l/altera-lpt.o
In file included from :0:0:
/tmp/sandbox/media_build/v4l/compat.h:1568:0: warning: "writel_relaxed" 
redefined
 #define writel_relaxed writel
 ^
In file included from include/linux/scatterlist.h:10:0,
 from /tmp/sandbox/media_build/v4l/compat.h:1255,
 from :0:
/tmp/sandbox/linux-3.4.39/arch/arm/include/asm/io.h:235:0: note: this is the 
location of the previous definition
 #define writel_relaxed(v,c) ((void)__raw_writel((__force u32) \
 ^

$ grep -rn NEED_WRITEL_RELAXED
v4l/compat.h:1567:#ifdef NEED_WRITEL_RELAXED
v4l/scripts/make_config_compat.pl:667:  check_files_for_func("writel_relaxed", 
"NEED_WRITEL_RELAXED", "include/asm-generic/io.h");
v4l/config-compat.h:1888:#define NEED_WRITEL_RELAXED 1



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

Re: Automatic device driver back-porting with media_build

[Mauro Carvalho Chehab]

Em Fri, 18 Dec 2015 11:44:35 +0100
Mason  escreveu:

> On 17/12/2015 18:03, Mason wrote:
> 
> > The media_build process prints:
> > 
> > "Preparing to compile for kernel version 3.4.3913"
> > 
> > In fact, the custom kernel's Makefile contains:
> > 
> > VERSION = 3
> > PATCHLEVEL = 4
> > SUBLEVEL = 39
> > EXTRAVERSION = 13
> > NAME = Saber-toothed Squirrel
> > 
> > Is it possible that the build process gets confused by the EXTRAVERSION 
> > field?
> 
> Here's the problem:
> 
> v4l/Makefile writes to KERNELRELEASE and v4l/.version
> 
>   -e 'printf 
> ("VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s%s\n",' \
>   -e '
> $$version,$$level,$$sublevel,$$version,$$level,$$sublevel,$$extra);' \
> 
> $ cat v4l/.version 
> VERSION=3
> PATCHLEVEL:=4
> SUBLEVEL:=39
> KERNELRELEASE:=3.4.3913
> SRCDIR:=/tmp/sandbox/custom-linux-3.4
> 
> Then $(MAKE) -C ../linux apply_patches calls
> patches_for_kernel.pl 3.4.3913
> 
> which computes kernel_version
> = 3 << 16 + 4 << 8 + 3913 = 0x031349
> 
> which is incorrectly interpreted as kernel 3.19.73
> thus the correct patches are not applied.
> 
> Trivial patch follows. Will test right away.
> 
> Regards.
> 
> diff --git a/v4l/Makefile b/v4l/Makefile
> index 1542092004fa..9147a98639b7 100644
> --- a/v4l/Makefile
> +++ b/v4l/Makefile
> @@ -233,9 +233,9 @@ ifneq ($(DIR),)
> -e 'elsif (/^EXTRAVERSION\s*=\s*(\S+)\n/){ $$extra=$$1; }' \
> -e 'elsif (/^KERNELSRC\s*:=\s*(\S.*)\n/ || 
> /^MAKEARGS\s*:=\s*-C\s*(\S.*)\n/)' \
> -e '{ $$o=$$d; $$d=$$1; goto S; }' \
> -e '};' \
> -   -e 'printf 
> ("VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s%s\n",' \
> +   -e 'printf 
> ("VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s.%s\n",' \
> -e '
> $$version,$$level,$$sublevel,$$version,$$level,$$sublevel,$$extra);' \

Hmm... that doesn't sound right on upstream Kernels.

For example, the extra version on the media_build current Kernel is:

Makefile:EXTRAVERSION = -rc2

So, I guess we'll need a different regex, like:

 -e 'elsif (/^EXTRAVERSION\s*=\s*(\d+)\n/){ $$extra=".$$1"; }' \
 -e 'elsif (/^EXTRAVERSION\s*=\s*(\S+)\n/){ $$extra=$$1; }' \

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

Re: [PATCH/RFC 26/48] videodev2.h: Add request field to v4l2_pix_format_mplane

[Hans Verkuil]

Hi Laurent,

On 12/17/2015 09:40 AM, Laurent Pinchart wrote:
> Let userspace specify a request ID when getting or setting formats. The
> support is limited to the multi-planar API at the moment, extending it
> to the single-planar API is possible if needed.
> 
> From a userspace point of view the API change is also minimized and
> doesn't require any new ioctl.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  include/uapi/linux/videodev2.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 5af1d2d87558..5b2a8bc80eb2 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -1973,6 +1973,7 @@ struct v4l2_plane_pix_format {
>   * @ycbcr_enc:   enum v4l2_ycbcr_encoding, Y'CbCr encoding
>   * @quantization:enum v4l2_quantization, colorspace quantization
>   * @xfer_func:   enum v4l2_xfer_func, colorspace transfer 
> function
> + * @request: request ID
>   */
>  struct v4l2_pix_format_mplane {
>   __u32   width;
> @@ -1987,7 +1988,8 @@ struct v4l2_pix_format_mplane {
>   __u8ycbcr_enc;
>   __u8quantization;
>   __u8xfer_func;
> - __u8reserved[7];
> + __u8reserved[3];
> + __u32   request;

I think I mentioned this before: I feel uncomfortable using 4 bytes of the 
reserved
fields when the request ID is limited to 16 bits anyway.

I would prefer a __u16 here. Also put the request field *before* the reserved
array, not after.

Regards,

Hans

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

Preliminary HDCP code available in my tree

[Hans Verkuil]

Hi all,

Two years ago Cisco did some work on HDCP support for HDMI receivers and 
transmitters,
but for one reason or another that work was never put into actual use. Rather 
than
letting that work go unnoticed I decided to put it up in my git tree:

http://git.linuxtv.org/hverkuil/media_tree.git/log/?h=hdcp

It's missing documentation, it's tested with HDCP 1.4 only (not 2.2), and it 
needs some
TLC, but it was working at the time. So this could be a good starting point for 
someone.

If someone decides to work on this, please contact me first.

Regards,

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

Re: [PATCH/RFC 27/48] v4l2-subdev.h: Add request field to format and selection structures

[Hans Verkuil]

On 12/17/2015 09:40 AM, Laurent Pinchart wrote:
> Let userspace specify a request ID when getting or setting formats or
> selection rectangles.
> 
> From a userspace point of view the API change is minimized and doesn't
> require any new ioctl.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  include/uapi/linux/v4l2-subdev.h | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/include/uapi/linux/v4l2-subdev.h 
> b/include/uapi/linux/v4l2-subdev.h
> index dbce2b554e02..2f1691ce9df5 100644
> --- a/include/uapi/linux/v4l2-subdev.h
> +++ b/include/uapi/linux/v4l2-subdev.h
> @@ -32,10 +32,12 @@
>   * enum v4l2_subdev_format_whence - Media bus format type
>   * @V4L2_SUBDEV_FORMAT_TRY: try format, for negotiation only
>   * @V4L2_SUBDEV_FORMAT_ACTIVE: active format, applied to the device
> + * @V4L2_SUBDEV_FORMAT_REQUEST: format stored in request
>   */
>  enum v4l2_subdev_format_whence {
>   V4L2_SUBDEV_FORMAT_TRY = 0,
>   V4L2_SUBDEV_FORMAT_ACTIVE = 1,
> + V4L2_SUBDEV_FORMAT_REQUEST = 2,
>  };
>  
>  /**
> @@ -43,12 +45,17 @@ enum v4l2_subdev_format_whence {
>   * @which: format type (from enum v4l2_subdev_format_whence)
>   * @pad: pad number, as reported by the media API
>   * @format: media bus format (format code and frame size)
> + * @request: request ID (when which is set to V4L2_SUBDEV_FORMAT_REQUEST)
> + * @reserved2: for future use, set to zero for now
> + * @reserved: for future use, set to zero for now
>   */
>  struct v4l2_subdev_format {
>   __u32 which;
>   __u32 pad;
>   struct v4l2_mbus_framefmt format;
> - __u32 reserved[8];
> + __u16 request;
> + __u16 reserved2;
> + __u32 reserved[7];

I would prefer:

__u16 request;
__u16 reserved[15];

>  };
>  
>  /**
> @@ -139,6 +146,8 @@ struct v4l2_subdev_frame_interval_enum {
>   *   defined in v4l2-common.h; V4L2_SEL_TGT_* .
>   * @flags: constraint flags, defined in v4l2-common.h; V4L2_SEL_FLAG_*.
>   * @r: coordinates of the selection window
> + * @request: request ID (when which is set to V4L2_SUBDEV_FORMAT_REQUEST)
> + * @reserved2: for future use, set to zero for now
>   * @reserved: for future use, set to zero for now
>   *
>   * Hardware may use multiple helper windows to process a video stream.
> @@ -151,7 +160,9 @@ struct v4l2_subdev_selection {
>   __u32 target;
>   __u32 flags;
>   struct v4l2_rect r;
> - __u32 reserved[8];
> + __u16 request;
> + __u16 reserved2;
> + __u32 reserved[7];

Ditto.

Generally apps do a memset of reserved, and that will just keep working.
But adding a reserved2 field means that they have to explicitly set reserved2
to 0, which won't happen.

>  };
>  
>  /* Backwards compatibility define --- to be removed */
> 

Regards,

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

Re: [PATCH 2/3] [media] hva: STiH41x multi-format video encoder V4L2 driver

[kbuild test robot]

Hi Yannick,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.4-rc5 next-20151217]

url:
https://github.com/0day-ci/linux/commits/Yannick-Fertre/Documentation-devicetree-add-STI-HVA-binding/20151218-184834
base:   git://linuxtv.org/media_tree.git master
config: x86_64-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   drivers/media/platform/sti/hva/hva-v4l2.c: In function 'hva_open_encoder':
>> drivers/media/platform/sti/hva/hva-v4l2.c:164:15: warning: cast to pointer 
>> from integer of different size [-Wint-to-pointer-cast]
   ctx->name, (char *)pixelformat, (char *)streamformat);
  ^
   drivers/media/platform/sti/hva/hva-v4l2.c:164:36: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
   ctx->name, (char *)pixelformat, (char *)streamformat);
   ^
   drivers/media/platform/sti/hva/hva-v4l2.c: In function 'hva_querybuf':
>> drivers/media/platform/sti/hva/hva-v4l2.c:97:28: error: implicit declaration 
>> of function 'UL' [-Werror=implicit-function-declaration]
#define MMAP_FRAME_OFFSET (UL(0x1) / 2)
   ^
>> drivers/media/platform/sti/hva/hva-v4l2.c:589:18: note: in expansion of 
>> macro 'MMAP_FRAME_OFFSET'
  b->m.offset += MMAP_FRAME_OFFSET;
 ^
   In file included from include/linux/printk.h:277:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from drivers/media/platform/sti/hva/hva-v4l2.c:8:
   drivers/media/platform/sti/hva/hva-v4l2.c: In function 
'hva_vb2_frame_prepare':
>> drivers/media/platform/sti/hva/hva-v4l2.c:875:16: warning: format '%x' 
>> expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t 
>> {aka long long unsigned int}' [-Wformat=]
  dev_dbg(dev, "%s frame[%d] prepared; virt=%p, phy=0x%x\n",
   ^
   include/linux/dynamic_debug.h:86:39: note: in definition of macro 
'dynamic_dev_dbg'
  __dynamic_dev_dbg(, dev, fmt, \
  ^
>> drivers/media/platform/sti/hva/hva-v4l2.c:875:3: note: in expansion of macro 
>> 'dev_dbg'
  dev_dbg(dev, "%s frame[%d] prepared; virt=%p, phy=0x%x\n",
  ^
   drivers/media/platform/sti/hva/hva-v4l2.c: In function 
'hva_vb2_stream_prepare':
   drivers/media/platform/sti/hva/hva-v4l2.c:999:16: warning: format '%x' 
expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t 
{aka long long unsigned int}' [-Wformat=]
  dev_dbg(dev, "%s stream[%d] prepared; virt=%p, phy=0x%x\n",
   ^
   include/linux/dynamic_debug.h:86:39: note: in definition of macro 
'dynamic_dev_dbg'
  __dynamic_dev_dbg(, dev, fmt, \
  ^
   drivers/media/platform/sti/hva/hva-v4l2.c:999:3: note: in expansion of macro 
'dev_dbg'
  dev_dbg(dev, "%s stream[%d] prepared; virt=%p, phy=0x%x\n",
  ^
   In file included from drivers/media/platform/sti/hva/hva-v4l2.c:8:0:
   drivers/media/platform/sti/hva/hva-v4l2.c: In function 'hva_probe':
   drivers/media/platform/sti/hva/hva-v4l2.c:1345:26: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
   HVA_PREFIX, HVA_NAME, (void *)hva->esram_addr,
 ^
   include/linux/device.h:1174:58: note: in definition of macro 'dev_info'
#define dev_info(dev, fmt, arg...) _dev_info(dev, fmt, ##arg)
 ^
   cc1: some warnings being treated as errors
--
   In file included from include/linux/printk.h:277:0,
from include/linux/kernel.h:13,
from include/linux/clk.h:16,
from drivers/media/platform/sti/hva/hva-hw.c:8:
   drivers/media/platform/sti/hva/hva-hw.c: In function 'hva_hw_execute_task':
>> drivers/media/platform/sti/hva/hva-hw.c:523:15: warning: format '%x' expects 
>> argument of type 'unsigned int', but argument 7 has type 'dma_addr_t {aka 
>> long long unsigned int}' [-Wformat=]
 dev_dbg(dev, "%s %s: Send task ( cmd:%d, task_desc:0x%x)\n",
  ^
   include/linux/dynamic_debug.h:86:39: note: in definition of macro 
'dynamic_dev_dbg'
  __dynamic_dev_dbg(, dev, fmt, \
  ^
>> drivers/media/platform/sti/hva/hva-hw.c:523:2: note: in expansion of macro 
>> 'dev_dbg'
 dev_dbg(dev, "%s %s: Send task ( cmd:%d, task_desc:0x%x)\n",
 ^
--
   In file included from include/

sn9c20x: incorrect support for 0c45:6270 MT9V011/MT9V111 ?

[TJ]

I've been trying to get the 0c45:6270 Vehoh VMS-001 'Discovery' 
Microscope to work correctly and discovered what seem to be differences 
in the bridge_init and other control commands. The most obvious 
difference currently is the LEDs do not turn on, but there seem to be 
other problems with empty frames, bad/unrecognised formats, and 
resolutions, although vlc is able to render a usable JPEG stream.


I've installed the Windows XP Sonix driver package in a Qemu virtual 
machine guest and used wireshark on the host (Kubuntu 15.10, kernel 
v4.2) to capture and analyse the control commands.


https://iam.tj/projects/misc/usbmon-0c45-6270.pcapng

That seems to show the bridge_init, and possibly some of the i2c_init, 
byte sequences are different. It being the first time I've sniffed a USB 
driver though, I'm not yet 100% confident I'm identifying the correct 
starting point of the control command flow or the relationships between 
code and what is on the wire.


The Windows .inf seems to indicate the chipset is MT9V111:

%USBPCamDesc% = SN.USBPCam,USB\VID_0c45_6270 ; SN9C201 + 
MI0360\MT9V111


but the sn9c20x is matching as the MT9V011 (I've copied the module to a 
DKMS build location and named the clone sn9c20x_vehoh, matching only on 
0c45_6270, to make testing easier):


 gspca_main: v2.14.0 registered
 gspca_main: sn9c20x_vehoh-2.14.0 probing 0c45:6270
 sn9c20x_vehoh: MT9V011 sensor detected
 sn9c20x_vehoh: MT9VPRB sensor detected
 input: sn9c20x_vehoh as 
/devices/pci:00/:00:1d.7/usb2/2-3/input/input34

 sn9c20x_vehoh 2-3:1.0: video1 created

I'd like to know the best way to add the correct command support in 
this situation where the existing Linux driver's control data is 
different to that in use by the Windows driver?


Do I somehow create another profile in the driver, or directly modify 
the existing data and command sequences (this latter would seem to risk 
regressions for other users) ?


If creating another profile, how would they differentiate seeing as the 
device IDs are identical (I've not seen any sign of obvious version 
responses so far) ?


My first attempt to add the correct command values for controlling the 
LEDs failed, and seems to indicate that more than 1 command is sent to 
control the LEDs, unlike the sn9c20x driver.

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

Re: Automatic device driver back-porting with media_build

[Mason]

On 18/12/2015 12:22, Mauro Carvalho Chehab wrote:

> Patch applied.

Great! Thanks.

Using the latest media_build master + my writel_relaxed work-around,
compilation proceeds much further, then dies on device tree stuff:
(same error with vanilla and custom kernel)

Will look into it. Any idea? :-(

By the way, if I was not clear, I'm cross-compiling for an ARM platform.

  CC [M]  /tmp/sandbox/media_build/v4l/v4l2-of.o
/tmp/sandbox/media_build/v4l/v4l2-of.c: In function 'v4l2_of_parse_csi_bus':
/tmp/sandbox/media_build/v4l/v4l2-of.c:38:4: error: implicit declaration of 
function 'of_prop_next_u32' [-Werror=implicit-function-declaration]
lane = of_prop_next_u32(prop, lane, );
^
/tmp/sandbox/media_build/v4l/v4l2-of.c:38:9: warning: assignment makes pointer 
from integer without a cast
lane = of_prop_next_u32(prop, lane, );
 ^
/tmp/sandbox/media_build/v4l/v4l2-of.c:52:13: warning: assignment makes pointer 
from integer without a cast
polarity = of_prop_next_u32(prop, polarity, );
 ^
/tmp/sandbox/media_build/v4l/v4l2-of.c: In function 'v4l2_of_parse_link':
/tmp/sandbox/media_build/v4l/v4l2-of.c:287:24: warning: passing argument 1 of 
'of_parse_phandle' discards 'const' qualifier from pointer target type
  np = of_parse_phandle(node, "remote-endpoint", 0);
^
In file included from include/linux/i2c.h:36:0,
 from /tmp/sandbox/media_build/v4l/compat.h:977,
 from :0:
include/linux/of.h:237:28: note: expected 'struct device_node *' but argument 
is of type 'const struct device_node *'
 extern struct device_node *of_parse_phandle(struct device_node *np,
^
cc1: some warnings being treated as errors
make[3]: *** [/tmp/sandbox/media_build/v4l/v4l2-of.o] Error 1
make[2]: *** [_module_/tmp/sandbox/media_build/v4l] Error 2
make[2]: Leaving directory `/tmp/sandbox/linux-3.4.39'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/tmp/sandbox/media_build/v4l'
make: *** [all] Error 2

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

Re: problem with coda when running qt-gstreamer and video reaches its end (resending in plain text)

[Piotr Lewicki]

Thank you,
I updated GStreamer to version 1.6.1 and applied patches from Nicolas 
(https://bugzilla.gnome.org/show_bug.cgi?id=733864).

This resolved the issue witch "CODA PIC_RUN timeout".

At the moment situation looks a little bit different:
1. Playing flv videos (video codec: Sorenson Spark Video) allows me to 
play multiple videos and EOS message is received.


2. Playing h264 videos with lower resolution runs smoothly (no CODA 
PIC_RUN timeout) but when video reaches it's end - no message is 
reaching the qt application and thus I can only stop it manually.
* Is there a resolution of this problem with missing end-of-stream 
detection?


3. When playing h264 videos in HD resolution (tested with 
big_buck_bunny_1080p_h264.mov) the problem with "CODA PIC_RUN timeout" 
still occurs with small difference - when I press STOP "CODA PIC_RUN 
timeout" messages don't show up anymore while before they were showing 
up repeatedly (every second) until my qt application stopped.
- Another strange behaviour is that after I get "coda 204.vpu: 
failed to allocate bitstream ringbuffer" message -> the video starts 
running again (when I press PLAY) and it starts detecting end-of-stream 
(!) - see attached file



> # [ 3049.161708] coda 204.vpu: dma_alloc_coherent of size 3133440 failed
> # "Failed to allocate required memory."

That shouldn't happen anymore in recent kernels. In the past, repeated
reqbufs calls would leak buffers because the cleanup was only done on
close.


Dear Phillip,
Unfortunately I'm using i.MX6 device so kernel provided by Freescale is 
v3.14 and I am using kernel provided by Phytec company which is based on 
mainline but the newest version is 3.19 and I cannot upgrade it.


I have already came upon some patches you provided:
starting with 
https://www.mail-archive.com/linux-media@vger.kernel.org/msg77439.html 
and another pack starting with 
http://www.spinics.net/lists/linux-media/msg91575.html
but I think that some of these are dependent on other components like 
e.g. "[PATCH 07/10] [media] coda: drop custom list of pixel format 
descriptions".


* Is there a possibility for you to give me a list of patches to apply 
(and maybe dependent packages) so I can try to apply them manually?

I hope it's not too much too ask..

Best regards
Piotr Lewicki

On 16.12.2015 22:49, Nicolas Dufresne wrote:

Le mercredi 16 décembre 2015 à 15:49 +0100, Philipp Zabel a écrit :

# [ 1382.828875] coda 204.vpu: CODA PIC_RUN timeout
# [ 1383.938704] coda 204.vpu: CODA PIC_RUN timeout
  
The video is stopped but I can see last frame on the screen although in

qt application it should receive end-of-stream message and stop the
video (resulting with black screen).

Looks like the coda driver is constantly fed empty buffers, which don't
increase the bitstream payload level, and the PIC_RUN times out with a
bitstream buffer underflow. What GStreamer version is this?

I believe this is side effect of how the MFC driver worked in it's
early stage. We had to keep pushing empty buffer to drain the driver.
So GStreamer still poll/queue/poll/queue/... until all capture buffers
are received. I notice recently that this behaviour can induce high CPU
load with some other drivers that don't do any active wait when a empty
buffer is queued. I would therefor suggest to change this code to only
push one empty buffer for your use case. An submitted patch to support
CMD_STOP can be found here, though is pending a re-submition by it's
author.

https://bugzilla.gnome.org/show_bug.cgi?id=733864

For proper EOS detection with CODA driver (using EPIPE return value),
you indeed need GStreamer 1.6+.

cheers,
Nicolas


root@phyflex-imx6-2:~# qmlplayer2 file:///.videos/big_buck_bunny_1080p_h264.mov 
QML debugging is enabled. Only use this in a safe environment.ny_1080p_h264.mov  
QEglFSImx6Hooks will set environment variable FB_MULTI_BUFFER=2 to enable double buffering and vsync.
 If this is not desired, you can override this via: export QT_EGLFS_IMX6_NO_FB_MULTI_BUFFER=1
Unable to query physical screen size, defaulting to 100 dpi.
To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters).
** PLAY **
** video runs **
[ 2022.118671] coda 204.vpu: CODA PIC_RUN timeout
[ 2023.118647] coda 204.vpu: CODA PIC_RUN timeout
[ 2024.118645] coda 204.vpu: CODA PIC_RUN timeout
[ 2025.118730] coda 204.vpu: CODA PIC_RUN timeout
[ 2026.118638] coda 204.vpu: CODA PIC_RUN timeout
[ 2027.118640] coda 204.vpu: CODA PIC_RUN timeout
[ 2028.118723] coda 204.vpu: CODA PIC_RUN timeout
[ 2029.118641] coda 204.vpu: CODA PIC_RUN timeout
[ 2030.118638] coda 204.vpu: CODA PIC_RUN timeout
[ 2031.118582] coda 204.vpu: CODA PIC_RUN timeout
[ 2032.118651] coda 204.vpu: CODA PIC_RUN timeout
[ 2033.118576] coda 204.vpu: CODA PIC_RUN timeout
[ 2034.118582] coda 204.vpu: CODA PIC_RUN timeout
[ 2035.118597] coda 204.vpu: CODA PIC_RUN timeout
[ 2036.118632] coda 

Re: Automatic device driver back-porting with media_build

[Mauro Carvalho Chehab]

Em Fri, 18 Dec 2015 09:03:45 -0200
Mauro Carvalho Chehab  escreveu:

> Em Fri, 18 Dec 2015 11:44:35 +0100
> Mason  escreveu:
> 
> > On 17/12/2015 18:03, Mason wrote:
> > 
> > > The media_build process prints:
> > > 
> > > "Preparing to compile for kernel version 3.4.3913"
> > > 
> > > In fact, the custom kernel's Makefile contains:
> > > 
> > > VERSION = 3
> > > PATCHLEVEL = 4
> > > SUBLEVEL = 39
> > > EXTRAVERSION = 13
> > > NAME = Saber-toothed Squirrel
> > > 
> > > Is it possible that the build process gets confused by the EXTRAVERSION 
> > > field?
> > 
> > Here's the problem:
> > 
> > v4l/Makefile writes to KERNELRELEASE and v4l/.version
> > 
> > -e 'printf 
> > ("VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s%s\n",' \
> > -e '
> > $$version,$$level,$$sublevel,$$version,$$level,$$sublevel,$$extra);' \
> > 
> > $ cat v4l/.version 
> > VERSION=3
> > PATCHLEVEL:=4
> > SUBLEVEL:=39
> > KERNELRELEASE:=3.4.3913
> > SRCDIR:=/tmp/sandbox/custom-linux-3.4
> > 
> > Then $(MAKE) -C ../linux apply_patches calls
> > patches_for_kernel.pl 3.4.3913
> > 
> > which computes kernel_version
> > = 3 << 16 + 4 << 8 + 3913 = 0x031349
> > 
> > which is incorrectly interpreted as kernel 3.19.73
> > thus the correct patches are not applied.
> > 
> > Trivial patch follows. Will test right away.
> > 
> > Regards.
> > 
> > diff --git a/v4l/Makefile b/v4l/Makefile
> > index 1542092004fa..9147a98639b7 100644
> > --- a/v4l/Makefile
> > +++ b/v4l/Makefile
> > @@ -233,9 +233,9 @@ ifneq ($(DIR),)
> > -e 'elsif (/^EXTRAVERSION\s*=\s*(\S+)\n/){ $$extra=$$1; }' \
> > -e 'elsif (/^KERNELSRC\s*:=\s*(\S.*)\n/ || 
> > /^MAKEARGS\s*:=\s*-C\s*(\S.*)\n/)' \
> > -e '{ $$o=$$d; $$d=$$1; goto S; }' \
> > -e '};' \
> > -   -e 'printf 
> > ("VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s%s\n",' \
> > +   -e 'printf 
> > ("VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s.%s\n",' 
> > \
> > -e '
> > $$version,$$level,$$sublevel,$$version,$$level,$$sublevel,$$extra);' \
> 
> Hmm... that doesn't sound right on upstream Kernels.
> 
> For example, the extra version on the media_build current Kernel is:
> 
> Makefile:EXTRAVERSION = -rc2
> 
> So, I guess we'll need a different regex, like:
> 
>  -e 'elsif (/^EXTRAVERSION\s*=\s*(\d+)\n/){ $$extra=".$$1"; }' \
>  -e 'elsif (/^EXTRAVERSION\s*=\s*(\S+)\n/){ $$extra=$$1; }' \

Yes, this works. Changing a 2.6.32 kernel to:

VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 32
EXTRAVERSION = 99

It gets:
Forcing compiling to version 2.6.32.99
make[1]: Leaving directory '/devel/v4l/media_build/v4l'

And
KERNELRELEASE:=2.6.32.99

Changing EXTRAVERSION to:
EXTRAVERSION = -rc99

It gets:
Forcing compiling to version 2.6.32-rc99
And
 KERNELRELEASE:=2.6.32-rc99 

Patch applied.

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

Re: Automatic device driver back-porting with media_build

[Mason]

On 18/12/2015 13:10, Mason wrote:

> On 18/12/2015 12:22, Mauro Carvalho Chehab wrote:
> 
>> Patch applied.
> 
> Great! Thanks.
> 
> Using the latest media_build master + my writel_relaxed work-around,
> compilation proceeds much further, then dies on device tree stuff:
> (same error with vanilla and custom kernel)
> 
> Will look into it. Any idea? :-(
> 
> By the way, if I was not clear, I'm cross-compiling for an ARM platform.
> 
>   CC [M]  /tmp/sandbox/media_build/v4l/v4l2-of.o
> /tmp/sandbox/media_build/v4l/v4l2-of.c: In function 'v4l2_of_parse_csi_bus':
> /tmp/sandbox/media_build/v4l/v4l2-of.c:38:4: error: implicit declaration of 
> function 'of_prop_next_u32' [-Werror=implicit-function-declaration]
> lane = of_prop_next_u32(prop, lane, );
> ^

of_prop_next_u32() was introduced by commit c541adc637066
$ git describe --contains c541adc637066
v3.5-rc1~176^2~34

So it seems something needs to be done for kernels older than 3.5

I'll hack around it by adding

static inline const __be32 *of_prop_next_u32(struct property *prop,
const __be32 *cur, u32 *pu)
{
return NULL;
}

What's the correct fix?

> /tmp/sandbox/media_build/v4l/v4l2-of.c: In function 'v4l2_of_parse_link':
> /tmp/sandbox/media_build/v4l/v4l2-of.c:287:24: warning: passing argument 1 of 
> 'of_parse_phandle' discards 'const' qualifier from pointer target type
>   np = of_parse_phandle(node, "remote-endpoint", 0);
> ^

Commit b8fbdc42c5c5d made the first parameter const.

$ git describe --contains b8fbdc42c5c5d
v3.8-rc1~105^2~13

I suppose I can live with the warning for now.

Regards.

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

[PATCH 5/5] staging: media: lirc: use new parport device model

[Sudip Mukherjee]

Modify lirc_parallel driver to use the new parallel port device model.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/media/lirc/lirc_parallel.c | 100 +++--
 1 file changed, 65 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_parallel.c 
b/drivers/staging/media/lirc/lirc_parallel.c
index 0156114..20ec9b6 100644
--- a/drivers/staging/media/lirc/lirc_parallel.c
+++ b/drivers/staging/media/lirc/lirc_parallel.c
@@ -629,43 +629,26 @@ static void kf(void *handle)
*/
 }
 
-/*** module initialization and cleanup ***/
-
-static int __init lirc_parallel_init(void)
+static void lirc_parallel_attach(struct parport *port)
 {
-   int result;
+   struct pardev_cb lirc_parallel_cb;
 
-   result = platform_driver_register(_parallel_driver);
-   if (result) {
-   pr_notice("platform_driver_register returned %d\n", result);
-   return result;
-   }
+   if (port->base != io)
+   return;
 
-   lirc_parallel_dev = platform_device_alloc(LIRC_DRIVER_NAME, 0);
-   if (!lirc_parallel_dev) {
-   result = -ENOMEM;
-   goto exit_driver_unregister;
-   }
+   pport = port;
+   memset(_parallel_cb, 0, sizeof(lirc_parallel_cb));
+   lirc_parallel_cb.preempt = pf;
+   lirc_parallel_cb.wakeup = kf;
+   lirc_parallel_cb.irq_func = lirc_lirc_irq_handler;
 
-   result = platform_device_add(lirc_parallel_dev);
-   if (result)
-   goto exit_device_put;
-
-   pport = parport_find_base(io);
-   if (!pport) {
-   pr_notice("no port at %x found\n", io);
-   result = -ENXIO;
-   goto exit_device_put;
-   }
-   ppdevice = parport_register_device(pport, LIRC_DRIVER_NAME,
-  pf, kf, lirc_lirc_irq_handler, 0,
-  NULL);
-   parport_put_port(pport);
+   ppdevice = parport_register_dev_model(port, LIRC_DRIVER_NAME,
+ _parallel_cb, 0);
if (!ppdevice) {
pr_notice("parport_register_device() failed\n");
-   result = -ENXIO;
-   goto exit_device_put;
+   return;
}
+
if (parport_claim(ppdevice) != 0)
goto skip_init;
is_claimed = 1;
@@ -693,18 +676,66 @@ static int __init lirc_parallel_init(void)
 
is_claimed = 0;
parport_release(ppdevice);
- skip_init:
+
+skip_init:
+   return;
+}
+
+static void lirc_parallel_detach(struct parport *port)
+{
+   if (port->base != io)
+   return;
+
+   parport_unregister_device(ppdevice);
+}
+
+static struct parport_driver lirc_parport_driver = {
+   .name = LIRC_DRIVER_NAME,
+   .match_port = lirc_parallel_attach,
+   .detach = lirc_parallel_detach,
+   .devmodel = true,
+};
+
+/*** module initialization and cleanup ***/
+
+static int __init lirc_parallel_init(void)
+{
+   int result;
+
+   result = platform_driver_register(_parallel_driver);
+   if (result) {
+   pr_notice("platform_driver_register returned %d\n", result);
+   return result;
+   }
+
+   lirc_parallel_dev = platform_device_alloc(LIRC_DRIVER_NAME, 0);
+   if (!lirc_parallel_dev) {
+   result = -ENOMEM;
+   goto exit_driver_unregister;
+   }
+
+   result = platform_device_add(lirc_parallel_dev);
+   if (result)
+   goto exit_device_put;
+
+   result = parport_register_driver(_parport_driver);
+   if (result) {
+   pr_notice("parport_register_driver returned %d\n", result);
+   goto exit_device_put;
+   }
+
driver.dev = _parallel_dev->dev;
driver.minor = lirc_register_driver();
if (driver.minor < 0) {
pr_notice("register_chrdev() failed\n");
-   parport_unregister_device(ppdevice);
result = -EIO;
-   goto exit_device_put;
+   goto exit_unregister;
}
pr_info("installed using port 0x%04x irq %d\n", io, irq);
return 0;
 
+exit_unregister:
+   parport_unregister_driver(_parport_driver);
 exit_device_put:
platform_device_put(lirc_parallel_dev);
 exit_driver_unregister:
@@ -714,9 +745,8 @@ exit_driver_unregister:
 
 static void __exit lirc_parallel_exit(void)
 {
-   parport_unregister_device(ppdevice);
lirc_unregister_driver(driver.minor);
-
+   parport_unregister_driver(_parport_driver);
platform_device_unregister(lirc_parallel_dev);
platform_driver_unregister(_parallel_driver);
 }
-- 
1.9.1

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

[PATCH 4/5] staging: media: lirc: place operator on previous line

[Sudip Mukherjee]

checkpatch complains about the logical operator, which should be on the
previous line.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/media/lirc/lirc_parallel.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_parallel.c 
b/drivers/staging/media/lirc/lirc_parallel.c
index e09894d..0156114 100644
--- a/drivers/staging/media/lirc/lirc_parallel.c
+++ b/drivers/staging/media/lirc/lirc_parallel.c
@@ -157,9 +157,9 @@ static unsigned int init_lirc_timer(void)
count++;
level = newlevel;
do_gettimeofday();
-   } while (count < 1000 && (now.tv_sec < tv.tv_sec
-|| (now.tv_sec == tv.tv_sec
-&& now.tv_usec < tv.tv_usec)));
+   } while (count < 1000 && (now.tv_sec < tv.tv_sec ||
+ (now.tv_sec == tv.tv_sec &&
+  now.tv_usec < tv.tv_usec)));
 
timeelapsed = (now.tv_sec + 1 - tv.tv_sec) * 100
 + (now.tv_usec - tv.tv_usec);
@@ -279,8 +279,8 @@ static void lirc_lirc_irq_handler(void *blah)
level = newlevel;
 
/* giving up */
-   if (signal > timeout
-   || (check_pselecd && (in(1) & LP_PSELECD))) {
+   if (signal > timeout ||
+   (check_pselecd && (in(1) & LP_PSELECD))) {
signal = 0;
pr_notice("timeout\n");
break;
-- 
1.9.1

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

[PATCH 3/5] staging: media: lirc: space around operator

[Sudip Mukherjee]

checkpatch complains about missing space around operators.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/media/lirc/lirc_parallel.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_parallel.c 
b/drivers/staging/media/lirc/lirc_parallel.c
index f65ab93..e09894d 100644
--- a/drivers/staging/media/lirc/lirc_parallel.c
+++ b/drivers/staging/media/lirc/lirc_parallel.c
@@ -161,17 +161,17 @@ static unsigned int init_lirc_timer(void)
 || (now.tv_sec == tv.tv_sec
 && now.tv_usec < tv.tv_usec)));
 
-   timeelapsed = (now.tv_sec + 1 - tv.tv_sec)*100
+   timeelapsed = (now.tv_sec + 1 - tv.tv_sec) * 100
 + (now.tv_usec - tv.tv_usec);
if (count >= 1000 && timeelapsed > 0) {
if (default_timer == 0) {
/* autodetect timer */
-   newtimer = (100*count)/timeelapsed;
+   newtimer = (100 * count) / timeelapsed;
pr_info("%u Hz timer detected\n", newtimer);
return newtimer;
}
-   newtimer = (100*count)/timeelapsed;
-   if (abs(newtimer - default_timer) > default_timer/10) {
+   newtimer = (100 * count) / timeelapsed;
+   if (abs(newtimer - default_timer) > default_timer / 10) {
/* bad timer */
pr_notice("bad timer: %u Hz\n", newtimer);
pr_notice("using default timer: %u Hz\n",
@@ -196,7 +196,7 @@ static int lirc_claim(void)
return 0;
}
}
-   out(LIRC_LP_CONTROL, LP_PSELECP|LP_PINITP);
+   out(LIRC_LP_CONTROL, LP_PSELECP | LP_PINITP);
is_claimed = 1;
return 1;
 }
@@ -251,7 +251,7 @@ static void lirc_lirc_irq_handler(void *blah)
/* really long time */
data = PULSE_MASK;
else
-   data = (int)(signal*100 +
+   data = (int)(signal * 100 +
 tv.tv_usec - lasttv.tv_usec +
 LIRC_SFH506_DELAY);
 
@@ -269,7 +269,7 @@ static void lirc_lirc_irq_handler(void *blah)
init = 1;
}
 
-   timeout = timer/10; /* timeout after 1/10 sec. */
+   timeout = timer / 10;   /* timeout after 1/10 sec. */
signal = 1;
level = lirc_get_timer();
do {
@@ -291,7 +291,7 @@ static void lirc_lirc_irq_handler(void *blah)
/* adjust value to usecs */
__u64 helper;
 
-   helper = ((__u64)signal)*100;
+   helper = ((__u64)signal) * 100;
do_div(helper, timer);
signal = (long)helper;
 
@@ -299,7 +299,7 @@ static void lirc_lirc_irq_handler(void *blah)
data = signal - LIRC_SFH506_DELAY;
else
data = 1;
-   rbuf_write(PULSE_BIT|data); /* pulse */
+   rbuf_write(PULSE_BIT | data); /* pulse */
}
do_gettimeofday();
 #else
@@ -336,7 +336,7 @@ static ssize_t lirc_read(struct file *filep, char __user 
*buf, size_t n,
set_current_state(TASK_INTERRUPTIBLE);
while (count < n) {
if (rptr != wptr) {
-   if (copy_to_user(buf+count, [rptr],
+   if (copy_to_user(buf + count, [rptr],
 sizeof(int))) {
result = -EFAULT;
break;
@@ -398,7 +398,7 @@ static ssize_t lirc_write(struct file *filep, const char 
__user *buf, size_t n,
for (i = 0; i < count; i++) {
__u64 helper;
 
-   helper = ((__u64)wbuf[i])*timer;
+   helper = ((__u64)wbuf[i]) * timer;
do_div(helper, 100);
wbuf[i] = (int)helper;
}
@@ -669,7 +669,7 @@ static int __init lirc_parallel_init(void)
if (parport_claim(ppdevice) != 0)
goto skip_init;
is_claimed = 1;
-   out(LIRC_LP_CONTROL, LP_PSELECP|LP_PINITP);
+   out(LIRC_LP_CONTROL, LP_PSELECP | LP_PINITP);
 
 #ifdef LIRC_TIMER
if (debug)
-- 
1.9.1

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

[PATCH 2/5] staging: media: lirc: no space after cast

[Sudip Mukherjee]

checkpatch complains about space after type cast.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/media/lirc/lirc_parallel.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_parallel.c 
b/drivers/staging/media/lirc/lirc_parallel.c
index 9df8d14..f65ab93 100644
--- a/drivers/staging/media/lirc/lirc_parallel.c
+++ b/drivers/staging/media/lirc/lirc_parallel.c
@@ -251,7 +251,7 @@ static void lirc_lirc_irq_handler(void *blah)
/* really long time */
data = PULSE_MASK;
else
-   data = (int) (signal*100 +
+   data = (int)(signal*100 +
 tv.tv_usec - lasttv.tv_usec +
 LIRC_SFH506_DELAY);
 
@@ -291,9 +291,9 @@ static void lirc_lirc_irq_handler(void *blah)
/* adjust value to usecs */
__u64 helper;
 
-   helper = ((__u64) signal)*100;
+   helper = ((__u64)signal)*100;
do_div(helper, timer);
-   signal = (long) helper;
+   signal = (long)helper;
 
if (signal > LIRC_SFH506_DELAY)
data = signal - LIRC_SFH506_DELAY;
@@ -398,9 +398,9 @@ static ssize_t lirc_write(struct file *filep, const char 
__user *buf, size_t n,
for (i = 0; i < count; i++) {
__u64 helper;
 
-   helper = ((__u64) wbuf[i])*timer;
+   helper = ((__u64)wbuf[i])*timer;
do_div(helper, 100);
-   wbuf[i] = (int) helper;
+   wbuf[i] = (int)helper;
}
 
local_irq_save(flags);
-- 
1.9.1

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

[PATCH 1/5] staging: media: lirc: replace NULL comparisons with !var

[Sudip Mukherjee]

A NULL comparison can be written as if (var) or if (!var).
Reported by checkpatch.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/media/lirc/lirc_parallel.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_parallel.c 
b/drivers/staging/media/lirc/lirc_parallel.c
index c140834..9df8d14 100644
--- a/drivers/staging/media/lirc/lirc_parallel.c
+++ b/drivers/staging/media/lirc/lirc_parallel.c
@@ -652,7 +652,7 @@ static int __init lirc_parallel_init(void)
goto exit_device_put;
 
pport = parport_find_base(io);
-   if (pport == NULL) {
+   if (!pport) {
pr_notice("no port at %x found\n", io);
result = -ENXIO;
goto exit_device_put;
@@ -661,7 +661,7 @@ static int __init lirc_parallel_init(void)
   pf, kf, lirc_lirc_irq_handler, 0,
   NULL);
parport_put_port(pport);
-   if (ppdevice == NULL) {
+   if (!ppdevice) {
pr_notice("parport_register_device() failed\n");
result = -ENXIO;
goto exit_device_put;
-- 
1.9.1

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

Re: Automatic device driver back-porting with media_build

[Mason]

On 18/12/2015 14:40, Mason wrote:

> I will try building a kernel with CONFIG_OF=n

Build works much better with CONFIG_OF=n
I suppose OF support with ancient kernels is untested.
(My setup didn't need it anyway.)

The remaining issue is:

WARNING: "nsecs_to_jiffies" [/tmp/sandbox/media_build/v4l/gpio-ir-recv.ko] 
undefined!

$ git describe --contains d560fed6abe0f
v3.17-rc1~109^2~40

The actual call site was added recently by commit 3fb136f3392d
(Hasn't even it linux-stable yet, I only see it in next-20151123)

I think a patch is needed for kernels < 3.17 right?

Regards.

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

[PATCH] [media] videobuf2: avoid memory leak on errors

[Mauro Carvalho Chehab]

As reported by smatch:
drivers/media/v4l2-core/videobuf2-core.c:2415 __vb2_init_fileio() warn: 
possible memory leak of 'fileio'

While here, avoid the usage of sizeof(struct foo_struct).

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/videobuf2-core.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index e6890d47cdcb..c5d49d7a0d76 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2406,13 +2406,15 @@ static int __vb2_init_fileio(struct vb2_queue *q, int 
read)
(read) ? "read" : "write", count, q->fileio_read_once,
q->fileio_write_immediately);
 
-   fileio = kzalloc(sizeof(struct vb2_fileio_data), GFP_KERNEL);
+   fileio = kzalloc(sizeof(*fileio), GFP_KERNEL);
if (fileio == NULL)
return -ENOMEM;
 
fileio->b = kzalloc(q->buf_struct_size, GFP_KERNEL);
-   if (fileio->b == NULL)
+   if (fileio->b == NULL) {
+   kfree(fileio);
return -ENOMEM;
+   }
 
fileio->read_once = q->fileio_read_once;
fileio->write_immediately = q->fileio_write_immediately;
-- 
2.5.0

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

Re: Automatic device driver back-porting with media_build

[Mason]

On 18/12/2015 13:59, Mason wrote: [snip previous work-arounds]

Compilation completes.

make -C /tmp/sandbox/custom-linux-3.4 SUBDIRS=/tmp/sandbox/media_build/v4l  
modules
make[2]: Entering directory `/tmp/sandbox/custom-linux-3.4'
  Building modules, stage 2.
  MODPOST 209 modules
WARNING: "of_graph_parse_endpoint" [/tmp/sandbox/media_build/v4l/videodev.ko] 
undefined!
WARNING: "of_get_next_parent" [/tmp/sandbox/media_build/v4l/videodev.ko] 
undefined!
WARNING: "nsecs_to_jiffies" [/tmp/sandbox/media_build/v4l/gpio-ir-recv.ko] 
undefined!
make[2]: Leaving directory `/tmp/sandbox/custom-linux-3.4'
./scripts/rmmod.pl check
found 209 modules
make[1]: Leaving directory `/tmp/sandbox/media_build/v4l'


A few link problems, two from device tree:

of_graph_parse_endpoint() commit fd9fdb78a9bf8

of_get_next_parent() was not exported until commit 6695be6863b75

nsecs_to_jiffies() was not exported until commit d560fed6abe0f

How would you fix those?

I will try building a kernel with CONFIG_OF=n

Regards.

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

Review & Reply

[J.Tynan]

Greetings,
My name is Mr.Michael J. Tynan, I am a banker with Bank Of America. It is true 
that we have not meet each other in person, but I strongly believe in trust and 
friendship in every business. I have a Lebanese deceased customer's abandoned 
fund, which I am his personal financial adviser before his accidental death, 
that being the main reason why I alone working in the bank here, know much 
about the existence of this fund and the secrets surrounding this money. But 
before I disclose the full details to you, I will like to know your interest 
and willingness to assist me. You can call me as soon you receive my message, 
so that i will send to you full details about the transaction.
My best regards,
Mr.Michael J. Tynan
MOBILE: +1 347 269 3740
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[v4l-utils PATCH-v2 1/4] dvbv5-zap.c: fix setting signal handlers

[Jemma Denson]

Signal handlers are currently out of order - SIGALRM is always set, and
SIGINT only set when timeout is set. These should be the other way round.

Signed-off-by: Jemma Denson 
---
 utils/dvb/dvbv5-zap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/utils/dvb/dvbv5-zap.c b/utils/dvb/dvbv5-zap.c
index e19d7c2..e927383 100644
--- a/utils/dvb/dvbv5-zap.c
+++ b/utils/dvb/dvbv5-zap.c
@@ -959,10 +959,10 @@ int main(int argc, char **argv)
goto err;
}
 
-   signal(SIGALRM, do_timeout);
signal(SIGTERM, do_timeout);
+   signal(SIGINT, do_timeout);
if (args.timeout > 0) {
-   signal(SIGINT, do_timeout);
+   signal(SIGALRM, do_timeout);
alarm(args.timeout);
}
 
-- 
2.1.0

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

[v4l-utils PATCH-v2 2/4] dvbv5-zap.c: allow timeout with -x

[Jemma Denson]

Timeout handlers aren't set when running with -x (exit after tuning).
This patch adds handlers so -t can be used with -x.

Without a timeout dvbv5-zap will run forever if there's no signal,
preventing it's use by scripts to obtain signal stats.

Signed-off-by: Jemma Denson 
---
 utils/dvb/dvbv5-zap.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/utils/dvb/dvbv5-zap.c b/utils/dvb/dvbv5-zap.c
index e927383..2d19d45 100644
--- a/utils/dvb/dvbv5-zap.c
+++ b/utils/dvb/dvbv5-zap.c
@@ -855,6 +855,13 @@ int main(int argc, char **argv)
goto err;
 
if (args.exit_after_tuning) {
+   signal(SIGTERM, do_timeout);
+   signal(SIGINT, do_timeout);
+   if (args.timeout > 0) {
+   signal(SIGALRM, do_timeout);
+   alarm(args.timeout);
+   }
+
err = 0;
check_frontend(, parms);
goto err;
-- 
2.1.0

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

[v4l-utils PATCH-v2 4/4] dvbv5-zap.c: Move common signals code into function

[Jemma Denson]

Code repeated 3 times; move to common function.

Signed-off-by: Jemma Denson 
---
 utils/dvb/dvbv5-zap.c | 33 +
 1 file changed, 13 insertions(+), 20 deletions(-)

diff --git a/utils/dvb/dvbv5-zap.c b/utils/dvb/dvbv5-zap.c
index 2d71307..ef17be9 100644
--- a/utils/dvb/dvbv5-zap.c
+++ b/utils/dvb/dvbv5-zap.c
@@ -737,6 +737,16 @@ int do_traffic_monitor(struct arguments *args,
return 0;
 }
 
+static void set_signals(struct arguments *args)
+{
+   signal(SIGTERM, do_timeout);
+   signal(SIGINT, do_timeout);
+   if (args->timeout > 0) {
+   signal(SIGALRM, do_timeout);
+   alarm(args->timeout);
+   }
+}
+
 int main(int argc, char **argv)
 {
struct arguments args;
@@ -855,26 +865,14 @@ int main(int argc, char **argv)
goto err;
 
if (args.exit_after_tuning) {
-   signal(SIGTERM, do_timeout);
-   signal(SIGINT, do_timeout);
-   if (args.timeout > 0) {
-   signal(SIGALRM, do_timeout);
-   alarm(args.timeout);
-   }
-
+   set_signals();
err = 0;
check_frontend(, parms);
goto err;
}
 
if (args.traffic_monitor) {
-   signal(SIGTERM, do_timeout);
-   signal(SIGINT, do_timeout);
-   if (args.timeout > 0) {
-   signal(SIGALRM, do_timeout);
-   alarm(args.timeout);
-   }
-
+   set_signals();
err = do_traffic_monitor(, parms);
goto err;
}
@@ -966,12 +964,7 @@ int main(int argc, char **argv)
goto err;
}
 
-   signal(SIGTERM, do_timeout);
-   signal(SIGINT, do_timeout);
-   if (args.timeout > 0) {
-   signal(SIGALRM, do_timeout);
-   alarm(args.timeout);
-   }
+   set_signals();
 
if (!check_frontend(, parms)) {
err = 1;
-- 
2.1.0

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

Patches to dvbv5-zap

[Jemma Denson]

This patch series replaces the single patch sent earlier today. Essentially
it's to allow -t to be used at the same time as -x. We have a requirement
to show signal stats in a web interface and a lack of timeout would cause
issues when there's no signal.

The other patches are fixing bugs I noticed in adding this and then
simplifying the code slightly.

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

[v4l-utils PATCH-v2 3/4] dvbv5-zap.c: fix wrong signal

[Jemma Denson]

Signal here should be SIGALRM and not SIGINT in order to call do_timeout().

Signed-off-by: Jemma Denson 
---
 utils/dvb/dvbv5-zap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utils/dvb/dvbv5-zap.c b/utils/dvb/dvbv5-zap.c
index 2d19d45..2d71307 100644
--- a/utils/dvb/dvbv5-zap.c
+++ b/utils/dvb/dvbv5-zap.c
@@ -871,7 +871,7 @@ int main(int argc, char **argv)
signal(SIGTERM, do_timeout);
signal(SIGINT, do_timeout);
if (args.timeout > 0) {
-   signal(SIGINT, do_timeout);
+   signal(SIGALRM, do_timeout);
alarm(args.timeout);
}
 
-- 
2.1.0

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

[PATCH] [media] dvbdev: avoid unused functions

[Arnd Bergmann]

The dvb_create_tsout_entity and dvb_create_media_entity
functions are only called if CONFIG_MEDIA_CONTROLLER_DVB is
enabled, otherwise we get a compiler warning:

dvb-core/dvbdev.c:219:12: warning: 'dvb_create_tsout_entity' defined but not 
used [-Wunused-function]
dvb-core/dvbdev.c:264:12: warning: 'dvb_create_media_entity' defined but not 
used [-Wunused-function]

This moves the #ifdef inside of the two functions to the
outside, to avoid the two warnings.

Signed-off-by: Arnd Bergmann 

diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
index b56e00817d3f..860dd7d06b60 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -216,10 +216,10 @@ static void dvb_media_device_free(struct dvb_device 
*dvbdev)
 #endif
 }
 
+#if defined(CONFIG_MEDIA_CONTROLLER_DVB)
 static int dvb_create_tsout_entity(struct dvb_device *dvbdev,
const char *name, int npads)
 {
-#if defined(CONFIG_MEDIA_CONTROLLER_DVB)
int i, ret = 0;
 
dvbdev->tsout_pads = kcalloc(npads, sizeof(*dvbdev->tsout_pads),
@@ -254,7 +254,6 @@ static int dvb_create_tsout_entity(struct dvb_device 
*dvbdev,
if (ret < 0)
return ret;
}
-#endif
return 0;
 }
 
@@ -264,7 +263,6 @@ static int dvb_create_tsout_entity(struct dvb_device 
*dvbdev,
 static int dvb_create_media_entity(struct dvb_device *dvbdev,
   int type, int demux_sink_pads)
 {
-#if defined(CONFIG_MEDIA_CONTROLLER_DVB)
int i, ret, npads;
 
switch (type) {
@@ -352,9 +350,9 @@ static int dvb_create_media_entity(struct dvb_device 
*dvbdev,
printk(KERN_DEBUG "%s: media entity '%s' registered.\n",
__func__, dvbdev->entity->name);
 
-#endif
return 0;
 }
+#endif
 
 static int dvb_register_media_device(struct dvb_device *dvbdev,
 int type, int minor,

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

[PATCH] [media] cx23885-dvb: move initialization of a8293_pdata

[Mauro Carvalho Chehab]

Smatch complains about where the au8293_data is placed:

drivers/media/pci/cx23885/cx23885-dvb.c:2174 dvb_register() info: 'a8293_pdata' 
is not actually initialized (unreached code).

It is not actually expected to have such initialization at

switch {
foo = bar;

case:
...
}

Not really sure how gcc does that, but this is something that I would
expect that different compilers would do different things.

So, move the initialization outside the switch(), making smatch to
shut up one warning.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/pci/cx23885/cx23885-dvb.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c 
b/drivers/media/pci/cx23885/cx23885-dvb.c
index adabb0bc21ad..80319bb73d94 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -2168,10 +2168,11 @@ static int dvb_register(struct cx23885_tsport *port)
}
port->i2c_client_tuner = client_tuner;
break;
-   case CX23885_BOARD_HAUPPAUGE_HVR5525:
-   switch (port->nr) {
+   case CX23885_BOARD_HAUPPAUGE_HVR5525: {
struct m88rs6000t_config m88rs6000t_config;
-   struct a8293_platform_data a8293_pdata = { 0 };
+   struct a8293_platform_data a8293_pdata = {};
+
+   switch (port->nr) {
 
/* port b - satellite */
case 1:
@@ -2267,6 +2268,7 @@ static int dvb_register(struct cx23885_tsport *port)
break;
}
break;
+   }
default:
printk(KERN_INFO "%s: The frontend of your DVB/ATSC card "
" isn't supported yet\n",
-- 
2.5.0

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

Re: [PATCH/RFC 26/48] videodev2.h: Add request field to v4l2_pix_format_mplane

[Laurent Pinchart]

Hi Hans,

Thank you for the review.

On Friday 18 December 2015 12:18:26 Hans Verkuil wrote:
> On 12/17/2015 09:40 AM, Laurent Pinchart wrote:
> > Let userspace specify a request ID when getting or setting formats. The
> > support is limited to the multi-planar API at the moment, extending it
> > to the single-planar API is possible if needed.
> > 
> > From a userspace point of view the API change is also minimized and
> > doesn't require any new ioctl.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  include/uapi/linux/videodev2.h | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/uapi/linux/videodev2.h
> > b/include/uapi/linux/videodev2.h index 5af1d2d87558..5b2a8bc80eb2 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -1973,6 +1973,7 @@ struct v4l2_plane_pix_format {
> > 
> >   * @ycbcr_enc: enum v4l2_ycbcr_encoding, Y'CbCr encoding
> >   * @quantization:  enum v4l2_quantization, colorspace quantization
> >   * @xfer_func: enum v4l2_xfer_func, colorspace transfer 
> > function
> > 
> > + * @request:   request ID
> > 
> >   */
> >  
> >  struct v4l2_pix_format_mplane {
> >  
> > __u32   width;
> > 
> > @@ -1987,7 +1988,8 @@ struct v4l2_pix_format_mplane {
> > 
> > __u8ycbcr_enc;
> > __u8quantization;
> > __u8xfer_func;
> > 
> > -   __u8reserved[7];
> > +   __u8reserved[3];
> > +   __u32   request;
> 
> I think I mentioned this before: I feel uncomfortable using 4 bytes of the
> reserved fields when the request ID is limited to 16 bits anyway.

I'm still unsure whether request IDs should be 16 or 32 bits long. If we go 
for 16 bits then I'll of course make this field a __u16.

> I would prefer a __u16 here. Also put the request field *before* the
> reserved array, not after.

The reserved array isn't aligned to a 32 bit (or even 16 bit) boundary. I can 
put the request field before it, with a 8 bit hole before the field.

> >  } __attribute__ ((packed));
> >  
> >  /**

-- 
Regards,

Laurent Pinchart

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

[GIT PULL] mem2mem changes

[Kamil Debski]

The following changes since commit ecc2fe20e63a21b7db23065ff061b66fbc08e08b:

  [media] cx23885: video instead of vbi register used (2015-12-18 13:37:12
-0200)

are available in the git repository at:

  git://linuxtv.org/kdebski/media_tree_2.git for-4.5

for you to fetch changes up to 64d8dc83df6bbd58e1782670d6adaf2ff6be9141:

  coda: enable MPEG-2 ES decoding (2015-12-18 17:31:03 +0100)


Andrzej Hajda (6):
  s5p-mfc: use one implementation of s5p_mfc_get_new_ctx
  s5p-mfc: make queue cleanup code common
  s5p-mfc: remove unnecessary callbacks
  s5p-mfc: use spinlock to protect MFC context
  s5p-mfc: merge together s5p_mfc_hw_call and s5p_mfc_hw_call_void
  s5p-mfc: remove volatile attribute from MFC register addresses

Julia Lawall (1):
  s5p-mfc: constify s5p_mfc_codec_ops structures

Philipp Zabel (5):
  coda: make to_coda_video_device static
  coda: relax coda_jpeg_check_buffer for trailing bytes
  coda: hook up vidioc_prepare_buf
  coda: don't start streaming without queued buffers
  coda: enable MPEG-2 ES decoding

 drivers/media/platform/coda/coda-bit.c  |   2 +-
 drivers/media/platform/coda/coda-common.c   |  21 +-
 drivers/media/platform/coda/coda-jpeg.c |  26 +-
 drivers/media/platform/coda/coda.h  |   2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc.c|  99 +++--
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  14 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   |  16 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|  35 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.h|   2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|  44 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.h|   2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.h| 507

 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c |  94 -
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 121 +-
 14 files changed, 390 insertions(+), 595 deletions(-)

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

Re: Automatic device driver back-porting with media_build

[Mason]

On 17/12/2015 15:55, Mauro Carvalho Chehab wrote:

> Did the driver compile fine?

Once all the modules finish building, I have many *.ko files in v4l.

I copy them to my target's /lib/modules/3.4.39.13/kernel
and run depmod -a

It seems modprobe rc-dvbsky doesn't bring in all the stuff needed
to actually use the device.

I added a few more modules at random:

Module  Size  Used by
dvb_core   73479  0 
v4l2_common 1628  0 
videodev  111886  1 v4l2_common
media   9838  1 videodev
rc_dvbsky815  0 
rc_core15521  1 rc_dvbsky

Probably needs dvb_usb but I don't see it built...

$ grep -rn '\'
linux/drivers/media/usb/dvb-usb/Makefile:3:obj-$(CONFIG_DVB_USB) += dvb-usb.o
v4l/.myconfig:245:CONFIG_DVB_USB   := n
v4l/Makefile.media:1010:obj-$(CONFIG_DVB_USB) += dvb-usb.o
v4l/config-compat.h:548:#undef CONFIG_DVB_USB
v4l/.config:183:# CONFIG_DVB_USB is not set

(All these files are generated by the build process.)

Am I doing something wrong?

Regards.

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

Re: [PATCH] [media] cx23885-dvb: move initialization of a8293_pdata

[Mauro Carvalho Chehab]

Em Fri, 18 Dec 2015 16:52:40 +
David Howells  escreveu:

> Mauro Carvalho Chehab  wrote:
> 
> > Smatch complains about where the au8293_data is placed:
> > 
> > drivers/media/pci/cx23885/cx23885-dvb.c:2174 dvb_register() info: 
> > 'a8293_pdata' is not actually initialized (unreached code).
> > 
> > It is not actually expected to have such initialization at
> > 
> > switch {
> > foo = bar;
> > 
> > case:
> > ...
> > }
> > 
> > Not really sure how gcc does that, but this is something that I would
> > expect that different compilers would do different things.
> > 
> > So, move the initialization outside the switch(), making smatch to
> > shut up one warning.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> 
> Yeah - checked with the compiler people: it's not really expected to
> initialise as expected.

Thank you for checking it! Yeah, the above code weren't smelling
well ;) Good to know for sure that such constructions may not be
doing what humans would expect...
 
> Acked-by: David Howells 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL for v4.4-rc6] media fixes

[Mauro Carvalho Chehab]

The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:

  Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v4.4-3

for you to fetch changes up to aa0850e1d56623845b46350ffd971afa9241886d:

  [media] airspy: increase USB control message buffer size (2015-12-18 15:25:29 
-0200)


media fixes for v4.4-rc6


Antti Palosaari (3):
  [media] hackrf: fix possible null ptr on debug printing
  [media] hackrf: move RF gain ctrl enable behind module parameter
  [media] airspy: increase USB control message buffer size

Mauro Carvalho Chehab (1):
  [media] Revert "[media] ivtv: avoid going past input/audio array"

 drivers/media/pci/ivtv/ivtv-driver.c |  4 ++--
 drivers/media/usb/airspy/airspy.c|  2 +-
 drivers/media/usb/hackrf/hackrf.c| 13 -
 3 files changed, 15 insertions(+), 4 deletions(-)

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

Re: [PATCH] [media] cx23885-dvb: move initialization of a8293_pdata

[David Howells]

Mauro Carvalho Chehab  wrote:

> Smatch complains about where the au8293_data is placed:
> 
> drivers/media/pci/cx23885/cx23885-dvb.c:2174 dvb_register() info: 
> 'a8293_pdata' is not actually initialized (unreached code).
> 
> It is not actually expected to have such initialization at
> 
> switch {
>   foo = bar;
> 
>   case:
> ...
> }
> 
> Not really sure how gcc does that, but this is something that I would
> expect that different compilers would do different things.
> 
> So, move the initialization outside the switch(), making smatch to
> shut up one warning.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Yeah - checked with the compiler people: it's not really expected to
initialise as expected.

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

Re: [PATCH/RFC 26/48] videodev2.h: Add request field to v4l2_pix_format_mplane

[Geert Uytterhoeven]

Hi Laurent,

On Fri, Dec 18, 2015 at 6:16 PM, Laurent Pinchart
 wrote:
>> > @@ -1987,7 +1988,8 @@ struct v4l2_pix_format_mplane {
>> >
>> > __u8ycbcr_enc;
>> > __u8quantization;
>> > __u8xfer_func;
>> >
>> > -   __u8reserved[7];
>> > +   __u8reserved[3];
>> > +   __u32   request;
>>
>> I think I mentioned this before: I feel uncomfortable using 4 bytes of the
>> reserved fields when the request ID is limited to 16 bits anyway.
>
> I'm still unsure whether request IDs should be 16 or 32 bits long. If we go
> for 16 bits then I'll of course make this field a __u16.
>
>> I would prefer a __u16 here. Also put the request field *before* the
>> reserved array, not after.
>
> The reserved array isn't aligned to a 32 bit (or even 16 bit) boundary. I can
> put the request field before it, with a 8 bit hole before the field.

There's no alignment at all due to:

>> >  } __attribute__ ((packed));

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 1/1] tea575x: convert to library

[Andy Shevchenko]

The module is used only as a library for now. Remove module init and exit
routines to show this.

While here, remove FSF snail address and attach EXPORT_SYMBOL() macros to
corresponding functions.

Signed-off-by: Andy Shevchenko 
---
 drivers/media/radio/tea575x.c | 21 ++---
 1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/media/radio/tea575x.c b/drivers/media/radio/tea575x.c
index 43d1ea5..21cd5de 100644
--- a/drivers/media/radio/tea575x.c
+++ b/drivers/media/radio/tea575x.c
@@ -14,10 +14,6 @@
  *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  *   GNU General Public License for more details.
  *
- *   You should have received a copy of the GNU General Public License
- *   along with this program; if not, write to the Free Software
- *   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
- *
  */
 
 #include 
@@ -226,6 +222,7 @@ void snd_tea575x_set_freq(struct snd_tea575x *tea)
snd_tea575x_write(tea, tea->val);
tea->freq = snd_tea575x_val_to_freq(tea, tea->val);
 }
+EXPORT_SYMBOL(snd_tea575x_set_freq);
 
 /*
  * Linux Video interface
@@ -582,25 +579,11 @@ int snd_tea575x_init(struct snd_tea575x *tea, struct 
module *owner)
 
return 0;
 }
+EXPORT_SYMBOL(snd_tea575x_init);
 
 void snd_tea575x_exit(struct snd_tea575x *tea)
 {
video_unregister_device(>vd);
v4l2_ctrl_handler_free(tea->vd.ctrl_handler);
 }
-
-static int __init alsa_tea575x_module_init(void)
-{
-   return 0;
-}
-
-static void __exit alsa_tea575x_module_exit(void)
-{
-}
-
-module_init(alsa_tea575x_module_init)
-module_exit(alsa_tea575x_module_exit)
-
-EXPORT_SYMBOL(snd_tea575x_init);
 EXPORT_SYMBOL(snd_tea575x_exit);
-EXPORT_SYMBOL(snd_tea575x_set_freq);
-- 
2.6.4

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

Re: Automatic device driver back-porting with media_build

[Mason]

On 18/12/2015 18:10, Mason wrote:

> Am I doing something wrong?

Yes, I didn't have I2C enabled.

By running 'make menuconfig' in a recent kernel, I could see which
Kconfig options are required to build the dvbsky driver.

Mauro, I hope you'll find time to address my remaining bug reports.

Issue #1
check_files_for_func("writel_relaxed", "NEED_WRITEL_RELAXED", 
"include/asm-generic/io.h");
is definitely incorrect for older kernels.

Issue #2
WARNING: "nsecs_to_jiffies" [/tmp/sandbox/media_build/v4l/gpio-ir-recv.ko] 
undefined!

Regards.

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

Re: [PATCH/RFC 22/48] media: Add per-file-handle data support

[Sakari Ailus]

Hi Laurent,

Thanks for the set!

On Thu, Dec 17, 2015 at 10:40:00AM +0200, Laurent Pinchart wrote:
> The media devnode core associates devnodes with files by storing the
> devnode pointer in the file structure private_data field. In order to
> allow tracking of per-file-handle data introduce a new media devnode
> file handle structure that stores the devnode pointer, and store a
> pointer to that structure in the file private_data field.
> 
> Users of the media devnode code (the only existing user being
> media_device) are responsible for managing their own subclass of the
> media_devnode_fh structure.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/media/media-device.c  | 22 ++
>  drivers/media/media-devnode.c | 19 +--
>  include/media/media-devnode.h | 18 +-
>  3 files changed, 48 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 7b39440192d6..285f7d79d848 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -24,23 +24,45 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
>  #include 
>  #include 
>  
> +struct media_device_fh {
> + struct media_devnode_fh fh;
> +};
> +
> +static inline struct media_device_fh *media_device_fh(struct file *filp)
> +{
> + return container_of(filp->private_data, struct media_device_fh, fh);
> +}
> +
>  /* 
> -
>   * Userspace API
>   */
>  
>  static int media_device_open(struct file *filp)
>  {
> + struct media_device_fh *fh;
> +
> + fh = kzalloc(sizeof(*media_device_fh), GFP_KERNEL);

sizeof(*fh) ?

With that fixed,

Acked-by: Sakari Ailus 

> + if (!fh)
> + return -ENOMEM;
> +
> + filp->private_data = >fh;
> +
>   return 0;
>  }
>  
>  static int media_device_close(struct file *filp)
>  {
> + struct media_device_fh *fh = media_device_fh(filp);
> +
> + kfree(fh);
> +
>   return 0;
>  }
>  
> diff --git a/drivers/media/media-devnode.c b/drivers/media/media-devnode.c
> index ebf9626e5ae5..67bac29838d3 100644
> --- a/drivers/media/media-devnode.c
> +++ b/drivers/media/media-devnode.c
> @@ -154,6 +154,7 @@ static long media_compat_ioctl(struct file *filp, 
> unsigned int cmd,
>  /* Override for the open function */
>  static int media_open(struct inode *inode, struct file *filp)
>  {
> + struct media_devnode_fh *fh;
>   struct media_devnode *mdev;
>   int ret;
>  
> @@ -175,16 +176,15 @@ static int media_open(struct inode *inode, struct file 
> *filp)
>   get_device(>dev);
>   mutex_unlock(_devnode_lock);
>  
> - filp->private_data = mdev;
> -
> - if (mdev->fops->open) {
> - ret = mdev->fops->open(filp);
> - if (ret) {
> - put_device(>dev);
> - return ret;
> - }
> + ret = mdev->fops->open(filp);
> + if (ret) {
> + put_device(>dev);
> + return ret;
>   }
>  
> + fh = filp->private_data;
> + fh->devnode = mdev;
> +
>   return 0;
>  }
>  
> @@ -193,8 +193,7 @@ static int media_release(struct inode *inode, struct file 
> *filp)
>  {
>   struct media_devnode *mdev = media_devnode_data(filp);
>  
> - if (mdev->fops->release)
> - mdev->fops->release(filp);
> + mdev->fops->release(filp);
>  
>   /* decrease the refcount unconditionally since the release()
>  return value is ignored. */
> diff --git a/include/media/media-devnode.h b/include/media/media-devnode.h
> index 17ddae32060d..ce81047cb4fc 100644
> --- a/include/media/media-devnode.h
> +++ b/include/media/media-devnode.h
> @@ -52,6 +52,20 @@ struct media_file_operations {
>  };
>  
>  /**
> + * struct media_devnode_fh - Media device node file handle
> + * @devnode: pointer to the media device node
> + *
> + * This structure serves as a base for per-file-handle data storage. Media
> + * device node users embed media_devnode_fh in their custom file handle data
> + * structures and store the media_devnode_fh in the file private_data in 
> order
> + * to let the media device node core locate the media_devnode corresponding 
> to a
> + * file handle.
> + */
> +struct media_devnode_fh {
> + struct media_devnode *devnode;
> +};
> +
> +/**
>   * struct media_devnode - Media device node
>   * @fops:pointer to struct media_file_operations with media device ops
>   * @dev: struct device pointer for the media controller device
> @@ -92,7 +106,9 @@ void media_devnode_unregister(struct media_devnode *mdev);
>  
>  static inline struct media_devnode *media_devnode_data(struct file *filp)
>  {
> - return filp->private_data;
> + struct media_devnode_fh *fh = filp->private_data;
> +
> + return fh->devnode;
>  }
>  
>  static inline int 

Re: per-frame camera metadata (again)

[Sakari Ailus]

Hi Guennadi and Hans,

Hans Verkuil wrote:

On 12/16/15 10:37, Guennadi Liakhovetski wrote:

Hi all,

A project, I am currently working on, requires acquiringing per-frame
metadata from the camera and passing it to user-space. This is not the
first time this comes up and I know such discussions have been held
before. A typical user is Android (also my case), where you have to
provide parameter values, that have been used to capture a specific frame,
to the user. I know Hans is working to handle one side of this process -
sending per-request controls,


Actually, the request framework can do both sides of the equation: giving
back meta data in read-only controls that are per-frame. While ideally the
driver would extract the information from the binary blob and put it in
nice controls, it is also possible to make a control that just contains the
binary blob itself. Whether that's a good approach depends on many factors
and that's another topic.


I think that could be possible in some cases. If you don't have a lot of
metadata, then, sure.




but I'm not aware whether he or anyone else
is actively working on this already or is planning to do so in the near
future? I also know, that several proprietary solutions have been
developed and are in use in various projects.

I think a general agreement has been, that such data has to be passed via
a buffer queue. But there are a few possibilities there too. Below are
some:

1. Multiplanar. A separate plane is dedicated to metadata. Pros: (a)
metadata is already associated to specific frames, which they correspond
to. Cons: (a) a correct implementation would specify image plane fourcc
separately from any metadata plane format description, but we currently
don't support per-plane format specification.


This only makes sense if the data actually comes in via DMA and if it is
large enough to make it worth the effort of implementing this. As you say,
it will require figuring out how to do per-frame fourcc.

It also only makes sense if the metadata comes in at the same time as the
frame.


I agree. Much of the time the metadata indeed arrives earlier than the
rest of the frame. The frame layout nor the use cases should be assumed
in the bridge (ISP) driver which implements the interface, essentially
forcing this on the user. This is a major drawback in the approach.

Albeit. If you combine this with the need to pass buffer data to the 
user before the entire buffer is ready, i.e. a plane is ready, you could 
get around this quite neatly.


However, if the DMA engine writing the metadata is different than what's 
writing the image data to memory, then you have a plain metadata buffer 
--- as it's a different video node. But there's really nothing special 
about that then.


Conceptually we should support multi-part frames rather than metadata, 
albeit metadata is just a single use case where a single DMA engine 
outputs multiple kind of data. This could be statistics as well. Or 
multiple images, e.g. YUV and RAW format images of the same frame.


With CSI-2, as the virtual channels are independent, one could start and 
stop them at different times and the frame rate in those channels could 
as well be unrelated. This suggests that different virtual channels 
should be conceptually separate streams also in V4L2 and thus the data 
from different streams should not end up to the same buffer.


Metadata usually (or practically ever?) does not arrive on a separate 
virtual channel though. So this isn't something that necessarily is 
taken into account right now but it's good to be aware of it.





2. Separate buffer queues. Pros: (a) no need to extend multiplanar buffer
implementation. Cons: (a) more difficult synchronisation with image
frames, (b) still need to work out a way to specify the metadata version.


Do you think you have different versions of metadata from a sensor, for
instance? Based on what I've seen these tend to be sensor specific, or
SMIA which defines a metadata type for each bit depth for compliant sensors.

Each metadata format should have a 4cc code, SMIA bit depth specific or
sensor specific where metadata is sensor specific.

Other kind of metadata than what you get from sensors is not covered by 
the thoughts above.




I think I'd still favour separate buffer queues.



Any further options? Of the above my choice would go with (1) but with a
dedicated metadata plane in struct vb2_buffer.


3. Use the request framework and return the metadata as control(s). Since 
controls
can be associated with events when they change you can subscribe to such events.
Note: currently I haven't implemented such events for request controls since I 
am
not certainly how it would be used, but this would be a good test case.

Pros: (a) no need to extend multiplanar buffer implementation, (b) syncing up
with the image frames should be easy (both use the same request ID), (c) a lot
of freedom on how to 

[media:topic/media-controller 2022/2026] drivers/media/usb/uvc/uvc_driver.c:1960:2: note: in expansion of macro 'if'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
topic/media-controller
head:   0a3c36e2b81cf4fe4b6d094b27259716f0ed9a4d
commit: 1590ad7b52714fddc958189103c95541b49b1dae [2022/2026] [media] 
media-device: split media initialization and registration
config: x86_64-randconfig-s1-12190421 (attached as .config)
reproduce:
git checkout 1590ad7b52714fddc958189103c95541b49b1dae
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from arch/x86/include/asm/atomic.h:4:0,
from include/linux/atomic.h:4,
from drivers/media/usb/uvc/uvc_driver.c:14:
   drivers/media/usb/uvc/uvc_driver.c: In function 'uvc_probe':
   drivers/media/usb/uvc/uvc_driver.c:1960:32: error: 'struct uvc_device' has 
no member named 'mdev'
 if (media_device_register(>mdev) < 0)
   ^
   include/linux/compiler.h:147:28: note: in definition of macro '__trace_if'
 if (__builtin_constant_p((cond)) ? !!(cond) :   \
   ^
>> drivers/media/usb/uvc/uvc_driver.c:1960:2: note: in expansion of macro 'if'
 if (media_device_register(>mdev) < 0)
 ^
   drivers/media/usb/uvc/uvc_driver.c:1960:32: error: 'struct uvc_device' has 
no member named 'mdev'
 if (media_device_register(>mdev) < 0)
   ^
   include/linux/compiler.h:147:40: note: in definition of macro '__trace_if'
 if (__builtin_constant_p((cond)) ? !!(cond) :   \
   ^
>> drivers/media/usb/uvc/uvc_driver.c:1960:2: note: in expansion of macro 'if'
 if (media_device_register(>mdev) < 0)
 ^
   drivers/media/usb/uvc/uvc_driver.c:1960:32: error: 'struct uvc_device' has 
no member named 'mdev'
 if (media_device_register(>mdev) < 0)
   ^
   include/linux/compiler.h:158:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^
>> drivers/media/usb/uvc/uvc_driver.c:1960:2: note: in expansion of macro 'if'
 if (media_device_register(>mdev) < 0)
 ^

vim +/if +1960 drivers/media/usb/uvc/uvc_driver.c

  1944  if (v4l2_device_register(>dev, >vdev) < 0)
  1945  goto error;
  1946  
  1947  /* Initialize controls. */
  1948  if (uvc_ctrl_init_device(dev) < 0)
  1949  goto error;
  1950  
  1951  /* Scan the device for video chains. */
  1952  if (uvc_scan_device(dev) < 0)
  1953  goto error;
  1954  
  1955  /* Register video device nodes. */
  1956  if (uvc_register_chains(dev) < 0)
  1957  goto error;
  1958  
  1959  /* Register the media device node */
> 1960  if (media_device_register(>mdev) < 0)
  1961  goto error;
  1962  
  1963  /* Save our data pointer in the interface data. */
  1964  usb_set_intfdata(intf, dev);
  1965  
  1966  /* Initialize the interrupt URB. */
  1967  if ((ret = uvc_status_init(dev)) < 0) {
  1968  uvc_printk(KERN_INFO, "Unable to initialize the status "

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


.config.gz
Description: Binary data

Re: [PATCH/RFC 21/48] media: Move media_device link_notify operation to an ops structure

[Sakari Ailus]

On Thu, Dec 17, 2015 at 10:39:59AM +0200, Laurent Pinchart wrote:
> This will allow adding new operations without increasing the
> media_device structure size for drivers that don't implement any media
> device operation.
> 
> Signed-off-by: Laurent Pinchart 

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Media Controller patches

[Shuah Khan]

On 12/17/2015 04:06 AM, Mauro Carvalho Chehab wrote:
> Em Thu, 17 Dec 2015 00:19:24 -0200
> Mauro Carvalho Chehab  escreveu:
> 
>> Em Wed, 16 Dec 2015 18:12:58 -0700
>> Shuah Khan  escreveu:
>>
>>> On 12/16/2015 10:43 AM, Mauro Carvalho Chehab wrote:
 Em Sun, 13 Dec 2015 09:12:50 -0200
 Mauro Carvalho Chehab  escreveu:

>>>

 As far as I know, all pending items for Kernel 4.5 merge are
 complete. I should be moving the remaining patches from my
 experimental tree:
git://linuxtv.org/mchehab/experimental.git media-controller-rc4

 to the media-controller topic branch by the end of this week, if
 nothing pops up.
>>>
>>> Hi Mauro,
>>>
>>> I don't like the flat graph I am seeing on experimental rc4
>>> with all the pending patches for 4.5. I am attaching two
>>> media graphs generated on au0828 on rc3 and rc4. Something
>>> is off with rc4.  I used the latest mc_nextgen_test tool
>>> to generate the graphs.
>>
>> I guess this problem is due to the patch changed the object ID 
>> to use a single number range:
>>  
>> http://git.linuxtv.org/mchehab/experimental.git/commit/?h=media-controller-rc4=9c04bcb45824fd8e5231f6f26269b57830c1f34d
>>
>> We likely need to change the userspace tool due to that, but I'll
>> take a look on it tomorrow.
> 
> Yes, this was the culprit. I changed the ID to 64 bits, but this
> was actually a bad idea. This got fixed on this patch:
> 
>   https://patchwork.linuxtv.org/patch/32348/
> 
> I replaced the old patch to the new one on my -rc4 branch:
> 
>   git://linuxtv.org/mchehab/experimental.git media-controller-rc4
> 

Graph looks good. Update on ALSA work. I rebased on
media-controller rc3 and test the 24 patch series.
I was hoping to wrap up reabse on media-controller rc4
and send patches out today.

However, I ran into problems on on patch 18 switches
au0828 to using managed media controller media_device.
The change to split media device registration into
init and register phases is posing some problems with
my approach for coordinating media device init and register
by au0828 bridge driver and smd-usb-audio. It can be easily
solved, I do have to rethink the logic and re-do the code
in these two drivers.

I am going to take care of this little (cross my fingers)
before the end of the year and still hope to make 4.5 if
stars and media and alsa maintainers are aligned :)

thanks,
-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usbvision: problems adding support for ATI TV Wonder USB Edition

[Christopher Chavez]

Hi,

Not yet an experienced developer here, still working on BSCmpE.

I have attempted to add long-awaited support for the ATI TV Wonder USB Edition
(NTSC) to usbvision. I have patches of what I've accomplished so far, but I'm
not yet able to test it due to a couple of issues, at least one of which appears
to be an outstanding bug from a few years ago (the "cannot change alternate
number to 1 (error=-22)" issue). The entry in usbvision-cards.c is based on a
similar Pinnacle and Hauppauge entries: the device looks like it might have been
a rebadged Hauppauge WinTV USB, but inside it has both the NT1004 and NT1005
bridges, SAA7113H input processor, and FI1236MK2 tuner (although none of the
supported devices use .tuner_type = TUNER_PHILIPS_NTSC).

I'm still researching what other programs to test this with (VLC? v4l-utils?)...

Christopher Chavez


---
 drivers/media/usb/usbvision/usbvision-cards.c | 15 +++
 drivers/media/usb/usbvision/usbvision-cards.h |  1 +
 drivers/media/usb/usbvision/usbvision-video.c |  3 ++-
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/usbvision/usbvision-cards.c
b/drivers/media/usb/usbvision/usbvision-cards.c
index 3103d0d..7b1edb7 100644
--- a/drivers/media/usb/usbvision/usbvision-cards.c
+++ b/drivers/media/usb/usbvision/usbvision-cards.c
@@ -1054,6 +1054,20 @@ struct usbvision_device_data_st
usbvision_device_data[] = {
 .y_offset   = 18,
 .model_string   = "Nogatech USB MicroCam PAL (NV3001P)",
 },
+[ATI_TV_WONDER_USB_NTSC] = {
+.interface  = 0,
+.codec  = CODEC_SAA7113,
+.video_channels = 3,
+.video_norm = V4L2_STD_NTSC,
+.audio_channels = 1,
+.radio  = 0,
+.vbi= 1,
+.tuner  = 1,
+.tuner_type = TUNER_PHILIPS_NTSC,
+.x_offset   = -1,
+.y_offset   = -1,
+.model_string   = "ATI TV Wonder USB Edition (NTSC)",
+},
 };
 const int usbvision_device_data_size = ARRAY_SIZE(usbvision_device_data);

@@ -1064,6 +1078,7 @@ struct usb_device_id usbvision_table[] = {
 { USB_DEVICE(0x050d, 0x0106), .driver_info = BELKIN_VIDEOBUS_II },
 { USB_DEVICE(0x050d, 0x0207), .driver_info = BELKIN_VIDEOBUS },
 { USB_DEVICE(0x050d, 0x0208), .driver_info = BELKIN_USB_VIDEOBUS_II },
+{ USB_DEVICE(0x0528, 0x7561), .driver_info = ATI_TV_WONDER_USB_NTSC },
 { USB_DEVICE(0x0571, 0x0002), .driver_info = ECHOFX_INTERVIEW_LITE },
 { USB_DEVICE(0x0573, 0x0003), .driver_info = USBGEAR_USBG_V1 },
 { USB_DEVICE(0x0573, 0x0400), .driver_info = D_LINK_V100 },
diff --git a/drivers/media/usb/usbvision/usbvision-cards.h
b/drivers/media/usb/usbvision/usbvision-cards.h
index a51cc11..ed1197c 100644
--- a/drivers/media/usb/usbvision/usbvision-cards.h
+++ b/drivers/media/usb/usbvision/usbvision-cards.h
@@ -65,5 +65,6 @@
 #define PINNA_PCTV_USB_NTSC_FM_V364
 #define MICROCAM_NTSC65
 #define MICROCAM_PAL 66
+#define ATI_TV_WONDER_USB_NTSC   67

 extern const int usbvision_device_data_size;
diff --git a/drivers/media/usb/usbvision/usbvision-video.c
b/drivers/media/usb/usbvision/usbvision-video.c
index de9ff3b..c76e1397 100644
--- a/drivers/media/usb/usbvision/usbvision-video.c
+++ b/drivers/media/usb/usbvision/usbvision-video.c
@@ -1511,7 +1511,8 @@ static int usbvision_probe(struct usb_interface *intf,

 if (dev->descriptor.bNumConfigurations > 1)
 usbvision->bridge_type = BRIDGE_NT1004;
-else if (model == DAZZLE_DVC_90_REV_1_SECAM)
+else if ((model == DAZZLE_DVC_90_REV_1_SECAM) ||
+ (model == ATI_TV_WONDER_USB_NTSC))
 usbvision->bridge_type = BRIDGE_NT1005;
 else
 usbvision->bridge_type = BRIDGE_NT1003;
-- 


example of dmesg after `modprobe usbvision`, plugging in device,
and a couple of guvcview segfaults on Ubuntu 15.04 amd64:

[  101.761249] media: module verification failed: signature and/or
required key missing - tainting kernel
[  101.761870] media: Linux media interface: v0.10
[  101.781325] Linux video capture interface: v2.00
[  101.781332] WARNING: You are using an experimental version of the
media stack.
As the driver is backported to an older kernel, it doesn't offer
enough quality for its usage in production.
Use it with care.
Latest git patches (needed if you report a bug to linux-media@vger.kernel.org):
52d60eb7e6d6429a766ea1b8f67e01c3b2dcd3c5 Revert [media] UVC: Add
support for ds4 depth camera
991ce92f8de24cde063d531246602b6e14d3fef2 [media] use
https://linuxtv.org for LinuxTV URLs
4a3d0cb06b3e4248ba4a659d7f2a7a8fa1a877fc drm, ipu-v3: use
https://linuxtv.org for LinuxTV URL
[  101.836434] usbcore: registered new interface driver usbvision
[  101.836439] USBVision USB Video Device Driver for Linux : 0.9.11
[  128.024178] usb 5-2: new full-speed USB device number 2 using uhci_hcd
[  128.256154] usb 

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:   Sat Dec 19 04:00:21 CET 2015
git branch: test
git hash:   0aff8a894a2be4c22e6414db33061153a4b35bc9
gcc version:i686-linux-gcc (GCC) 5.1.0
sparse version: v0.5.0-51-ga53cea2
smatch version: v0.5.0-3202-g618e15b
host hardware:  x86_64
host os:4.2.0-164

linux-git-arm-at91: ERRORS
linux-git-arm-davinci: OK
linux-git-arm-exynos: ERRORS
linux-git-arm-mx: ERRORS
linux-git-arm-omap: ERRORS
linux-git-arm-omap1: ERRORS
linux-git-arm-pxa: ERRORS
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.34.7-i686: ERRORS
linux-2.6.35.9-i686: ERRORS
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: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.23-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0-i686: ERRORS
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-rc1-i686: OK
linux-2.6.34.7-x86_64: ERRORS
linux-2.6.35.9-x86_64: ERRORS
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: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.23-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0-x86_64: ERRORS
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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