Re: [PATCH v7 6/8] [media] vcodec: mediatek: Add Mediatek VP8 Video Encoder Driver
Hi,
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.6-rc4 next-20160421]
[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/Tiffany-Lin/Add-MT8173-Video-Encoder-Driver-and-VPU-Driver/20160422-123111
base: git://linuxtv.org/media_tree.git master
config: xtensa-allmodconfig (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=xtensa
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:13:0,
from include/linux/interrupt.h:5,
from
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:17:
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c: In function
'vp8_enc_alloc_work_buf':
>> drivers/media/platform/mtk-vcodec/venc/../mtk_vcodec_util.h:56:14: warning:
>> format '%lx' expects argument of type 'long unsigned int', but argument 7
>> has type 'size_t' [-Wformat=]
((struct mtk_vcodec_ctx *)h->ctx)->idx, \
^
include/linux/printk.h:259:34: note: in definition of macro 'pr_info'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:214:3: note: in
expansion of macro 'mtk_vcodec_debug'
mtk_vcodec_debug(inst,
^
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c: In function
'vp8_enc_compose_one_frame':
>> drivers/media/platform/mtk-vcodec/venc/../mtk_vcodec_util.h:62:18: warning:
>> format '%ld' expects argument of type 'long int', but argument 4 has type
>> 'size_t' [-Wformat=]
((struct mtk_vcodec_ctx *)h->ctx)->idx, __func__, ##args)
^
include/linux/printk.h:252:33: note: in definition of macro 'pr_err'
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:279:3: note: in
expansion of macro 'mtk_vcodec_err'
mtk_vcodec_err(inst, "bitstream buf size is too small(%ld)",
^
vim +56 drivers/media/platform/mtk-vcodec/venc/../mtk_vcodec_util.h
67e5508b Tiffany Lin 2016-04-22 50 #define mtk_v4l2_debug_leave()
mtk_v4l2_debug(3, "-")
67e5508b Tiffany Lin 2016-04-22 51
67e5508b Tiffany Lin 2016-04-22 52 #define mtk_vcodec_debug(h, fmt, args...)
\
67e5508b Tiffany Lin 2016-04-22 53 do {
\
67e5508b Tiffany Lin 2016-04-22 54 if (mtk_vcodec_dbg)
\
67e5508b Tiffany Lin 2016-04-22 55
pr_info("[MTK_VCODEC][%d]: %s() " fmt "\n", \
67e5508b Tiffany Lin 2016-04-22 @56 ((struct
mtk_vcodec_ctx *)h->ctx)->idx, \
67e5508b Tiffany Lin 2016-04-22 57 __func__,
##args); \
67e5508b Tiffany Lin 2016-04-22 58 } while (0)
67e5508b Tiffany Lin 2016-04-22 59
67e5508b Tiffany Lin 2016-04-22 60 #define mtk_vcodec_err(h, fmt, args...)
\
67e5508b Tiffany Lin 2016-04-22 61 pr_err("[MTK_VCODEC][ERROR][%d]: %s() "
fmt "\n", \
67e5508b Tiffany Lin 2016-04-22 @62((struct mtk_vcodec_ctx
*)h->ctx)->idx, __func__, ##args)
67e5508b Tiffany Lin 2016-04-22 63
67e5508b Tiffany Lin 2016-04-22 64 #define mtk_vcodec_debug_enter(h)
mtk_vcodec_debug(h, "+")
67e5508b Tiffany Lin 2016-04-22 65 #define mtk_vcodec_debug_leave(h)
mtk_vcodec_debug(h, "-")
:: The code at line 56 was first introduced by commit
:: 67e5508b437349a82c1a884f6abf3aaa434959e5 vcodec: mediatek: Add Mediatek
V4L2 Video Encoder Driver
:: TO: Tiffany Lin
:: CC: 0day robot
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
[PATCH v7 8/8] arm64: dts: mediatek: Add Video Encoder for MT8173
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 = <&larb3>,
+ <&larb5>;
+ iommus = <&iommu M4U_PORT_VENC_RCPU>,
+<&iommu M4U_PORT_VENC_REC>,
+<&iommu M4U_PORT_VENC_BSDMA>,
+<&iommu M4U_PORT_VENC_SV_COMV>,
+<&iommu M4U_PORT_VENC_RD_COMV>,
+<&iommu M4U_PORT_VENC_CUR_LUMA>,
+<&iommu M4U_PORT_VENC_CUR_CHROMA>,
+<&iommu M4U_PORT_VENC_REF_LUMA>,
+<&iommu M4U_PORT_VENC_REF_CHROMA>,
+<&iommu M4U_PORT_VENC_NBM_RDMA>,
+<&iommu M4U_PORT_VENC_NBM_WDMA>,
+<&iommu M4U_PORT_VENC_RCPU_SET2>,
+<&iommu M4U_PORT_VENC_REC_FRM_SET2>,
+<&iommu M4U_PORT_VENC_BSDMA_SET2>,
+<&iommu M4U_PORT_VENC_SV_COMA_SET2>,
+<&iommu M4U_PORT_VENC_RD_COMA_SET2>,
+<&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
+<&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
+<&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
+<&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
+ mediatek,vpu = <&vpu>;
+ clocks = <&topckgen CLK_TOP_VENCPLL_D2>,
+<&topckgen CLK_TOP_VENC_SEL>,
+<&topckgen CLK_TOP_UNIVPLL1_D2>,
+<&topckgen 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
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 = <&topckgen 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
== 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
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 = <&larb3>,
+ <&larb5>;
+iommus = <&iommu M4U_PORT_VENC_RCPU>,
+ <&iommu M4U_PORT_VENC_REC>,
+ <&iommu M4U_PORT_VENC_BSDMA>,
+ <&iommu M4U_PORT_VENC_SV_COMV>,
+ <&iommu M4U_PORT_VENC_RD_COMV>,
+ <&iommu M4U_PORT_VENC_CUR_LUMA>,
+ <&iommu M4U_PORT_VENC_CUR_CHROMA>,
+ <&iommu M4U_PORT_VENC_REF_LUMA>,
+ <&iommu M4U_PORT_VENC_REF_CHROMA>,
+ <&iommu M4U_PORT_VENC_NBM_RDMA>,
+ <&iommu M4U_PORT_VENC_NBM_WDMA>,
+ <&iommu M4U_PORT_VENC_RCPU_SET2>,
+ <&iommu M4U_PORT_VENC_REC_FRM_SET2>,
+ <&iommu M4U_PORT_VENC_BSDMA_SET2>,
+ <&iommu M4U_PORT_VENC_SV_COMA_SET2>,
+ <&iommu M4U_PORT_VENC_RD_COMA_SET2>,
+ <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
+ <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
+ <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
+ <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
+mediatek,vpu = <&vpu>;
+clocks = <&topckgen CLK_TOP_VENCPLL_D2>,
+ <&topckgen CLK_TOP_VENC_SEL>,
+ <&topckgen CLK_TOP_UNIVPLL1_D2>,
+ <&topckgen 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
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 = <&gic>;
@@ -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 = <&topckgen CLK_TOP_SCP_SEL>;
+ clock-names = "main";
+ memory-region = <&vpu_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
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 VPU_D_FW "vpu_d.bin" + +#define VPU_RESET 0x0 +#define VPU_TCM_CFG0x0008 +#define
[PATCH v7 7/8] [media] vcodec: mediatek: Add Mediatek H264 Video Encoder Driver
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' field here for
+ * register setting in VPU side.
+ * @sizeimage: image size for each plane
+ */
+struct venc_h264_vsi {
+ struct v
[PATCH v7 5/8] [media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver
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 it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied wa
[PATCH v7 6/8] [media] vcodec: mediatek: Add Mediatek VP8 Video Encoder Driver
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 work_bufs here is for storing the 'size' info shared to AP side.
+ * The similar item in struct venc_vp8
cron job: media_tree daily build: WARNINGS
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
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 &v4l2-capability; > > > +returned by the &VIDIOC-QUERYCAP; 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 &VIDIOC-ENUM-FMT; ioctl > > > +must be supported as well. > > > + > > > + > > > + > > > +To use the format ioctls applications set > > > the +type field of a &v4l2-format; to > > > +V4L2_BUF_TYPE_META_CAPTURE and use the > > > &v4l2-meta-format; +meta member of the > > > fmt +union as needed per the desired > > > operation. > > > +Currently there are two fields, pixelformat > > > and > > > +buffersize, of struct &v4l2-meta-format; 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 > > > + > > > +&cs-str; > > > + > > > + > > > +__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 byte
[PATCH/RFC] dvb-core: drop stubs for llseek()
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
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, &src, &dst);
> > + vsp1_du_atomic_update_zpos(plane->vsp->vsp, plane->index, pixelformat,
> > + fb->pitches[0], paddr, &src, &dst,
> > + 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->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->plane.base,
> >
> >rcdu->props.alpha, 255);
> >
> > + drm_object_attach_property(&plane->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 line "un
Re: [PATCH 0/2] Renesas R-Car Gen3 DU alpha and z-order support
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
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 &v4l2-capability; > > +returned by the &VIDIOC-QUERYCAP; 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 &VIDIOC-ENUM-FMT; ioctl > > +must be supported as well. > > + > > + > > + > > +To use the format ioctls applications set > > the +type field of a &v4l2-format; to > > +V4L2_BUF_TYPE_META_CAPTURE and use the > > &v4l2-meta-format; +meta member of the > > fmt +union as needed per the desired > > operation. > > +Currently there are two fields, pixelformat > > and > > +buffersize, of struct &v4l2-meta-format; 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 > > + > > +&cs-str; > > + > > + > > +__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 o
Re: [PATCH/RFC 1/2] v4l: Add meta-data video device type
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 &v4l2-capability; > > +returned by the &VIDIOC-QUERYCAP; 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 &VIDIOC-ENUM-FMT; ioctl > > +must be supported as well. > > + > > + > > + > > +To use the format ioctls applications set > > the +type field of a &v4l2-format; to > > +V4L2_BUF_TYPE_META_CAPTURE and use the > > &v4l2-meta-format; +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 &v4l2-meta-format; 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 > > + > > +&cs-str; > > + > > + > > +__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
Re: [PATCH 2/2] tw686x-video: test for 60Hz instead of 50Hz
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
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
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, &msg[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 :
true;
+ } else {
+ switc
Re: [PATCH 1/2] drm: rcar-du: Add Z-order support for VSP planes
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, &src, &dst);
> + vsp1_du_atomic_update_zpos(plane->vsp->vsp, plane->index, pixelformat,
> +fb->pitches[0], paddr, &src, &dst,
> +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->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->plane.base,
> rcdu->props.alpha, 255);
> + drm_object_attach_property(&plane->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
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
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: test second video open: OK
Re: [PATCH v7 00/24] i2c mux cleanup and locking update
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
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
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(&data->dbg.vdev);
> 1553 v4l2_device_unregister(&data->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
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
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(&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
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, &b, 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
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 > >http://www.spinics.net/lists/linux-media/msg67295.html>), 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
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')
> +&manvol;
> +
> +
> +
> + 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
> + max(R,G,B) bin 0 [31:0]
> +
> +
[PATCH 5/8] Input: atmel_mxt_ts - add diagnostic data support for mXT1386
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 = &data->info;
struct mxt_dbg *dbg = &data->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(&dbg->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 = &data->info;
struct mxt_dbg *dbg = &data->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(&data->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
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 = &data->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(&dbg->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:
[PATCH 1/8] Input: atmel_mxt_ts - add support for T37 diagnostic data
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 = &data->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(&dbg->t37_buf[page].data[ofs]);
+}
+
+static int mxt_convert_debug_pages(struct mxt_data *data, u16 *outbuf)
+{
+ struct mxt_dbg *dbg = &data->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 = &data->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), &cmd_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(&data->client->dev, "T37 page mismatch\n");
+ return -EINVAL;
+ }
+
+ dev_dbg(&data->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 = &data->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(&data->client->dev, "Bad T37 size");
+ return;
+ }
+
[PATCH 8/8] Input: atmel_mxt_ts - add v4l pixelformat definition for touch refs output
---
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 3/8] Input: atmel_mxt_ts - read touchscreen size
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), &data->xsize);
+ if (error)
+ return error;
+
+ error = __mxt_read_reg(client,
+ object->start_address + MXT_T9_YSIZE,
+ sizeof(data->ysize), &data->ysize);
+ if (error)
+ return error;
+
+ error = __mxt_read_reg(client,
object->start_address + MXT_T9_RANGE,
sizeof(range), &range);
if (error)
@@ -1759,6 +1777,18 @@ static int mxt_read_t100_config(struct mxt_data *data)
data->max_y = get_unaligned_le16(&range_y);
+ error = __mxt_read_reg(client,
+ object->start_address + MXT_T100_XSIZE,
+ sizeof(data->xsize), &data->xsize);
+ if (error)
+ return error;
+
+ error = __mxt_read_reg(client,
+ object->start_address + MXT_T100_YSIZE,
+ sizeof(data->ysize), &data->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(&data->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 majordo
Re: [PATCHv4] [media] rcar-vin: add Renesas R-Car VIN driver
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
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 = &data->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
---
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(&data->dbg.vdev);
+ v4l2_device_unregister(&data->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(&data->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 = &mxt_queue_ops,
+ .mem_ops = &vb2_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 = &data->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->fi
[PATCH 6/8] Input: atmel_mxt_ts - add support for reference data
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 = &data->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
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
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, &fh->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
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 &v4l2-capability; > +returned by the &VIDIOC-QUERYCAP; 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 &VIDIOC-ENUM-FMT; ioctl > +must be supported as well. > + > + > + > +To use the format ioctls applications set the > +type field of a &v4l2-format; to > +V4L2_BUF_TYPE_META_CAPTURE and use the > &v4l2-meta-format; > +meta member of the fmt > +union as needed per the desired operation. > +Currently there are two fields, pixelformat and > +buffersize, of struct &v4l2-meta-format; 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 > + > +&cs-str; > + > + > +__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. >
