[PATCH v7 8/8] arm64: dts: mediatek: Add Video Encoder for MT8173

[Tiffany Lin]

Add video encoder node for MT8173

Signed-off-by: Tiffany Lin 

---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   39 ++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index ae147bb..348ce0e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -717,6 +717,45 @@
clock-names = "apb", "smi";
};
 
+   vcodec_enc: vcodec@18002000 {
+   compatible = "mediatek,mt8173-vcodec-enc";
+   reg = <0 0x18002000 0 0x1000>,  /* VENC_SYS */
+ <0 0x19002000 0 0x1000>;  /* VENC_LT_SYS */
+   interrupts = ,
+;
+   mediatek,larb = <>,
+   <>;
+   iommus = < M4U_PORT_VENC_RCPU>,
+< M4U_PORT_VENC_REC>,
+< M4U_PORT_VENC_BSDMA>,
+< M4U_PORT_VENC_SV_COMV>,
+< M4U_PORT_VENC_RD_COMV>,
+< M4U_PORT_VENC_CUR_LUMA>,
+< M4U_PORT_VENC_CUR_CHROMA>,
+< M4U_PORT_VENC_REF_LUMA>,
+< M4U_PORT_VENC_REF_CHROMA>,
+< M4U_PORT_VENC_NBM_RDMA>,
+< M4U_PORT_VENC_NBM_WDMA>,
+< M4U_PORT_VENC_RCPU_SET2>,
+< M4U_PORT_VENC_REC_FRM_SET2>,
+< M4U_PORT_VENC_BSDMA_SET2>,
+< M4U_PORT_VENC_SV_COMA_SET2>,
+< M4U_PORT_VENC_RD_COMA_SET2>,
+< M4U_PORT_VENC_CUR_LUMA_SET2>,
+< M4U_PORT_VENC_CUR_CHROMA_SET2>,
+< M4U_PORT_VENC_REF_LUMA_SET2>,
+< M4U_PORT_VENC_REC_CHROMA_SET2>;
+   mediatek,vpu = <>;
+   clocks = < CLK_TOP_VENCPLL_D2>,
+< CLK_TOP_VENC_SEL>,
+< CLK_TOP_UNIVPLL1_D2>,
+< CLK_TOP_VENC_LT_SEL>;
+   clock-names = "venc_sel_src",
+ "venc_sel",
+ "venc_lt_sel_src",
+ "venc_lt_sel";
+   };
+
vencltsys: clock-controller@1900 {
compatible = "mediatek,mt8173-vencltsys", "syscon";
reg = <0 0x1900 0 0x1000>;
-- 
1.7.9.5

--
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 v7 1/8] dt-bindings: Add a binding for Mediatek Video Processor

[Tiffany Lin]

From: Andrew-CT Chen 

Add a DT binding documentation of Video Processor Unit for the
MT8173 SoC from Mediatek.

Signed-off-by: Andrew-CT Chen 
Signed-off-by: Tiffany Lin 
Acked-by: Rob Herring 

---
 .../devicetree/bindings/media/mediatek-vpu.txt |   31 
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek-vpu.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-vpu.txt 
b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
new file mode 100644
index 000..2a5bac3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
@@ -0,0 +1,31 @@
+* Mediatek Video Processor Unit
+
+Video Processor Unit is a HW video controller. It controls HW Codec including
+H.264/VP8/VP9 Decode, H.264/VP8 Encode and Image Processor (scale/rotate/color 
convert).
+
+Required properties:
+  - compatible: "mediatek,mt8173-vpu"
+  - reg: Must contain an entry for each entry in reg-names.
+  - reg-names: Must include the following entries:
+"tcm": tcm base
+"cfg_reg": Main configuration registers base
+  - interrupts: interrupt number to the cpu.
+  - clocks : clock name from clock manager
+  - clock-names: must be main. It is the main clock of VPU
+
+Optional properties:
+  - memory-region: phandle to a node describing memory (see
+Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
+to be used for VPU extended memory; if not present, VPU may be located
+anywhere in the memory
+
+Example:
+   vpu: vpu@1002 {
+   compatible = "mediatek,mt8173-vpu";
+   reg = <0 0x1002 0 0x3>,
+ <0 0x1005 0 0x100>;
+   reg-names = "tcm", "cfg_reg";
+   interrupts = ;
+   clocks = < TOP_SCP_SEL>;
+   clock-names = "main";
+   };
-- 
1.7.9.5

--
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 v7 0/8] Add MT8173 Video Encoder Driver and VPU Driver

[Tiffany Lin]

==
 Introduction
==

The purpose of this series is to add the driver for video codec hw embedded in 
the Mediatek's MT8173 SoCs.
Mediatek Video Codec is able to handle video encoding of in a range of formats.

This patch series also include VPU driver. Mediatek Video Codec driver rely on 
VPU driver to load,
communicate with VPU.

Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI both 
have been merged in v4.6-rc1.

==
 Device interface
==

In principle the driver bases on v4l2 memory-to-memory framework:
it provides a single video node and each opened file handle gets its own 
private context with separate
buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source 
buffers, i.e. raw video
frames) and CAPTURE (for destination buffers, i.e. encoded video frames).

==
 VPU (Video Processor Unit)
==
The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
It is able to handle video decoding/encoding in a range of formats.
The driver provides with VPU firmware download, memory management and the 
communication interface between CPU and VPU.
For VPU initialization, it will create virtual memory for CPU access and 
physical address for VPU hw device access. 
When a decode/encode instance opens a device node, vpu driver will download vpu 
firmware to the device.
A decode/encode instant will decode/encode a frame using VPU interface to 
interrupt vpu to handle decoding/encoding jobs.

Please have a look at the code and comments will be very much appreciated.

Change in v7:
1. Rebase against the master branch of git://linuxtv.org/media_tree.git
2. Add ycbcr_enc, quantization and xfer_func in try_fmt, g_fmt, s_fmt
3. Merge h264_enc and vp8_enc to one venc directory

Change in v6:
1. Add synchronization access protect between irq handler and work thread
2. Add DMA_ATTR_ALLOC_SINGLE_PAGES support
3. S_FMT will return coded_width, coded_height, so user space could allocate 
correct size memory that HW required
4. merge h264/vp8 enc ap and md32 ipi msg
5. separate h264/vp8 enc gop_size and intra_period handle
6. remove sizeimage relative code in work buffer function
7. Refine makefile to build as an module
8. Code clean up

VPU Part
1. export symbols for building VPU as an module
2. change function from "wait_event_interruptible_timeout" to 
"wait_event_timeout" since
   CPU needs to wait for ACK from VPU even if it was interrupted by a signal

v4l2-compliance test output:
localhost Encode # ./v4l2-compliance -d /dev/video1
Driver Info:
Driver name   : mtk-vcodec-enc
Card type : platform:mt8173
Bus info  : platform:mt8173
Driver version: 4.4.0
Capabilities  : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format

Compliance test for device /dev/video1 (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_QUERYCTRL/MENU: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 12 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)
   

[PATCH v7 4/8] dt-bindings: Add a binding for Mediatek Video Encoder

[Tiffany Lin]

Add a DT binding documentation of Video Encoder for the
MT8173 SoC from Mediatek.

Signed-off-by: Tiffany Lin 
Acked-by: Rob Herring 

---
 .../devicetree/bindings/media/mediatek-vcodec.txt  |   59 
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt 
b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
new file mode 100644
index 000..59a47a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -0,0 +1,59 @@
+Mediatek Video Codec
+
+Mediatek Video Codec is the video codec hw present in Mediatek SoCs which
+supports high resolution encoding functionalities.
+
+Required properties:
+- compatible : "mediatek,mt8173-vcodec-enc" for encoder
+- reg : Physical base address of the video codec registers and length of
+  memory mapped region.
+- interrupts : interrupt number to the cpu.
+- mediatek,larb : must contain the local arbiters in the current Socs.
+- clocks : list of clock specifiers, corresponding to entries in
+  the clock-names property.
+- clock-names: encoder must contain "venc_sel_src", "venc_sel",
+- "venc_lt_sel_src", "venc_lt_sel".
+- iommus : should point to the respective IOMMU block with master port as
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  for details.
+- mediatek,vpu : the node of video processor unit
+
+Example:
+vcodec_enc: vcodec@0x18002000 {
+compatible = "mediatek,mt8173-vcodec-enc";
+reg = <0 0x18002000 0 0x1000>,/*VENC_SYS*/
+  <0 0x19002000 0 0x1000>;/*VENC_LT_SYS*/
+interrupts = ,
+;
+mediatek,larb = <>,
+   <>;
+iommus = < M4U_PORT_VENC_RCPU>,
+ < M4U_PORT_VENC_REC>,
+ < M4U_PORT_VENC_BSDMA>,
+ < M4U_PORT_VENC_SV_COMV>,
+ < M4U_PORT_VENC_RD_COMV>,
+ < M4U_PORT_VENC_CUR_LUMA>,
+ < M4U_PORT_VENC_CUR_CHROMA>,
+ < M4U_PORT_VENC_REF_LUMA>,
+ < M4U_PORT_VENC_REF_CHROMA>,
+ < M4U_PORT_VENC_NBM_RDMA>,
+ < M4U_PORT_VENC_NBM_WDMA>,
+ < M4U_PORT_VENC_RCPU_SET2>,
+ < M4U_PORT_VENC_REC_FRM_SET2>,
+ < M4U_PORT_VENC_BSDMA_SET2>,
+ < M4U_PORT_VENC_SV_COMA_SET2>,
+ < M4U_PORT_VENC_RD_COMA_SET2>,
+ < M4U_PORT_VENC_CUR_LUMA_SET2>,
+ < M4U_PORT_VENC_CUR_CHROMA_SET2>,
+ < M4U_PORT_VENC_REF_LUMA_SET2>,
+ < M4U_PORT_VENC_REC_CHROMA_SET2>;
+mediatek,vpu = <>;
+clocks = < CLK_TOP_VENCPLL_D2>,
+ < CLK_TOP_VENC_SEL>,
+ < CLK_TOP_UNIVPLL1_D2>,
+ < CLK_TOP_VENC_LT_SEL>;
+clock-names = "venc_sel_src",
+  "venc_sel",
+  "venc_lt_sel_src",
+  "venc_lt_sel";
+  };
-- 
1.7.9.5

--
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 v7 3/8] arm64: dts: mediatek: Add node for Mediatek Video Processor Unit

[Tiffany Lin]

From: Andrew-CT Chen 

Add VPU drivers for MT8173

Signed-off-by: Andrew-CT Chen 
Signed-off-by: Tiffany Lin 

---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index eab7efc..ae147bb 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -125,6 +125,18 @@
clock-output-names = "cpum_ck";
};
 
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   vpu_dma_reserved: vpu_dma_mem_region {
+   compatible = "shared-dma-pool";
+   reg = <0 0xb700 0 0x50>;
+   alignment = <0x1000>;
+   no-map;
+   };
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupt-parent = <>;
@@ -269,6 +281,17 @@
clock-names = "spi", "wrap";
};
 
+   vpu: vpu@1002 {
+   compatible = "mediatek,mt8173-vpu";
+   reg = <0 0x1002 0 0x3>,
+ <0 0x1005 0 0x100>;
+   reg-names = "tcm", "cfg_reg";
+   interrupts = ;
+   clocks = < CLK_TOP_SCP_SEL>;
+   clock-names = "main";
+   memory-region = <_dma_reserved>;
+   };
+
sysirq: intpol-controller@10200620 {
compatible = "mediatek,mt8173-sysirq",
 "mediatek,mt6577-sysirq";
-- 
1.7.9.5

--
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 v7 2/8] [media] VPU: mediatek: support Mediatek VPU

[Tiffany Lin]

From: Andrew-CT Chen 

The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
It is able to handle video decoding/encoding of in a range of formats.
The driver provides with VPU firmware download, memory management and
the communication interface between CPU and VPU.
For VPU initialization, it will create virtual memory for CPU access and
IOMMU address for vcodec hw device access. When a decode/encode instance
opens a device node, vpu driver will download vpu firmware to the device.
A decode/encode instant will decode/encode a frame using VPU
interface to interrupt vpu to handle decoding/encoding jobs.

Signed-off-by: Andrew-CT Chen 
Signed-off-by: Tiffany Lin 

---
 drivers/media/platform/Kconfig   |   13 +
 drivers/media/platform/Makefile  |2 +
 drivers/media/platform/mtk-vpu/Makefile  |3 +
 drivers/media/platform/mtk-vpu/mtk_vpu.c |  950 ++
 drivers/media/platform/mtk-vpu/mtk_vpu.h |  162 +
 5 files changed, 1130 insertions(+)
 create mode 100644 drivers/media/platform/mtk-vpu/Makefile
 create mode 100755 drivers/media/platform/mtk-vpu/mtk_vpu.c
 create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 84e041c..74c3575 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -152,6 +152,19 @@ config VIDEO_CODA
   Coda is a range of video codec IPs that supports
   H.264, MPEG-4, and other video formats.
 
+config VIDEO_MEDIATEK_VPU
+   tristate "Mediatek Video Processor Unit"
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   ---help---
+   This driver provides downloading VPU firmware and
+   communicating with VPU. This driver for hw video
+   codec embedded in Mediatek's MT8173 SOCs. It is able
+   to handle video decoding/encoding in a range of formats.
+
+   To compile this driver as a module, choose M here: the
+   module will be called mtk-vpu.
+
 config VIDEO_MEM2MEM_DEINTERLACE
tristate "Deinterlace support"
depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index bbb7bd1..2efb7b1 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -56,3 +56,5 @@ obj-$(CONFIG_VIDEO_AM437X_VPFE)   += am437x/
 obj-$(CONFIG_VIDEO_XILINX) += xilinx/
 
 ccflags-y += -I$(srctree)/drivers/media/i2c
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VPU)   += mtk-vpu/
diff --git a/drivers/media/platform/mtk-vpu/Makefile 
b/drivers/media/platform/mtk-vpu/Makefile
new file mode 100644
index 000..58cc1b4
--- /dev/null
+++ b/drivers/media/platform/mtk-vpu/Makefile
@@ -0,0 +1,3 @@
+mtk-vpu-y += mtk_vpu.o
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu.o
diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c 
b/drivers/media/platform/mtk-vpu/mtk_vpu.c
new file mode 100755
index 000..55c081e
--- /dev/null
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
@@ -0,0 +1,950 @@
+/*
+* Copyright (c) 2016 MediaTek Inc.
+* Author: Andrew-CT Chen 
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 as
+* published by the Free Software Foundation.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+* GNU General Public License for more details.
+*/
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mtk_vpu.h"
+
+/**
+ * VPU (video processor unit) is a tiny processor controlling video hardware
+ * related to video codec, scaling and color format converting.
+ * VPU interfaces with other blocks by share memory and interrupt.
+ **/
+
+#define INIT_TIMEOUT_MS2000U
+#define IPI_TIMEOUT_MS 2000U
+#define VPU_FW_VER_LEN 16
+
+/* maximum program/data TCM (Tightly-Coupled Memory) size */
+#define VPU_PTCM_SIZE  (96 * SZ_1K)
+#define VPU_DTCM_SIZE  (32 * SZ_1K)
+/* the offset to get data tcm address */
+#define VPU_DTCM_OFFSET0x18000UL
+/* daynamic allocated maximum extended memory size */
+#define VPU_EXT_P_SIZE SZ_1M
+#define VPU_EXT_D_SIZE SZ_4M
+/* maximum binary firmware size */
+#define VPU_P_FW_SIZE  (VPU_PTCM_SIZE + VPU_EXT_P_SIZE)
+#define VPU_D_FW_SIZE  (VPU_DTCM_SIZE + VPU_EXT_D_SIZE)
+/* the size of share buffer between Host and  VPU */
+#define SHARE_BUF_SIZE 48
+
+/* binary firmware name */
+#define VPU_P_FW   "vpu_p.bin"
+#define 

[PATCH v7 7/8] [media] vcodec: mediatek: Add Mediatek H264 Video Encoder Driver

[Tiffany Lin]

Add h264 encoder driver for MT8173

Signed-off-by: PoChun Lin 
Signed-off-by: Tiffany Lin 

---
 drivers/media/platform/mtk-vcodec/Makefile |1 +
 .../media/platform/mtk-vcodec/venc/venc_h264_if.c  |  687 
 drivers/media/platform/mtk-vcodec/venc_drv_if.c|4 +-
 3 files changed, 691 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c

diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
index bf73a45..dc5cb00 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -12,6 +12,7 @@ mtk-vcodec-enc-y := venc/venc_vp8_if.o \
venc_drv_if.o \
venc_vpu_if.o \
 
+
 mtk-vcodec-common-y := mtk_vcodec_intr.o \
mtk_vcodec_util.o\
 
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c 
b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
new file mode 100644
index 000..6e90b3f
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
@@ -0,0 +1,687 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Jungchang Tsao 
+ * Daniel Hsiao 
+ * PoChun Lin 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+#include "../mtk_vcodec_drv.h"
+#include "../mtk_vcodec_util.h"
+#include "../mtk_vcodec_intr.h"
+#include "../mtk_vcodec_enc.h"
+#include "../mtk_vcodec_enc_pm.h"
+#include "../venc_drv_base.h"
+#include "../venc_ipi_msg.h"
+#include "../venc_vpu_if.h"
+#include "mtk_vpu.h"
+
+static const char h264_filler_marker[] = {0x0, 0x0, 0x0, 0x1, 0xc};
+
+#define H264_FILLER_MARKER_SIZE ARRAY_SIZE(h264_filler_marker)
+#define VENC_PIC_BITSTREAM_BYTE_CNT 0x0098
+
+/**
+ * enum venc_h264_vpu_work_buf - h264 encoder buffer index
+ */
+enum venc_h264_vpu_work_buf {
+   VENC_H264_VPU_WORK_BUF_RC_INFO,
+   VENC_H264_VPU_WORK_BUF_RC_CODE,
+   VENC_H264_VPU_WORK_BUF_REC_LUMA,
+   VENC_H264_VPU_WORK_BUF_REC_CHROMA,
+   VENC_H264_VPU_WORK_BUF_REF_LUMA,
+   VENC_H264_VPU_WORK_BUF_REF_CHROMA,
+   VENC_H264_VPU_WORK_BUF_MV_INFO_1,
+   VENC_H264_VPU_WORK_BUF_MV_INFO_2,
+   VENC_H264_VPU_WORK_BUF_SKIP_FRAME,
+   VENC_H264_VPU_WORK_BUF_MAX,
+};
+
+/**
+ * enum venc_h264_bs_mode - for bs_mode argument in h264_enc_vpu_encode
+ */
+enum venc_h264_bs_mode {
+   H264_BS_MODE_SPS,
+   H264_BS_MODE_PPS,
+   H264_BS_MODE_FRAME,
+};
+
+/*
+ * struct venc_h264_vpu_config - Structure for h264 encoder configuration
+ * @input_fourcc: input fourcc
+ * @bitrate: target bitrate (in bps)
+ * @pic_w: picture width. Picture size is visible stream resolution, in pixels,
+ * to be used for display purposes; must be smaller or equal to buffer
+ * size.
+ * @pic_h: picture height
+ * @buf_w: buffer width. Buffer size is stream resolution in pixels aligned to
+ * hardware requirements.
+ * @buf_h: buffer height
+ * @gop_size: group of picture size (idr frame)
+ * @intra_period: intra frame period
+ * @framerate: frame rate in fps
+ * @profile: as specified in standard
+ * @level: as specified in standard
+ * @wfd: WFD mode 1:on, 0:off
+ */
+struct venc_h264_vpu_config {
+   u32 input_fourcc;
+   u32 bitrate;
+   u32 pic_w;
+   u32 pic_h;
+   u32 buf_w;
+   u32 buf_h;
+   u32 gop_size;
+   u32 intra_period;
+   u32 framerate;
+   u32 profile;
+   u32 level;
+   u32 wfd;
+};
+
+/*
+ * struct venc_h264_vpu_buf - Structure for buffer information
+ * @align: buffer alignment (in bytes)
+ * @iova: IO virtual address
+ * @vpua: VPU side memory addr which is used by RC_CODE
+ * @size: buffer size (in bytes)
+ */
+struct venc_h264_vpu_buf {
+   u32 align;
+   u32 iova;
+   u32 vpua;
+   u32 size;
+};
+
+/*
+ * struct venc_h264_vsi - Structure for VPU driver control and info share
+ * This structure is allocated in VPU side and shared to AP side.
+ * @config: h264 encoder configuration
+ * @work_bufs: working buffer information in VPU side
+ * The work_bufs here is for storing the 'size' info shared to AP side.
+ * The similar item in struct venc_h264_inst is for memory allocation
+ * in AP side. The AP driver will copy the 'size' from here to the one in
+ * struct mtk_vcodec_mem, then invoke mtk_vcodec_mem_alloc to allocate
+ * the buffer. After that, bypass the 'dma_addr' to the 'iova' 

[PATCH v7 5/8] [media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver

[Tiffany Lin]

Add v4l2 layer encoder driver for MT8173

Signed-off-by: Tiffany Lin 

---
 drivers/media/platform/Kconfig |   16 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/mtk-vcodec/Makefile |   14 +
 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |  339 +
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1301 
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h |   59 +
 .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c |  467 +++
 .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c  |  137 +++
 .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.h  |   26 +
 .../media/platform/mtk-vcodec/mtk_vcodec_intr.c|   56 +
 .../media/platform/mtk-vcodec/mtk_vcodec_intr.h|   27 +
 .../media/platform/mtk-vcodec/mtk_vcodec_util.c|   96 ++
 .../media/platform/mtk-vcodec/mtk_vcodec_util.h|   87 ++
 drivers/media/platform/mtk-vcodec/venc_drv_base.h  |   62 +
 drivers/media/platform/mtk-vcodec/venc_drv_if.c|  107 ++
 drivers/media/platform/mtk-vcodec/venc_drv_if.h|  165 +++
 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h   |  210 
 17 files changed, 3171 insertions(+)
 create mode 100644 drivers/media/platform/mtk-vcodec/Makefile
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_base.h
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.h
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 74c3575..13b765a 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -165,6 +165,22 @@ config VIDEO_MEDIATEK_VPU
To compile this driver as a module, choose M here: the
module will be called mtk-vpu.
 
+config VIDEO_MEDIATEK_VCODEC
+   tristate "Mediatek Video Codec driver"
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+   select VIDEO_MEDIATEK_VPU
+   default n
+   ---help---
+   Mediatek video codec driver provides HW capability to
+   encode and decode in a range of video formats
+   This driver rely on VPU driver to communicate with VPU.
+
+   To compile this driver as a module, choose M here: the
+   module will be called mtk-vcodec
+
 config VIDEO_MEM2MEM_DEINTERLACE
tristate "Deinterlace support"
depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 2efb7b1..6e735fe 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -58,3 +58,5 @@ obj-$(CONFIG_VIDEO_XILINX)+= xilinx/
 ccflags-y += -I$(srctree)/drivers/media/i2c
 
 obj-$(CONFIG_VIDEO_MEDIATEK_VPU)   += mtk-vpu/
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/
diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
new file mode 100644
index 000..d04433be
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -0,0 +1,14 @@
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-enc.o mtk-vcodec-common.o
+
+
+
+mtk-vcodec-enc-y := mtk_vcodec_enc.o \
+   mtk_vcodec_enc_drv.o \
+   mtk_vcodec_enc_pm.o \
+   venc_drv_if.o \
+
+mtk-vcodec-common-y := mtk_vcodec_intr.o \
+   mtk_vcodec_util.o\
+
+ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
new file mode 100644
index 000..bf41ff3
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -0,0 +1,339 @@
+/*
+* Copyright (c) 2016 MediaTek Inc.
+* Author: PC Chen 
+* Tiffany Lin 
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 as
+* published by the Free Software Foundation.
+*
+* This program is distributed in the hope that 

[PATCH v7 6/8] [media] vcodec: mediatek: Add Mediatek VP8 Video Encoder Driver

[Tiffany Lin]

Add vp8 encoder driver for MT8173

Signed-off-by: PoChun Lin 
Signed-off-by: Tiffany Lin 

---
 drivers/media/platform/mtk-vcodec/Makefile |6 +-
 .../media/platform/mtk-vcodec/venc/venc_vp8_if.c   |  488 
 drivers/media/platform/mtk-vcodec/venc_drv_if.c|7 +-
 drivers/media/platform/mtk-vcodec/venc_vpu_if.c|  240 ++
 drivers/media/platform/mtk-vcodec/venc_vpu_if.h|   61 +++
 5 files changed, 800 insertions(+), 2 deletions(-)
 create mode 100644 drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_vpu_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_vpu_if.h

diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
index d04433be..bf73a45 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -1,12 +1,16 @@
 
+
 obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-enc.o mtk-vcodec-common.o
 
 
 
-mtk-vcodec-enc-y := mtk_vcodec_enc.o \
+mtk-vcodec-enc-y := venc/venc_vp8_if.o \
+   venc/venc_h264_if.o \
+   mtk_vcodec_enc.o \
mtk_vcodec_enc_drv.o \
mtk_vcodec_enc_pm.o \
venc_drv_if.o \
+   venc_vpu_if.o \
 
 mtk-vcodec-common-y := mtk_vcodec_intr.o \
mtk_vcodec_util.o\
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c 
b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
new file mode 100644
index 000..5389841
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
@@ -0,0 +1,488 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Daniel Hsiao 
+ * PoChun Lin 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+#include "../mtk_vcodec_drv.h"
+#include "../mtk_vcodec_util.h"
+#include "../mtk_vcodec_intr.h"
+#include "../mtk_vcodec_enc.h"
+#include "../mtk_vcodec_enc_pm.h"
+#include "../venc_drv_base.h"
+#include "../venc_ipi_msg.h"
+#include "../venc_vpu_if.h"
+#include "mtk_vpu.h"
+
+#define VENC_BITSTREAM_FRAME_SIZE 0x0098
+#define VENC_BITSTREAM_HEADER_LEN 0x00e8
+
+/* This ac_tag is vp8 frame tag. */
+#define MAX_AC_TAG_SIZE 10
+
+/**
+ * enum venc_vp8_vpu_work_buf - vp8 encoder buffer index
+ */
+enum venc_vp8_vpu_work_buf {
+   VENC_VP8_VPU_WORK_BUF_LUMA,
+   VENC_VP8_VPU_WORK_BUF_LUMA2,
+   VENC_VP8_VPU_WORK_BUF_LUMA3,
+   VENC_VP8_VPU_WORK_BUF_CHROMA,
+   VENC_VP8_VPU_WORK_BUF_CHROMA2,
+   VENC_VP8_VPU_WORK_BUF_CHROMA3,
+   VENC_VP8_VPU_WORK_BUF_MV_INFO,
+   VENC_VP8_VPU_WORK_BUF_BS_HEADER,
+   VENC_VP8_VPU_WORK_BUF_PROB_BUF,
+   VENC_VP8_VPU_WORK_BUF_RC_INFO,
+   VENC_VP8_VPU_WORK_BUF_RC_CODE,
+   VENC_VP8_VPU_WORK_BUF_RC_CODE2,
+   VENC_VP8_VPU_WORK_BUF_RC_CODE3,
+   VENC_VP8_VPU_WORK_BUF_MAX,
+};
+
+/*
+ * struct venc_vp8_vpu_config - Structure for vp8 encoder configuration
+ * @input_fourcc: input fourcc
+ * @bitrate: target bitrate (in bps)
+ * @pic_w: picture width. Picture size is visible stream resolution, in pixels,
+ * to be used for display purposes; must be smaller or equal to buffer
+ * size.
+ * @pic_h: picture height
+ * @buf_w: buffer width (with 16 alignment). Buffer size is stream resolution
+ * in pixels aligned to hardware requirements.
+ * @buf_h: buffer height (with 16 alignment)
+ * @gop_size: group of picture size (key frame)
+ * @framerate: frame rate in fps
+ * @ts_mode: temporal scalability mode (0: disable, 1: enable)
+ *  support three temporal layers - 0: 7.5fps 1: 7.5fps 2: 15fps.
+ */
+struct venc_vp8_vpu_config {
+   u32 input_fourcc;
+   u32 bitrate;
+   u32 pic_w;
+   u32 pic_h;
+   u32 buf_w;
+   u32 buf_h;
+   u32 gop_size;
+   u32 framerate;
+   u32 ts_mode;
+};
+
+/*
+ * struct venc_vp8_vpu_buf -Structure for buffer information
+ * @align: buffer alignment (in bytes)
+ * @iova: IO virtual address
+ * @vpua: VPU side memory addr which is used by RC_CODE
+ * @size: buffer size (in bytes)
+ */
+struct venc_vp8_vpu_buf {
+   u32 align;
+   u32 iova;
+   u32 vpua;
+   u32 size;
+};
+
+/*
+ * struct venc_vp8_vsi - Structure for VPU driver control and info share
+ * This structure is allocated in VPU side and shared to AP side.
+ * @config: vp8 encoder configuration
+ * @work_bufs: working buffer information in VPU side
+ * The 

cron job: media_tree daily build: WARNINGS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Fri Apr 22 04:00:19 CEST 2016
git branch: test
git hash:   e07d46e7e0da86c146f199dae76f879096bc436a
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3413-g618cd5c
host hardware:  x86_64
host os:4.4.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-i686: WARNINGS
linux-4.6-rc1-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-x86_64: WARNINGS
linux-4.6-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH/RFC 1/2] v4l: Add meta-data video device type

[Sakari Ailus]

Heippa!

On Thu, Apr 21, 2016 at 10:24:48PM +0300, Laurent Pinchart wrote:
> Hi Sakari,
> 
> Thank you for the review.
> 
> On Thursday 21 Apr 2016 11:44:26 Sakari Ailus wrote:
> > On Thu, Apr 21, 2016 at 03:40:26AM +0300, Laurent Pinchart wrote:
> > > The meta-data video device is used to transfer meta-data between
> > > userspace and kernelspace through a V4L2 buffers queue. It comes with a
> > > new meta-data capture capability, buffer type and format description.
> > > 
> > > Signed-off-by: Laurent Pinchart
> > > 
> > > ---
> > > 
> > >  Documentation/DocBook/media/v4l/dev-meta.xml  | 100 +
> > >  Documentation/DocBook/media/v4l/v4l2.xml  |   1 +
> > >  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  19 +
> > >  drivers/media/v4l2-core/v4l2-dev.c|  21 +-
> > >  drivers/media/v4l2-core/v4l2-ioctl.c  |  39 ++
> > >  drivers/media/v4l2-core/videobuf2-v4l2.c  |   3 +
> > >  include/media/v4l2-dev.h  |   3 +-
> > >  include/media/v4l2-ioctl.h|   8 +++
> > >  include/uapi/linux/media.h|   2 +
> > >  include/uapi/linux/videodev2.h|  14 
> > >  10 files changed, 208 insertions(+), 2 deletions(-)
> > >  create mode 100644 Documentation/DocBook/media/v4l/dev-meta.xml
> > > 
> > > diff --git a/Documentation/DocBook/media/v4l/dev-meta.xml
> > > b/Documentation/DocBook/media/v4l/dev-meta.xml new file mode 100644
> > > index ..ddc685186015
> > > --- /dev/null
> > > +++ b/Documentation/DocBook/media/v4l/dev-meta.xml
> > > @@ -0,0 +1,100 @@
> > > +  Meta-Data Interface
> > 
> > I propose:
> > 
> > s/-/ /
> 
> How about metadata ? That's the spelling used by wikipedia

Fine for me.

> 
> > > +
> > > +  
> > > +Experimental
> > > +This is an  experimental 
> > > +interface and may change in the future.
> > > +  
> > > +
> > > +  
> > > +Meta-data refers to any non-image data that supplements video frames with
> > > +additional information. This may include statistics computed over the
> > > image +or frame capture parameters supplied by the image source. This
> > > interface is +intended for transfer of meta-data to userspace and control
> > > of that operation.
> >
> > Ditto.
> > 
> > > +  
> > > +
> > > +  
> > > +Meta-data devices are accessed through character device special files
> > > named +/dev/v4l-meta0 to
> > > /dev/v4l-meta255 +with major number 81 and
> > > dynamically allocated minor numbers 0 to 255.
> >
> > Where does 255 come from? At least in kernel the minor number space has got
> > 20 bits, not 8. Not that I prefer having that many meta data nodes, but
> > still that's a possibility.
> 
> We have
> 
> #define VIDEO_NUM_DEVICES   256
> 
> in drivers/media/v4l2-core/v4l2-dev.c. If you want to take care of the code 
> I'll update the documentation :-)

I think we could just omit telling how many there are. That's not really a
part of the API.

> 
> > > +  
> > > +
> > > +  
> > > +Querying Capabilities
> > > +
> > > +
> > > +Devices supporting the meta-data interface set the
> > > +V4L2_CAP_META_CAPTURE flag in the
> > > +capabilities field of 
> > > +returned by the  ioctl. That flag means the device can
> > > capture +meta-data to memory.
> > > +
> > > +
> > > +At least one of the read/write, streaming or asynchronous I/O methods
> > > must
> > > +be supported.
> > > +
> > > +  
> > > +
> > > +  
> > > +Data Format Negotiation
> > > +
> > > +
> > > +The meta-data device uses the format ioctls
> > > to +select the capture format. The meta-data buffer content format is
> > > bound to that +selectable format. In addition to the basic
> > > +format ioctls, the  ioctl
> > > +must be supported as well.
> > > +
> > > +
> > > +
> > > +To use the format ioctls applications set
> > > the +type field of a  to
> > > +V4L2_BUF_TYPE_META_CAPTURE and use the
> > >  +meta member of the
> > > fmt +union as needed per the desired
> > > operation.
> > > +Currently there are two fields, pixelformat
> > > and
> > > +buffersize, of struct  that
> > > are +used. Content of the pixelformat is the
> > > V4L2 FourCC +code of the data format. The
> > > buffersize field is the +maximum buffer size
> > > in bytes required for data transfer, set by the driver in +order to
> > > inform applications.
> > > +
> > > +
> > > +
> > > +  struct v4l2_meta_format
> > > +  
> > > +
> > > +
> > > +  
> > > +__u32
> > > +pixelformat
> > > +
> > > +The data format or type of compression, set by the application. This is a
> > > +little endian four character code.
> > > +V4L2 defines meta-data formats in .
> > > +   
> > > +  
> > > +  
> > > +__u32
> > > +buffersize
> > > +
> > > +Maximum size in bytes required for data. Value is set by the driver.
> > > + 

[PATCH/RFC] dvb-core: drop stubs for llseek()

[Dominic Chen]

Since the default behavior in vfs_llseek() is now no_llseek(), and
filp->f_pos / ppos are not actually used anywhere in dvb, drop the
inconsistent llseek() stubs.

Signed-off-by: Dominic Chen 
---
 drivers/media/dvb-core/dmxdev.c | 2 --
 drivers/media/dvb-core/dvb_ca_en50221.c | 1 -
 drivers/media/dvb-core/dvb_frontend.c   | 1 -
 drivers/media/dvb-core/dvb_net.c| 1 -
 drivers/media/dvb-core/dvbdev.c | 1 -
 5 files changed, 6 deletions(-)

diff --git a/drivers/media/dvb-core/dmxdev.c
b/drivers/media/dvb-core/dmxdev.c
index a168cbe..25494bf 100644
--- a/drivers/media/dvb-core/dmxdev.c
+++ b/drivers/media/dvb-core/dmxdev.c
@@ -1135,7 +1135,6 @@ static const struct file_operations dvb_demux_fops = {
 .open = dvb_demux_open,
 .release = dvb_demux_release,
 .poll = dvb_demux_poll,
-.llseek = default_llseek,
 };
 
 static const struct dvb_device dvbdev_demux = {
@@ -1211,7 +1210,6 @@ static const struct file_operations dvb_dvr_fops = {
 .open = dvb_dvr_open,
 .release = dvb_dvr_release,
 .poll = dvb_dvr_poll,
-.llseek = default_llseek,
 };
 
 static const struct dvb_device dvbdev_dvr = {
diff --git a/drivers/media/dvb-core/dvb_ca_en50221.c
b/drivers/media/dvb-core/dvb_ca_en50221.c
index f82cd1f..e736fb9 100644
--- a/drivers/media/dvb-core/dvb_ca_en50221.c
+++ b/drivers/media/dvb-core/dvb_ca_en50221.c
@@ -1636,7 +1636,6 @@ static const struct file_operations dvb_ca_fops = {
 .open = dvb_ca_en50221_io_open,
 .release = dvb_ca_en50221_io_release,
 .poll = dvb_ca_en50221_io_poll,
-.llseek = noop_llseek,
 };
 
 static const struct dvb_device dvbdev_ca = {
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index c014261..e29543c 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2600,7 +2600,6 @@ static const struct file_operations
dvb_frontend_fops = {
 .poll= dvb_frontend_poll,
 .open= dvb_frontend_open,
 .release= dvb_frontend_release,
-.llseek= noop_llseek,
 };
 
 int dvb_frontend_suspend(struct dvb_frontend *fe)
diff --git a/drivers/media/dvb-core/dvb_net.c
b/drivers/media/dvb-core/dvb_net.c
index ce6a711..d4af8d0 100644
--- a/drivers/media/dvb-core/dvb_net.c
+++ b/drivers/media/dvb-core/dvb_net.c
@@ -1457,7 +1457,6 @@ static const struct file_operations dvb_net_fops = {
 .unlocked_ioctl = dvb_net_ioctl,
 .open =dvb_generic_open,
 .release = dvb_net_close,
-.llseek = noop_llseek,
 };
 
 static const struct dvb_device dvbdev_net = {
diff --git a/drivers/media/dvb-core/dvbdev.c
b/drivers/media/dvb-core/dvbdev.c
index e1684c5..bc8086d 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -101,7 +101,6 @@ static const struct file_operations dvb_device_fops =
 {
 .owner =THIS_MODULE,
 .open =dvb_device_open,
-.llseek =noop_llseek,
 };
 
 static struct cdev dvb_device_cdev;
-- 
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: [PATCH 1/2] drm: rcar-du: Add Z-order support for VSP planes

[Laurent Pinchart]

Hi Daniel,

On Thursday 21 Apr 2016 18:10:25 Daniel Vetter wrote:
> On Thu, Apr 21, 2016 at 04:14:12AM +0300, Laurent Pinchart wrote:
> > Make the Z-order of VSP planes configurable through the zpos property,
> > exactly as for the native DU planes.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 16 
> >  drivers/gpu/drm/rcar-du/rcar_du_vsp.h |  2 ++
> >  2 files changed, 14 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index de7ef041182b..62e9619eaea4
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > @@ -180,8 +180,9 @@ static void rcar_du_vsp_plane_setup(struct
> > rcar_du_vsp_plane *plane)> 
> > WARN_ON(!pixelformat);
> > 
> > -   vsp1_du_atomic_update(plane->vsp->vsp, plane->index, pixelformat,
> > - fb->pitches[0], paddr, , );
> > +   vsp1_du_atomic_update_zpos(plane->vsp->vsp, plane->index, pixelformat,
> > +  fb->pitches[0], paddr, , ,
> > +  state->zpos);
> > 
> >  }
> >  
> >  static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
> > 
> > @@ -220,8 +221,8 @@ static void rcar_du_vsp_plane_atomic_update(struct
> > drm_plane *plane,> 
> > if (plane->state->crtc)
> > 
> > rcar_du_vsp_plane_setup(rplane);
> > 
> > else
> > 
> > -   vsp1_du_atomic_update(rplane->vsp->vsp, rplane->index, 0, 0, 0,
> > - NULL, NULL);
> > +   vsp1_du_atomic_update_zpos(rplane->vsp->vsp, rplane->index,
> > +  0, 0, 0, NULL, NULL, 0);
> > 
> >  }
> >  
> >  static const struct drm_plane_helper_funcs rcar_du_vsp_plane_helper_funcs
> >  = {> 
> > @@ -269,6 +270,7 @@ static void rcar_du_vsp_plane_reset(struct drm_plane
> > *plane)> 
> > return;
> > 
> > state->alpha = 255;
> > 
> > +   state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
> > 
> > plane->state = >state;
> > plane->state->plane = plane;
> > 
> > @@ -283,6 +285,8 @@ static int
> > rcar_du_vsp_plane_atomic_set_property(struct drm_plane *plane,> 
> > if (property == rcdu->props.alpha)
> > 
> > rstate->alpha = val;
> > 
> > +   else if (property == rcdu->props.zpos)
> > +   rstate->zpos = val;
> > 
> > else
> > 
> > return -EINVAL;
> > 
> > @@ -299,6 +303,8 @@ static int
> > rcar_du_vsp_plane_atomic_get_property(struct drm_plane *plane,> 
> > if (property == rcdu->props.alpha)
> > 
> > *val = rstate->alpha;
> > 
> > +   else if (property == rcdu->props.zpos)
> > +   *val = rstate->zpos;
> > 
> > else
> > 
> > return -EINVAL;
> > 
> > @@ -378,6 +384,8 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp)
> > 
> > drm_object_attach_property(>plane.base,
> > 
> >rcdu->props.alpha, 255);
> > 
> > +   drm_object_attach_property(>plane.base,
> > +  rcdu->props.zpos, 1);
> > 
> > }
> > 
> > return 0;
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> > b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h index df3bf3805c69..510dcc9c6816
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> > @@ -44,6 +44,7 @@ static inline struct rcar_du_vsp_plane
> > *to_rcar_vsp_plane(struct drm_plane *p)> 
> >   * @state: base DRM plane state
> >   * @format: information about the pixel format used by the plane
> >   * @alpha: value of the plane alpha property
> > 
> > + * @zpos: value of the plane zpos property
> > 
> >   */
> >  
> >  struct rcar_du_vsp_plane_state {
> >  
> > struct drm_plane_state state;
> > 
> > @@ -51,6 +52,7 @@ struct rcar_du_vsp_plane_state {
> > 
> > const struct rcar_du_format_info *format;
> > 
> > unsigned int alpha;
> > 
> > +   unsigned int zpos;
> 
> There's lots of effort by various people to create a generic zpos/blending
> set of properties. Care to jump onto that effort and making it finally
> happen for real? I kinda don't want to have a propliferation of slightly
> diffferent zpos/blending props across all the drivers ...

OK, I'll try to. Would you mind if we got these patches merged first for v4.7, 
and then switched to a generic property for v4.8 ? The reason is that this 
series depends on a large patch series queued in the linux-media tree for 
v4.7, and it would be easier to handle the dependency by merging these two 
patches in linux-media. A rework of the zpos and alpha properties would need 
to be merged through the drm tree.

> >  };
> >  
> >  static inline struct rcar_du_vsp_plane_state *

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the 

Re: [PATCH 0/2] Renesas R-Car Gen3 DU alpha and z-order support

[Dave Airlie]

On 21 April 2016 at 11:14, Laurent Pinchart
 wrote:
> Hello,
>
> This patch series implement support for alpha and z-order configuration in the
> R-Car DU driver for the Gen3 SoCs family.
>
> The Gen3 SoCs delegate composition to an external IP core called VSP,
> supported by a V4L2 driver. The DU driver interfaces with the VSP driver using
> direct function calls. Alpha and z-order configuration is implemented in the
> VSP driver, the DU driver thus just needs to pass the values using the VSP
> API.
>
> This series depends on a large VSP series that has been merged in the Linux
> media git tree for v4.7. Dave, instead of merging the media tree in your tree
> to pull the dependency in, it would be easier to get those two patches
> upstream through the media tree. I don't expect any conflict related to the
> DU driver for v4.7. If you're fine with that, could you ack the patches ?
>
> Laurent Pinchart (2):
>   drm: rcar-du: Add Z-order support for VSP planes
>   drm: rcar-du: Add alpha support for VSP planes
>

Seems fine,

Acked-by: Dave AIrlie 

for inclusion via media.

Dave.

>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 16 
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.h |  2 ++
>  2 files changed, 14 insertions(+), 4 deletions(-)
>
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 1/2] v4l: Add meta-data video device type

[Laurent Pinchart]

Hi Sakari,

Thank you for the review.

On Thursday 21 Apr 2016 11:44:26 Sakari Ailus wrote:
> On Thu, Apr 21, 2016 at 03:40:26AM +0300, Laurent Pinchart wrote:
> > The meta-data video device is used to transfer meta-data between
> > userspace and kernelspace through a V4L2 buffers queue. It comes with a
> > new meta-data capture capability, buffer type and format description.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  Documentation/DocBook/media/v4l/dev-meta.xml  | 100 +
> >  Documentation/DocBook/media/v4l/v4l2.xml  |   1 +
> >  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  19 +
> >  drivers/media/v4l2-core/v4l2-dev.c|  21 +-
> >  drivers/media/v4l2-core/v4l2-ioctl.c  |  39 ++
> >  drivers/media/v4l2-core/videobuf2-v4l2.c  |   3 +
> >  include/media/v4l2-dev.h  |   3 +-
> >  include/media/v4l2-ioctl.h|   8 +++
> >  include/uapi/linux/media.h|   2 +
> >  include/uapi/linux/videodev2.h|  14 
> >  10 files changed, 208 insertions(+), 2 deletions(-)
> >  create mode 100644 Documentation/DocBook/media/v4l/dev-meta.xml
> > 
> > diff --git a/Documentation/DocBook/media/v4l/dev-meta.xml
> > b/Documentation/DocBook/media/v4l/dev-meta.xml new file mode 100644
> > index ..ddc685186015
> > --- /dev/null
> > +++ b/Documentation/DocBook/media/v4l/dev-meta.xml
> > @@ -0,0 +1,100 @@
> > +  Meta-Data Interface
> 
> I propose:
> 
> s/-/ /

How about metadata ? That's the spelling used by wikipedia

> > +
> > +  
> > +Experimental
> > +This is an  experimental 
> > +interface and may change in the future.
> > +  
> > +
> > +  
> > +Meta-data refers to any non-image data that supplements video frames with
> > +additional information. This may include statistics computed over the
> > image +or frame capture parameters supplied by the image source. This
> > interface is +intended for transfer of meta-data to userspace and control
> > of that operation.
>
> Ditto.
> 
> > +  
> > +
> > +  
> > +Meta-data devices are accessed through character device special files
> > named +/dev/v4l-meta0 to
> > /dev/v4l-meta255 +with major number 81 and
> > dynamically allocated minor numbers 0 to 255.
>
> Where does 255 come from? At least in kernel the minor number space has got
> 20 bits, not 8. Not that I prefer having that many meta data nodes, but
> still that's a possibility.

We have

#define VIDEO_NUM_DEVICES   256

in drivers/media/v4l2-core/v4l2-dev.c. If you want to take care of the code 
I'll update the documentation :-)

> > +  
> > +
> > +  
> > +Querying Capabilities
> > +
> > +
> > +Devices supporting the meta-data interface set the
> > +V4L2_CAP_META_CAPTURE flag in the
> > +capabilities field of 
> > +returned by the  ioctl. That flag means the device can
> > capture +meta-data to memory.
> > +
> > +
> > +At least one of the read/write, streaming or asynchronous I/O methods
> > must
> > +be supported.
> > +
> > +  
> > +
> > +  
> > +Data Format Negotiation
> > +
> > +
> > +The meta-data device uses the format ioctls
> > to +select the capture format. The meta-data buffer content format is
> > bound to that +selectable format. In addition to the basic
> > +format ioctls, the  ioctl
> > +must be supported as well.
> > +
> > +
> > +
> > +To use the format ioctls applications set
> > the +type field of a  to
> > +V4L2_BUF_TYPE_META_CAPTURE and use the
> >  +meta member of the
> > fmt +union as needed per the desired
> > operation.
> > +Currently there are two fields, pixelformat
> > and
> > +buffersize, of struct  that
> > are +used. Content of the pixelformat is the
> > V4L2 FourCC +code of the data format. The
> > buffersize field is the +maximum buffer size
> > in bytes required for data transfer, set by the driver in +order to
> > inform applications.
> > +
> > +
> > +
> > +  struct v4l2_meta_format
> > +  
> > +
> > +
> > +  
> > +__u32
> > +pixelformat
> > +
> > +The data format or type of compression, set by the application. This is a
> > +little endian four character code.
> > +V4L2 defines meta-data formats in .
> > +   
> > +  
> > +  
> > +__u32
> > +buffersize
> > +
> > +Maximum size in bytes required for data. Value is set by the driver.
> > +   
> > +  
> > +  
> > +__u8
> > +reserved[24]
> > +This array is reserved for future extensions.
> > +Drivers and applications must set it to zero.
> 
> 200 bytes is reserved for this struct in all IOCTLs. How about using closer
> to that amount? 24 bytes of reserved space isn't much. Albeit you could
> argue that this struct could be changed later on as it does not affect IOCTL
> argument size.

Should we just 

Re: [PATCH/RFC 1/2] v4l: Add meta-data video device type

[Laurent Pinchart]

Hi Hans,

Thank you for the review.

On Thursday 21 Apr 2016 08:39:59 Hans Verkuil wrote:
> Hi Laurent,
> 
> Thanks for the patch!
> 
> Some, mostly small, comments follow:
> 
> On 04/21/2016 02:40 AM, Laurent Pinchart wrote:
> > The meta-data video device is used to transfer meta-data between
> > userspace and kernelspace through a V4L2 buffers queue. It comes with a
> > new meta-data capture capability, buffer type and format description.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  Documentation/DocBook/media/v4l/dev-meta.xml  | 100 +
> >  Documentation/DocBook/media/v4l/v4l2.xml  |   1 +
> >  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  19 +
> >  drivers/media/v4l2-core/v4l2-dev.c|  21 +-
> >  drivers/media/v4l2-core/v4l2-ioctl.c  |  39 ++
> >  drivers/media/v4l2-core/videobuf2-v4l2.c  |   3 +
> >  include/media/v4l2-dev.h  |   3 +-
> >  include/media/v4l2-ioctl.h|   8 +++
> >  include/uapi/linux/media.h|   2 +
> >  include/uapi/linux/videodev2.h|  14 
> >  10 files changed, 208 insertions(+), 2 deletions(-)
> >  create mode 100644 Documentation/DocBook/media/v4l/dev-meta.xml
> > 
> > diff --git a/Documentation/DocBook/media/v4l/dev-meta.xml
> > b/Documentation/DocBook/media/v4l/dev-meta.xml new file mode 100644
> > index ..ddc685186015
> > --- /dev/null
> > +++ b/Documentation/DocBook/media/v4l/dev-meta.xml
> > @@ -0,0 +1,100 @@
> > +  Meta-Data Interface
> > +
> > +  
> > +Experimental
> > +This is an  experimental 
> > +interface and may change in the future.
> > +  
> > +
> > +  
> > +Meta-data refers to any non-image data that supplements video frames with
> > +additional information. This may include statistics computed over the
> > image +or frame capture parameters supplied by the image source. This
> > interface is +intended for transfer of meta-data to userspace and control
> > of that operation. +  
> > +
> > +  
> > +Meta-data devices are accessed through character device special files
> > named +/dev/v4l-meta0 to
> > /dev/v4l-meta255 +with major number 81 and
> > dynamically allocated minor numbers 0 to 255. +  
> > +
> > +  
> > +Querying Capabilities
> > +
> > +
> > +Devices supporting the meta-data interface set the
> > +V4L2_CAP_META_CAPTURE flag in the
> > +capabilities field of 
> > +returned by the  ioctl. That flag means the device can
> > capture +meta-data to memory.
> > +
> > +
> > +At least one of the read/write, streaming or asynchronous I/O methods
> > must
> 
> I think we can drop 'asynchronous I/O' since that's never been used. I
> assume this is copy-and-pasted and we should probably just remove any
> reference to async IO.

Agreed. I'll fix it.

> > +be supported.
> > +
> > +  
> > +
> > +  
> > +Data Format Negotiation
> > +
> > +
> > +The meta-data device uses the format ioctls
> > to +select the capture format. The meta-data buffer content format is
> > bound to that +selectable format. In addition to the basic
> > +format ioctls, the  ioctl
> > +must be supported as well.
> > +
> > +
> > +
> > +To use the format ioctls applications set
> > the +type field of a  to
> > +V4L2_BUF_TYPE_META_CAPTURE and use the
> >  +meta member of the
> > fmt +union as needed per the desired
> > operation.
> > +Currently there are two fields, pixelformat
> > and
> 
> Shouldn't that be metaformat? Since there are no pixels here? It was a bit
> dubious to call it pixelformat for SDR as well, but at least there you
> still have discrete samples which might be called pixels with some
> imagination. But certainly doesn't apply to meta data.

How about dataformat ? Or just format ?

> > +buffersize, of struct  that
> > are +used. Content of the pixelformat is the
> > V4L2 FourCC +code of the data format. The
> > buffersize field is the +maximum buffer size
> > in bytes required for data transfer, set by the driver in +order to
> > inform applications.
> > +
> > +
> > +
> > +  struct v4l2_meta_format
> > +  
> > +
> > +
> > +  
> > +__u32
> > +pixelformat
> > +
> > +The data format or type of compression, set by the application. This is a
> > +little endian four character code.
> > +V4L2 defines meta-data formats in .
> > +   
> > +  
> > +  
> > +__u32
> > +buffersize
> > +
> > +Maximum size in bytes required for data. Value is set by the driver.
> > +   
> > +  
> > +  
> > +__u8
> > +reserved[24]
> > +This array is reserved for future extensions.
> > +Drivers and applications must set it to zero.
> > +  
> > +
> > +  
> > +
> > +
> > +
> > +A meta-data device may support read/write
> > +and/or streaming 

Re: [PATCH 2/2] tw686x-video: test for 60Hz instead of 50Hz

[Ezequiel Garcia]

On 21 Apr 08:50 AM, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> When determining if the standard is 50 or 60 Hz it is standard
> practice to test for 60 Hz instead of 50 Hz.
> 
> This doesn't matter normally, except if the user specifies both
> 60 and 50 Hz standards.
> 
> Signed-off-by: Hans Verkuil 

Acked-by: Ezequiel Garcia 

Thanks for the fixes!

> ---
>  drivers/media/pci/tw686x/tw686x-video.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/pci/tw686x/tw686x-video.c 
> b/drivers/media/pci/tw686x/tw686x-video.c
> index 9a31de9..9cfee0a 100644
> --- a/drivers/media/pci/tw686x/tw686x-video.c
> +++ b/drivers/media/pci/tw686x/tw686x-video.c
> @@ -25,7 +25,7 @@
>  
>  #define TW686X_INPUTS_PER_CH 4
>  #define TW686X_VIDEO_WIDTH   720
> -#define TW686X_VIDEO_HEIGHT(id)  ((id & V4L2_STD_625_50) ? 576 : 
> 480)
> +#define TW686X_VIDEO_HEIGHT(id)  ((id & V4L2_STD_525_60) ? 480 : 
> 576)
>  
>  static const struct tw686x_format formats[] = {
>   {
> @@ -518,10 +518,10 @@ static int tw686x_s_std(struct file *file, void *priv, 
> v4l2_std_id id)
>   reg_write(vc->dev, SDT[vc->ch], val);
>  
>   val = reg_read(vc->dev, VIDEO_CONTROL1);
> - if (id & V4L2_STD_625_50)
> - val |= (1 << (SYS_MODE_DMA_SHIFT + vc->ch));
> - else
> + if (id & V4L2_STD_525_60)
>   val &= ~(1 << (SYS_MODE_DMA_SHIFT + vc->ch));
> + else
> + val |= (1 << (SYS_MODE_DMA_SHIFT + vc->ch));
>   reg_write(vc->dev, VIDEO_CONTROL1, val);
>  
>   /*
> -- 
> 2.8.0.rc3
> 

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

Re: [PATCH 1/2] tw686x: fix sparse warning

[Ezequiel Garcia]

On 21 Apr 08:50 AM, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> tw686x-video.c: In function 'tw686x_video_init':
> tw686x-video.c:65:543: warning: array subscript is above array bounds 
> [-Warray-bounds]
> 
> Signed-off-by: Hans Verkuil 

Acked-by: Ezequiel Garcia 

Thanks,

> ---
>  drivers/media/pci/tw686x/tw686x-video.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/pci/tw686x/tw686x-video.c 
> b/drivers/media/pci/tw686x/tw686x-video.c
> index 118e9fa..9a31de9 100644
> --- a/drivers/media/pci/tw686x/tw686x-video.c
> +++ b/drivers/media/pci/tw686x/tw686x-video.c
> @@ -60,10 +60,11 @@ static unsigned int tw686x_fields_map(v4l2_std_id std, 
> unsigned int fps)
>   0, 1, 1, 1, 2,  2,  3,  3,  4,  4,  5,  5,  6,  6, 7, 7,
>  8, 8, 9, 9, 10, 10, 11, 11, 12, 12, 13, 13, 14, 0, 0
>   };
> + unsigned int max_fps = (std & V4L2_STD_525_60) ? 30 : 25;
> + unsigned int i;
>  
> - unsigned int i =
> - (std & V4L2_STD_625_50) ? std_625_50[fps] : std_525_60[fps];
> -
> + fps = fps > max_fps ? max_fps : fps;
> + i = (std & V4L2_STD_525_60) ? std_625_50[fps] : std_525_60[fps];
>   return map[i];
>  }
>  
> -- 
> 2.8.0.rc3
> 

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

Re: [PATCH] [media] af9035: fix for MXL5007T devices with I2C read issues

[Alex Rad]

On Thu, Apr 21, 2016 at 2:12 AM, Antti Palosaari  wrote:
> On 04/20/2016 12:13 PM, Alex Rad wrote:
>>
>> On Wed, Apr 20, 2016 at 1:02 AM, Antti Palosaari  wrote:
>>>
>>> Hello
>>> I am not happy with that new module parameter as I cannot see real need
>>> for
>>> it. So get rid of it.
>>
>>
>> My reasoning for this is:
>> 1) We know of just two devices which may have the issue, but there are
>> probably more.  The module parameter allows a user to apply the
>> workaround to other devices we did not consider or test.  Should we
>> perhaps apply for all mxl5007t devices?
>
>
> So what. It is easier for me add just new IDs to driver when problematic
> device is found than adding new module parameter which allows user to
> work-around issues and I will likely newer even hear about those issues.
>

I guess I like to be more user friendly, but your call... I'll remove it.

>> 2) Not all devices that match VID and PID have the issue, so it allows
>> the user to disable the workaround.
>
>
> Due to that better to add three checks
> 1) it is Avermedia VID
> 2) it is known problematic Avermedia device PID
> 3) it has tuner MxL5007t
>
> It is not surprise it is just only Avermedia which has this kind of
> problems. Not first time at all. I have added such Avermedia hacks for
> af9015 driver too and if you look af9035 there is tuner id hack - which was
> added also due to Avermedia.
>
> Worst case there could be is some mxl5007t device having reference design
> ID. But even on that case returning fake values is pretty much OK.
>

Well, considering the combined write/read bug in the driver, we can
say the same for all devices.  I'll add the checks and propose v2.

Regards,
Alessandro

>
> regards
> Antti
>
>
>
>>> Better to compare both VID and PID when enabling that work-around. Driver
>>> supports currently quite many different USB IDs and there is still small
>>> risk duplicate PID will exists at some point enabling work-around for
>>> wrong
>>> device.
>>>
>>
>> OK.  Will wait for comments on above before a v2.
>>
>> Thanks,
>> Alessandro
>>
>>> regards
>>> Antti
>>>
>>>
>>>
>>>
>>> On 04/15/2016 06:37 PM, Alessandro Radicati wrote:


 The MXL5007T tuner will lock-up on some devices after an I2C read
 transaction.  This patch adds a kernel module parameter "no_read" to
 work
 around this issue by inhibiting such operations and emulating a 0x00
 response.  The workaround is applied automatically to USB product IDs
 known
 to exhibit this flaw, unless the kernel module parameter is specified.

 Signed-off-by: Alessandro Radicati 
 ---
drivers/media/usb/dvb-usb-v2/af9035.c | 27
 +++
drivers/media/usb/dvb-usb-v2/af9035.h |  1 +
2 files changed, 28 insertions(+)

 diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c
 b/drivers/media/usb/dvb-usb-v2/af9035.c
 index 2638e32..8225403 100644
 --- a/drivers/media/usb/dvb-usb-v2/af9035.c
 +++ b/drivers/media/usb/dvb-usb-v2/af9035.c
 @@ -24,6 +24,10 @@
/* Max transfer size done by I2C transfer functions */
#define MAX_XFER_SIZE  64

 +static int dvb_usb_af9035_no_read = -1;
 +module_param_named(no_read, dvb_usb_af9035_no_read, int, 0644);
 +MODULE_PARM_DESC(no_read, "Emulate I2C reads for devices that do not
 support them.");
 +
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);

static u16 af9035_checksum(const u8 *buf, size_t len)
 @@ -348,6 +352,9 @@ static int af9035_i2c_master_xfer(struct i2c_adapter
 *adap,

  ret = af9035_rd_regs(d, reg, [1].buf[0],
  msg[1].len);
 +   } else if (state->no_read) {
 +   memset(msg[1].buf, 0, msg[1].len);
 +   ret = 0;
  } else {
  /* I2C write + read */
  u8 buf[MAX_XFER_SIZE];
 @@ -421,6 +428,9 @@ static int af9035_i2c_master_xfer(struct i2c_adapter
 *adap,
  if (msg[0].len > 40) {
  /* TODO: correct limits > 40 */
  ret = -EOPNOTSUPP;
 +   } else if (state->no_read) {
 +   memset(msg[0].buf, 0, msg[0].len);
 +   ret = 0;
  } else {
  /* I2C read */
  u8 buf[5];
 @@ -962,6 +972,23 @@ skip_eeprom:
  state->af9033_config[i].clock =
 clock_lut_af9035[tmp];
  }

 +   /* Some MXL5007T devices cannot properly handle tuner I2C read
 ops. */
 +   if (dvb_usb_af9035_no_read != -1) { /* Override with module
 param
 */
 +   state->no_read = dvb_usb_af9035_no_read == 0 ? false :
 

Re: [PATCH 1/2] drm: rcar-du: Add Z-order support for VSP planes

[Daniel Vetter]

On Thu, Apr 21, 2016 at 04:14:12AM +0300, Laurent Pinchart wrote:
> Make the Z-order of VSP planes configurable through the zpos property,
> exactly as for the native DU planes.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 16 
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.h |  2 ++
>  2 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index de7ef041182b..62e9619eaea4 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -180,8 +180,9 @@ static void rcar_du_vsp_plane_setup(struct 
> rcar_du_vsp_plane *plane)
>  
>   WARN_ON(!pixelformat);
>  
> - vsp1_du_atomic_update(plane->vsp->vsp, plane->index, pixelformat,
> -   fb->pitches[0], paddr, , );
> + vsp1_du_atomic_update_zpos(plane->vsp->vsp, plane->index, pixelformat,
> +fb->pitches[0], paddr, , ,
> +state->zpos);
>  }
>  
>  static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
> @@ -220,8 +221,8 @@ static void rcar_du_vsp_plane_atomic_update(struct 
> drm_plane *plane,
>   if (plane->state->crtc)
>   rcar_du_vsp_plane_setup(rplane);
>   else
> - vsp1_du_atomic_update(rplane->vsp->vsp, rplane->index, 0, 0, 0,
> -   NULL, NULL);
> + vsp1_du_atomic_update_zpos(rplane->vsp->vsp, rplane->index,
> +0, 0, 0, NULL, NULL, 0);
>  }
>  
>  static const struct drm_plane_helper_funcs rcar_du_vsp_plane_helper_funcs = {
> @@ -269,6 +270,7 @@ static void rcar_du_vsp_plane_reset(struct drm_plane 
> *plane)
>   return;
>  
>   state->alpha = 255;
> + state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
>  
>   plane->state = >state;
>   plane->state->plane = plane;
> @@ -283,6 +285,8 @@ static int rcar_du_vsp_plane_atomic_set_property(struct 
> drm_plane *plane,
>  
>   if (property == rcdu->props.alpha)
>   rstate->alpha = val;
> + else if (property == rcdu->props.zpos)
> + rstate->zpos = val;
>   else
>   return -EINVAL;
>  
> @@ -299,6 +303,8 @@ static int rcar_du_vsp_plane_atomic_get_property(struct 
> drm_plane *plane,
>  
>   if (property == rcdu->props.alpha)
>   *val = rstate->alpha;
> + else if (property == rcdu->props.zpos)
> + *val = rstate->zpos;
>   else
>   return -EINVAL;
>  
> @@ -378,6 +384,8 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp)
>  
>   drm_object_attach_property(>plane.base,
>  rcdu->props.alpha, 255);
> + drm_object_attach_property(>plane.base,
> +rcdu->props.zpos, 1);
>   }
>  
>   return 0;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h 
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> index df3bf3805c69..510dcc9c6816 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> @@ -44,6 +44,7 @@ static inline struct rcar_du_vsp_plane 
> *to_rcar_vsp_plane(struct drm_plane *p)
>   * @state: base DRM plane state
>   * @format: information about the pixel format used by the plane
>   * @alpha: value of the plane alpha property
> + * @zpos: value of the plane zpos property
>   */
>  struct rcar_du_vsp_plane_state {
>   struct drm_plane_state state;
> @@ -51,6 +52,7 @@ struct rcar_du_vsp_plane_state {
>   const struct rcar_du_format_info *format;
>  
>   unsigned int alpha;
> + unsigned int zpos;

There's lots of effort by various people to create a generic zpos/blending
set of properties. Care to jump onto that effort and making it finally
happen for real? I kinda don't want to have a propliferation of slightly
diffferent zpos/blending props across all the drivers ...
-Daniel

>  };
>  
>  static inline struct rcar_du_vsp_plane_state *
> -- 
> 2.7.3
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
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: [RFT PATCH v2] [media] exynos4-is: Fix fimc_is_parse_sensor_config() nodes handling

[Javier Martinez Canillas]

Hello Sylwester,

On 03/23/2016 08:41 PM, Javier Martinez Canillas wrote:
> The same struct device_node * is used for looking up the I2C sensor, OF
> graph endpoint and port. So the reference count is incremented but not
> decremented for the endpoint and port nodes.
> 
> Fix this by having separate pointers for each node looked up.
> 
> Signed-off-by: Javier Martinez Canillas 
>

Any comments about this patch?

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv5] [media] rcar-vin: add Renesas R-Car VIN driver

[Niklas Söderlund]

A V4L2 driver for Renesas R-Car VIN driver that do not depend on
soc_camera. The driver is heavily based on its predecessor and aims to
replace it.

Signed-off-by: Niklas Söderlund 
---

The patched is based on and depends on patches from the media_tree
(git://linuxtv.org/media_tree.git) master branch.

The driver is tested on Koelsch and can do streaming using qv4l2 and
grab frames using yavta. It passes a v4l2-compliance (git master) run
without any failures, see bellow for output. Some issues I know about
but will have to wait for future work in other patches.
 - One can not bind/unbind the subdevice and continue using the driver.
 - Do not support FIELD_ALTERNATE.
 - Suggested compat string "renesas,rcar-gen2-vin" is not included. Will
   address this in a separate patch together with gen3.

The goal is to replace the soc_camera driver completely to prepare for
Gen3 enablement. I have therefor chosen to inherit the
CONFIG_VIDEO_RCAR_VIN name for this new driver and renamed the
soc_camera driver CONFIG_VIDEO_RCAR_VIN_OLD.

* Changes since v4
- Set device_caps in struct video_device instead of in vidioc_querycap
  call.
- Verify type is V4L2_BUF_TYPE_VIDEO_CAPTURE in vidioc_g_selection,
  vidioc_s_selection and vidioc_cropcap calls.
- Call subdev operation g_input_status in vidioc_enum_input to fill in
  the struct v4l2_input status field.
- Rework the logic that verifies that the HW is properly stopped when
  calling stop_streaming to not depend on the interrupt handler. One
  user reported problems with the soc_camera driver which used the same
  stop logic as this driver. The report described a scenario where an
  interrupt would not be generated when stopping the HW hence the state
  would not be set to stopped.
- Use the v4l2_rect_* helper functions from recently merged v4l2-rect.h
  instead of having our own implementation of the same functions.

* Changes since v3
- Print error and return EINVAL instead of ENOBUFS if there is not
  enough buffers to fill HW in start_streaming. This error should not
  happen since 'min_buffers_needed' should ensure it never happens but
  we check for the condition anyhow.
- Return all buffers with state VB2_BUF_STATE_QUEUED if there is an
  error in start_streaming.

* Changes since v2
- Fix review comments from Hans Verkuil, thanks!
- Update description in Kconfig
- Drop V4L2_SEL_TGT_COMPOSE_PADDED
- Wrong size for NV16 image
- Copy ycbcr_enc and xfer_func when keeping old format.
- Add vidioc_cropcap
- Return -ENOBUFS in start_streaming to signal more buffers are
  needed instead of sleeping in a critical section...
- Move all v4l2 ioctls and file ops to rcar-v4l2.c (and as a follow
  up moved all HW functions to rcar-dma.c to increase readability).
- Fixed RGB formats 's/V4L2_PIX_FMT_RGB555X/V4L2_PIX_FMT_XRGB555' and
  's/V4L2_PIX_FMT_RGB32/V4L2_PIX_FMT_XBGR32'. This was an error carried
  over from soc-camera dirver, whit this fix I get correct colors in
  qv4l2.
- Rework how media bus type and flags are handled. Instead of defining
  own values and a unsigned int use struct v4l2_mbus_config to store the
  configuration parsed from DT.
- Remove duplicated code from the v4l2_file_operations release code
  path. There is no need to try and stop the streaming from here. If
  start_streaming have been called stop_streaming will be called by the
  framework stopping the streaming.
- Remove all special checks for the chip RCAR_E1. There are no compat
  string that will select this chip model. Neither for this driver or
  its predecessor in soc-camera.
- Force an width alignment of 32 if the NV16 format is used due to HW
  limitation.

* Changes since RFC/PATCH
- Fixed review comments from Hans Verkuil, thanks for reviewing.
- Added vidioc_[gs]_selection crop and composition is supported. Thanks
  Laurent for taking the time and explaining to me how to do
  composition.
- Reworked the DMA flow to better support single and continues frame
  grabbing mode.
- Dropped a lot of the formats that was ported from soc_camera, once I
  looked at it in a working driver it was obvious that the rcar_vin
  soc_camera driver did not support them.
- Added better comments for the core structs
- Fixed copyright in file headers
- A lot more testing.

# v4l2-compliance -d 27 -s -f
Driver Info:
Driver name   : rcar_vin
Card type : R_Car_VIN
Bus info  : platform:e6ef1000.video
Driver version: 4.6.0
Capabilities  : 0x8521
Video Capture
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0521
Video Capture
Read/Write
Streaming
Extended Pix Format

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

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
   

Re: [PATCH v7 00/24] i2c mux cleanup and locking update

[Crestez Dan Leonard]

On 04/20/2016 06:17 PM, Peter Rosin wrote:
> v7 compared to v6:
> - Removed i2c_mux_reserve_adapters, and all realloc attempts in
>   i2c_mux_add_adapter. Supply a maximum number of adapters in i2c_mux_alloc
>   instead.
> - Removed i2c_mux_one_adapter since it is was hard to use correctly, which
>   was evident from the crash in the mpu6050 driver (on a mpu9150 chip) 
> reported
>   by Crestez Dan Leonard. Also, it didn't make things all that much simpler
>   anyway (even if used correctly).
> - Rename i2c_mux_core:adapters into i2c_mux_core:num_adapters.
> - Some grammar and spelling fixes.

I tested this new version on mpu9150 and there are no more obvious
deadlocks or crashes. The magnetometer and accel/gyro can be used at the
same time without issues.
--
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/8] Input: atmel_mxt_ts - output diagnostic debug via v4l2 device

[kbuild test robot]

Hi,

[auto build test ERROR on input/next]
[also build test ERROR on v4.6-rc4 next-20160420]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Nick-Dyer/Input-atmel_mxt_ts-output-raw-touch-diagnostic-data-via-V4L/20160421-174351
base:   https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
config: arm-multi_v7_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `mxt_vidioc_s_input':
>> :(.text+0x376b70): undefined reference to `video_devdata'
   drivers/built-in.o: In function `mxt_vidioc_g_input':
   :(.text+0x376bdc): undefined reference to `video_devdata'
   drivers/built-in.o: In function `mxt_vidioc_fmt':
   :(.text+0x376bfc): undefined reference to `video_devdata'
   drivers/built-in.o: In function `mxt_vidioc_enum_framesizes':
   :(.text+0x376c34): undefined reference to `video_devdata'
   drivers/built-in.o: In function `mxt_vidioc_querycap':
   :(.text+0x376d10): undefined reference to `video_devdata'
   drivers/built-in.o: In function `mxt_free_object_table':
>> :(.text+0x377744): undefined reference to `video_unregister_device'
>> :(.text+0x37774c): undefined reference to `v4l2_device_unregister'
   drivers/built-in.o: In function `mxt_buffer_queue':
>> :(.text+0x377a38): undefined reference to `vb2_plane_vaddr'
>> :(.text+0x377ad0): undefined reference to `vb2_buffer_done'
   :(.text+0x377bb0): undefined reference to `vb2_buffer_done'
   drivers/built-in.o: In function `mxt_config_cb':
>> :(.text+0x378e84): undefined reference to `v4l2_device_register'
>> :(.text+0x379104): undefined reference to `vb2_vmalloc_memops'
   :(.text+0x379108): undefined reference to `vb2_vmalloc_memops'
>> :(.text+0x37913c): undefined reference to `vb2_queue_init'
>> :(.text+0x37919c): undefined reference to `video_device_release_empty'
   :(.text+0x3791a4): undefined reference to `video_device_release_empty'
>> :(.text+0x3791d0): undefined reference to `__video_register_device'
   :(.text+0x3791f4): undefined reference to `v4l2_device_unregister'
   drivers/built-in.o: In function `.LANCHOR1':
   :(.rodata+0x12c9ac): undefined reference to `vb2_ops_wait_prepare'
   :(.rodata+0x12c9b0): undefined reference to `vb2_ops_wait_finish'
   :(.rodata+0x12c9d4): undefined reference to `vb2_fop_read'
   :(.rodata+0x12c9dc): undefined reference to `vb2_fop_poll'
   :(.rodata+0x12c9e0): undefined reference to `video_ioctl2'
   :(.rodata+0x12c9e8): undefined reference to `vb2_fop_mmap'
   :(.rodata+0x12c9ec): undefined reference to `v4l2_fh_open'
   :(.rodata+0x12c9f0): undefined reference to `vb2_fop_release'
   :(.rodata+0x12cac4): undefined reference to `vb2_ioctl_reqbufs'
   :(.rodata+0x12cac8): undefined reference to `vb2_ioctl_querybuf'
   :(.rodata+0x12cacc): undefined reference to `vb2_ioctl_qbuf'
   :(.rodata+0x12cad0): undefined reference to `vb2_ioctl_expbuf'
   :(.rodata+0x12cad4): undefined reference to `vb2_ioctl_dqbuf'
   :(.rodata+0x12cad8): undefined reference to `vb2_ioctl_create_bufs'
   :(.rodata+0x12caec): undefined reference to `vb2_ioctl_streamon'
   :(.rodata+0x12caf0): undefined reference to `vb2_ioctl_streamoff'

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


.config.gz
Description: Binary data

Re: [PATCH 2/8] Input: atmel_mxt_ts - output diagnostic debug via v4l2 device

[kbuild test robot]

Hi,

[auto build test ERROR on input/next]
[also build test ERROR on v4.6-rc4 next-20160420]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Nick-Dyer/Input-atmel_mxt_ts-output-raw-touch-diagnostic-data-via-V4L/20160421-174351
base:   https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
config: arm-exynos_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `video_drvdata':
>> include/media/v4l2-dev.h:224: undefined reference to `video_devdata'
>> include/media/v4l2-dev.h:224: undefined reference to `video_devdata'
>> include/media/v4l2-dev.h:224: undefined reference to `video_devdata'
>> include/media/v4l2-dev.h:224: undefined reference to `video_devdata'
>> include/media/v4l2-dev.h:224: undefined reference to `video_devdata'
   drivers/built-in.o: In function `mxt_free_object_table':
>> drivers/input/touchscreen/atmel_mxt_ts.c:1552: undefined reference to 
>> `video_unregister_device'
>> drivers/input/touchscreen/atmel_mxt_ts.c:1553: undefined reference to 
>> `v4l2_device_unregister'
   drivers/built-in.o: In function `mxt_buffer_queue':
>> drivers/input/touchscreen/atmel_mxt_ts.c:2210: undefined reference to 
>> `vb2_plane_vaddr'
>> drivers/input/touchscreen/atmel_mxt_ts.c:2225: undefined reference to 
>> `vb2_buffer_done'
   drivers/input/touchscreen/atmel_mxt_ts.c:2221: undefined reference to 
`vb2_buffer_done'
   drivers/built-in.o: In function `mxt_debug_init':
>> drivers/input/touchscreen/atmel_mxt_ts.c:2429: undefined reference to 
>> `v4l2_device_register'
>> drivers/input/touchscreen/atmel_mxt_ts.c:2437: undefined reference to 
>> `vb2_vmalloc_memops'
>> drivers/input/touchscreen/atmel_mxt_ts.c:2437: undefined reference to 
>> `vb2_vmalloc_memops'
>> drivers/input/touchscreen/atmel_mxt_ts.c:2441: undefined reference to 
>> `vb2_queue_init'
>> drivers/input/touchscreen/atmel_mxt_ts.c:2445: undefined reference to 
>> `video_device_release_empty'
>> drivers/input/touchscreen/atmel_mxt_ts.c:2445: undefined reference to 
>> `video_device_release_empty'
   drivers/built-in.o: In function `video_register_device':
>> include/media/v4l2-dev.h:160: undefined reference to 
>> `__video_register_device'
   drivers/built-in.o: In function `mxt_debug_init':
   drivers/input/touchscreen/atmel_mxt_ts.c:2461: undefined reference to 
`v4l2_device_unregister'
   drivers/built-in.o: In function `.LANCHOR1':
>> :(.rodata+0x3a090): undefined reference to `vb2_ops_wait_prepare'
>> :(.rodata+0x3a094): undefined reference to `vb2_ops_wait_finish'
>> :(.rodata+0x3a0b8): undefined reference to `vb2_fop_read'
>> :(.rodata+0x3a0c0): undefined reference to `vb2_fop_poll'

vim +1552 drivers/input/touchscreen/atmel_mxt_ts.c

  1546  data->input_dev = NULL;
  1547  }
  1548  }
  1549  
  1550  static void mxt_free_object_table(struct mxt_data *data)
  1551  {
> 1552  video_unregister_device(>dbg.vdev);
> 1553  v4l2_device_unregister(>dbg.v4l2);
  1554  
  1555  kfree(data->object_table);
  1556  data->object_table = NULL;

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


.config.gz
Description: Binary data

Re: [PATCH 2/8] Input: atmel_mxt_ts - output diagnostic debug via v4l2 device

[kbuild test robot]

Hi,

[auto build test ERROR on input/next]
[also build test ERROR on v4.6-rc4 next-20160420]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Nick-Dyer/Input-atmel_mxt_ts-output-raw-touch-diagnostic-data-via-V4L/20160421-174351
base:   https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
config: x86_64-randconfig-b0-04211643 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "vb2_fop_release" [drivers/input/touchscreen/atmel_mxt_ts.ko] 
>> undefined!
>> ERROR: "v4l2_fh_open" [drivers/input/touchscreen/atmel_mxt_ts.ko] undefined!
>> ERROR: "vb2_fop_mmap" [drivers/input/touchscreen/atmel_mxt_ts.ko] undefined!
>> ERROR: "video_ioctl2" [drivers/input/touchscreen/atmel_mxt_ts.ko] undefined!
>> ERROR: "vb2_fop_poll" [drivers/input/touchscreen/atmel_mxt_ts.ko] undefined!
>> ERROR: "vb2_fop_read" [drivers/input/touchscreen/atmel_mxt_ts.ko] undefined!
>> ERROR: "vb2_ops_wait_finish" [drivers/input/touchscreen/atmel_mxt_ts.ko] 
>> undefined!
>> ERROR: "vb2_ops_wait_prepare" [drivers/input/touchscreen/atmel_mxt_ts.ko] 
>> undefined!
>> ERROR: "vb2_ioctl_streamoff" [drivers/input/touchscreen/atmel_mxt_ts.ko] 
>> undefined!
>> ERROR: "vb2_ioctl_streamon" [drivers/input/touchscreen/atmel_mxt_ts.ko] 
>> undefined!
>> ERROR: "vb2_ioctl_create_bufs" [drivers/input/touchscreen/atmel_mxt_ts.ko] 
>> undefined!
>> ERROR: "vb2_ioctl_dqbuf" [drivers/input/touchscreen/atmel_mxt_ts.ko] 
>> undefined!
>> ERROR: "vb2_ioctl_expbuf" [drivers/input/touchscreen/atmel_mxt_ts.ko] 
>> undefined!
>> ERROR: "vb2_ioctl_qbuf" [drivers/input/touchscreen/atmel_mxt_ts.ko] 
>> undefined!
>> ERROR: "vb2_ioctl_querybuf" [drivers/input/touchscreen/atmel_mxt_ts.ko] 
>> undefined!
>> ERROR: "vb2_ioctl_reqbufs" [drivers/input/touchscreen/atmel_mxt_ts.ko] 
>> undefined!
>> ERROR: "__video_register_device" [drivers/input/touchscreen/atmel_mxt_ts.ko] 
>> undefined!
>> ERROR: "video_device_release_empty" 
>> [drivers/input/touchscreen/atmel_mxt_ts.ko] undefined!
>> ERROR: "vb2_queue_init" [drivers/input/touchscreen/atmel_mxt_ts.ko] 
>> undefined!
>> ERROR: "vb2_vmalloc_memops" [drivers/input/touchscreen/atmel_mxt_ts.ko] 
>> undefined!

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


.config.gz
Description: Binary data

re: file (standard input) matches

[Dan Carpenter]

Hello file (standard input) matches,

The patch d855497edbfb: "V4L/DVB (4228a): pvrusb2 to kernel 2.6.18" from
Jun 26 2006, leads to the following static checker warning:

drivers/media/usb/pvrusb2/pvrusb2-hdw.c:881 ctrl_std_sym_to_val()
error: uninitialized symbol 'id'.

drivers/media/usb/pvrusb2/pvrusb2-hdw.c
   873  static int ctrl_std_sym_to_val(struct pvr2_ctrl *cptr,
   874 const char *bufPtr,unsigned int bufSize,
   875 int *mskp,int *valp)
   876  {
   877  int ret;
   878  v4l2_std_id id;
   879  ret = pvr2_std_str_to_id(,bufPtr,bufSize);
   880  if (ret < 0) return ret;

pvr2_std_str_to_id() appears to return 0 on error and !0 on success.
Not joking, that's the actual code.

   881  if (mskp) *mskp = id;
   882  if (valp) *valp = id;
   883  return 0;
   884  }

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

re: [PATCH] v4l: 790: added support for terratec cinergy 250 usb

[Dan Carpenter]

Hello Markus Rechberger,

The patch e43f14af1439: "[PATCH] v4l: 790: added support for terratec
cinergy 250 usb" from Nov 8, 2005, leads to the following static
checker warning:

drivers/media/usb/em28xx/em28xx-input.c:307 em28xx_i2c_ir_handle_key()
error: uninitialized symbol 'protocol'.

drivers/media/usb/em28xx/em28xx-input.c
84  static int em28xx_get_key_terratec(struct i2c_client *i2c_dev,
85 enum rc_type *protocol, u32 
*scancode)
86  {
87  unsigned char b;
88  
89  /* poll IR chip */
90  if (1 != i2c_master_recv(i2c_dev, , 1))
91  return -EIO;
92  
93  /* it seems that 0xFE indicates that a button is still hold
94 down, while 0xff indicates that no button is hold down. */
95  
96  if (b == 0xff)
97  return 0;
98  
99  if (b == 0xfe)
   100  /* keep old data */
   101  return 1;

This is only called from em28xx_i2c_ir_handle_key() and the "old data"
is uninitialized garbage.

   102  
   103  *protocol = RC_TYPE_UNKNOWN;
   104  *scancode = b;
   105  return 1;
   106  }

regards,
dan carpenter
--
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] smiapp: provide g_skip_top_lines method in sensor ops

[Sakari Ailus]

Hi Ivaylo,

On Mon, Apr 18, 2016 at 09:27:53AM +0300, Ivaylo Dimitrov wrote:
> Hi,
> 
> On 18.04.2016 00:44, Sakari Ailus wrote:
> >Hi Ivaylo,
> >
> >On Sat, Apr 16, 2016 at 11:12:20AM +0300, Ivaylo Dimitrov wrote:
> >>Some sensors (like the one in Nokia N900) provide metadata in the first
> >>couple of lines. Make that information information available to the
> >>pipeline.
> >>
> >>Signed-off-by: Ivaylo Dimitrov 
> >>---
> >>  drivers/media/i2c/smiapp/smiapp-core.c | 12 
> >>  drivers/media/i2c/smiapp/smiapp.h  |  1 +
> >>  2 files changed, 13 insertions(+)
> >>
> ...
> >
> >I'm afraid I think this is not exactly the best way to approach the issue.
> >It'd work, somehow, yes, but ---
> >
> >1. A compliant sensor (at least in theory) is able to tell this information
> >itself. The number of metadata lines is present in the sensor frame format
> >descriptors.
> >
> 
> Right. And this is where that number is taken from in the patch and made
> available to whoever wants to use it. See 
> http://lxr.free-electrons.com/source/drivers/media/i2c/smiapp/smiapp-core.c#L177
> . I don't really understand your point here. Maybe the patch description is
> fuzzy? Could you elaborate?

I missed just that part, apologies for that. I'll apply this into my tree.

> 
> >2. The more generic problem of describing the frame layout should be solved.
> >Sensor metadata is just a special case of this. I've proposed frame
> >descriptors (see an old RFC
> >), but this is
> >just a partial solution as well; the APIs would need to be extended to
> >support metadata capture (I think Laurent has been working on that).
> >
> 
> Could be, however what we have right now is 
> http://lxr.free-electrons.com/source/drivers/media/platform/omap3isp/ispccp2.c#L369.
> Also, the patch is not trying to solve the problem with frame format
> description(or anything in general), but a mere way to pass an already
> available information in the sensor which is needed by omap3isp, by using an
> already existing API. I don't see how's that related to the way v4l API
> going to evolve in some (distant?) future. Not to say that once those frame
> format descriptors are available, it should be relatively easy to simply
> remove g_skip_top_lines form v4l2_subdev_sensor_ops and fix the drivers to
> use the new API.
> 
> BTW if you have any idea on how to pass (or set) the number of lines to be
> skipped at the start of the frame to omap3isp driver in some other way, I am
> fine with dropping the $subject patch and sending another one implementing
> your proposal.

Hopefully we'll have a better solution in not so distant future. Metadata is
just a special case for frame descriptors.

-- 
Kind regards,

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: [PATCH/RFC 2/2] v4l: Define a pixel format for the R-Car VSP1 1-D histogram engine

[Sakari Ailus]

Hi Laurent,

On Thu, Apr 21, 2016 at 03:40:27AM +0300, Laurent Pinchart wrote:
> The format is used on the R-Car VSP1 video queues that carry
> 1-D histogram statistics data.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  .../DocBook/media/v4l/pixfmt-meta-vsp1-hgo.xml | 307 
> +
>  Documentation/DocBook/media/v4l/pixfmt.xml |   9 +
>  drivers/media/v4l2-core/v4l2-ioctl.c   |   1 +
>  include/uapi/linux/videodev2.h |   3 +
>  4 files changed, 320 insertions(+)
>  create mode 100644 Documentation/DocBook/media/v4l/pixfmt-meta-vsp1-hgo.xml
> 
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-meta-vsp1-hgo.xml 
> b/Documentation/DocBook/media/v4l/pixfmt-meta-vsp1-hgo.xml
> new file mode 100644
> index ..b40bd10695d2
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/pixfmt-meta-vsp1-hgo.xml
> @@ -0,0 +1,307 @@
> +
> +  
> +V4L2_META_FMT_VSP1_HGO ('VSPH')
> +
> +  
> +  
> +
> +  V4L2_META_FMT_VSP1_HGO
> +
> +Renesas R-Car VSP1 1-D Histogram Data
> +  
> +  
> +Description
> +
> +This format describes histogram data generated by the Renesas R-Car VSP1 1-D
> +Histogram (HGO) engine.
> +
> +
> +The VSP1 HGO is a histogram computation engine that can operate on RGB, YCrCb
> +or HSV data. It operates on a possibly cropped and subsampled input image and
> +computes the minimum, maximum and sum of all pixels as well as per-channel
> +histograms.
> +
> +The HGO can compute histograms independently per channel, on the maximum of 
> the
> +three channels (RGB data only) or on the Y channel only (YCbCr only). It can
> +additionally output the histogram with 64 or 256 bins, resulting in four
> +possible modes of operation.
> +  
> + 
> +   
> + In 64 bins normal mode, the HGO operates
> + on the three channels independently to compute three 64-bins
> + histograms. RGB, YCbCr and HSV image formats are supported.
> +   
> + 
> + 
> +   
> + In 64 bins maximum mode, the HGO operates
> + on the maximum of the (R, G, B) channels to compute a single
> + 64-bins histogram. Only the RGB image format is supported.
> +   
> + 
> + 
> +   
> + In 256 bins normal mode, the HGO operates
> + on the Y channel to compute a single 256-bins histogram. Only the
> + YCbCr image format is supported.
> +   
> + 
> + 
> +   
> + In 256 bins maximum mode, the HGO operates
> + on the maximum of the (R, G, B) channels to compute a single
> + 256-bins histogram. Only the RGB image format is supported.
> +   
> + 
> +  
> +
> +
> +
> +All data is stored in memory in little endian format. Each cell in the tables
> +below contains one byte.
> +
> +
> +  VSP1 HGO Data - 64 Bins, Normal Mode (792 bytes)
> +  
> + 
> + 
> + 
> + 
> + 
> +  align="center" />
> + 
> +   
> + Offset
> + Memory
> +   
> +   
> + 
> + [31:24]
> + [23:16]
> + [15:8]
> + [7:0]
> +   
> + 
> + 
> +   
> + 0
> + -
> + R/Cr/H max [7:0]
> + -
> + R/Cr/H min [7:0]
> +   
> +   
> + 4
> + -
> + G/Y/S max [7:0]
> + -
> + G/Y/S min [7:0]
> +   
> +   
> + 8
> + -
> + B/Cb/V max [7:0]
> + -
> + B/Cb/V min [7:0]
> +   
> +   
> + 12
> + R/Cr/H sum [31:0]
> +   
> +   
> + 16
> + G/Y/S sum [31:0]
> +   
> +   
> + 20
> + B/Cb/V sum [31:0]
> +   
> +   
> + 24
> + R/Cr/H bin 0 [31:0]
> +   
> +   
> + 
> + ...
> +   
> +   
> + 276
> + R/Cr/H bin 63 [31:0]
> +   
> +   
> + 280
> + G/Y/S bin 0 [31:0]
> +   
> +   
> + 
> + ...
> +   
> +   
> + 532
> + G/Y/S bin 63 [31:0]
> +   
> +   
> + 536
> + B/Cb/V bin 0 [31:0]
> +   
> +   
> + 
> + ...
> +   
> +   
> + 788
> + B/Cb/V bin 63 [31:0]
> +   
> + 
> +  
> +
> +
> +  VSP1 HGO Data - 64 Bins, Max Mode (264 bytes)
> +  
> + 
> + 
> + 
> + 
> + 
> +  align="center" />
> + 
> +   
> + Offset
> + Memory
> +   
> +   
> + 
> + [31:24]
> + [23:16]
> + [15:8]
> + [7:0]
> +   
> + 
> + 
> +   
> + 0
> + -
> + max(R,G,B) max [7:0]
> + -
> + max(R,G,B) min [7:0]
> +   
> +   
> + 4
> + max(R,G,B) sum [31:0]
> +   
> +   
> + 8
> + 

[PATCH 1/8] Input: atmel_mxt_ts - add support for T37 diagnostic data

[Nick Dyer]

Add function to retrieve raw references data from the diagnostic data
object

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 152 +++
 1 file changed, 152 insertions(+)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 2160512..0784a18 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -124,6 +124,17 @@ struct t9_range {
 #define MXT_COMMS_CTRL 0
 #define MXT_COMMS_CMD  1
 
+/* MXT_DEBUG_DIAGNOSTIC_T37 */
+#define MXT_DIAGNOSTIC_PAGEUP 0x01
+#define MXT_DIAGNOSTIC_DELTAS 0x10
+#define MXT_DIAGNOSTIC_SIZE128
+
+struct t37_debug {
+   u8 mode;
+   u8 page;
+   u8 data[MXT_DIAGNOSTIC_SIZE];
+};
+
 /* Define for MXT_GEN_COMMAND_T6 */
 #define MXT_BOOT_VALUE 0xa5
 #define MXT_RESET_VALUE0x01
@@ -205,6 +216,14 @@ struct mxt_object {
u8 num_report_ids;
 } __packed;
 
+struct mxt_dbg {
+   u16 t37_address;
+   u16 diag_cmd_address;
+   struct t37_debug *t37_buf;
+   unsigned int t37_pages;
+   unsigned int t37_nodes;
+};
+
 /* Each client has this additional data */
 struct mxt_data {
struct i2c_client *client;
@@ -233,6 +252,7 @@ struct mxt_data {
u8 num_touchids;
u8 multitouch;
struct t7_config t7_cfg;
+   struct mxt_dbg dbg;
 
/* Cached parameters from object table */
u16 T5_address;
@@ -2043,6 +2063,136 @@ recheck:
return 0;
 }
 
+static u16 mxt_get_debug_value(struct mxt_data *data, unsigned int x,
+  unsigned int y)
+{
+   struct mxt_dbg *dbg = >dbg;
+   unsigned int ofs, page;
+
+   ofs = (y + (x * data->info.matrix_ysize)) * sizeof(u16);
+   page = ofs / MXT_DIAGNOSTIC_SIZE;
+   ofs %= MXT_DIAGNOSTIC_SIZE;
+
+   return get_unaligned_le16(>t37_buf[page].data[ofs]);
+}
+
+static int mxt_convert_debug_pages(struct mxt_data *data, u16 *outbuf)
+{
+   struct mxt_dbg *dbg = >dbg;
+   unsigned int x = 0;
+   unsigned int y = 0;
+   unsigned int i;
+
+   for (i = 0; i < dbg->t37_nodes; i++) {
+   outbuf[i] = mxt_get_debug_value(data, x, y);
+
+   /* Next value */
+   if (++x >= data->info.matrix_xsize) {
+   x = 0;
+   y++;
+   }
+   }
+
+   return 0;
+}
+
+static int mxt_read_diagnostic_debug(struct mxt_data *data, u8 mode,
+u16 *outbuf)
+{
+   struct mxt_dbg *dbg = >dbg;
+   int retries = 0;
+   int page;
+   int ret;
+   u8 cmd = mode;
+   struct t37_debug *p;
+   u8 cmd_poll;
+
+   for (page = 0; page < dbg->t37_pages; page++) {
+   p = dbg->t37_buf + page;
+
+   ret = mxt_write_reg(data->client, dbg->diag_cmd_address,
+   cmd);
+   if (ret)
+   return ret;
+
+   retries = 0;
+   msleep(20);
+wait_cmd:
+   /* Read back command byte */
+   ret = __mxt_read_reg(data->client, dbg->diag_cmd_address,
+sizeof(cmd_poll), _poll);
+   if (ret)
+   return ret;
+
+   /* Field is cleared once the command has been processed */
+   if (cmd_poll) {
+   if (retries++ > 100)
+   return -EINVAL;
+
+   msleep(20);
+   goto wait_cmd;
+   }
+
+   /* Read T37 page */
+   ret = __mxt_read_reg(data->client, dbg->t37_address,
+   sizeof(struct t37_debug), p);
+   if (ret)
+   return ret;
+
+   if ((p->mode != mode) || (p->page != page)) {
+   dev_err(>client->dev, "T37 page mismatch\n");
+   return -EINVAL;
+   }
+
+   dev_dbg(>client->dev, "%s page:%d retries:%d\n",
+   __func__, page, retries);
+
+   /* For remaining pages, write PAGEUP rather than mode */
+   cmd = MXT_DIAGNOSTIC_PAGEUP;
+   }
+
+   return mxt_convert_debug_pages(data, outbuf);
+}
+
+static void mxt_debug_init(struct mxt_data *data)
+{
+   struct mxt_dbg *dbg = >dbg;
+   struct mxt_object *object;
+
+   object = mxt_get_object(data, MXT_GEN_COMMAND_T6);
+   if (!object)
+   return;
+
+   dbg->diag_cmd_address = object->start_address + MXT_COMMAND_DIAGNOSTIC;
+
+   object = mxt_get_object(data, MXT_DEBUG_DIAGNOSTIC_T37);
+   if (!object)
+   return;
+
+   if (mxt_obj_size(object) != sizeof(struct t37_debug)) {
+   dev_warn(>client->dev, "Bad T37 size");
+   return;
+   }
+
+   dbg->t37_address = 

[PATCH 8/8] Input: atmel_mxt_ts - add v4l pixelformat definition for touch refs output

[Nick Dyer]

---
 drivers/input/touchscreen/atmel_mxt_ts.c | 33 
 include/uapi/linux/videodev2.h   |  1 +
 2 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 3bb1179..94ed8bd 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -2396,21 +2396,24 @@ static int mxt_set_input(struct mxt_data *data, 
unsigned int i)
if (i >= MXT_V4L_INPUT_MAX)
return -EINVAL;
 
+   f->pixelformat = V4L2_PIX_FMT_Y16;
+
switch (i) {
-   case MXT_V4L_INPUT_REFS:
case MXT_V4L_INPUT_DELTAS:
+   f->pixelformat = V4L2_PIX_FMT_YS16; /* fall-through */
+   case MXT_V4L_INPUT_REFS:
f->width = data->xy_switch ? data->ysize : data->xsize;
f->height = data->xy_switch ? data->xsize : data->ysize;
break;
 
-   case MXT_V4L_INPUT_REFS_SINGLE:
case MXT_V4L_INPUT_DELTAS_SINGLE:
+   f->pixelformat = V4L2_PIX_FMT_YS16; /* fall-through */
+   case MXT_V4L_INPUT_REFS_SINGLE:
f->width = 1;
f->height = 1;
break;
}
 
-   f->pixelformat = V4L2_PIX_FMT_Y16;
f->field = V4L2_FIELD_NONE;
f->colorspace = V4L2_COLORSPACE_SRGB;
f->bytesperline = f->width * sizeof(u16);
@@ -2447,12 +2450,26 @@ static int mxt_vidioc_fmt(struct file *file, void 
*priv, struct v4l2_format *f)
 static int mxt_vidioc_enum_fmt(struct file *file, void *priv,
 struct v4l2_fmtdesc *fmt)
 {
-   if (fmt->index > 0 || fmt->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+   if (fmt->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
 
-   fmt->pixelformat = V4L2_PIX_FMT_Y16;
-   strlcpy(fmt->description, "16-bit raw debug data",
-   sizeof(fmt->description));
+   switch (fmt->index) {
+   case 0:
+   fmt->pixelformat = V4L2_PIX_FMT_Y16;
+   strlcpy(fmt->description, "16-bit unsigned raw debug data",
+   sizeof(fmt->description));
+   break;
+
+   case 1:
+   fmt->pixelformat = V4L2_PIX_FMT_YS16;
+   strlcpy(fmt->description, "16-bit signed raw debug data",
+   sizeof(fmt->description));
+   break;
+
+   default:
+   return -EINVAL;
+   }
+
fmt->flags = 0;
return 0;
 }
@@ -2484,7 +2501,7 @@ static int mxt_vidioc_enum_framesizes(struct file *file, 
void *priv,
 static int mxt_vidioc_enum_frameintervals(struct file *file, void *priv,
  struct v4l2_frmivalenum *f)
 {
-   if ((f->index > 0) || (f->pixel_format != V4L2_PIX_FMT_Y16))
+   if (f->index > 0)
return -EINVAL;
 
f->type = V4L2_FRMIVAL_TYPE_DISCRETE;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 14cd5eb..ab577dd 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -496,6 +496,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_Y12 v4l2_fourcc('Y', '1', '2', ' ') /* 12  Greyscale  
   */
 #define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16  Greyscale  
   */
 #define V4L2_PIX_FMT_Y16_BE  v4l2_fourcc_be('Y', '1', '6', ' ') /* 16  
Greyscale BE  */
+#define V4L2_PIX_FMT_YS16v4l2_fourcc('Y', 'S', '1', '6') /* signed 16-bit 
Greyscale */
 
 /* Grey bit-packed formats */
 #define V4L2_PIX_FMT_Y10BPACKv4l2_fourcc('Y', '1', '0', 'B') /* 10  
Greyscale bit-packed */
-- 
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

[PATCH 5/8] Input: atmel_mxt_ts - add diagnostic data support for mXT1386

[Nick Dyer]

The mXT1386 family of chips have a different architecture which splits
the diagnostic data into 3 columns.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 29 ++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 3dd312f..bac0aa0 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -137,6 +137,10 @@ struct t9_range {
 #define MXT_DIAGNOSTIC_DELTAS 0x10
 #define MXT_DIAGNOSTIC_SIZE128
 
+#define MXT_FAMILY_1386160
+#define MXT1386_COLUMNS3
+#define MXT1386_PAGES_PER_COLUMN   8
+
 struct t37_debug {
u8 mode;
u8 page;
@@ -2135,13 +2139,27 @@ recheck:
 static u16 mxt_get_debug_value(struct mxt_data *data, unsigned int x,
   unsigned int y)
 {
+   struct mxt_info *info = >info;
struct mxt_dbg *dbg = >dbg;
unsigned int ofs, page;
+   unsigned int col = 0;
+   unsigned int col_width;
+
+   if (info->family_id == MXT_FAMILY_1386) {
+   col_width = info->matrix_ysize / MXT1386_COLUMNS;
+   col = y / col_width;
+   y = y % col_width;
+   } else {
+   col_width = info->matrix_ysize;
+   }
 
-   ofs = (y + (x * data->info.matrix_ysize)) * sizeof(u16);
+   ofs = (y + (x * col_width)) * sizeof(u16);
page = ofs / MXT_DIAGNOSTIC_SIZE;
ofs %= MXT_DIAGNOSTIC_SIZE;
 
+   if (info->family_id == MXT_FAMILY_1386)
+   page += col * MXT1386_PAGES_PER_COLUMN;
+
return get_unaligned_le16(>t37_buf[page].data[ofs]);
 }
 
@@ -2435,6 +2453,7 @@ static const struct video_device mxt_video_device = {
 
 static void mxt_debug_init(struct mxt_data *data)
 {
+   struct mxt_info *info = >info;
struct mxt_dbg *dbg = >dbg;
struct mxt_object *object;
int error;
@@ -2458,9 +2477,13 @@ static void mxt_debug_init(struct mxt_data *data)
 
/* Calculate size of data and allocate buffer */
dbg->t37_nodes = data->xsize * data->ysize;
-   dbg->t37_pages = ((data->xsize * data->info.matrix_ysize)
- * sizeof(u16) / sizeof(dbg->t37_buf->data)) + 1;
 
+   if (info->family_id == MXT_FAMILY_1386)
+   dbg->t37_pages = MXT1386_COLUMNS * MXT1386_PAGES_PER_COLUMN;
+   else
+   dbg->t37_pages = ((data->xsize * info->matrix_ysize)
+  * sizeof(u16) / sizeof(dbg->t37_buf->data))
+  + 1;
 
dbg->t37_buf = devm_kzalloc(>client->dev,
 sizeof(struct t37_debug) * dbg->t37_pages,
-- 
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

[PATCH 7/8] Input: atmel_mxt_ts - single node diagnostic data support

[Nick Dyer]

Add support for retrieving a single node of data at high rate.
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 79 
 1 file changed, 70 insertions(+), 9 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 6a35d94..3bb1179 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -239,6 +239,7 @@ struct mxt_dbg {
struct t37_debug *t37_buf;
unsigned int t37_pages;
unsigned int t37_nodes;
+   unsigned int single_node_ofs;
 
struct v4l2_device v4l2;
struct v4l2_pix_format format;
@@ -251,6 +252,8 @@ struct mxt_dbg {
 enum v4l_dbg_inputs {
MXT_V4L_INPUT_DELTAS,
MXT_V4L_INPUT_REFS,
+   MXT_V4L_INPUT_DELTAS_SINGLE,
+   MXT_V4L_INPUT_REFS_SINGLE,
MXT_V4L_INPUT_MAX,
 };
 
@@ -2197,17 +2200,19 @@ static int mxt_convert_debug_pages(struct mxt_data 
*data, u16 *outbuf)
 }
 
 static int mxt_read_diagnostic_debug(struct mxt_data *data, u8 mode,
-u16 *outbuf)
+u16 *outbuf, bool single_node)
 {
struct mxt_dbg *dbg = >dbg;
int retries = 0;
int page;
+   int pages = single_node ? 1 : dbg->t37_pages;
int ret;
u8 cmd = mode;
struct t37_debug *p;
u8 cmd_poll;
 
-   for (page = 0; page < dbg->t37_pages; page++) {
+
+   for (page = 0; page < pages; page++) {
p = dbg->t37_buf + page;
 
ret = mxt_write_reg(data->client, dbg->diag_cmd_address,
@@ -2251,7 +2256,15 @@ wait_cmd:
cmd = MXT_DIAGNOSTIC_PAGEUP;
}
 
-   return mxt_convert_debug_pages(data, outbuf);
+   if (single_node) {
+   *outbuf = get_unaligned_le16(>t37_buf[0]
+.data[dbg->single_node_ofs]);
+   ret = 0;
+   } else {
+   ret = mxt_convert_debug_pages(data, outbuf);
+   }
+
+   return ret;
 }
 
 static int mxt_queue_setup(struct vb2_queue *q,
@@ -2278,6 +2291,7 @@ static void mxt_buffer_queue(struct vb2_buffer *vb)
u16 *ptr;
int ret;
u8 mode;
+   bool single_node = false;
 
ptr = vb2_plane_vaddr(vb, 0);
if (!ptr) {
@@ -2286,17 +2300,21 @@ static void mxt_buffer_queue(struct vb2_buffer *vb)
}
 
switch (data->dbg.input) {
+   case MXT_V4L_INPUT_DELTAS_SINGLE:
+   single_node = true; /* fall through */
case MXT_V4L_INPUT_DELTAS:
default:
mode = MXT_DIAGNOSTIC_DELTAS;
break;
 
+   case MXT_V4L_INPUT_REFS_SINGLE:
+   single_node = true; /* fall through */
case MXT_V4L_INPUT_REFS:
mode = MXT_DIAGNOSTIC_REFS;
break;
}
 
-   ret = mxt_read_diagnostic_debug(data, mode, ptr);
+   ret = mxt_read_diagnostic_debug(data, mode, ptr, single_node);
if (ret)
goto fault;
 
@@ -2360,6 +2378,12 @@ static int mxt_vidioc_enum_input(struct file *file, void 
*priv,
case MXT_V4L_INPUT_DELTAS:
strlcpy(i->name, "Mutual Deltas", sizeof(i->name));
break;
+   case MXT_V4L_INPUT_REFS_SINGLE:
+   strlcpy(i->name, "Single node refs", sizeof(i->name));
+   break;
+   case MXT_V4L_INPUT_DELTAS_SINGLE:
+   strlcpy(i->name, "Single node deltas", sizeof(i->name));
+   break;
}
 
return 0;
@@ -2372,8 +2396,20 @@ static int mxt_set_input(struct mxt_data *data, unsigned 
int i)
if (i >= MXT_V4L_INPUT_MAX)
return -EINVAL;
 
-   f->width = data->xy_switch ? data->ysize : data->xsize;
-   f->height = data->xy_switch ? data->xsize : data->ysize;
+   switch (i) {
+   case MXT_V4L_INPUT_REFS:
+   case MXT_V4L_INPUT_DELTAS:
+   f->width = data->xy_switch ? data->ysize : data->xsize;
+   f->height = data->xy_switch ? data->xsize : data->ysize;
+   break;
+
+   case MXT_V4L_INPUT_REFS_SINGLE:
+   case MXT_V4L_INPUT_DELTAS_SINGLE:
+   f->width = 1;
+   f->height = 1;
+   break;
+   }
+
f->pixelformat = V4L2_PIX_FMT_Y16;
f->field = V4L2_FIELD_NONE;
f->colorspace = V4L2_COLORSPACE_SRGB;
@@ -2426,11 +2462,21 @@ static int mxt_vidioc_enum_framesizes(struct file 
*file, void *priv,
 {
struct mxt_data *data = video_drvdata(file);
 
-   if (f->index > 0)
+   switch (f->index) {
+   case 0:
+   f->discrete.width = data->xy_switch ? data->ysize:data->xsize;
+   f->discrete.height = data->xy_switch ? data->xsize:data->ysize;
+   break;
+
+   case 1:
+   f->discrete.width = 1;
+   f->discrete.height = 1;
+   break;
+
+   default:
return 

[PATCH 3/8] Input: atmel_mxt_ts - read touchscreen size

[Nick Dyer]

The touchscreen may have a margin where not all the matrix is used. Read
the parameters from T9 and T100 and take account of the difference.

Note: this does not read the XORIGIN/YORIGIN fields so it assumes that
the touchscreen starts at (0,0)

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 47 ++--
 1 file changed, 39 insertions(+), 8 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 81eecf1..bcace51 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -103,6 +103,8 @@ struct t7_config {
 
 /* MXT_TOUCH_MULTI_T9 field */
 #define MXT_T9_CTRL0
+#define MXT_T9_XSIZE   3
+#define MXT_T9_YSIZE   4
 #define MXT_T9_ORIENT  9
 #define MXT_T9_RANGE   18
 
@@ -148,7 +150,9 @@ struct t37_debug {
 #define MXT_T100_CTRL  0
 #define MXT_T100_CFG1  1
 #define MXT_T100_TCHAUX3
+#define MXT_T100_XSIZE 9
 #define MXT_T100_XRANGE13
+#define MXT_T100_YSIZE 20
 #define MXT_T100_YRANGE24
 
 #define MXT_T100_CFG_SWITCHXY  BIT(5)
@@ -257,6 +261,8 @@ struct mxt_data {
unsigned int max_x;
unsigned int max_y;
bool xy_switch;
+   u8 xsize;
+   u8 ysize;
bool in_bootloader;
u16 mem_size;
u8 t100_aux_ampl;
@@ -1710,6 +1716,18 @@ static int mxt_read_t9_resolution(struct mxt_data *data)
return -EINVAL;
 
error = __mxt_read_reg(client,
+  object->start_address + MXT_T9_XSIZE,
+  sizeof(data->xsize), >xsize);
+   if (error)
+   return error;
+
+   error = __mxt_read_reg(client,
+  object->start_address + MXT_T9_YSIZE,
+  sizeof(data->ysize), >ysize);
+   if (error)
+   return error;
+
+   error = __mxt_read_reg(client,
   object->start_address + MXT_T9_RANGE,
   sizeof(range), );
if (error)
@@ -1759,6 +1777,18 @@ static int mxt_read_t100_config(struct mxt_data *data)
 
data->max_y = get_unaligned_le16(_y);
 
+   error = __mxt_read_reg(client,
+  object->start_address + MXT_T100_XSIZE,
+  sizeof(data->xsize), >xsize);
+   if (error)
+   return error;
+
+   error = __mxt_read_reg(client,
+  object->start_address + MXT_T100_YSIZE,
+  sizeof(data->ysize), >ysize);
+   if (error)
+   return error;
+
/* read orientation config */
error =  __mxt_read_reg(client,
object->start_address + MXT_T100_CFG1,
@@ -2116,7 +2146,7 @@ static int mxt_convert_debug_pages(struct mxt_data *data, 
u16 *outbuf)
outbuf[i] = mxt_get_debug_value(data, x, y);
 
/* Next value */
-   if (++x >= data->info.matrix_xsize) {
+   if (++x >= data->xsize) {
x = 0;
y++;
}
@@ -2280,8 +2310,8 @@ static int mxt_set_input(struct mxt_data *data, unsigned 
int i)
if (i > 0)
return -EINVAL;
 
-   f->width = data->info.matrix_xsize;
-   f->height = data->info.matrix_ysize;
+   f->width = data->xsize;
+   f->height = data->ysize;
f->pixelformat = V4L2_PIX_FMT_Y16;
f->field = V4L2_FIELD_NONE;
f->colorspace = V4L2_COLORSPACE_SRGB;
@@ -2337,8 +2367,8 @@ static int mxt_vidioc_enum_framesizes(struct file *file, 
void *priv,
if (f->index > 0)
return -EINVAL;
 
-   f->discrete.width = data->info.matrix_xsize;
-   f->discrete.height = data->info.matrix_ysize;
+   f->discrete.width = data->xsize;
+   f->discrete.height = data->ysize;
f->type = V4L2_FRMSIZE_TYPE_DISCRETE;
return 0;
 }
@@ -2411,9 +2441,10 @@ static void mxt_debug_init(struct mxt_data *data)
dbg->t37_address = object->start_address;
 
/* Calculate size of data and allocate buffer */
-   dbg->t37_nodes = data->info.matrix_xsize * data->info.matrix_ysize;
-   dbg->t37_pages = dbg->t37_nodes * sizeof(u16)
-   / sizeof(dbg->t37_buf->data) + 1;
+   dbg->t37_nodes = data->xsize * data->ysize;
+   dbg->t37_pages = ((data->xsize * data->info.matrix_ysize)
+ * sizeof(u16) / sizeof(dbg->t37_buf->data)) + 1;
+
 
dbg->t37_buf = devm_kzalloc(>client->dev,
 sizeof(struct t37_debug) * dbg->t37_pages,
-- 
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  

Re: [PATCHv4] [media] rcar-vin: add Renesas R-Car VIN driver

[Niklas Söderlund]

On 2016-04-21 08:55:46 +0200, Hans Verkuil wrote:
> On 04/12/2016 04:33 PM, Niklas Söderlund wrote:
> > +static void rect_set_min_size(struct v4l2_rect *r,
> > + const struct v4l2_rect *min_size)
> > +{
> > +   if (r->width < min_size->width)
> > +   r->width = min_size->width;
> > +   if (r->height < min_size->height)
> > +   r->height = min_size->height;
> > +}
> > +
> > +static void rect_set_max_size(struct v4l2_rect *r,
> > + const struct v4l2_rect *max_size)
> > +{
> > +   if (r->width > max_size->width)
> > +   r->width = max_size->width;
> > +   if (r->height > max_size->height)
> > +   r->height = max_size->height;
> > +}
> > +
> > +static void rect_map_inside(struct v4l2_rect *r,
> > +   const struct v4l2_rect *boundary)
> > +{
> > +   rect_set_max_size(r, boundary);
> > +
> > +   if (r->left < boundary->left)
> > +   r->left = boundary->left;
> > +   if (r->top < boundary->top)
> > +   r->top = boundary->top;
> > +   if (r->left + r->width > boundary->width)
> > +   r->left = boundary->width - r->width;
> > +   if (r->top + r->height > boundary->height)
> > +   r->top = boundary->height - r->height;
> > +}
> > +
> 
> The v4l2-rect.h helpers have been merged, so you should be able to use
> those for v5 and drop these functions here.

Thanks I'm about to send out a v5 so this was good timing. I did just 
discover one odd behavior in the driver I would like to look in to 
today. But will include the v4l2-rect.h helpers in v5.

-- 
Regards,
Niklas Söderlund
--
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/8] Input: atmel_mxt_ts - handle diagnostic data orientation

[Nick Dyer]

Invert the diagnostic data to match the orientation of the input device.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index bcace51..3dd312f 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -125,6 +125,8 @@ struct t9_range {
 
 /* MXT_TOUCH_MULTI_T9 orient */
 #define MXT_T9_ORIENT_SWITCH   (1 << 0)
+#define MXT_T9_ORIENT_INVERTX  (1 << 1)
+#define MXT_T9_ORIENT_INVERTY  (1 << 2)
 
 /* MXT_SPT_COMMSCONFIG_T18 */
 #define MXT_COMMS_CTRL 0
@@ -156,6 +158,8 @@ struct t37_debug {
 #define MXT_T100_YRANGE24
 
 #define MXT_T100_CFG_SWITCHXY  BIT(5)
+#define MXT_T100_CFG_INVERTY   BIT(6)
+#define MXT_T100_CFG_INVERTX   BIT(7)
 
 #define MXT_T100_TCHAUX_VECT   BIT(0)
 #define MXT_T100_TCHAUX_AMPL   BIT(1)
@@ -260,6 +264,8 @@ struct mxt_data {
unsigned int irq;
unsigned int max_x;
unsigned int max_y;
+   bool invertx;
+   bool inverty;
bool xy_switch;
u8 xsize;
u8 ysize;
@@ -1743,6 +1749,8 @@ static int mxt_read_t9_resolution(struct mxt_data *data)
return error;
 
data->xy_switch = orient & MXT_T9_ORIENT_SWITCH;
+   data->invertx = orient & MXT_T9_ORIENT_INVERTX;
+   data->inverty = orient & MXT_T9_ORIENT_INVERTY;
 
return 0;
 }
@@ -1797,6 +1805,8 @@ static int mxt_read_t100_config(struct mxt_data *data)
return error;
 
data->xy_switch = cfg & MXT_T100_CFG_SWITCHXY;
+   data->invertx = cfg & MXT_T100_CFG_INVERTX;
+   data->inverty = cfg & MXT_T100_CFG_INVERTY;
 
/* allocate aux bytes */
error =  __mxt_read_reg(client,
@@ -2140,13 +2150,19 @@ static int mxt_convert_debug_pages(struct mxt_data 
*data, u16 *outbuf)
struct mxt_dbg *dbg = >dbg;
unsigned int x = 0;
unsigned int y = 0;
-   unsigned int i;
+   unsigned int i, rx, ry;
 
for (i = 0; i < dbg->t37_nodes; i++) {
-   outbuf[i] = mxt_get_debug_value(data, x, y);
+   /* Handle orientation */
+   rx = data->xy_switch ? y : x;
+   ry = data->xy_switch ? x : y;
+   rx = data->invertx ? (data->xsize - 1 - rx) : rx;
+   ry = data->inverty ? (data->ysize - 1 - ry) : ry;
+
+   outbuf[i] = mxt_get_debug_value(data, rx, ry);
 
/* Next value */
-   if (++x >= data->xsize) {
+   if (++x >= (data->xy_switch ? data->ysize : data->xsize)) {
x = 0;
y++;
}
@@ -2310,8 +2326,8 @@ static int mxt_set_input(struct mxt_data *data, unsigned 
int i)
if (i > 0)
return -EINVAL;
 
-   f->width = data->xsize;
-   f->height = data->ysize;
+   f->width = data->xy_switch ? data->ysize : data->xsize;
+   f->height = data->xy_switch ? data->xsize : data->ysize;
f->pixelformat = V4L2_PIX_FMT_Y16;
f->field = V4L2_FIELD_NONE;
f->colorspace = V4L2_COLORSPACE_SRGB;
@@ -2367,8 +2383,8 @@ static int mxt_vidioc_enum_framesizes(struct file *file, 
void *priv,
if (f->index > 0)
return -EINVAL;
 
-   f->discrete.width = data->xsize;
-   f->discrete.height = data->ysize;
+   f->discrete.width = data->xy_switch ? data->ysize : data->xsize;
+   f->discrete.height = data->xy_switch ? data->xsize : data->ysize;
f->type = V4L2_FRMSIZE_TYPE_DISCRETE;
return 0;
 }
-- 
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

[PATCH 2/8] Input: atmel_mxt_ts - output diagnostic debug via v4l2 device

[Nick Dyer]

---
 drivers/input/touchscreen/atmel_mxt_ts.c | 270 +++
 1 file changed, 270 insertions(+)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 0784a18..81eecf1 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -28,6 +28,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 /* Firmware files */
 #define MXT_FW_NAME"maxtouch.fw"
@@ -222,6 +226,23 @@ struct mxt_dbg {
struct t37_debug *t37_buf;
unsigned int t37_pages;
unsigned int t37_nodes;
+
+   struct v4l2_device v4l2;
+   struct v4l2_pix_format format;
+   struct video_device vdev;
+   struct vb2_queue queue;
+   struct mutex lock;
+   int input;
+};
+
+static const struct v4l2_file_operations mxt_video_fops = {
+   .owner = THIS_MODULE,
+   .open = v4l2_fh_open,
+   .release = vb2_fop_release,
+   .unlocked_ioctl = video_ioctl2,
+   .read = vb2_fop_read,
+   .mmap = vb2_fop_mmap,
+   .poll = vb2_fop_poll,
 };
 
 /* Each client has this additional data */
@@ -277,6 +298,11 @@ struct mxt_data {
struct completion crc_completion;
 };
 
+struct mxt_vb2_buffer {
+   struct vb2_buffer   vb;
+   struct list_headlist;
+};
+
 static size_t mxt_obj_size(const struct mxt_object *obj)
 {
return obj->size_minus_one + 1;
@@ -1523,6 +1549,9 @@ static void mxt_free_input_device(struct mxt_data *data)
 
 static void mxt_free_object_table(struct mxt_data *data)
 {
+   video_unregister_device(>dbg.vdev);
+   v4l2_device_unregister(>dbg.v4l2);
+
kfree(data->object_table);
data->object_table = NULL;
kfree(data->msg_buf);
@@ -2154,10 +2183,215 @@ wait_cmd:
return mxt_convert_debug_pages(data, outbuf);
 }
 
+static int mxt_queue_setup(struct vb2_queue *q,
+  unsigned int *nbuffers, unsigned int *nplanes,
+  unsigned int sizes[], void *alloc_ctxs[])
+{
+   struct mxt_data *data = q->drv_priv;
+
+   *nbuffers = 1;
+   *nplanes = 1;
+   sizes[0] = data->dbg.t37_nodes * sizeof(u16);
+
+   return 0;
+}
+
+static int mxt_buffer_prepare(struct vb2_buffer *vb)
+{
+   return 0;
+}
+
+static void mxt_buffer_queue(struct vb2_buffer *vb)
+{
+   struct mxt_data *data = vb2_get_drv_priv(vb->vb2_queue);
+   u16 *ptr;
+   int ret;
+
+   ptr = vb2_plane_vaddr(vb, 0);
+   if (!ptr) {
+   dev_err(>client->dev, "Error acquiring frame ptr\n");
+   goto fault;
+   }
+
+   ret = mxt_read_diagnostic_debug(data, MXT_DIAGNOSTIC_DELTAS, ptr);
+   if (ret)
+   goto fault;
+
+   vb2_set_plane_payload(vb, 0, data->dbg.t37_nodes * sizeof(u16));
+   vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
+   return;
+
+fault:
+   vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
+}
+
+/* V4L2 structures */
+static const struct vb2_ops mxt_queue_ops = {
+   .queue_setup= mxt_queue_setup,
+   .buf_prepare= mxt_buffer_prepare,
+   .buf_queue  = mxt_buffer_queue,
+   .wait_prepare   = vb2_ops_wait_prepare,
+   .wait_finish= vb2_ops_wait_finish,
+};
+
+static const struct vb2_queue mxt_queue = {
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+   .io_modes = VB2_MMAP,
+   .buf_struct_size = sizeof(struct mxt_vb2_buffer),
+   .ops = _queue_ops,
+   .mem_ops = _vmalloc_memops,
+   .timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC,
+   .min_buffers_needed = 1,
+};
+
+static int mxt_vidioc_querycap(struct file *file, void *priv,
+struct v4l2_capability *cap)
+{
+   struct mxt_data *data = video_drvdata(file);
+
+   strlcpy(cap->driver, "atmel_mxt_ts", sizeof(cap->driver));
+   strlcpy(cap->card, "atmel_mxt_ts touch", sizeof(cap->card));
+   strlcpy(cap->bus_info, data->phys, sizeof(cap->bus_info));
+   cap->device_caps = V4L2_CAP_VIDEO_CAPTURE |
+   V4L2_CAP_READWRITE |
+   V4L2_CAP_STREAMING;
+   cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
+
+   return 0;
+}
+
+static int mxt_vidioc_enum_input(struct file *file, void *priv,
+  struct v4l2_input *i)
+{
+   if (i->index > 0)
+   return -EINVAL;
+
+   i->type = V4L2_INPUT_TYPE_CAMERA;
+   i->std = V4L2_STD_UNKNOWN;
+   i->capabilities = 0;
+   strlcpy(i->name, "Mutual References", sizeof(i->name));
+   return 0;
+}
+
+static int mxt_set_input(struct mxt_data *data, unsigned int i)
+{
+   struct v4l2_pix_format *f = >dbg.format;
+
+   if (i > 0)
+   return -EINVAL;
+
+   f->width = data->info.matrix_xsize;
+   f->height = data->info.matrix_ysize;
+   f->pixelformat = V4L2_PIX_FMT_Y16;
+   f->field = V4L2_FIELD_NONE;
+   

[PATCH 6/8] Input: atmel_mxt_ts - add support for reference data

[Nick Dyer]

There are different datatypes available from a maXTouch chip. Add
support to retrieve reference data as well.

Signed-off-by: Nick Dyer 
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 36 
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index bac0aa0..6a35d94 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -135,6 +135,7 @@ struct t9_range {
 /* MXT_DEBUG_DIAGNOSTIC_T37 */
 #define MXT_DIAGNOSTIC_PAGEUP 0x01
 #define MXT_DIAGNOSTIC_DELTAS 0x10
+#define MXT_DIAGNOSTIC_REFS   0x11
 #define MXT_DIAGNOSTIC_SIZE128
 
 #define MXT_FAMILY_1386160
@@ -247,6 +248,12 @@ struct mxt_dbg {
int input;
 };
 
+enum v4l_dbg_inputs {
+   MXT_V4L_INPUT_DELTAS,
+   MXT_V4L_INPUT_REFS,
+   MXT_V4L_INPUT_MAX,
+};
+
 static const struct v4l2_file_operations mxt_video_fops = {
.owner = THIS_MODULE,
.open = v4l2_fh_open,
@@ -2270,6 +2277,7 @@ static void mxt_buffer_queue(struct vb2_buffer *vb)
struct mxt_data *data = vb2_get_drv_priv(vb->vb2_queue);
u16 *ptr;
int ret;
+   u8 mode;
 
ptr = vb2_plane_vaddr(vb, 0);
if (!ptr) {
@@ -2277,7 +2285,18 @@ static void mxt_buffer_queue(struct vb2_buffer *vb)
goto fault;
}
 
-   ret = mxt_read_diagnostic_debug(data, MXT_DIAGNOSTIC_DELTAS, ptr);
+   switch (data->dbg.input) {
+   case MXT_V4L_INPUT_DELTAS:
+   default:
+   mode = MXT_DIAGNOSTIC_DELTAS;
+   break;
+
+   case MXT_V4L_INPUT_REFS:
+   mode = MXT_DIAGNOSTIC_REFS;
+   break;
+   }
+
+   ret = mxt_read_diagnostic_debug(data, mode, ptr);
if (ret)
goto fault;
 
@@ -2327,13 +2346,22 @@ static int mxt_vidioc_querycap(struct file *file, void 
*priv,
 static int mxt_vidioc_enum_input(struct file *file, void *priv,
   struct v4l2_input *i)
 {
-   if (i->index > 0)
+   if (i->index >= MXT_V4L_INPUT_MAX)
return -EINVAL;
 
i->type = V4L2_INPUT_TYPE_CAMERA;
i->std = V4L2_STD_UNKNOWN;
i->capabilities = 0;
-   strlcpy(i->name, "Mutual References", sizeof(i->name));
+
+   switch (i->index) {
+   case MXT_V4L_INPUT_REFS:
+   strlcpy(i->name, "Mutual References", sizeof(i->name));
+   break;
+   case MXT_V4L_INPUT_DELTAS:
+   strlcpy(i->name, "Mutual Deltas", sizeof(i->name));
+   break;
+   }
+
return 0;
 }
 
@@ -2341,7 +2369,7 @@ static int mxt_set_input(struct mxt_data *data, unsigned 
int i)
 {
struct v4l2_pix_format *f = >dbg.format;
 
-   if (i > 0)
+   if (i >= MXT_V4L_INPUT_MAX)
return -EINVAL;
 
f->width = data->xy_switch ? data->ysize : data->xsize;
-- 
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

[PATCH 0/8] Input: atmel_mxt_ts - output raw touch diagnostic data via V4L

[Nick Dyer]

This is a series of patches to add diagnostic data support to the Atmel
maXTouch driver. It's a rewrite of the previous implementation which output via
debugfs: it now uses a V4L2 device in a similar way to the sur40 driver.

There are significant performance advantages to putting this code into the
driver. The algorithm for retrieving the data has been fairly consistent across
a range of chips, with the exception of the mXT1386 series (see patch).

We have a utility which can read the data and display it in a useful format:
https://github.com/ndyer/heatmap/commits/heatmap-v4l

These patches are also available from
https://github.com/ndyer/linux/commits/diagnostic-v4l

Any feedback appreciated.

--
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: vb2: Fix regression on poll() for RW mode

[Ricardo Ribalda Delgado]

When using a device is read/write mode, vb2 does not handle properly the
first select/poll operation. It allways return POLLERR.

The reason for this is that when this code has been refactored, some of
the operations have changed their order, and now fileio emulator is not
started by poll, due to a previous check.

Reported-by: Dimitrios Katsaros 
Cc: Junghak Sung 
Cc: sta...@vger.kernel.org
Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/v4l2-core/videobuf2-core.c | 8 
 drivers/media/v4l2-core/videobuf2-v4l2.c | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 5d016f496e0e..199c65dbe330 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2298,6 +2298,14 @@ unsigned int vb2_core_poll(struct vb2_queue *q, struct 
file *file,
return POLLERR;
 
/*
+* For compatibility with vb1: if QBUF hasn't been called yet, then
+* return POLLERR as well. This only affects capture queues, output
+* queues will always initialize waiting_for_buffers to false.
+*/
+   if (q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
+   return POLLERR;
+
+   /*
 * For output streams you can call write() as long as there are fewer
 * buffers queued than there are buffers available.
 */
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 91f552124050..c9bad9ef2104 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -818,14 +818,6 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file 
*file, poll_table *wait)
poll_wait(file, >wait, wait);
}
 
-   /*
-* For compatibility with vb1: if QBUF hasn't been called yet, then
-* return POLLERR as well. This only affects capture queues, output
-* queues will always initialize waiting_for_buffers to false.
-*/
-   if (q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
-   return POLLERR;
-
return res | vb2_core_poll(q, file, wait);
 }
 EXPORT_SYMBOL_GPL(vb2_poll);
-- 
2.8.0.rc3

--
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 1/2] v4l: Add meta-data video device type

[Sakari Ailus]

Hi Laurent,

Thanks for the set!

On Thu, Apr 21, 2016 at 03:40:26AM +0300, Laurent Pinchart wrote:
> The meta-data video device is used to transfer meta-data between
> userspace and kernelspace through a V4L2 buffers queue. It comes with a
> new meta-data capture capability, buffer type and format description.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  Documentation/DocBook/media/v4l/dev-meta.xml  | 100 
> ++
>  Documentation/DocBook/media/v4l/v4l2.xml  |   1 +
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  19 +
>  drivers/media/v4l2-core/v4l2-dev.c|  21 +-
>  drivers/media/v4l2-core/v4l2-ioctl.c  |  39 ++
>  drivers/media/v4l2-core/videobuf2-v4l2.c  |   3 +
>  include/media/v4l2-dev.h  |   3 +-
>  include/media/v4l2-ioctl.h|   8 +++
>  include/uapi/linux/media.h|   2 +
>  include/uapi/linux/videodev2.h|  14 
>  10 files changed, 208 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/DocBook/media/v4l/dev-meta.xml
> 
> diff --git a/Documentation/DocBook/media/v4l/dev-meta.xml 
> b/Documentation/DocBook/media/v4l/dev-meta.xml
> new file mode 100644
> index ..ddc685186015
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/dev-meta.xml
> @@ -0,0 +1,100 @@
> +  Meta-Data Interface

I propose:

s/-/ /

> +
> +  
> +Experimental
> +This is an  experimental 
> +interface and may change in the future.
> +  
> +
> +  
> +Meta-data refers to any non-image data that supplements video frames with
> +additional information. This may include statistics computed over the image
> +or frame capture parameters supplied by the image source. This interface is
> +intended for transfer of meta-data to userspace and control of that 
> operation.

Ditto.

> +  
> +
> +  
> +Meta-data devices are accessed through character device special files named
> +/dev/v4l-meta0 to /dev/v4l-meta255
> +with major number 81 and dynamically allocated minor numbers 0 to 255.

Where does 255 come from? At least in kernel the minor number space has got
20 bits, not 8. Not that I prefer having that many meta data nodes, but
still that's a possibility.

> +  
> +
> +  
> +Querying Capabilities
> +
> +
> +Devices supporting the meta-data interface set the
> +V4L2_CAP_META_CAPTURE flag in the
> +capabilities field of 
> +returned by the  ioctl. That flag means the device can 
> capture
> +meta-data to memory.
> +
> +
> +At least one of the read/write, streaming or asynchronous I/O methods must
> +be supported.
> +
> +  
> +
> +  
> +Data Format Negotiation
> +
> +
> +The meta-data device uses the format ioctls to
> +select the capture format. The meta-data buffer content format is bound to 
> that
> +selectable format. In addition to the basic
> +format ioctls, the  ioctl
> +must be supported as well.
> +
> +
> +
> +To use the format ioctls applications set the
> +type field of a  to
> +V4L2_BUF_TYPE_META_CAPTURE and use the 
> 
> +meta member of the fmt
> +union as needed per the desired operation.
> +Currently there are two fields, pixelformat and
> +buffersize, of struct  that are
> +used. Content of the pixelformat is the V4L2 
> FourCC
> +code of the data format. The buffersize field is 
> the
> +maximum buffer size in bytes required for data transfer, set by the driver in
> +order to inform applications.
> +
> +
> +
> +  struct v4l2_meta_format
> +  
> +
> +
> +  
> +__u32
> +pixelformat
> +
> +The data format or type of compression, set by the application. This is a
> +little endian four character code.
> +V4L2 defines meta-data formats in .
> +   
> +  
> +  
> +__u32
> +buffersize
> +
> +Maximum size in bytes required for data. Value is set by the driver.
> +   
> +  
> +  
> +__u8
> +reserved[24]
> +This array is reserved for future extensions.
> +Drivers and applications must set it to zero.

200 bytes is reserved for this struct in all IOCTLs. How about using closer
to that amount? 24 bytes of reserved space isn't much. Albeit you could
argue that this struct could be changed later on as it does not affect IOCTL
argument size.

> +  
> +
> +  
> +
> +
> +
> +A meta-data device may support read/write
> +and/or streaming (memory mapping
> +or user pointer) I/O.
> +
> +
> +  
> diff --git a/Documentation/DocBook/media/v4l/v4l2.xml 
> b/Documentation/DocBook/media/v4l/v4l2.xml
> index 42e626d6c936..5c83b5d342dd 100644
> --- a/Documentation/DocBook/media/v4l/v4l2.xml
> +++ b/Documentation/DocBook/media/v4l/v4l2.xml
> @@ -605,6 +605,7 @@ and discussions on the V4L mailing list.
>
>
>
> +  
>
>
>
> 

Re: [PATCHv4] [media] rcar-vin: add Renesas R-Car VIN driver

[Hans Verkuil]

On 04/12/2016 04:33 PM, Niklas Söderlund wrote:
> +static void rect_set_min_size(struct v4l2_rect *r,
> +   const struct v4l2_rect *min_size)
> +{
> + if (r->width < min_size->width)
> + r->width = min_size->width;
> + if (r->height < min_size->height)
> + r->height = min_size->height;
> +}
> +
> +static void rect_set_max_size(struct v4l2_rect *r,
> +   const struct v4l2_rect *max_size)
> +{
> + if (r->width > max_size->width)
> + r->width = max_size->width;
> + if (r->height > max_size->height)
> + r->height = max_size->height;
> +}
> +
> +static void rect_map_inside(struct v4l2_rect *r,
> + const struct v4l2_rect *boundary)
> +{
> + rect_set_max_size(r, boundary);
> +
> + if (r->left < boundary->left)
> + r->left = boundary->left;
> + if (r->top < boundary->top)
> + r->top = boundary->top;
> + if (r->left + r->width > boundary->width)
> + r->left = boundary->width - r->width;
> + if (r->top + r->height > boundary->height)
> + r->top = boundary->height - r->height;
> +}
> +

The v4l2-rect.h helpers have been merged, so you should be able to use
those for v5 and drop these functions here.

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

[PATCH 2/2] tw686x-video: test for 60Hz instead of 50Hz

[Hans Verkuil]

From: Hans Verkuil 

When determining if the standard is 50 or 60 Hz it is standard
practice to test for 60 Hz instead of 50 Hz.

This doesn't matter normally, except if the user specifies both
60 and 50 Hz standards.

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

diff --git a/drivers/media/pci/tw686x/tw686x-video.c 
b/drivers/media/pci/tw686x/tw686x-video.c
index 9a31de9..9cfee0a 100644
--- a/drivers/media/pci/tw686x/tw686x-video.c
+++ b/drivers/media/pci/tw686x/tw686x-video.c
@@ -25,7 +25,7 @@
 
 #define TW686X_INPUTS_PER_CH   4
 #define TW686X_VIDEO_WIDTH 720
-#define TW686X_VIDEO_HEIGHT(id)((id & V4L2_STD_625_50) ? 576 : 
480)
+#define TW686X_VIDEO_HEIGHT(id)((id & V4L2_STD_525_60) ? 480 : 
576)
 
 static const struct tw686x_format formats[] = {
{
@@ -518,10 +518,10 @@ static int tw686x_s_std(struct file *file, void *priv, 
v4l2_std_id id)
reg_write(vc->dev, SDT[vc->ch], val);
 
val = reg_read(vc->dev, VIDEO_CONTROL1);
-   if (id & V4L2_STD_625_50)
-   val |= (1 << (SYS_MODE_DMA_SHIFT + vc->ch));
-   else
+   if (id & V4L2_STD_525_60)
val &= ~(1 << (SYS_MODE_DMA_SHIFT + vc->ch));
+   else
+   val |= (1 << (SYS_MODE_DMA_SHIFT + vc->ch));
reg_write(vc->dev, VIDEO_CONTROL1, val);
 
/*
-- 
2.8.0.rc3

--
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/2] tw686x: fix sparse warning

[Hans Verkuil]

From: Hans Verkuil 

tw686x-video.c: In function 'tw686x_video_init':
tw686x-video.c:65:543: warning: array subscript is above array bounds 
[-Warray-bounds]

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

diff --git a/drivers/media/pci/tw686x/tw686x-video.c 
b/drivers/media/pci/tw686x/tw686x-video.c
index 118e9fa..9a31de9 100644
--- a/drivers/media/pci/tw686x/tw686x-video.c
+++ b/drivers/media/pci/tw686x/tw686x-video.c
@@ -60,10 +60,11 @@ static unsigned int tw686x_fields_map(v4l2_std_id std, 
unsigned int fps)
0, 1, 1, 1, 2,  2,  3,  3,  4,  4,  5,  5,  6,  6, 7, 7,
   8, 8, 9, 9, 10, 10, 11, 11, 12, 12, 13, 13, 14, 0, 0
};
+   unsigned int max_fps = (std & V4L2_STD_525_60) ? 30 : 25;
+   unsigned int i;
 
-   unsigned int i =
-   (std & V4L2_STD_625_50) ? std_625_50[fps] : std_525_60[fps];
-
+   fps = fps > max_fps ? max_fps : fps;
+   i = (std & V4L2_STD_525_60) ? std_625_50[fps] : std_525_60[fps];
return map[i];
 }
 
-- 
2.8.0.rc3

--
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 1/2] v4l: Add meta-data video device type

[Hans Verkuil]

Hi Laurent,

Thanks for the patch!

Some, mostly small, comments follow:

On 04/21/2016 02:40 AM, Laurent Pinchart wrote:
> The meta-data video device is used to transfer meta-data between
> userspace and kernelspace through a V4L2 buffers queue. It comes with a
> new meta-data capture capability, buffer type and format description.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  Documentation/DocBook/media/v4l/dev-meta.xml  | 100 
> ++
>  Documentation/DocBook/media/v4l/v4l2.xml  |   1 +
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  19 +
>  drivers/media/v4l2-core/v4l2-dev.c|  21 +-
>  drivers/media/v4l2-core/v4l2-ioctl.c  |  39 ++
>  drivers/media/v4l2-core/videobuf2-v4l2.c  |   3 +
>  include/media/v4l2-dev.h  |   3 +-
>  include/media/v4l2-ioctl.h|   8 +++
>  include/uapi/linux/media.h|   2 +
>  include/uapi/linux/videodev2.h|  14 
>  10 files changed, 208 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/DocBook/media/v4l/dev-meta.xml
> 
> diff --git a/Documentation/DocBook/media/v4l/dev-meta.xml 
> b/Documentation/DocBook/media/v4l/dev-meta.xml
> new file mode 100644
> index ..ddc685186015
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/dev-meta.xml
> @@ -0,0 +1,100 @@
> +  Meta-Data Interface
> +
> +  
> +Experimental
> +This is an  experimental 
> +interface and may change in the future.
> +  
> +
> +  
> +Meta-data refers to any non-image data that supplements video frames with
> +additional information. This may include statistics computed over the image
> +or frame capture parameters supplied by the image source. This interface is
> +intended for transfer of meta-data to userspace and control of that 
> operation.
> +  
> +
> +  
> +Meta-data devices are accessed through character device special files named
> +/dev/v4l-meta0 to /dev/v4l-meta255
> +with major number 81 and dynamically allocated minor numbers 0 to 255.
> +  
> +
> +  
> +Querying Capabilities
> +
> +
> +Devices supporting the meta-data interface set the
> +V4L2_CAP_META_CAPTURE flag in the
> +capabilities field of 
> +returned by the  ioctl. That flag means the device can 
> capture
> +meta-data to memory.
> +
> +
> +At least one of the read/write, streaming or asynchronous I/O methods must

I think we can drop 'asynchronous I/O' since that's never been used. I assume
this is copy-and-pasted and we should probably just remove any reference to
async IO.

> +be supported.
> +
> +  
> +
> +  
> +Data Format Negotiation
> +
> +
> +The meta-data device uses the format ioctls to
> +select the capture format. The meta-data buffer content format is bound to 
> that
> +selectable format. In addition to the basic
> +format ioctls, the  ioctl
> +must be supported as well.
> +
> +
> +
> +To use the format ioctls applications set the
> +type field of a  to
> +V4L2_BUF_TYPE_META_CAPTURE and use the 
> 
> +meta member of the fmt
> +union as needed per the desired operation.
> +Currently there are two fields, pixelformat and

Shouldn't that be metaformat? Since there are no pixels here? It was a bit 
dubious
to call it pixelformat for SDR as well, but at least there you still have 
discrete
samples which might be called pixels with some imagination. But certainly 
doesn't
apply to meta data.

> +buffersize, of struct  that are
> +used. Content of the pixelformat is the V4L2 
> FourCC
> +code of the data format. The buffersize field is 
> the
> +maximum buffer size in bytes required for data transfer, set by the driver in
> +order to inform applications.
> +
> +
> +
> +  struct v4l2_meta_format
> +  
> +
> +
> +  
> +__u32
> +pixelformat
> +
> +The data format or type of compression, set by the application. This is a
> +little endian four character code.
> +V4L2 defines meta-data formats in .
> +   
> +  
> +  
> +__u32
> +buffersize
> +
> +Maximum size in bytes required for data. Value is set by the driver.
> +   
> +  
> +  
> +__u8
> +reserved[24]
> +This array is reserved for future extensions.
> +Drivers and applications must set it to zero.
> +  
> +
> +  
> +
> +
> +
> +A meta-data device may support read/write
> +and/or streaming (memory mapping
> +or user pointer) I/O.

Add dma-buf to this as well, or just say "streaming I/O" without listing
the possibilities. If this is copied-and-pasted, then the same should be
done in the original.

> +
> +
> +  
> diff --git a/Documentation/DocBook/media/v4l/v4l2.xml 
> b/Documentation/DocBook/media/v4l/v4l2.xml
> index 42e626d6c936..5c83b5d342dd 100644
> --- a/Documentation/DocBook/media/v4l/v4l2.xml

Direct Cash Loan Offer At Fixed 3.5% Interest Rate

[Direct Cash Loan SA]

Dear Valued Client,



   We are currently giving out loans at 3.5% interest rate,Kindly find attached 
documents for more information about our offer and send

your details to : infodirec...@fastservice.com



Regards,


Direct Cash Loans Team

Email :infodirec...@fastservice.com



Direct Cash Loan Low Rate Offer.docx
Description: MS-Word 2007 document