Re: [PATCH v6 1/2] [media] atmel-isc: add the Image Sensor Controller code
On 07/22/2016 07:18 AM, Wu, Songjun wrote: >>> +/* >>> + * index(0~11): raw formats. >>> + * index(12~12): the formats which can be converted from raw format by ISC. >>> + * index(): the formats which can only be provided by subdev. >>> + */ >>> +static struct isc_format isc_formats[] = { >> >> static const >> > Some members in structure isc_format need be modified, so it can not be > const. OK. Please add a comment about that. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] dt-bindings: Add a binding for Mediatek MDP
Add a DT binding documentation of MDP for the MT8173 SoC from Mediatek Signed-off-by: Minghsiu Tsai --- .../devicetree/bindings/media/mediatek-mdp.txt | 96 1 file changed, 96 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/mediatek-mdp.txt diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt new file mode 100644 index 000..2dad031 --- /dev/null +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt @@ -0,0 +1,96 @@ +* Mediatek Media Data Path + +Media Data Path is used for scaling and color space conversion. + +Required properties (all function blocks): +- compatible: "mediatek,-mdp" +"mediatek,-mdp-", one of +"mediatek,-mdp-rdma" - read DMA +"mediatek,-mdp-rsz" - resizer +"mediatek,-mdp-wdma" - write DMA +"mediatek,-mdp-wrot" - write DMA with rotation +- reg: Physical base address and length of the function block register space +- clocks: device clocks +- power-domains: a phandle to the power domain. +- mediatek,vpu: the node of video processor unit + +Required properties (DMA function blocks): +- compatible: Should be one of +"mediatek,-mdp-rdma" +"mediatek,-mdp-wdma" +"mediatek,-mdp-wrot" +- iommus: should point to the respective IOMMU block with master port as + argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt + for details. +- mediatek,larb: must contain the local arbiters in the current Socs. + +Example: + mdp_rdma0: rdma@14001000 { + compatible = "mediatek,mt8173-mdp-rdma", +"mediatek,mt8173-mdp"; + reg = <0 0x14001000 0 0x1000>; + clocks = <&mmsys CLK_MM_MDP_RDMA0>, +<&mmsys CLK_MM_MUTEX_32K>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + iommus = <&iommu M4U_PORT_MDP_RDMA0>; + mediatek,larb = <&larb0>; + mediatek,vpu = <&vpu>; + }; + + mdp_rdma1: rdma@14002000 { + compatible = "mediatek,mt8173-mdp-rdma"; + reg = <0 0x14002000 0 0x1000>; + clocks = <&mmsys CLK_MM_MDP_RDMA1>, +<&mmsys CLK_MM_MUTEX_32K>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + iommus = <&iommu M4U_PORT_MDP_RDMA1>; + mediatek,larb = <&larb4>; + }; + + mdp_rsz0: rsz@14003000 { + compatible = "mediatek,mt8173-mdp-rsz"; + reg = <0 0x14003000 0 0x1000>; + clocks = <&mmsys CLK_MM_MDP_RSZ0>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + }; + + mdp_rsz1: rsz@14004000 { + compatible = "mediatek,mt8173-mdp-rsz"; + reg = <0 0x14004000 0 0x1000>; + clocks = <&mmsys CLK_MM_MDP_RSZ1>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + }; + + mdp_rsz2: rsz@14005000 { + compatible = "mediatek,mt8173-mdp-rsz"; + reg = <0 0x14005000 0 0x1000>; + clocks = <&mmsys CLK_MM_MDP_RSZ2>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + }; + + mdp_wdma0: wdma@14006000 { + compatible = "mediatek,mt8173-mdp-wdma"; + reg = <0 0x14006000 0 0x1000>; + clocks = <&mmsys CLK_MM_MDP_WDMA>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + iommus = <&iommu M4U_PORT_MDP_WDMA>; + mediatek,larb = <&larb0>; + }; + + mdp_wrot0: wrot@14007000 { + compatible = "mediatek,mt8173-mdp-wrot"; + reg = <0 0x14007000 0 0x1000>; + clocks = <&mmsys CLK_MM_MDP_WROT0>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + iommus = <&iommu M4U_PORT_MDP_WROT0>; + mediatek,larb = <&larb0>; + }; + + mdp_wrot1: wrot@14008000 { + compatible = "mediatek,mt8173-mdp-wrot"; + reg = <0 0x14008000 0 0x1000>; + clocks = <&mmsys CLK_MM_MDP_WROT1>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + iommus = <&iommu M4U_PORT_MDP_WROT1>; + mediatek,larb = <&larb4>; + }; -- 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 v2 0/4] Add MT8173 MDP Driver
Changes in v2: - Add section to describe blocks function in dts-bindings - Remove the assignment of device_caps in querycap() - Remove format's name assignment - Copy colorspace-related parameters from OUTPUT to CAPTURE - Use m2m helper functions - Fix DMA allocation failure - Initialize lazily vpu instance in streamon() == Introduction == The purpose of this series is to add the driver for Media Data Path HW embedded in the Mediatek's MT8173 SoC. MDP is used for scaling and color space conversion. It could convert V4L2_PIX_FMT_MT21 to V4L2_PIX_FMT_NV12M or V4L2_PIX_FMT_YUV420M. NV12M/YUV420M/MT21 -> MDP -> NV12M/YUV420M This patch series rely on MTK VPU driver in patch series "Add MT8173 Video Encoder Driver and VPU Driver"[1] and "Add MT8173 Video Decoder Driver"[2]. MDP 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. [1]https://patchwork.kernel.org/patch/9002171/ [2]https://patchwork.kernel.org/patch/9141245/ == 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) and CAPTURE (for destination buffers). OUTPUT and CAPTURE buffer could be MMAP or DMABUF memory type. v4l2-compliance test output: Need the patch "[for,4.7] v4l2-ioctl: fix stupid mistake in cropcap condition"[3] to pass test item Cropping. [3]https://patchwork.linuxtv.org/patch/34374/ # v4l2-compliance -d /dev/image-proc0 v4l2-compliance SHA : 42e5b23fcb64fd0012688b537446df565507b2d7 Driver Info: Driver name : mtk-mdp Card type : 14001000.rdma Bus info : platform:mt8173 Driver version: 4.7.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/image-proc0 (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 test for unlimited opens: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 0 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK test VIDIOC_QUERYCTRL: 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: 5 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK test Composing: OK test Scaling: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK Test input 0: Total: 43, Succeeded: 43, Failed: 0, Warnings: 0 Minghsiu Tsai (4): VPU: mediat
[PATCH v2 1/4] VPU: mediatek: Add mdp support
VPU driver add mdp support Signed-off-by: Minghsiu Tsai --- drivers/media/platform/mtk-vpu/mtk_vpu.h |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.h b/drivers/media/platform/mtk-vpu/mtk_vpu.h index f457479..291ae46 100644 --- a/drivers/media/platform/mtk-vpu/mtk_vpu.h +++ b/drivers/media/platform/mtk-vpu/mtk_vpu.h @@ -53,6 +53,8 @@ typedef void (*ipi_handler_t) (void *data, handle H264 video encoder job, and vice versa. * @IPI_VENC_VP8: The interrupt fro vpu is to notify kernel to handle VP8 video encoder job,, and vice versa. + * @IPI_MDP:The interrupt from vpu is to notify kernel to +handle MDP (Media Data Path) job, and vice versa. * @IPI_MAX:The maximum IPI number */ @@ -63,6 +65,7 @@ enum ipi_id { IPI_VDEC_VP9, IPI_VENC_H264, IPI_VENC_VP8, + IPI_MDP, IPI_MAX, }; @@ -71,11 +74,13 @@ enum ipi_id { * * @VPU_RST_ENC: encoder reset id * @VPU_RST_DEC: decoder reset id + * @VPU_RST_MDP: MDP (Media Data Path) reset id * @VPU_RST_MAX: maximum reset id */ enum rst_id { VPU_RST_ENC, VPU_RST_DEC, + VPU_RST_MDP, VPU_RST_MAX, }; -- 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 v2 3/4] media: Add Mediatek MDP Driver
Add MDP driver for MT8173 Signed-off-by: Minghsiu Tsai --- drivers/media/platform/Kconfig| 16 + drivers/media/platform/Makefile |2 + drivers/media/platform/mtk-mdp/Makefile |9 + drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 159 drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 72 ++ drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 294 ++ drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 240 + drivers/media/platform/mtk-mdp/mtk_mdp_ipi.h | 126 +++ drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 1263 + drivers/media/platform/mtk-mdp/mtk_mdp_m2m.h | 22 + drivers/media/platform/mtk-mdp/mtk_mdp_regs.c | 153 +++ drivers/media/platform/mtk-mdp/mtk_mdp_regs.h | 31 + drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c | 145 +++ drivers/media/platform/mtk-mdp/mtk_mdp_vpu.h | 41 + 14 files changed, 2573 insertions(+) create mode 100644 drivers/media/platform/mtk-mdp/Makefile create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_comp.c create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_comp.h create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_core.c create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_core.h create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_ipi.h create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.h create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_regs.c create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_regs.h create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.h diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index f25344b..4bb874b 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -166,6 +166,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_MDP + tristate "Mediatek MDP driver" + depends on MTK_IOMMU || COMPILE_TEST + 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--- + It is a v4l2 driver and present in Mediatek MT8173 SoCs. + The driver supports for scaling and color space conversion. + + To compile this driver as a module, choose M here: the + module will be called mtk-mdp. + config VIDEO_MEDIATEK_VCODEC tristate "Mediatek Video Codec driver" depends on MTK_IOMMU || COMPILE_TEST diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index 21771c1..221aace 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -63,3 +63,5 @@ ccflags-y += -I$(srctree)/drivers/media/i2c obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu/ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/ + +obj-$(CONFIG_VIDEO_MEDIATEK_MDP) += mtk-mdp/ diff --git a/drivers/media/platform/mtk-mdp/Makefile b/drivers/media/platform/mtk-mdp/Makefile new file mode 100644 index 000..f802569 --- /dev/null +++ b/drivers/media/platform/mtk-mdp/Makefile @@ -0,0 +1,9 @@ +mtk-mdp-y += mtk_mdp_core.o +mtk-mdp-y += mtk_mdp_comp.o +mtk-mdp-y += mtk_mdp_m2m.o +mtk-mdp-y += mtk_mdp_regs.o +mtk-mdp-y += mtk_mdp_vpu.o + +obj-$(CONFIG_VIDEO_MEDIATEK_MDP) += mtk-mdp.o + +ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c new file mode 100644 index 000..aa8f9fd --- /dev/null +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c @@ -0,0 +1,159 @@ +/* + * Copyright (c) 2016 MediaTek Inc. + * Author: Ming Hsiu Tsai + * + * 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 "mtk_mdp_comp.h" + + +static const char * const mtk_mdp_comp_stem[MTK_MDP_COMP_TYPE_MAX] = { + "mdp_rdma", + "mdp_rsz", + "mdp_wdma", + "mdp_wrot", +}; + +struct mtk_mdp_comp_match { + enum mtk_mdp_comp_type type; + int alias_id; +}; + +static const struct mtk_mdp_comp_match mtk_mdp_matches[MTK_MDP_COMP_ID_MAX] = { + { MTK_MDP_RDMA, 0 }, + { MTK_MDP_RDMA, 1 }, + { MTK_MDP_RSZ, 0 }, + { MTK_MDP_RSZ, 1 }, + { MTK_MDP_RSZ, 2 }, + { MTK_MDP_
[PATCH v2 4/4] arm64: dts: mediatek: Add MDP for MT8173
Add MDP node for MT8173 Signed-off-by: Minghsiu Tsai --- arch/arm64/boot/dts/mediatek/mt8173.dtsi | 80 ++ 1 file changed, 80 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi index a44cfb7..cabbd85 100644 --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi @@ -26,6 +26,16 @@ #address-cells = <2>; #size-cells = <2>; + aliases { + mdp_rdma0 = &mdp_rdma0; + mdp_rdma1 = &mdp_rdma1; + mdp_rsz0 = &mdp_rsz0; + mdp_rsz1 = &mdp_rsz1; + mdp_rsz2 = &mdp_rsz2; + mdp_wdma0 = &mdp_wdma0; + mdp_wrot0 = &mdp_wrot0; + mdp_wrot1 = &mdp_wrot1; + }; cpus { #address-cells = <1>; #size-cells = <0>; @@ -678,6 +688,76 @@ #clock-cells = <1>; }; + mdp_rdma0: rdma@14001000 { + compatible = "mediatek,mt8173-mdp-rdma", +"mediatek,mt8173-mdp"; + reg = <0 0x14001000 0 0x1000>; + clocks = <&mmsys CLK_MM_MDP_RDMA0>, +<&mmsys CLK_MM_MUTEX_32K>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + iommus = <&iommu M4U_PORT_MDP_RDMA0>; + mediatek,larb = <&larb0>; + mediatek,vpu = <&vpu>; + }; + + mdp_rdma1: rdma@14002000 { + compatible = "mediatek,mt8173-mdp-rdma"; + reg = <0 0x14002000 0 0x1000>; + clocks = <&mmsys CLK_MM_MDP_RDMA1>, +<&mmsys CLK_MM_MUTEX_32K>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + iommus = <&iommu M4U_PORT_MDP_RDMA1>; + mediatek,larb = <&larb4>; + }; + + mdp_rsz0: rsz@14003000 { + compatible = "mediatek,mt8173-mdp-rsz"; + reg = <0 0x14003000 0 0x1000>; + clocks = <&mmsys CLK_MM_MDP_RSZ0>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + }; + + mdp_rsz1: rsz@14004000 { + compatible = "mediatek,mt8173-mdp-rsz"; + reg = <0 0x14004000 0 0x1000>; + clocks = <&mmsys CLK_MM_MDP_RSZ1>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + }; + + mdp_rsz2: rsz@14005000 { + compatible = "mediatek,mt8173-mdp-rsz"; + reg = <0 0x14005000 0 0x1000>; + clocks = <&mmsys CLK_MM_MDP_RSZ2>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + }; + + mdp_wdma0: wdma@14006000 { + compatible = "mediatek,mt8173-mdp-wdma"; + reg = <0 0x14006000 0 0x1000>; + clocks = <&mmsys CLK_MM_MDP_WDMA>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + iommus = <&iommu M4U_PORT_MDP_WDMA>; + mediatek,larb = <&larb0>; + }; + + mdp_wrot0: wrot@14007000 { + compatible = "mediatek,mt8173-mdp-wrot"; + reg = <0 0x14007000 0 0x1000>; + clocks = <&mmsys CLK_MM_MDP_WROT0>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + iommus = <&iommu M4U_PORT_MDP_WROT0>; + mediatek,larb = <&larb0>; + }; + + mdp_wrot1: wrot@14008000 { + compatible = "mediatek,mt8173-mdp-wrot"; + reg = <0 0x14008000 0 0x1000>; + clocks = <&mmsys CLK_MM_MDP_WROT1>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + iommus = <&iommu M4U_PORT_MDP_WROT1>; + mediatek,larb = <&larb4>; + }; + pwm0: pwm@1401e000 { compatible = "mediatek,mt8173-disp-pwm", "mediatek,mt6595-disp-pwm"; -- 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 for v4.8] cec: fix off-by-one memset
The unused bytes of the features array should be zeroed, but the start index was one byte too early. This caused the device features byte to be overwritten by 0. The compliance test for the CEC_S_LOG_ADDRS ioctl didn't catch this because it tested byte continuation with the second device features byte being 0 :-( Signed-off-by: Hans Verkuil --- diff --git a/drivers/staging/media/cec/cec-adap.c b/drivers/staging/media/cec/cec-adap.c index 9fffddb..b2393bb 100644 --- a/drivers/staging/media/cec/cec-adap.c +++ b/drivers/staging/media/cec/cec-adap.c @@ -1252,7 +1252,7 @@ int __cec_s_log_addrs(struct cec_adapter *adap, return -EINVAL; } /* Zero unused part of the feature array */ - memset(features + i, 0, feature_sz - i); + memset(features + i + 1, 0, feature_sz - i - 1); } if (log_addrs->cec_version >= CEC_OP_CEC_VERSION_2_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 v6 1/4] media: adv7604: automatic "default-input" selection
Fall back to input 0 if "default-input" property is not present. Additionally, documentation in commit bf9c82278c34 ("[media] media: adv7604: ability to read default input port from DT") states that the "default-input" property should reside directly in the node for adv7612. Hence, also adjust the parsing to make the implementation consistent with this. Based on patch by William Towle . Signed-off-by: Ulrich Hecht --- drivers/media/i2c/adv7604.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index 4003831..055c9df 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -3077,10 +3077,13 @@ static int adv76xx_parse_dt(struct adv76xx_state *state) if (!of_property_read_u32(endpoint, "default-input", &v)) state->pdata.default_input = v; else - state->pdata.default_input = -1; + state->pdata.default_input = 0; of_node_put(endpoint); + if (!of_property_read_u32(np, "default-input", &v)) + state->pdata.default_input = v; + flags = bus_cfg.bus.parallel.flags; if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 4/4] rcar-vin: implement EDID control ioctls
Adds G_EDID and S_EDID. Signed-off-by: Ulrich Hecht --- drivers/media/platform/rcar-vin/rcar-v4l2.c | 33 + 1 file changed, 33 insertions(+) diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c b/drivers/media/platform/rcar-vin/rcar-v4l2.c index 396eabc..57e040c 100644 --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c @@ -661,6 +661,36 @@ static int rvin_dv_timings_cap(struct file *file, void *priv_fh, return ret; } +static int rvin_g_edid(struct file *file, void *fh, struct v4l2_edid *edid) +{ + struct rvin_dev *vin = video_drvdata(file); + int input, ret; + + input = edid->pad; + edid->pad = vin->inputs[input].sink_idx; + + ret = rvin_subdev_call(vin, pad, get_edid, edid); + + edid->pad = input; + + return ret; +} + +static int rvin_s_edid(struct file *file, void *fh, struct v4l2_edid *edid) +{ + struct rvin_dev *vin = video_drvdata(file); + int input, ret; + + input = edid->pad; + edid->pad = vin->inputs[input].sink_idx; + + ret = rvin_subdev_call(vin, pad, set_edid, edid); + + edid->pad = input; + + return ret; +} + static const struct v4l2_ioctl_ops rvin_ioctl_ops = { .vidioc_querycap= rvin_querycap, .vidioc_try_fmt_vid_cap = rvin_try_fmt_vid_cap, @@ -683,6 +713,9 @@ static const struct v4l2_ioctl_ops rvin_ioctl_ops = { .vidioc_s_dv_timings= rvin_s_dv_timings, .vidioc_query_dv_timings= rvin_query_dv_timings, + .vidioc_g_edid = rvin_g_edid, + .vidioc_s_edid = rvin_s_edid, + .vidioc_querystd= rvin_querystd, .vidioc_g_std = rvin_g_std, .vidioc_s_std = rvin_s_std, -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 0/4] Lager/Koelsch board HDMI input support
Hi! This revision implements the pad translation between rcar-vin and subdevices as suggested by Niklas. It also moves around the i2c devices, following the introduction of i2c multiplexing in the Gen2 device trees. Based on renesas-drivers-2016-07-19-v4.7-rc7. CU Uli Changes since v5: - implement vin/subdev pad translation - move i2c devices Changes since v4: - drop merged patches - adv7604: always fall back to input 0 if nothing else is specified - rcar-vin: implement G_EDID, S_EDID in place of hard-coded EDID blob Changes since v3: - rvin_enum_dv_timings(): use vin->src_pad_idx - rvin_dv_timings_cap(): likewise - rvin_s_dv_timings(): update vin->format - add Koelsch support Changes since v2: - rebased on top of rcar-vin driver v4 - removed "adv7604: fix SPA register location for ADV7612" (picked up) - changed prefix of dts patch to "ARM: dts: lager: " Hans Verkuil (1): ARM: dts: koelsch: add HDMI input Ulrich Hecht (2): media: adv7604: automatic "default-input" selection rcar-vin: implement EDID control ioctls William Towle (1): ARM: dts: lager: Add entries for VIN HDMI input support arch/arm/boot/dts/r8a7790-lager.dts | 39 +++ arch/arm/boot/dts/r8a7791-koelsch.dts | 41 + drivers/media/i2c/adv7604.c | 5 +++- drivers/media/platform/rcar-vin/rcar-v4l2.c | 33 +++ 4 files changed, 117 insertions(+), 1 deletion(-) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 3/4] ARM: dts: koelsch: add HDMI input
From: Hans Verkuil Add support in the dts for the HDMI input. Based on the Lager dts patch from Ulrich Hecht. Signed-off-by: Hans Verkuil [uli: removed "renesas," prefixes from pfc nodes] Signed-off-by: Ulrich Hecht --- arch/arm/boot/dts/r8a7791-koelsch.dts | 41 +++ 1 file changed, 41 insertions(+) diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts index 980f41b..28ec3a8 100644 --- a/arch/arm/boot/dts/r8a7791-koelsch.dts +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts @@ -400,6 +400,21 @@ }; }; + hdmi-in@4c { + compatible = "adi,adv7612"; + reg = <0x4c>; + interrupt-parent = <&gpio1>; + interrupts = <20 IRQ_TYPE_LEVEL_LOW>; + remote = <&vin0>; + default-input = <0>; + + port { + adv7612: endpoint { + remote-endpoint = <&vin0ep>; + }; + }; + }; + eeprom@50 { compatible = "renesas,24c02"; reg = <0x50>; @@ -534,6 +549,11 @@ function = "usb1"; }; + vin0_pins: vin0 { + groups = "vin0_data24", "vin0_sync", "vin0_clkenb", "vin0_clk"; + function = "vin0"; + }; + vin1_pins: vin1 { groups = "vin1_data8", "vin1_clk"; function = "vin1"; @@ -765,6 +785,27 @@ cpu0-supply = <&vdd_dvfs>; }; +/* HDMI video input */ +&vin0 { + status = "okay"; + pinctrl-0 = <&vin0_pins>; + pinctrl-names = "default"; + + port { + #address-cells = <1>; + #size-cells = <0>; + + vin0ep: endpoint { + remote-endpoint = <&adv7612>; + bus-width = <24>; + hsync-active = <0>; + vsync-active = <0>; + pclk-sample = <1>; + data-active = <1>; + }; + }; +}; + /* composite video input */ &vin1 { status = "okay"; -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/4] ARM: dts: lager: Add entries for VIN HDMI input support
From: William Towle Add DT entries for vin0, vin0_pins, and adv7612. Sets the 'default-input' property for ADV7612, enabling image and video capture without the need to have userspace specifying routing. Signed-off-by: William Towle Signed-off-by: Rob Taylor [uli: added interrupt, renamed endpoint, merged default-input] Signed-off-by: Ulrich Hecht --- arch/arm/boot/dts/r8a7790-lager.dts | 39 + 1 file changed, 39 insertions(+) diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts index ffc2f4e..16e86d0 100644 --- a/arch/arm/boot/dts/r8a7790-lager.dts +++ b/arch/arm/boot/dts/r8a7790-lager.dts @@ -374,6 +374,21 @@ }; }; }; + + hdmi-in@4c { + compatible = "adi,adv7612"; + reg = <0x4c>; + interrupt-parent = <&gpio1>; + interrupts = <20 IRQ_TYPE_LEVEL_LOW>; + remote = <&vin0>; + default-input = <0>; + + port { + adv7612: endpoint { + remote-endpoint = <&vin0ep0>; + }; + }; + }; }; /* @@ -587,6 +602,11 @@ function = "usb2"; }; + vin0_pins: vin0 { + groups = "vin0_data24", "vin0_sync", "vin0_clkenb", "vin0_clk"; + function = "vin0"; + }; + vin1_pins: vin1 { groups = "vin1_data8", "vin1_clk"; function = "vin1"; @@ -818,6 +838,25 @@ status = "okay"; }; +/* HDMI video input */ +&vin0 { + pinctrl-0 = <&vin0_pins>; + pinctrl-names = "default"; + + status = "ok"; + + port { + vin0ep0: endpoint { + remote-endpoint = <&adv7612>; + bus-width = <24>; + hsync-active = <0>; + vsync-active = <0>; + pclk-sample = <1>; + data-active = <1>; + }; + }; +}; + /* composite video input */ &vin1 { pinctrl-0 = <&vin1_pins>; -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Staging: media: timblogiw: File cleanup.
This driver will be removed in 4.8, so I won't take this patch. Regards, Hans On 07/20/2016 08:47 PM, Jeremiah Goerdt wrote: > Cleaned up checkpatch.pl warnings and checks. > > Signed-off-by: Jeremiah Goerdt > --- > drivers/staging/media/timb/timblogiw.c | 134 > - > 1 file changed, 67 insertions(+), 67 deletions(-) > > diff --git a/drivers/staging/media/timb/timblogiw.c > b/drivers/staging/media/timb/timblogiw.c > index 113c9f3..66d2898 100644 > --- a/drivers/staging/media/timb/timblogiw.c > +++ b/drivers/staging/media/timb/timblogiw.c > @@ -10,10 +10,6 @@ > * 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. > - * > - * You should have received a copy of the GNU General Public License > - * along with this program; if not, write to the Free Software > - * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. > */ > > /* Supports: > @@ -43,7 +39,6 @@ > > #define TIMBLOGIW_HAS_DECODER(lw)(lw->pdata.encoder.module_name) > > - > struct timblogiw { > struct video_device video_dev; > struct v4l2_device v4l2_dev; /* mutual exclusion */ > @@ -98,7 +93,6 @@ static int timblogiw_bytes_per_line(const struct > timblogiw_tvnorm *norm) > return norm->width * 2; > } > > - > static int timblogiw_frame_size(const struct timblogiw_tvnorm *norm) > { > return norm->height * timblogiw_bytes_per_line(norm); > @@ -107,6 +101,7 @@ static int timblogiw_frame_size(const struct > timblogiw_tvnorm *norm) > static const struct timblogiw_tvnorm *timblogiw_get_norm(const v4l2_std_id > std) > { > int i; > + > for (i = 0; i < ARRAY_SIZE(timblogiw_tvnorms); i++) > if (timblogiw_tvnorms[i].std & std) > return timblogiw_tvnorms + i; > @@ -138,8 +133,8 @@ static void timblogiw_dma_cb(void *data) > } > > if (!list_empty(&fh->capture)) { > - vb = list_entry(fh->capture.next, struct videobuf_buffer, > - queue); > + vb = list_entry( > + fh->capture.next, struct videobuf_buffer, queue); > vb->state = VIDEOBUF_ACTIVE; > } > > @@ -153,8 +148,8 @@ static bool timblogiw_dma_filter_fn(struct dma_chan > *chan, void *filter_param) > > /* IOCTL functions */ > > -static int timblogiw_g_fmt(struct file *file, void *priv, > - struct v4l2_format *format) > +static int timblogiw_g_fmt( > + struct file *file, void *priv, struct v4l2_format *format) > { > struct video_device *vdev = video_devdata(file); > struct timblogiw *lw = video_get_drvdata(vdev); > @@ -179,8 +174,8 @@ static int timblogiw_g_fmt(struct file *file, void *priv, > return 0; > } > > -static int timblogiw_try_fmt(struct file *file, void *priv, > - struct v4l2_format *format) > +static int timblogiw_try_fmt( > + struct file *file, void *priv, struct v4l2_format *format) > { > struct video_device *vdev = video_devdata(file); > struct v4l2_pix_format *pix = &format->fmt.pix; > @@ -204,8 +199,8 @@ static int timblogiw_try_fmt(struct file *file, void > *priv, > return 0; > } > > -static int timblogiw_s_fmt(struct file *file, void *priv, > - struct v4l2_format *format) > +static int timblogiw_s_fmt( > + struct file *file, void *priv, struct v4l2_format *format) > { > struct video_device *vdev = video_devdata(file); > struct timblogiw *lw = video_get_drvdata(vdev); > @@ -233,15 +228,17 @@ out: > return err; > } > > -static int timblogiw_querycap(struct file *file, void *priv, > - struct v4l2_capability *cap) > +static int timblogiw_querycap( > + struct file *file, void *priv, struct v4l2_capability *cap) > { > struct video_device *vdev = video_devdata(file); > > dev_dbg(&vdev->dev, "%s: Entry\n", __func__); > - strncpy(cap->card, TIMBLOGIWIN_NAME, sizeof(cap->card)-1); > + strncpy(cap->card, TIMBLOGIWIN_NAME, sizeof(cap->card) - 1); > strncpy(cap->driver, DRIVER_NAME, sizeof(cap->driver) - 1); > - snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s", > vdev->name); > + snprintf( > + cap->bus_info, sizeof(cap->bus_info), > + "platform:%s", vdev->name); > cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING | > V4L2_CAP_READWRITE; > cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS; > @@ -249,8 +246,8 @@ static int timblogiw_querycap(struct file *file, void > *priv, > return 0; > } > > -static int timblogiw_enum_fmt(struct file *file, void *priv, > - struct v4l2_fmtdesc *fmt) > +static int timblogiw_enum_fmt( > + struct file *file, void *priv, struct v4l2_fmtdesc *fmt) > { > struct video_device *vdev = video_devdata(file); > > @@ -261,15 +258,16 @@
Re: [PATCH v6 0/4] Lager/Koelsch board HDMI input support
Looks good to me. I plan to queue this for 4.9. Regards, Hans On 07/22/2016 11:09 AM, Ulrich Hecht wrote: > Hi! > > This revision implements the pad translation between rcar-vin and subdevices > as suggested by Niklas. It also moves around the i2c devices, following the > introduction of i2c multiplexing in the Gen2 device trees. > > Based on renesas-drivers-2016-07-19-v4.7-rc7. > > CU > Uli > > > Changes since v5: > - implement vin/subdev pad translation > - move i2c devices > > Changes since v4: > - drop merged patches > - adv7604: always fall back to input 0 if nothing else is specified > - rcar-vin: implement G_EDID, S_EDID in place of hard-coded EDID blob > > Changes since v3: > - rvin_enum_dv_timings(): use vin->src_pad_idx > - rvin_dv_timings_cap(): likewise > - rvin_s_dv_timings(): update vin->format > - add Koelsch support > > Changes since v2: > - rebased on top of rcar-vin driver v4 > - removed "adv7604: fix SPA register location for ADV7612" (picked up) > - changed prefix of dts patch to "ARM: dts: lager: " > > > Hans Verkuil (1): > ARM: dts: koelsch: add HDMI input > > Ulrich Hecht (2): > media: adv7604: automatic "default-input" selection > rcar-vin: implement EDID control ioctls > > William Towle (1): > ARM: dts: lager: Add entries for VIN HDMI input support > > arch/arm/boot/dts/r8a7790-lager.dts | 39 +++ > arch/arm/boot/dts/r8a7791-koelsch.dts | 41 > + > drivers/media/i2c/adv7604.c | 5 +++- > drivers/media/platform/rcar-vin/rcar-v4l2.c | 33 +++ > 4 files changed, 117 insertions(+), 1 deletion(-) > -- 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 00/18] Complete moving media documentation to ReST format
Em Thu, 21 Jul 2016 17:17:26 +0200 Markus Heiser escreveu: > Am 19.07.2016 um 19:18 schrieb Mauro Carvalho Chehab > : > > >> A bit OT, but I see that you often use tabs / I recommend to use > >> spaces for indentation: > >> > >> http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#whitespace > >> > > > > The Kernel policies are to use tabs instead of spaces, > > Yes, but not in text files .. I think. See chapter 1 of Documentation/CodingStyle: Chapter 1: Indentation Tabs are 8 characters, and thus indentations are also 8 characters. > > -- Markus -- > > > and tabs have > > size of 8. I have some git automation to avoid commit patches with > > bad whitespaces, and some tools to convert spaces into tabs. > > > > > > > Thanks, > > Mauro > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sony imx219 driver?
On 07/21/2016 08:19 PM, Dave Stevenson wrote: > Hi All. > > Just a quick query to avoid duplicating effort. Has anyone worked on a > Sony IMX219 (or other Sony sensor) subdevice driver as yet? Not that I am aware of. > With the new Raspberry Pi camera being IMX219, and as Broadcom have > released an soc_camera based driver for the sensor already > (https://android.googlesource.com/kernel/bcm/+/android-bcm-tetra-3.10-lollipop-wear-release/drivers/media/video/imx219.c) > #@!@$! Why do they never ever ask us what would be a good example driver to use. The soc-camera framework is deprecated and will likely be gone by the end of the year. > I was going to investigate converting that to a subdevice. I just wanted > to check this wasn't already in someone else's work queue. > > A further Google shows that there's also an soc_camera IMX219 driver in > ChromiumOS, copyright Andrew Chew @ Nvidia, but author Guennadi > Liakhovetski who I know posts on here. > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/factory-ryu-6486.14.B-chromeos-3.14/drivers/media/i2c/soc_camera/imx219.c. > At least for the tegra there is a proper non-soc-camera driver in the works. > The Broadcom one supports 8MPix and 1080P, the Chromium one only 8MP. > Perhaps a hybrid of the feature set? They usually only implement what they need, so I'd say for chromium they only needed 8MP support. > Throw in > https://github.com/ZenfoneArea/android_kernel_asus_zenfone5/blob/master/linux/modules/camera/drivers/media/i2c/imx219/imx219.h > > as well, and we have register sets for numerous readout modes, plus > there are the ones in the Pi firmware which can be extracted if necessary. With all that code it shouldn't be hard to write a proper subdev driver. > > On a related note, if putting together a system with IMX219 or similar > producing Bayer raw 10, the data on the CSI2 bus is one of the > V4L2_PIX_FMT_SRGGB10P formats. What's the correct way to reflect that > from the sensor subdevice in an MEDIA_BUS_FMT_ enum? > The closest is MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_BE (or LE), but the data > isn't padded (the Pi CSI2 receiver can do the unpacking and padding, but > that just takes up more memory). Or is it MEDIA_BUS_FMT_SBGGR10_1X10 > to describe the data on the bus correctly as 10bpp Bayer, and the odd > packing is ignored. Or do we need new enums? Just add new enums to media-bus-format.h. It should be clear from comments and/or the naming of the enum what the exact format it, so you'll need to think about that carefully. Otherwise it's no big deal to add new formats there. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] tw686x-kh: Delete an unnecessary check before the function call "video_unregister_device"
SF Markus Elfring writes: > The video_unregister_device() function tests whether its argument is NULL > and then returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > --- > drivers/staging/media/tw686x-kh/tw686x-kh-video.c | 3 +-- Thanks. -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- 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 v3 1/5] media: Determine early whether an IOCTL is supported
Hi Sakari, On 07/21/2016 01:14 PM, Sakari Ailus wrote: > Preparation for refactoring media IOCTL handling to unify common parts. > > Reviewed-by: Laurent Pinchart > Signed-off-by: Sakari Ailus > --- > drivers/media/media-device.c | 48 > ++-- > 1 file changed, 46 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c > index 1795abe..3ac526d 100644 > --- a/drivers/media/media-device.c > +++ b/drivers/media/media-device.c > @@ -419,13 +419,33 @@ static long media_device_get_topology(struct > media_device *mdev, > return 0; > } > > -static long media_device_ioctl(struct file *filp, unsigned int cmd, > -unsigned long arg) > +#define MEDIA_IOC(__cmd) \ > + [_IOC_NR(MEDIA_IOC_##__cmd)] = { .cmd = MEDIA_IOC_##__cmd } > + > +/* the table is indexed by _IOC_NR(cmd) */ > +struct media_ioctl_info { > + unsigned int cmd; > +}; > + > +static inline long is_valid_ioctl(const struct media_ioctl_info *info, > + unsigned int len, unsigned int cmd) > +{ > + return (_IOC_NR(cmd) >= len > + || info[_IOC_NR(cmd)].cmd != cmd) ? -ENOIOCTLCMD : 0; > +} > + > +static long __media_device_ioctl( > + struct file *filp, unsigned int cmd, void __user *arg, > + const struct media_ioctl_info *info_array, unsigned int info_array_len) > { > struct media_devnode *devnode = media_devnode_data(filp); > struct media_device *dev = devnode->media_dev; > long ret; > > + ret = is_valid_ioctl(info_array, info_array_len, cmd); > + if (ret) > + return ret; > + > mutex_lock(&dev->graph_mutex); > switch (cmd) { > case MEDIA_IOC_DEVICE_INFO: > @@ -461,6 +481,22 @@ static long media_device_ioctl(struct file *filp, > unsigned int cmd, > return ret; > } > > +static const struct media_ioctl_info ioctl_info[] = { > + MEDIA_IOC(DEVICE_INFO), > + MEDIA_IOC(ENUM_ENTITIES), > + MEDIA_IOC(ENUM_LINKS), > + MEDIA_IOC(SETUP_LINK), > + MEDIA_IOC(G_TOPOLOGY), > +}; Why not move this up and use ARRAY_SIZE instead of having to pass the length around? > + > +static long media_device_ioctl(struct file *filp, unsigned int cmd, > +unsigned long arg) > +{ > + return __media_device_ioctl( > + filp, cmd, (void __user *)arg, > + ioctl_info, ARRAY_SIZE(ioctl_info)); > +} > + > #ifdef CONFIG_COMPAT > > struct media_links_enum32 { > @@ -491,6 +527,14 @@ static long media_device_enum_links32(struct > media_device *mdev, > > #define MEDIA_IOC_ENUM_LINKS32 _IOWR('|', 0x02, struct > media_links_enum32) > > +static const struct media_ioctl_info compat_ioctl_info[] = { > + MEDIA_IOC(DEVICE_INFO), > + MEDIA_IOC(ENUM_ENTITIES), > + MEDIA_IOC(ENUM_LINKS32), > + MEDIA_IOC(SETUP_LINK), > + MEDIA_IOC(G_TOPOLOGY), > +}; I assume the size of the compat array will always be the same as that of the 'regular' array. In fact, you should probably test for that (the compiler should be able to catch that). > + > static long media_device_compat_ioctl(struct file *filp, unsigned int cmd, > unsigned long arg) > { > Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] media: Refactor copying IOCTL arguments from and to user space
On 07/21/2016 01:14 PM, Sakari Ailus wrote: > Refactor copying the IOCTL argument structs from the user space and back, > in order to reduce code copied around and make the implementation more > robust. > > As a result, the copying is done while not holding the graph mutex. > > Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil Thanks! Hans > --- > drivers/media/media-device.c | 190 > --- > 1 file changed, 90 insertions(+), 100 deletions(-) > > diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c > index 6fd9b77..87d17a0 100644 > --- a/drivers/media/media-device.c > +++ b/drivers/media/media-device.c > @@ -59,27 +59,24 @@ static int media_device_close(struct file *filp) > } > > static int media_device_get_info(struct media_device *dev, > - struct media_device_info __user *__info) > + struct media_device_info *info) > { > - struct media_device_info info; > - > - memset(&info, 0, sizeof(info)); > + memset(info, 0, sizeof(*info)); > > if (dev->driver_name[0]) > - strlcpy(info.driver, dev->driver_name, sizeof(info.driver)); > + strlcpy(info->driver, dev->driver_name, sizeof(info->driver)); > else > - strlcpy(info.driver, dev->dev->driver->name, > sizeof(info.driver)); > + strlcpy(info->driver, dev->dev->driver->name, > + sizeof(info->driver)); > > - strlcpy(info.model, dev->model, sizeof(info.model)); > - strlcpy(info.serial, dev->serial, sizeof(info.serial)); > - strlcpy(info.bus_info, dev->bus_info, sizeof(info.bus_info)); > + strlcpy(info->model, dev->model, sizeof(info->model)); > + strlcpy(info->serial, dev->serial, sizeof(info->serial)); > + strlcpy(info->bus_info, dev->bus_info, sizeof(info->bus_info)); > > - info.media_version = MEDIA_API_VERSION; > - info.hw_revision = dev->hw_revision; > - info.driver_version = dev->driver_version; > + info->media_version = MEDIA_API_VERSION; > + info->hw_revision = dev->hw_revision; > + info->driver_version = dev->driver_version; > > - if (copy_to_user(__info, &info, sizeof(*__info))) > - return -EFAULT; > return 0; > } > > @@ -101,29 +98,25 @@ static struct media_entity *find_entity(struct > media_device *mdev, u32 id) > } > > static long media_device_enum_entities(struct media_device *mdev, > -struct media_entity_desc __user *uent) > +struct media_entity_desc *entd) > { > struct media_entity *ent; > - struct media_entity_desc u_ent; > - > - memset(&u_ent, 0, sizeof(u_ent)); > - if (copy_from_user(&u_ent.id, &uent->id, sizeof(u_ent.id))) > - return -EFAULT; > - > - ent = find_entity(mdev, u_ent.id); > > + ent = find_entity(mdev, entd->id); > if (ent == NULL) > return -EINVAL; > > - u_ent.id = media_entity_id(ent); > + memset(entd, 0, sizeof(*entd)); > + > + entd->id = media_entity_id(ent); > if (ent->name) > - strlcpy(u_ent.name, ent->name, sizeof(u_ent.name)); > - u_ent.type = ent->function; > - u_ent.revision = 0; /* Unused */ > - u_ent.flags = ent->flags; > - u_ent.group_id = 0; /* Unused */ > - u_ent.pads = ent->num_pads; > - u_ent.links = ent->num_links - ent->num_backlinks; > + strlcpy(entd->name, ent->name, sizeof(entd->name)); > + entd->type = ent->function; > + entd->revision = 0; /* Unused */ > + entd->flags = ent->flags; > + entd->group_id = 0; /* Unused */ > + entd->pads = ent->num_pads; > + entd->links = ent->num_links - ent->num_backlinks; > > /* >* Workaround for a bug at media-ctl <= v1.10 that makes it to > @@ -139,14 +132,13 @@ static long media_device_enum_entities(struct > media_device *mdev, > if (ent->function < MEDIA_ENT_F_OLD_BASE || > ent->function > MEDIA_ENT_T_DEVNODE_UNKNOWN) { > if (is_media_entity_v4l2_subdev(ent)) > - u_ent.type = MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN; > + entd->type = MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN; > else if (ent->function != MEDIA_ENT_F_IO_V4L) > - u_ent.type = MEDIA_ENT_T_DEVNODE_UNKNOWN; > + entd->type = MEDIA_ENT_T_DEVNODE_UNKNOWN; > } > > - memcpy(&u_ent.raw, &ent->info, sizeof(ent->info)); > - if (copy_to_user(uent, &u_ent, sizeof(u_ent))) > - return -EFAULT; > + memcpy(&entd->raw, &ent->info, sizeof(ent->info)); > + > return 0; > } > > @@ -158,8 +150,8 @@ static void media_device_kpad_to_upad(const struct > media_pad *kpad, > upad->flags = kpad->flags; > } > > -static long __media_device_enum_links(struct media_device *mdev, > -
Re: [PATCH v3 2/5] media: Unify IOCTL handler calling
On 07/21/2016 01:14 PM, Sakari Ailus wrote: > Each IOCTL handler can be listed in an array instead of using a large and > cumbersome switch. Do that. > > Reviewed-by: Laurent Pinchart > Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil Thanks! Hans > --- > drivers/media/media-device.c | 81 > +--- > 1 file changed, 23 insertions(+), 58 deletions(-) > > diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c > index 3ac526d..6fd9b77 100644 > --- a/drivers/media/media-device.c > +++ b/drivers/media/media-device.c > @@ -419,12 +419,16 @@ static long media_device_get_topology(struct > media_device *mdev, > return 0; > } > > -#define MEDIA_IOC(__cmd) \ > - [_IOC_NR(MEDIA_IOC_##__cmd)] = { .cmd = MEDIA_IOC_##__cmd } > +#define MEDIA_IOC(__cmd, func) > \ > + [_IOC_NR(MEDIA_IOC_##__cmd)] = {\ > + .cmd = MEDIA_IOC_##__cmd, \ > + .fn = (long (*)(struct media_device *, void __user *))func,\ > + } > > /* the table is indexed by _IOC_NR(cmd) */ > struct media_ioctl_info { > unsigned int cmd; > + long (*fn)(struct media_device *dev, void __user *arg); > }; > > static inline long is_valid_ioctl(const struct media_ioctl_info *info, > @@ -440,53 +444,28 @@ static long __media_device_ioctl( > { > struct media_devnode *devnode = media_devnode_data(filp); > struct media_device *dev = devnode->media_dev; > + const struct media_ioctl_info *info; > long ret; > > ret = is_valid_ioctl(info_array, info_array_len, cmd); > if (ret) > return ret; > > + info = &info_array[_IOC_NR(cmd)]; > + > mutex_lock(&dev->graph_mutex); > - switch (cmd) { > - case MEDIA_IOC_DEVICE_INFO: > - ret = media_device_get_info(dev, > - (struct media_device_info __user *)arg); > - break; > - > - case MEDIA_IOC_ENUM_ENTITIES: > - ret = media_device_enum_entities(dev, > - (struct media_entity_desc __user *)arg); > - break; > - > - case MEDIA_IOC_ENUM_LINKS: > - ret = media_device_enum_links(dev, > - (struct media_links_enum __user *)arg); > - break; > - > - case MEDIA_IOC_SETUP_LINK: > - ret = media_device_setup_link(dev, > - (struct media_link_desc __user *)arg); > - break; > - > - case MEDIA_IOC_G_TOPOLOGY: > - ret = media_device_get_topology(dev, > - (struct media_v2_topology __user *)arg); > - break; > - > - default: > - ret = -ENOIOCTLCMD; > - } > + ret = info->fn(dev, arg); > mutex_unlock(&dev->graph_mutex); > > return ret; > } > > static const struct media_ioctl_info ioctl_info[] = { > - MEDIA_IOC(DEVICE_INFO), > - MEDIA_IOC(ENUM_ENTITIES), > - MEDIA_IOC(ENUM_LINKS), > - MEDIA_IOC(SETUP_LINK), > - MEDIA_IOC(G_TOPOLOGY), > + MEDIA_IOC(DEVICE_INFO, media_device_get_info), > + MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities), > + MEDIA_IOC(ENUM_LINKS, media_device_enum_links), > + MEDIA_IOC(SETUP_LINK, media_device_setup_link), > + MEDIA_IOC(G_TOPOLOGY, media_device_get_topology), > }; > > static long media_device_ioctl(struct file *filp, unsigned int cmd, > @@ -528,33 +507,19 @@ static long media_device_enum_links32(struct > media_device *mdev, > #define MEDIA_IOC_ENUM_LINKS32 _IOWR('|', 0x02, struct > media_links_enum32) > > static const struct media_ioctl_info compat_ioctl_info[] = { > - MEDIA_IOC(DEVICE_INFO), > - MEDIA_IOC(ENUM_ENTITIES), > - MEDIA_IOC(ENUM_LINKS32), > - MEDIA_IOC(SETUP_LINK), > - MEDIA_IOC(G_TOPOLOGY), > + MEDIA_IOC(DEVICE_INFO, media_device_get_info), > + MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities), > + MEDIA_IOC(ENUM_LINKS32, media_device_enum_links32), > + MEDIA_IOC(SETUP_LINK, media_device_setup_link), > + MEDIA_IOC(G_TOPOLOGY, media_device_get_topology), > }; > > static long media_device_compat_ioctl(struct file *filp, unsigned int cmd, > unsigned long arg) > { > - struct media_devnode *devnode = media_devnode_data(filp); > - struct media_device *dev = devnode->media_dev; > - long ret; > - > - switch (cmd) { > - case MEDIA_IOC_ENUM_LINKS32: > - mutex_lock(&dev->graph_mutex); > - ret = media_device_enum_links32(dev, > - (struct media_links_enum32 __user *)arg); > - mutex_unlock(&dev->graph_mutex); > - break; > - > - default: > - return media_device_ioctl(filp, cmd, arg); > - } > - > - return ret; > + return __media_device
Re: [PATCH v3 4/5] media: Add flags to tell whether to take graph mutex for an IOCTL
On 07/21/2016 01:17 PM, Sakari Ailus wrote: > New IOCTLs (especially for the request API) do not necessarily need the > graph mutex acquired. Leave this up to the drivers. > > Signed-off-by: Sakari Ailus > Reviewed-by: Laurent Pinchart Acked-by: Hans Verkuil Thanks! Hans > --- > drivers/media/media-device.c | 47 > ++-- > 1 file changed, 28 insertions(+), 19 deletions(-) > > diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c > index 87d17a0..6dfcc50 100644 > --- a/drivers/media/media-device.c > +++ b/drivers/media/media-device.c > @@ -381,20 +381,25 @@ static long copy_arg_to_user(void __user *uarg, void > *karg, unsigned int cmd) > return 0; > } > > -#define MEDIA_IOC_ARG(__cmd, func, from_user, to_user) \ > - [_IOC_NR(MEDIA_IOC_##__cmd)] = {\ > - .cmd = MEDIA_IOC_##__cmd, \ > +/* Do acquire the graph mutex */ > +#define MEDIA_IOC_FL_GRAPH_MUTEX BIT(0) > + > +#define MEDIA_IOC_ARG(__cmd, func, fl, from_user, to_user) \ > + [_IOC_NR(MEDIA_IOC_##__cmd)] = {\ > + .cmd = MEDIA_IOC_##__cmd, \ > .fn = (long (*)(struct media_device *, void *))func,\ > - .arg_from_user = from_user, \ > - .arg_to_user = to_user, \ > + .flags = fl,\ > + .arg_from_user = from_user, \ > + .arg_to_user = to_user, \ > } > > -#define MEDIA_IOC(__cmd, func) > \ > - MEDIA_IOC_ARG(__cmd, func, copy_arg_from_user, copy_arg_to_user) > +#define MEDIA_IOC(__cmd, func, fl) \ > + MEDIA_IOC_ARG(__cmd, func, fl, copy_arg_from_user, copy_arg_to_user) > > /* the table is indexed by _IOC_NR(cmd) */ > struct media_ioctl_info { > unsigned int cmd; > + unsigned short flags; > long (*fn)(struct media_device *dev, void *arg); > long (*arg_from_user)(void *karg, void __user *uarg, unsigned int cmd); > long (*arg_to_user)(void __user *uarg, void *karg, unsigned int cmd); > @@ -435,9 +440,13 @@ static long __media_device_ioctl( > goto out_free; > } > > - mutex_lock(&dev->graph_mutex); > + if (info->flags & MEDIA_IOC_FL_GRAPH_MUTEX) > + mutex_lock(&dev->graph_mutex); > + > ret = info->fn(dev, karg); > - mutex_unlock(&dev->graph_mutex); > + > + if (info->flags & MEDIA_IOC_FL_GRAPH_MUTEX) > + mutex_unlock(&dev->graph_mutex); > > if (!ret && info->arg_to_user) > ret = info->arg_to_user(arg, karg, cmd); > @@ -450,11 +459,11 @@ out_free: > } > > static const struct media_ioctl_info ioctl_info[] = { > - MEDIA_IOC(DEVICE_INFO, media_device_get_info), > - MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities), > - MEDIA_IOC(ENUM_LINKS, media_device_enum_links), > - MEDIA_IOC(SETUP_LINK, media_device_setup_link), > - MEDIA_IOC(G_TOPOLOGY, media_device_get_topology), > + MEDIA_IOC(DEVICE_INFO, media_device_get_info, MEDIA_IOC_FL_GRAPH_MUTEX), > + MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities, > MEDIA_IOC_FL_GRAPH_MUTEX), > + MEDIA_IOC(ENUM_LINKS, media_device_enum_links, > MEDIA_IOC_FL_GRAPH_MUTEX), > + MEDIA_IOC(SETUP_LINK, media_device_setup_link, > MEDIA_IOC_FL_GRAPH_MUTEX), > + MEDIA_IOC(G_TOPOLOGY, media_device_get_topology, > MEDIA_IOC_FL_GRAPH_MUTEX), > }; > > static long media_device_ioctl(struct file *filp, unsigned int cmd, > @@ -497,11 +506,11 @@ static long from_user_enum_links32(void *karg, void > __user *uarg, > #define MEDIA_IOC_ENUM_LINKS32 _IOWR('|', 0x02, struct > media_links_enum32) > > static const struct media_ioctl_info compat_ioctl_info[] = { > - MEDIA_IOC(DEVICE_INFO, media_device_get_info), > - MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities), > - MEDIA_IOC_ARG(ENUM_LINKS32, media_device_enum_links, > from_user_enum_links32, NULL), > - MEDIA_IOC(SETUP_LINK, media_device_setup_link), > - MEDIA_IOC(G_TOPOLOGY, media_device_get_topology), > + MEDIA_IOC(DEVICE_INFO, media_device_get_info, MEDIA_IOC_FL_GRAPH_MUTEX), > + MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities, > MEDIA_IOC_FL_GRAPH_MUTEX), > + MEDIA_IOC_ARG(ENUM_LINKS32, media_device_enum_links, > MEDIA_IOC_FL_GRAPH_MUTEX, from_user_enum_links32, NULL), > + MEDIA_IOC(SETUP_LINK, media_device_setup_link, > MEDIA_IOC_FL_GRAPH_MUTEX), > + MEDIA_IOC(G_TOPOLOGY, media_device_get_topology, > MEDIA_IOC_FL_GRAPH_MUTEX), > }; > > static long media_device_compat_ioctl(struct file *filp, unsigned int cmd, > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to maj
Re: [PATCH v3 5/5] media: Support variable size IOCTL arguments
On 07/21/2016 01:17 PM, Sakari Ailus wrote: > Instead of checking for a strict size for the IOCTL arguments, place > minimum and maximum limits. This sentence is out of date: it checks for alternative smaller sizes, not min/max. > > As an additional bonus, IOCTL handlers will be able to check whether the > caller actually set (using the argument size) the field vs. assigning it > to zero. Separate macro can be provided for that. > > This will be easier for applications as well since there is no longer the > problem of setting the reserved fields zero, or at least it is a lesser > problem. > > Signed-off-by: Sakari Ailus > --- > drivers/media/media-device.c | 52 > +++- > 1 file changed, 47 insertions(+), 5 deletions(-) > > diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c > index 6dfcc50..c7be2ce 100644 > --- a/drivers/media/media-device.c > +++ b/drivers/media/media-device.c > @@ -384,32 +384,71 @@ static long copy_arg_to_user(void __user *uarg, void > *karg, unsigned int cmd) > /* Do acquire the graph mutex */ > #define MEDIA_IOC_FL_GRAPH_MUTEX BIT(0) > > -#define MEDIA_IOC_ARG(__cmd, func, fl, from_user, to_user) \ > +#define MEDIA_IOC_SZ_ARG(__cmd, func, fl, alt_sz, from_user, to_user) > \ > [_IOC_NR(MEDIA_IOC_##__cmd)] = {\ > .cmd = MEDIA_IOC_##__cmd, \ > .fn = (long (*)(struct media_device *, void *))func,\ > .flags = fl,\ > + .alt_arg_sizes = alt_sz,\ > .arg_from_user = from_user, \ > .arg_to_user = to_user, \ > } > > -#define MEDIA_IOC(__cmd, func, fl) \ > - MEDIA_IOC_ARG(__cmd, func, fl, copy_arg_from_user, copy_arg_to_user) > +#define MEDIA_IOC_ARG(__cmd, func, fl, from_user, to_user) \ > + MEDIA_IOC_SZ_ARG(__cmd, func, fl, NULL, from_user, to_user) > + > +#define MEDIA_IOC_SZ(__cmd, func, fl, alt_sz)\ > + MEDIA_IOC_SZ_ARG(__cmd, func, fl, alt_sz, \ > + copy_arg_from_user, copy_arg_to_user) > + > +#define MEDIA_IOC(__cmd, func, fl) \ > + MEDIA_IOC_ARG(__cmd, func, fl, \ > + copy_arg_from_user, copy_arg_to_user) > > /* the table is indexed by _IOC_NR(cmd) */ > struct media_ioctl_info { > unsigned int cmd; > unsigned short flags; > + const unsigned short *alt_arg_sizes; I think an additional comment would be useful here. > long (*fn)(struct media_device *dev, void *arg); > long (*arg_from_user)(void *karg, void __user *uarg, unsigned int cmd); > long (*arg_to_user)(void __user *uarg, void *karg, unsigned int cmd); > }; > > +#define MASK_IOC_SIZE(cmd) \ > + ((cmd) & ~(_IOC_SIZEMASK << _IOC_SIZESHIFT)) > + > static inline long is_valid_ioctl(const struct media_ioctl_info *info, > unsigned int len, unsigned int cmd) > { > - return (_IOC_NR(cmd) >= len > - || info[_IOC_NR(cmd)].cmd != cmd) ? -ENOIOCTLCMD : 0; > + const unsigned short *alt_arg_sizes; > + > + if (unlikely(_IOC_NR(cmd) >= len)) Please don't use 'unlikely'. Unless you can prove with hard numbers that it actually make a performance difference it only pollutes the code. > + return -ENOIOCTLCMD; > + > + info += _IOC_NR(cmd); > + > + if (info->cmd == cmd) > + return 0; > + > + /* > + * Verify that the size-dependent patch of the IOCTL command > + * matches and that the size does not exceed the principal > + * argument size. > + */ > + if (unlikely(MASK_IOC_SIZE(info->cmd) != MASK_IOC_SIZE(cmd) > + || _IOC_SIZE(info->cmd) < _IOC_SIZE(cmd))) > + return -ENOIOCTLCMD; > + > + alt_arg_sizes = info->alt_arg_sizes; > + if (unlikely(!alt_arg_sizes)) > + return -ENOIOCTLCMD; > + > + for (; *alt_arg_sizes; alt_arg_sizes++) > + if (_IOC_SIZE(cmd) == *alt_arg_sizes) > + return 0; > + > + return -ENOIOCTLCMD; > } > > static long __media_device_ioctl( > @@ -440,6 +479,9 @@ static long __media_device_ioctl( > goto out_free; > } > > + /* Set the rest of the argument struct to zero */ > + memset(karg + _IOC_SIZE(cmd), 0, _IOC_SIZE(info->cmd) - _IOC_SIZE(cmd)); > + > if (info->flags & MEDIA_IOC_FL_GRAPH_MUTEX) > mutex_lock(&dev->graph_mutex); > > I'm in two minds: I like this idea, but on the other hand it is not actually needed at the moment. So should we just park this in patchwork until needed, or apply anyway? Comments? Personally I think it is better to park i
[GIT PULL FOR v4.8] (v3) Various fixes/cleanups
Hi Mauro, Another bunch of bug fixes and small cleanups for 4.8. The vb2 fix is particularly nasty, the others are all pretty trivial. Regards, Hans New for v3: added patch "cec: fix off-by-one memset" New for v2: added patch "staging: add MEDIA_SUPPORT dependency" The following changes since commit 009a620848218d521f008141c62f56bf19294dd9: [media] cec: always check all_device_types and features (2016-07-19 13:27:46 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.8a for you to fetch changes up to d96ab0b4929b026d040e4c01de2c5d2558722425: cec: fix off-by-one memset (2016-07-22 12:42:52 +0200) Arnd Bergmann (1): staging: add MEDIA_SUPPORT dependency Bhaktipriya Shridhar (6): pvrusb2: Remove deprecated create_singlethread_workqueue gspca: sonixj: Remove deprecated create_singlethread_workqueue gspca: vicam: Remove deprecated create_singlethread_workqueue gspca: jl2005bcd: Remove deprecated create_singlethread_workqueue gspca: finepix: Remove deprecated create_singlethread_workqueue ad9389b: Remove deprecated create_singlethread_workqueue Hans Verkuil (6): adv7511: fix VIC autodetect cobalt: support reduced fps vim2m: copy the other colorspace-related fields as well vivid: don't handle CEC_MSG_SET_STREAM_PATH airspy: fix compiler warning cec: fix off-by-one memset Markus Elfring (4): tw686x-kh: Delete an unnecessary check before the function call "video_unregister_device" cec: Delete an unnecessary check before the function call "rc_free_device" v4l2-common: Delete an unnecessary check before the function call "spi_unregister_device" tw686x: Delete an unnecessary check before the function call "video_unregister_device" Steve Longerbeam (3): media: adv7180: Fix broken interrupt register access media: adv7180: define more registers media: adv7180: add power pin control Vincent Stehlé (1): vb2: Fix allocation size of dma_parms Documentation/devicetree/bindings/media/i2c/adv7180.txt | 5 +++ drivers/media/i2c/Kconfig | 2 +- drivers/media/i2c/ad9389b.c | 22 +++-- drivers/media/i2c/adv7180.c | 118 +++--- drivers/media/i2c/adv7511.c | 24 +++--- drivers/media/pci/cobalt/cobalt-v4l2.c | 7 ++-- drivers/media/pci/tw686x/tw686x-video.c | 3 +- drivers/media/platform/vim2m.c | 15 - drivers/media/platform/vivid/vivid-cec.c| 10 -- drivers/media/usb/airspy/airspy.c | 1 - drivers/media/usb/gspca/finepix.c | 8 ++--- drivers/media/usb/gspca/jl2005bcd.c | 8 ++--- drivers/media/usb/gspca/sonixj.c| 13 +++- drivers/media/usb/gspca/vicam.c | 8 ++--- drivers/media/usb/pvrusb2/pvrusb2-hdw-internal.h| 1 - drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 23 - drivers/media/v4l2-core/v4l2-common.c | 2 +- drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +- drivers/staging/media/Kconfig | 2 +- drivers/staging/media/cec/cec-adap.c| 2 +- drivers/staging/media/cec/cec-core.c| 3 +- drivers/staging/media/tw686x-kh/tw686x-kh-video.c | 3 +- 22 files changed, 158 insertions(+), 124 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Complete moving media documentation to ReST format
Am 22.07.2016 um 11:46 schrieb Mauro Carvalho Chehab : > Em Thu, 21 Jul 2016 17:17:26 +0200 > Markus Heiser escreveu: > >> Am 19.07.2016 um 19:18 schrieb Mauro Carvalho Chehab >> : >> A bit OT, but I see that you often use tabs / I recommend to use spaces for indentation: http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#whitespace >>> >>> The Kernel policies are to use tabs instead of spaces, >> >> Yes, but not in text files .. I think. > > See chapter 1 of Documentation/CodingStyle: > > Chapter 1: Indentation > > Tabs are 8 characters, and thus indentations are also 8 characters. Hi Mauro, sorry if I'am pedantic, IMHO this is "Coding" style. See end of chapter 1: Outside of comments, documentation and except in Kconfig, spaces are never used for indentation ... As far as I can see, nearly all of the ASCII markups in the *.txt files use space for indentation (some mix tabs and spaces). I don't know if tab indentation in kernel-doc comments is a good choice. --Markus 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 v3 1/5] media: Determine early whether an IOCTL is supported
Hi Hans, Hans Verkuil wrote: Hi Sakari, On 07/21/2016 01:14 PM, Sakari Ailus wrote: Preparation for refactoring media IOCTL handling to unify common parts. Reviewed-by: Laurent Pinchart Signed-off-by: Sakari Ailus --- drivers/media/media-device.c | 48 ++-- 1 file changed, 46 insertions(+), 2 deletions(-) diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c index 1795abe..3ac526d 100644 --- a/drivers/media/media-device.c +++ b/drivers/media/media-device.c @@ -419,13 +419,33 @@ static long media_device_get_topology(struct media_device *mdev, return 0; } -static long media_device_ioctl(struct file *filp, unsigned int cmd, - unsigned long arg) +#define MEDIA_IOC(__cmd) \ + [_IOC_NR(MEDIA_IOC_##__cmd)] = { .cmd = MEDIA_IOC_##__cmd } + +/* the table is indexed by _IOC_NR(cmd) */ +struct media_ioctl_info { + unsigned int cmd; +}; + +static inline long is_valid_ioctl(const struct media_ioctl_info *info, + unsigned int len, unsigned int cmd) +{ + return (_IOC_NR(cmd) >= len + || info[_IOC_NR(cmd)].cmd != cmd) ? -ENOIOCTLCMD : 0; +} + +static long __media_device_ioctl( + struct file *filp, unsigned int cmd, void __user *arg, + const struct media_ioctl_info *info_array, unsigned int info_array_len) { struct media_devnode *devnode = media_devnode_data(filp); struct media_device *dev = devnode->media_dev; long ret; + ret = is_valid_ioctl(info_array, info_array_len, cmd); + if (ret) + return ret; + mutex_lock(&dev->graph_mutex); switch (cmd) { case MEDIA_IOC_DEVICE_INFO: @@ -461,6 +481,22 @@ static long media_device_ioctl(struct file *filp, unsigned int cmd, return ret; } +static const struct media_ioctl_info ioctl_info[] = { + MEDIA_IOC(DEVICE_INFO), + MEDIA_IOC(ENUM_ENTITIES), + MEDIA_IOC(ENUM_LINKS), + MEDIA_IOC(SETUP_LINK), + MEDIA_IOC(G_TOPOLOGY), +}; Why not move this up and use ARRAY_SIZE instead of having to pass the length around? + +static long media_device_ioctl(struct file *filp, unsigned int cmd, + unsigned long arg) +{ + return __media_device_ioctl( + filp, cmd, (void __user *)arg, + ioctl_info, ARRAY_SIZE(ioctl_info)); +} + #ifdef CONFIG_COMPAT struct media_links_enum32 { @@ -491,6 +527,14 @@ static long media_device_enum_links32(struct media_device *mdev, #define MEDIA_IOC_ENUM_LINKS32_IOWR('|', 0x02, struct media_links_enum32) +static const struct media_ioctl_info compat_ioctl_info[] = { + MEDIA_IOC(DEVICE_INFO), + MEDIA_IOC(ENUM_ENTITIES), + MEDIA_IOC(ENUM_LINKS32), + MEDIA_IOC(SETUP_LINK), + MEDIA_IOC(G_TOPOLOGY), +}; I assume the size of the compat array will always be the same as that of the 'regular' array. In fact, you should probably test for that (the compiler should be able to catch that). Yeah, the sizes will be the same, so ARRAY_SIZE() works well. I'll add a BUILD_BUG_ON() check for the sizes. -- Sakari Ailus sakari.ai...@linux.intel.com -- 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: [v4l-utils RFC 0/3] mediatext library and test program
Hi Sakari, First a practical matter: you should consider using the v4l-helpers.h: it will shield you and probably the end-user as well from lots of complexities, esp. the single vs multiplanar differences. I really need to spend some time documenting it, but it isn't all that difficult. On 07/21/2016 05:15 PM, Sakari Ailus wrote: > Hi everyone, > > We've got a number of V4L2 (and MC) test programs for about as many reasons. > The existing programs are concentrated to work on a single device node at a > time, and with a single interface, be that Media controller or V4L2. > > The test programs are also command line controlled, working their way with > the device at hand based on the information passed to the test programs on > the command line. This has made perfect sense for the past 15 years, as long > as we've had such test programs: they have covered, for large part, needs to > perform testing in various cases without leaving significant gaps. > > With the upcoming request API, however, this has become insufficient. The > very nature of the request API requires that requests can contain resources > (e.g. memory buffers) that is associated to a number of video device nodes. > The requests may well be different from each other, including the types of > resources that are used for each request. > > So I decided we need a new test program. The scope for the original > mediatext library and test program were slightly different from what is in > this (very RFC) patchset. I deemed mediatext as the best starting point for > writing a new test program. Is this utility meant to testing different scenarios, or as a way to test drivers (compliance tests)? I think the first, right? > mediatext acts as an interface between an end user or a script and the > kernel interfaces, with an ability to work with multiple devices at a time, > including multiple video nodes: > >shell script >| >| >| <- two-way pipe >| >| >mediatext > / | \ > / | \ > /dev/video* | /dev/v4l-subdev* >| > /dev/mediaX > > The shell script (which could be any other program as well but shell scripts > are convenient for the purpose) is always in the control of the main loop of > the test. Events are delivered to the script by mediatext based on file > handle state changes, so the script has a possibility to react to each of > them (e.g. buffer becoming dequeueable on one of the video nodes). > > A simple example script for a UVC compliant Logitech webcam is below. It > opens the device based on the name of the entity, and sets up the device for > streaming with a specified format with three MMAP buffers. The first 50 > frames are written to a file, and capturing is stopped once about 100 frames > have been captured. Dequeued buffers are immediately requeued, and this is > explicitly done by the shell script. > > -8<- > #!/bin/bash > > eval_line() { > while [ $# -ne 0 ]; do > local name=${1%=*} > local value=${1#*=} > p[$name]="$value" > shift > done > } > > coproc mediatext -d /dev/media0 2>&1 > > cat <&${COPROC[1]} > v4l open entity="UVC Camera (046d:0825)" name=uvc > v4l fmt vdev=uvc type=CAPTURE width=320 height=240 \ > pixelformat=YUYV bytesperline=0 > v4l reqbufs vdev=uvc type=CAPTURE count=3 memory=MMAP > v4l qbuf vdev=uvc > v4l qbuf vdev=uvc > v4l qbuf vdev=uvc > > v4l streamon vdev=uvc type=CAPTURE > EOF > > while IFS= read -ru ${COPROC[0]} line; do > unset p; declare -A p > eval eval_line $line > echo $line > case ${p[event]} in > dqbuf) > if ((${p[seq]} < 50)); then > echo v4l write vdev=uvc \ > sequence=${p[seq]} >&${COPROC[1]} > fi > if ((${p[seq]} > 100)); then > echo quit >&${COPROC[1]} > fi > cat <&${COPROC[1]} > v4l qbuf vdev=uvc > EOF > ;; > esac; > done > -8<- > > Requests are naturally supported as well, right now only for buffer-related > IOCTLs but support for other IOCTLs can be added as well. The library has > been designed to be modular and easily extensible. There are no drivers > implementing them yet, and the kernel patches are still in development. > > The kernel patches from which the headers have been generated from are > available here: > > http://git.retiisi.org.uk/?p=~sailus/linux.git;a=shortlog;h=refs/heads/request> > > As noted, the test program is still in development phase. I thought this > still would be useful for others
[PATCH] [media] Documentation: Fix V4L2_CTRL_FLAG_VOLATILE
V4L2_CTRL_FLAG_VOLATILE behaviour when V4L2_CTRL_FLAG_EXECUTE_ON_WRITE is set was not properly explained. Reported-by: Dimitrios Katsaros Credit-to: Hans Verkuil Signed-off-by: Ricardo Ribalda Delgado --- Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst index 8d6e61a7284d..3a30d6cf70b4 100644 --- a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst +++ b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst @@ -728,10 +728,10 @@ See also the examples in :ref:`control`. case the hardware calculates the gain value based on the lighting conditions which can change over time. - .. note:: Setting a new value for a volatile control will have no -effect and no ``V4L2_EVENT_CTRL_CH_VALUE`` will be sent, unless -the ``V4L2_CTRL_FLAG_EXECUTE_ON_WRITE`` flag (see below) is -also set. Otherwise the new value will just be ignored. + .. note:: Setting a new value for a volatile control will be ignored + unless `V4L2_CTRL_FLAG_EXECUTE_ON_WRITE`` flag (see below) is also set. + Setting a new value for a volatile contol will never trigger a + ``V4L2_EVENT_CTRL_CH_VALUE`` event. - .. row 9 -- 2.8.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] [media] Documentation: Fix V4L2_CTRL_FLAG_VOLATILE
On 07/22/2016 04:07 PM, Ricardo Ribalda Delgado wrote: > V4L2_CTRL_FLAG_VOLATILE behaviour when V4L2_CTRL_FLAG_EXECUTE_ON_WRITE > is set was not properly explained. > > Reported-by: Dimitrios Katsaros > Credit-to: Hans Verkuil > Signed-off-by: Ricardo Ribalda Delgado > --- > Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst > b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst > index 8d6e61a7284d..3a30d6cf70b4 100644 > --- a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst > +++ b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst > @@ -728,10 +728,10 @@ See also the examples in :ref:`control`. > case the hardware calculates the gain value based on the lighting > conditions which can change over time. > > - .. note:: Setting a new value for a volatile control will have no > - effect and no ``V4L2_EVENT_CTRL_CH_VALUE`` will be sent, unless > - the ``V4L2_CTRL_FLAG_EXECUTE_ON_WRITE`` flag (see below) is > - also set. Otherwise the new value will just be ignored. > + .. note:: Setting a new value for a volatile control will be ignored > + unless `V4L2_CTRL_FLAG_EXECUTE_ON_WRITE`` flag (see below) is > also set. That should start with `` not ` (i.e. a double ` instead of a single `). > + Setting a new value for a volatile contol will never trigger a s/contol/control/ Also emphasize 'never': s/never/*never*/ > + ``V4L2_EVENT_CTRL_CH_VALUE`` event. > > - .. row 9 > > Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] doc-rst: kernel-doc: fix handling of address_space tags
The RST cpp:function handler is very pedantic: it doesn't allow any macros like __user on it: Documentation/media/kapi/dtv-core.rst:28: WARNING: Error when parsing function declaration. If the function has no return type: Error in declarator or parameters and qualifiers Invalid definition: Expecting "(" in parameters_and_qualifiers. [error at 8] ssize_t dvb_ringbuffer_pkt_read_user (struct dvb_ringbuffer * rbuf, size_t idx, int offset, u8 __user * buf, size_t len) ^ If the function has a return type: Error in declarator or parameters and qualifiers If pointer to member declarator: Invalid definition: Expected '::' in pointer to member (function). [error at 37] ssize_t dvb_ringbuffer_pkt_read_user (struct dvb_ringbuffer * rbuf, size_t idx, int offset, u8 __user * buf, size_t len) -^ If declarator-id: Invalid definition: Expecting "," or ")" in parameters_and_qualifiers, got "*". [error at 102] ssize_t dvb_ringbuffer_pkt_read_user (struct dvb_ringbuffer * rbuf, size_t idx, int offset, u8 __user * buf, size_t len) --^ So, we have to remove it from the function prototype. Signed-off-by: Mauro Carvalho Chehab --- scripts/kernel-doc | 4 1 file changed, 4 insertions(+) diff --git a/scripts/kernel-doc b/scripts/kernel-doc index 41eade332307..4394746cc1aa 100755 --- a/scripts/kernel-doc +++ b/scripts/kernel-doc @@ -1848,6 +1848,10 @@ sub output_function_rst(%) { } $count++; $type = $args{'parametertypes'}{$parameter}; + + # RST doesn't like address_space tags at function prototypes + $type =~ s/__(user|kernel|iomem|percpu|pmem|rcu)\s*//; + if ($type =~ m/([^\(]*\(\*)\s*\)\s*\(([^\)]*)\)/) { # pointer-to-function print $1 . $parameter . ") (" . $2; -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/11] [media] v4l2-event.rst: add text from v4l2-framework.rst
Move the v4l2 event-specific text from v4l2-framework.rst to v4l2-event.rst. That helps to keep the text together with the functions it describes, and makes easier to identify documentation gaps. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/v4l2-event.rst | 107 Documentation/media/kapi/v4l2-framework.rst | 107 2 files changed, 107 insertions(+), 107 deletions(-) diff --git a/Documentation/media/kapi/v4l2-event.rst b/Documentation/media/kapi/v4l2-event.rst index 6ac94efc07bf..567ff7b1a3c2 100644 --- a/Documentation/media/kapi/v4l2-event.rst +++ b/Documentation/media/kapi/v4l2-event.rst @@ -1,3 +1,110 @@ + +V4L2 events +--- + +The V4L2 events provide a generic way to pass events to user space. +The driver must use v4l2_fh to be able to support V4L2 events. + +Events are defined by a type and an optional ID. The ID may refer to a V4L2 +object such as a control ID. If unused, then the ID is 0. + +When the user subscribes to an event the driver will allocate a number of +kevent structs for that event. So every (type, ID) event tuple will have +its own set of kevent structs. This guarantees that if a driver is generating +lots of events of one type in a short time, then that will not overwrite +events of another type. + +But if you get more events of one type than the number of kevents that were +reserved, then the oldest event will be dropped and the new one added. + +Furthermore, the internal struct v4l2_subscribed_event has merge() and +replace() callbacks which drivers can set. These callbacks are called when +a new event is raised and there is no more room. The replace() callback +allows you to replace the payload of the old event with that of the new event, +merging any relevant data from the old payload into the new payload that +replaces it. It is called when this event type has only one kevent struct +allocated. The merge() callback allows you to merge the oldest event payload +into that of the second-oldest event payload. It is called when there are two +or more kevent structs allocated. + +This way no status information is lost, just the intermediate steps leading +up to that state. + +A good example of these replace/merge callbacks is in v4l2-event.c: +ctrls_replace() and ctrls_merge() callbacks for the control event. + +Note: these callbacks can be called from interrupt context, so they must be +fast. + +Useful functions: + +.. code-block:: none + + void v4l2_event_queue(struct video_device *vdev, const struct v4l2_event *ev) + + Queue events to video device. The driver's only responsibility is to fill + in the type and the data fields. The other fields will be filled in by + V4L2. + +.. code-block:: none + + int v4l2_event_subscribe(struct v4l2_fh *fh, +struct v4l2_event_subscription *sub, unsigned elems, +const struct v4l2_subscribed_event_ops *ops) + + The video_device->ioctl_ops->vidioc_subscribe_event must check the driver + is able to produce events with specified event id. Then it calls + v4l2_event_subscribe() to subscribe the event. + + The elems argument is the size of the event queue for this event. If it is 0, + then the framework will fill in a default value (this depends on the event + type). + + The ops argument allows the driver to specify a number of callbacks: + * add: called when a new listener gets added (subscribing to the same + event twice will only cause this callback to get called once) + * del: called when a listener stops listening + * replace: replace event 'old' with event 'new'. + * merge: merge event 'old' into event 'new'. + All 4 callbacks are optional, if you don't want to specify any callbacks + the ops argument itself maybe NULL. + +.. code-block:: none + + int v4l2_event_unsubscribe(struct v4l2_fh *fh, + struct v4l2_event_subscription *sub) + + vidioc_unsubscribe_event in struct v4l2_ioctl_ops. A driver may use + v4l2_event_unsubscribe() directly unless it wants to be involved in + unsubscription process. + + The special type V4L2_EVENT_ALL may be used to unsubscribe all events. The + drivers may want to handle this in a special way. + +.. code-block:: none + + int v4l2_event_pending(struct v4l2_fh *fh) + + Returns the number of pending events. Useful when implementing poll. + +Events are delivered to user space through the poll system call. The driver +can use v4l2_fh->wait (a wait_queue_head_t) as the argument for poll_wait(). + +There are standard and private events. New standard events must use the +smallest available event type. The drivers must allocate their events from +their own class starting from class base. Class base is +V4L2_EVENT_PRIVATE_START + n * 1000 where n is the lowest available number. +The first event type in the class is reserved for future use, so the first +available event typ
[PATCH 05/11] [media] v4l2-fh.h: add documentation for it
This header file was undocumented. Add documentation for it. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/v4l2-core.rst | 1 + Documentation/media/kapi/v4l2-fh.rst | 3 + include/media/v4l2-fh.h| 128 - 3 files changed, 100 insertions(+), 32 deletions(-) create mode 100644 Documentation/media/kapi/v4l2-fh.rst diff --git a/Documentation/media/kapi/v4l2-core.rst b/Documentation/media/kapi/v4l2-core.rst index 6fa30f8908dd..67eaf0c0b6b6 100644 --- a/Documentation/media/kapi/v4l2-core.rst +++ b/Documentation/media/kapi/v4l2-core.rst @@ -8,6 +8,7 @@ Video2Linux devices v4l2-dev v4l2-controls v4l2-device +v4l2-fh v4l2-dv-timings v4l2-event v4l2-flash-led-class diff --git a/Documentation/media/kapi/v4l2-fh.rst b/Documentation/media/kapi/v4l2-fh.rst new file mode 100644 index ..9309c18e967a --- /dev/null +++ b/Documentation/media/kapi/v4l2-fh.rst @@ -0,0 +1,3 @@ +V4L2 File Handler kAPI +^^ +.. kernel-doc:: include/media/v4l2-fh.h diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h index 803516775162..e19e6246e21c 100644 --- a/include/media/v4l2-fh.h +++ b/include/media/v4l2-fh.h @@ -33,6 +33,21 @@ struct video_device; struct v4l2_ctrl_handler; +/** + * struct v4l2_fh - Describes a V4L2 file handler + * + * @list: list of file handlers + * @vdev: pointer to &struct video_device + * @ctrl_handler: pointer to &struct v4l2_ctrl_handler + * @prio: priority of the file handler, as defined by &enum v4l2_priority + * + * @wait: event' s wait queue + * @subscribed: list of subscribed events + * @available: list of events waiting to be dequeued + * @navailable: number of available events at @available list + * @sequence: event sequence number + * @m2m_ctx: pointer to &struct v4l2_m2m_ctx + */ struct v4l2_fh { struct list_headlist; struct video_device *vdev; @@ -41,8 +56,8 @@ struct v4l2_fh { /* Events */ wait_queue_head_t wait; - struct list_headsubscribed; /* Subscribed events */ - struct list_headavailable; /* Dequeueable event */ + struct list_headsubscribed; + struct list_headavailable; unsigned intnavailable; u32 sequence; @@ -51,53 +66,102 @@ struct v4l2_fh { #endif }; -/* - * Initialise the file handle. Parts of the V4L2 framework using the +/** + * v4l2_fh_init - Initialise the file handle. + * + * @fh: pointer to &struct v4l2_fh + * @vdev: pointer to &struct video_device + * + * Parts of the V4L2 framework using the * file handles should be initialised in this function. Must be called - * from driver's v4l2_file_operations->open() handler if the driver - * uses v4l2_fh. + * from driver's v4l2_file_operations->open\(\) handler if the driver + * uses &struct v4l2_fh. */ void v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev); -/* - * Add the fh to the list of file handles on a video_device. The file - * handle must be initialised first. + +/** + * v4l2_fh_add - Add the fh to the list of file handles on a video_device. + * + * @fh: pointer to &struct v4l2_fh + * + * .. note:: + *The @fh file handle must be initialised first. */ void v4l2_fh_add(struct v4l2_fh *fh); -/* - * Can be used as the open() op of v4l2_file_operations. - * It allocates a v4l2_fh and inits and adds it to the video_device associated - * with the file pointer. + +/** + * v4l2_fh_open - Ancillary routine that can be used as the open\(\) op + * of v4l2_file_operations. + * + * @filp: pointer to struct file + * + * It allocates a v4l2_fh and inits and adds it to the &struct video_device + * associated with the file pointer. */ int v4l2_fh_open(struct file *filp); -/* - * Remove file handle from the list of file handles. Must be called in - * v4l2_file_operations->release() handler if the driver uses v4l2_fh. - * On error filp->private_data will be NULL, otherwise it will point to - * the v4l2_fh struct. + +/** + * v4l2_fh_del - Remove file handle from the list of file handles. + * + * @fh: pointer to &struct v4l2_fh + * + * On error filp->private_data will be %NULL, otherwise it will point to + * the &struct v4l2_fh. + * + * .. note:: + *Must be called in v4l2_file_operations->release\(\) handler if the driver + *uses &struct v4l2_fh. */ void v4l2_fh_del(struct v4l2_fh *fh); -/* - * Release resources related to a file handle. Parts of the V4L2 - * framework using the v4l2_fh must release their resources here, too. - * Must be called in v4l2_file_operations->release() handler if the - * driver uses v4l2_fh. + +/** + * v4l2_fh_exit - Release resources related to a file handle. + * + * @fh: pointer to &struct v4l2_fh + * + * Parts of the V4L2 framework using the v4l2_fh must release their + * resources here, too. + * + * .. note:: + *Must be called in v4l2_file_operations->release\(\) handler
[PATCH 06/11] [media] v4l2-fh.rst: add fh contents from v4l2-framework.rst
Move the v4l2_fh specific content from v4l2-framework.rst to v4l2-fh.rst. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/v4l2-fh.rst| 134 Documentation/media/kapi/v4l2-framework.rst | 133 --- 2 files changed, 134 insertions(+), 133 deletions(-) diff --git a/Documentation/media/kapi/v4l2-fh.rst b/Documentation/media/kapi/v4l2-fh.rst index 9309c18e967a..f39374262d3f 100644 --- a/Documentation/media/kapi/v4l2-fh.rst +++ b/Documentation/media/kapi/v4l2-fh.rst @@ -1,3 +1,137 @@ +V4L2 File handlers +-- + +struct v4l2_fh provides a way to easily keep file handle specific data +that is used by the V4L2 framework. New drivers must use struct v4l2_fh +since it is also used to implement priority handling (VIDIOC_G/S_PRIORITY). + +The users of v4l2_fh (in the V4L2 framework, not the driver) know +whether a driver uses v4l2_fh as its file->private_data pointer by +testing the V4L2_FL_USES_V4L2_FH bit in video_device->flags. This bit is +set whenever v4l2_fh_init() is called. + +struct v4l2_fh is allocated as a part of the driver's own file handle +structure and file->private_data is set to it in the driver's open +function by the driver. + +In many cases the struct v4l2_fh will be embedded in a larger structure. +In that case you should call v4l2_fh_init+v4l2_fh_add in open() and +v4l2_fh_del+v4l2_fh_exit in release(). + +Drivers can extract their own file handle structure by using the container_of +macro. Example: + +.. code-block:: none + + struct my_fh { + int blah; + struct v4l2_fh fh; + }; + + ... + + int my_open(struct file *file) + { + struct my_fh *my_fh; + struct video_device *vfd; + int ret; + + ... + + my_fh = kzalloc(sizeof(*my_fh), GFP_KERNEL); + + ... + + v4l2_fh_init(&my_fh->fh, vfd); + + ... + + file->private_data = &my_fh->fh; + v4l2_fh_add(&my_fh->fh); + return 0; + } + + int my_release(struct file *file) + { + struct v4l2_fh *fh = file->private_data; + struct my_fh *my_fh = container_of(fh, struct my_fh, fh); + + ... + v4l2_fh_del(&my_fh->fh); + v4l2_fh_exit(&my_fh->fh); + kfree(my_fh); + return 0; + } + +Below is a short description of the v4l2_fh functions used: + +.. code-block:: none + + void v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev) + + Initialise the file handle. This *MUST* be performed in the driver's + v4l2_file_operations->open() handler. + +.. code-block:: none + + void v4l2_fh_add(struct v4l2_fh *fh) + + Add a v4l2_fh to video_device file handle list. Must be called once the + file handle is completely initialized. + +.. code-block:: none + + void v4l2_fh_del(struct v4l2_fh *fh) + + Unassociate the file handle from video_device(). The file handle + exit function may now be called. + +.. code-block:: none + + void v4l2_fh_exit(struct v4l2_fh *fh) + + Uninitialise the file handle. After uninitialisation the v4l2_fh + memory can be freed. + + +If struct v4l2_fh is not embedded, then you can use these helper functions: + +.. code-block:: none + + int v4l2_fh_open(struct file *filp) + + This allocates a struct v4l2_fh, initializes it and adds it to the struct + video_device associated with the file struct. + +.. code-block:: none + + int v4l2_fh_release(struct file *filp) + + This deletes it from the struct video_device associated with the file + struct, uninitialised the v4l2_fh and frees it. + +These two functions can be plugged into the v4l2_file_operation's open() and +release() ops. + + +Several drivers need to do something when the first file handle is opened and +when the last file handle closes. Two helper functions were added to check +whether the v4l2_fh struct is the only open filehandle of the associated +device node: + +.. code-block:: none + + int v4l2_fh_is_singular(struct v4l2_fh *fh) + + Returns 1 if the file handle is the only open file handle, else 0. + +.. code-block:: none + + int v4l2_fh_is_singular_file(struct file *filp) + + Same, but it calls v4l2_fh_is_singular with filp->private_data. + + V4L2 File Handler kAPI ^^ .. kernel-doc:: include/media/v4l2-fh.h diff --git a/Documentation/media/kapi/v4l2-framework.rst b/Documentation/media/kapi/v4l2-framework.rst index d46380ac7c1d..8b4f684e1a7a 100644 --- a/Documentation/media/kapi/v4l2-framework.rst +++ b/Documentation/media/kapi/v4l2-framework.rst @@ -80,139 +80,6 @@ The V4L2 framework also optionally integrates with the media framework. If a driver sets the struct v4l2_device mdev field, sub-devices and video nodes will automatically appear in the media framework as entities. -struct v4
[PATCH 08/11] [media] move V4L2 clocks to a separate .rst file
Move the v4l2 clocks stuff from v4l2-framework to a separate file and adds an attention that came from the v4l2-clk.h. Note: as this is meant to be a temporary kAPI, and it is used only by two drivers (soc_camera and em28xx), where the first one is in deprecation process, it probably not a worth effort to document its header. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/v4l2-clocks.rst| 29 + Documentation/media/kapi/v4l2-core.rst | 1 + Documentation/media/kapi/v4l2-framework.rst | 25 - 3 files changed, 30 insertions(+), 25 deletions(-) create mode 100644 Documentation/media/kapi/v4l2-clocks.rst diff --git a/Documentation/media/kapi/v4l2-clocks.rst b/Documentation/media/kapi/v4l2-clocks.rst new file mode 100644 index ..b8a895860a8a --- /dev/null +++ b/Documentation/media/kapi/v4l2-clocks.rst @@ -0,0 +1,29 @@ +V4L2 clocks +--- + +.. attention:: + + This is a temporary API and it shall be replaced by the generic + clock API, when the latter becomes widely available. + +Many subdevices, like camera sensors, TV decoders and encoders, need a clock +signal to be supplied by the system. Often this clock is supplied by the +respective bridge device. The Linux kernel provides a Common Clock Framework for +this purpose. However, it is not (yet) available on all architectures. Besides, +the nature of the multi-functional (clock, data + synchronisation, I2C control) +connection of subdevices to the system might impose special requirements on the +clock API usage. E.g. V4L2 has to support clock provider driver unregistration +while a subdevice driver is holding a reference to the clock. For these reasons +a V4L2 clock helper API has been developed and is provided to bridge and +subdevice drivers. + +The API consists of two parts: two functions to register and unregister a V4L2 +clock source: v4l2_clk_register() and v4l2_clk_unregister() and calls to control +a clock object, similar to the respective generic clock API calls: +v4l2_clk_get(), v4l2_clk_put(), v4l2_clk_enable(), v4l2_clk_disable(), +v4l2_clk_get_rate(), and v4l2_clk_set_rate(). Clock suppliers have to provide +clock operations that will be called when clock users invoke respective API +methods. + +It is expected that once the CCF becomes available on all relevant +architectures this API will be removed. diff --git a/Documentation/media/kapi/v4l2-core.rst b/Documentation/media/kapi/v4l2-core.rst index 67eaf0c0b6b6..c69d167bce7a 100644 --- a/Documentation/media/kapi/v4l2-core.rst +++ b/Documentation/media/kapi/v4l2-core.rst @@ -9,6 +9,7 @@ Video2Linux devices v4l2-controls v4l2-device v4l2-fh +v4l2-clocks v4l2-dv-timings v4l2-event v4l2-flash-led-class diff --git a/Documentation/media/kapi/v4l2-framework.rst b/Documentation/media/kapi/v4l2-framework.rst index 8b4f684e1a7a..7f4f26e666a2 100644 --- a/Documentation/media/kapi/v4l2-framework.rst +++ b/Documentation/media/kapi/v4l2-framework.rst @@ -79,28 +79,3 @@ and the v4l2_fh struct keeps track of filehandle instances. The V4L2 framework also optionally integrates with the media framework. If a driver sets the struct v4l2_device mdev field, sub-devices and video nodes will automatically appear in the media framework as entities. - -V4L2 clocks - -Many subdevices, like camera sensors, TV decoders and encoders, need a clock -signal to be supplied by the system. Often this clock is supplied by the -respective bridge device. The Linux kernel provides a Common Clock Framework for -this purpose. However, it is not (yet) available on all architectures. Besides, -the nature of the multi-functional (clock, data + synchronisation, I2C control) -connection of subdevices to the system might impose special requirements on the -clock API usage. E.g. V4L2 has to support clock provider driver unregistration -while a subdevice driver is holding a reference to the clock. For these reasons -a V4L2 clock helper API has been developed and is provided to bridge and -subdevice drivers. - -The API consists of two parts: two functions to register and unregister a V4L2 -clock source: v4l2_clk_register() and v4l2_clk_unregister() and calls to control -a clock object, similar to the respective generic clock API calls: -v4l2_clk_get(), v4l2_clk_put(), v4l2_clk_enable(), v4l2_clk_disable(), -v4l2_clk_get_rate(), and v4l2_clk_set_rate(). Clock suppliers have to provide -clock operations that will be called when clock users invoke respective API -methods. - -It is expected that once the CCF becomes available on all relevant -architectures this API will be removed. -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/11] [media] doc-rst: Fix some typedef ugly warnings
Sphinx can't handle well typedefs. Change two typedef occurrences, in order to cleanup some of such warnings. Signed-off-by: Mauro Carvalho Chehab --- include/media/v4l2-ctrls.h | 4 +++- include/media/v4l2-dv-timings.h | 2 +- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h index 8b59336b2217..d6f63406b885 100644 --- a/include/media/v4l2-ctrls.h +++ b/include/media/v4l2-ctrls.h @@ -534,6 +534,8 @@ struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct v4l2_ctrl_handler *hdl, const struct v4l2_ctrl_ops *ops, u32 id, u8 max, u8 def, const s64 *qmenu_int); +typedef bool (*v4l2_ctrl_filter)(const struct v4l2_ctrl *ctrl); + /** * v4l2_ctrl_add_handler() - Add all controls from handler @add to * handler @hdl. @@ -550,7 +552,7 @@ struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct v4l2_ctrl_handler *hdl, */ int v4l2_ctrl_add_handler(struct v4l2_ctrl_handler *hdl, struct v4l2_ctrl_handler *add, - bool (*filter)(const struct v4l2_ctrl *ctrl)); + v4l2_ctrl_filter filter); /** * v4l2_ctrl_radio_filter() - Standard filter for radio controls. diff --git a/include/media/v4l2-dv-timings.h b/include/media/v4l2-dv-timings.h index 1113c8874c26..65caadf13eec 100644 --- a/include/media/v4l2-dv-timings.h +++ b/include/media/v4l2-dv-timings.h @@ -28,7 +28,7 @@ */ extern const struct v4l2_dv_timings v4l2_dv_timings_presets[]; -/** +/* * v4l2_check_dv_timings_fnc - timings check callback * * @t: the v4l2_dv_timings struct. -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/11] [media] v4l2-fh.rst: add cross references and markups
Add cross-references with the kernel-doc functions/structs and improve the markups. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/v4l2-fh.rst | 111 ++- 1 file changed, 56 insertions(+), 55 deletions(-) diff --git a/Documentation/media/kapi/v4l2-fh.rst b/Documentation/media/kapi/v4l2-fh.rst index f39374262d3f..a212698d5725 100644 --- a/Documentation/media/kapi/v4l2-fh.rst +++ b/Documentation/media/kapi/v4l2-fh.rst @@ -1,27 +1,35 @@ V4L2 File handlers -- -struct v4l2_fh provides a way to easily keep file handle specific data -that is used by the V4L2 framework. New drivers must use struct v4l2_fh -since it is also used to implement priority handling (VIDIOC_G/S_PRIORITY). +struct :c:type:`v4l2_fh` provides a way to easily keep file handle specific +data that is used by the V4L2 framework. -The users of v4l2_fh (in the V4L2 framework, not the driver) know -whether a driver uses v4l2_fh as its file->private_data pointer by -testing the V4L2_FL_USES_V4L2_FH bit in video_device->flags. This bit is -set whenever v4l2_fh_init() is called. +.. attention:: + New drivers must use struct :c:type:`v4l2_fh` + since it is also used to implement priority handling + (:ref:`VIDIOC_G_PRIORITY`). -struct v4l2_fh is allocated as a part of the driver's own file handle -structure and file->private_data is set to it in the driver's open +The users of :c:type:`v4l2_fh` (in the V4L2 framework, not the driver) know +whether a driver uses :c:type:`v4l2_fh` as its ``file->private_data`` pointer +by testing the ``V4L2_FL_USES_V4L2_FH`` bit in :c:type:`video_device`->flags. +This bit is set whenever :cpp:func:`v4l2_fh_init` is called. + +struct :c:type:`v4l2_fh` is allocated as a part of the driver's own file handle +structure and ``file->private_data`` is set to it in the driver's ``open()`` function by the driver. -In many cases the struct v4l2_fh will be embedded in a larger structure. -In that case you should call v4l2_fh_init+v4l2_fh_add in open() and -v4l2_fh_del+v4l2_fh_exit in release(). +In many cases the struct :c:type:`v4l2_fh` will be embedded in a larger +structure. In that case you should call: + +#) :cpp:func:`v4l2_fh_init` and :cpp:func:`v4l2_fh_add` in ``open()`` +#) :cpp:func:`v4l2_fh_del` and :cpp:func:`v4l2_fh_exit` in ``release()`` Drivers can extract their own file handle structure by using the container_of -macro. Example: +macro. -.. code-block:: none +Example: + +.. code-block:: c struct my_fh { int blah; @@ -63,73 +71,66 @@ macro. Example: return 0; } -Below is a short description of the v4l2_fh functions used: +Below is a short description of the :c:type:`v4l2_fh` functions used: -.. code-block:: none +:cpp:func:`v4l2_fh_init ` +(:c:type:`fh `, :c:type:`vdev `) - void v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev) - Initialise the file handle. This *MUST* be performed in the driver's - v4l2_file_operations->open() handler. +- Initialise the file handle. This **MUST** be performed in the driver's + :c:type:`v4l2_file_operations`->open() handler. -.. code-block:: none - void v4l2_fh_add(struct v4l2_fh *fh) +:cpp:func:`v4l2_fh_add ` +(:c:type:`fh `) - Add a v4l2_fh to video_device file handle list. Must be called once the - file handle is completely initialized. +- Add a :c:type:`v4l2_fh` to :c:type:`video_device` file handle list. + Must be called once the file handle is completely initialized. -.. code-block:: none +:cpp:func:`v4l2_fh_del ` +(:c:type:`fh `) - void v4l2_fh_del(struct v4l2_fh *fh) - - Unassociate the file handle from video_device(). The file handle +- Unassociate the file handle from :c:type:`video_device`. The file handle exit function may now be called. -.. code-block:: none +:cpp:func:`v4l2_fh_exit ` +(:c:type:`fh `) - void v4l2_fh_exit(struct v4l2_fh *fh) - - Uninitialise the file handle. After uninitialisation the v4l2_fh +- Uninitialise the file handle. After uninitialisation the :c:type:`v4l2_fh` memory can be freed. -If struct v4l2_fh is not embedded, then you can use these helper functions: +If struct :c:type:`v4l2_fh` is not embedded, then you can use these helper functions: -.. code-block:: none +:cpp:func:`v4l2_fh_open ` +(struct file \*filp) - int v4l2_fh_open(struct file *filp) +- This allocates a struct :c:type:`v4l2_fh`, initializes it and adds it to + the struct :c:type:`video_device` associated with the file struct. - This allocates a struct v4l2_fh, initializes it and adds it to the struct - video_device associated with the file struct. +:cpp:func:`v4l2_fh_release ` +(struct file \*filp) -.. code-block:: none - - int v4l2_fh_release(struct file *filp) - - This deletes it from the struct video_device associated with the file - struct, uninitialised the v4l2_fh and frees it. - -These two functions can be plugged into the v4
[PATCH 04/11] [media] v4l2-event.rst: add cross-references and markups
Improve events documentation by adding cross references, sub-titles and other markup elements. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/v4l2-event.rst | 137 +++- 1 file changed, 81 insertions(+), 56 deletions(-) diff --git a/Documentation/media/kapi/v4l2-event.rst b/Documentation/media/kapi/v4l2-event.rst index 567ff7b1a3c2..0aed99459732 100644 --- a/Documentation/media/kapi/v4l2-event.rst +++ b/Documentation/media/kapi/v4l2-event.rst @@ -3,7 +3,7 @@ V4L2 events --- The V4L2 events provide a generic way to pass events to user space. -The driver must use v4l2_fh to be able to support V4L2 events. +The driver must use :c:type:`v4l2_fh` to be able to support V4L2 events. Events are defined by a type and an optional ID. The ID may refer to a V4L2 object such as a control ID. If unused, then the ID is 0. @@ -17,93 +17,118 @@ events of another type. But if you get more events of one type than the number of kevents that were reserved, then the oldest event will be dropped and the new one added. -Furthermore, the internal struct v4l2_subscribed_event has merge() and -replace() callbacks which drivers can set. These callbacks are called when -a new event is raised and there is no more room. The replace() callback -allows you to replace the payload of the old event with that of the new event, -merging any relevant data from the old payload into the new payload that -replaces it. It is called when this event type has only one kevent struct -allocated. The merge() callback allows you to merge the oldest event payload -into that of the second-oldest event payload. It is called when there are two -or more kevent structs allocated. +Furthermore, the internal struct :c:type:`v4l2_subscribed_event` has +``merge()`` and ``replace()`` callbacks which drivers can set. These +callbacks are called when a new event is raised and there is no more room. +The ``replace()`` callback allows you to replace the payload of the old event +with that of the new event, merging any relevant data from the old payload +into the new payload that replaces it. It is called when this event type has +only one kevent struct allocated. The ``merge()`` callback allows you to merge +the oldest event payload into that of the second-oldest event payload. It is +called when there are two or more kevent structs allocated. This way no status information is lost, just the intermediate steps leading up to that state. -A good example of these replace/merge callbacks is in v4l2-event.c: -ctrls_replace() and ctrls_merge() callbacks for the control event. +A good example of these ``replace``/``merge`` callbacks is in v4l2-event.c: +``ctrls_replace()`` and ``ctrls_merge()`` callbacks for the control event. -Note: these callbacks can be called from interrupt context, so they must be -fast. +.. note:: + these callbacks can be called from interrupt context, so they must + be fast. -Useful functions: +In order to queue events to video device, drivers should call: -.. code-block:: none + :cpp:func:`v4l2_event_queue ` + (:c:type:`vdev `, :ref:`ev `) - void v4l2_event_queue(struct video_device *vdev, const struct v4l2_event *ev) +The driver's only responsibility is to fill in the type and the data fields. +The other fields will be filled in by V4L2. - Queue events to video device. The driver's only responsibility is to fill - in the type and the data fields. The other fields will be filled in by - V4L2. +Event subscription +~~ -.. code-block:: none +Subscribing to an event is via: - int v4l2_event_subscribe(struct v4l2_fh *fh, -struct v4l2_event_subscription *sub, unsigned elems, -const struct v4l2_subscribed_event_ops *ops) + :cpp:func:`v4l2_event_subscribe ` + (:c:type:`fh `, :ref:`sub ` , + elems, :c:type:`ops `) - The video_device->ioctl_ops->vidioc_subscribe_event must check the driver - is able to produce events with specified event id. Then it calls - v4l2_event_subscribe() to subscribe the event. - The elems argument is the size of the event queue for this event. If it is 0, - then the framework will fill in a default value (this depends on the event - type). +This function is used to implement :c:type:`video_device`-> +:c:type:`ioctl_ops `-> ``vidioc_subscribe_event``, +but the driver must check first if the driver is able to produce events +with specified event id, and then should call +:cpp:func:`v4l2_event_subscribe` to subscribe the event. - The ops argument allows the driver to specify a number of callbacks: - * add: called when a new listener gets added (subscribing to the same - event twice will only cause this callback to get called once) - * del: called when a listener stops listening - * replace: replace event 'old' with event 'new'. - * merge: merge event 'old' into event 'new'.
[PATCH 09/11] [media] rename v4l2-framework.rst to v4l2-intro.rst
Now that the only remaining chapters at v4l2-framework are the introduction ones, let' s rename the file. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/v4l2-core.rst | 2 +- Documentation/media/kapi/{v4l2-framework.rst => v4l2-intro.rst} | 0 2 files changed, 1 insertion(+), 1 deletion(-) rename Documentation/media/kapi/{v4l2-framework.rst => v4l2-intro.rst} (100%) diff --git a/Documentation/media/kapi/v4l2-core.rst b/Documentation/media/kapi/v4l2-core.rst index c69d167bce7a..6285c18978d1 100644 --- a/Documentation/media/kapi/v4l2-core.rst +++ b/Documentation/media/kapi/v4l2-core.rst @@ -4,7 +4,7 @@ Video2Linux devices .. toctree:: :maxdepth: 1 -v4l2-framework +v4l2-intro v4l2-dev v4l2-controls v4l2-device diff --git a/Documentation/media/kapi/v4l2-framework.rst b/Documentation/media/kapi/v4l2-intro.rst similarity index 100% rename from Documentation/media/kapi/v4l2-framework.rst rename to Documentation/media/kapi/v4l2-intro.rst -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/11] [media] v4l2-event.h: document all functions
Several functions weren't documented. Document them all. While here, makes checkpatch.pl happy. Signed-off-by: Mauro Carvalho Chehab --- include/media/v4l2-event.h | 125 - 1 file changed, 113 insertions(+), 12 deletions(-) diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h index 9792f906423b..ca854203b8b9 100644 --- a/include/media/v4l2-event.h +++ b/include/media/v4l2-event.h @@ -73,14 +73,15 @@ struct video_device; * @list: List node for the v4l2_fh->available list. * @sev: Pointer to parent v4l2_subscribed_event. * @event: The event itself. - */ + */ struct v4l2_kevent { struct list_headlist; struct v4l2_subscribed_event *sev; struct v4l2_event event; }; -/** struct v4l2_subscribed_event_ops - Subscribed event operations. +/** + * struct v4l2_subscribed_event_ops - Subscribed event operations. * * @add: Optional callback, called when a new listener is added * @del: Optional callback, called when a listener stops listening @@ -88,20 +89,23 @@ struct v4l2_kevent { * @merge: Optional callback that can merge event 'old' into event 'new'. */ struct v4l2_subscribed_event_ops { - int (*add)(struct v4l2_subscribed_event *sev, unsigned elems); + int (*add)(struct v4l2_subscribed_event *sev, unsigned int elems); void (*del)(struct v4l2_subscribed_event *sev); void (*replace)(struct v4l2_event *old, const struct v4l2_event *new); void (*merge)(const struct v4l2_event *old, struct v4l2_event *new); }; /** - * struct v4l2_subscribed_event - Internal struct representing a subscribed event. + * struct v4l2_subscribed_event - Internal struct representing a subscribed + * event. + * * @list: List node for the v4l2_fh->subscribed list. * @type: Event type. * @id:Associated object ID (e.g. control ID). 0 if there isn't any. * @flags: Copy of v4l2_event_subscription->flags. * @fh:Filehandle that subscribed to this event. - * @node: List node that hooks into the object's event list (if there is one). + * @node: List node that hooks into the object's event list + * (if there is one). * @ops: v4l2_subscribed_event_ops * @elems: The number of elements in the events array. * @first: The index of the events containing the oldest available event. @@ -116,27 +120,124 @@ struct v4l2_subscribed_event { struct v4l2_fh *fh; struct list_headnode; const struct v4l2_subscribed_event_ops *ops; - unsignedelems; - unsignedfirst; - unsignedin_use; + unsigned intelems; + unsigned intfirst; + unsigned intin_use; struct v4l2_kevent events[]; }; +/** + * v4l2_event_dequeue - Dequeue events from video device. + * + * @fh: pointer to struct v4l2_fh + * @event: pointer to struct v4l2_event + * @nonblocking: if not zero, waits for an event to arrive + */ int v4l2_event_dequeue(struct v4l2_fh *fh, struct v4l2_event *event, int nonblocking); + +/** + * v4l2_event_queue - Queue events to video device. + * + * @vdev: pointer to &struct video_device + * @ev: pointer to &struct v4l2_event + * + * The event will be queued for all &struct v4l2_fh file handlers. + * + * .. note:: + *The driver's only responsibility is to fill in the type and the data + *fields.The other fields will be filled in by V4L2. + */ void v4l2_event_queue(struct video_device *vdev, const struct v4l2_event *ev); + +/** + * v4l2_event_queue_fh - Queue events to video device. + * + * @fh: pointer to &struct v4l2_fh + * @ev: pointer to &struct v4l2_event + * + * + * The event will be queued only for the specified &struct v4l2_fh file handler. + * + * .. note:: + *The driver's only responsibility is to fill in the type and the data + *fields.The other fields will be filled in by V4L2. + */ void v4l2_event_queue_fh(struct v4l2_fh *fh, const struct v4l2_event *ev); + +/** + * v4l2_event_pending - Check if an event is available + * + * @fh: pointer to &struct v4l2_fh + * + * Returns the number of pending events. + */ int v4l2_event_pending(struct v4l2_fh *fh); + +/** + * v4l2_event_subscribe - Subscribes to an event + * + * @fh: pointer to &struct v4l2_fh + * @sub: pointer to &struct v4l2_event_subscription + * @elems: size of the events queue + * @ops: pointer to &v4l2_subscribed_event_ops + * + * .. note:: + * + *if @elems is zero, the framework will fill in a default value, + *with is currently 1 element. + */ int v4l2_event_subscribe(struct v4l2_fh *fh, -const struct v4l2_event_subscription *sub, unsigned elems, +const struct v4l2_event_subscription *sub, +unsigned int elems,
[PATCH 01/11] [media] v4l2-framework.rst: remove videobuf quick chapter
As we merged the videobuf chapter at the kABI section, and it is a way more complete, just remove the small videobuf chapter that came from framework.txt. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/v4l2-framework.rst | 16 1 file changed, 16 deletions(-) diff --git a/Documentation/media/kapi/v4l2-framework.rst b/Documentation/media/kapi/v4l2-framework.rst index c97ffd0d783b..9204d9329124 100644 --- a/Documentation/media/kapi/v4l2-framework.rst +++ b/Documentation/media/kapi/v4l2-framework.rst @@ -80,22 +80,6 @@ The V4L2 framework also optionally integrates with the media framework. If a driver sets the struct v4l2_device mdev field, sub-devices and video nodes will automatically appear in the media framework as entities. - - -video buffer helper functions -- - -The v4l2 core API provides a set of standard methods (called "videobuf") -for dealing with video buffers. Those methods allow a driver to implement -read(), mmap() and overlay() in a consistent way. There are currently -methods for using video buffers on devices that supports DMA with -scatter/gather method (videobuf-dma-sg), DMA with linear access -(videobuf-dma-contig), and vmalloced buffers, mostly used on USB drivers -(videobuf-vmalloc). - -Please see Documentation/video4linux/videobuf for more information on how -to use the videobuf layer. - struct v4l2_fh -- -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/11] [media] doc-rst: reorganize the kAPI v4l2 chapters
Reorganize the order of the document, putting the chapters on a more logical order and renaming some sections. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/v4l2-common.rst | 4 Documentation/media/kapi/v4l2-controls.rst| 4 ++-- Documentation/media/kapi/v4l2-core.rst| 11 ++- Documentation/media/kapi/v4l2-dev.rst | 12 ++-- Documentation/media/kapi/v4l2-device.rst | 8 Documentation/media/kapi/v4l2-dv-timings.rst | 4 ++-- Documentation/media/kapi/v4l2-event.rst | 4 ++-- Documentation/media/kapi/v4l2-fh.rst | 5 +++-- Documentation/media/kapi/v4l2-flash-led-class.rst | 4 ++-- Documentation/media/kapi/v4l2-intro.rst | 15 --- Documentation/media/kapi/v4l2-mc.rst | 4 ++-- Documentation/media/kapi/v4l2-mediabus.rst| 4 ++-- Documentation/media/kapi/v4l2-mem2mem.rst | 5 +++-- Documentation/media/kapi/v4l2-rect.rst| 4 ++-- Documentation/media/kapi/v4l2-subdev.rst | 12 Documentation/media/kapi/v4l2-tuner.rst | 4 ++-- Documentation/media/kapi/v4l2-tveeprom.rst| 4 ++-- Documentation/media/kapi/v4l2-videobuf2.rst | 4 ++-- 18 files changed, 50 insertions(+), 62 deletions(-) create mode 100644 Documentation/media/kapi/v4l2-common.rst diff --git a/Documentation/media/kapi/v4l2-common.rst b/Documentation/media/kapi/v4l2-common.rst new file mode 100644 index ..d1ea1c9e35a0 --- /dev/null +++ b/Documentation/media/kapi/v4l2-common.rst @@ -0,0 +1,4 @@ +V4L2 common functions and data structures +^ + +.. kernel-doc:: include/media/v4l2-common.h diff --git a/Documentation/media/kapi/v4l2-controls.rst b/Documentation/media/kapi/v4l2-controls.rst index 2d433305fd4e..07a179eeb2fb 100644 --- a/Documentation/media/kapi/v4l2-controls.rst +++ b/Documentation/media/kapi/v4l2-controls.rst @@ -808,7 +808,7 @@ notify function is called. There can be only one notify function per control handler. Any attempt to set another notify function will cause a WARN_ON. -V4L2 control kAPI -- +v4l2_ctrl functions and data structures +--- .. kernel-doc:: include/media/v4l2-ctrls.h diff --git a/Documentation/media/kapi/v4l2-core.rst b/Documentation/media/kapi/v4l2-core.rst index 6285c18978d1..e9677150ed99 100644 --- a/Documentation/media/kapi/v4l2-core.rst +++ b/Documentation/media/kapi/v4l2-core.rst @@ -6,20 +6,21 @@ Video2Linux devices v4l2-intro v4l2-dev -v4l2-controls v4l2-device v4l2-fh +v4l2-subdev +v4l2-event +v4l2-controls +v4l2-videobuf +v4l2-videobuf2 v4l2-clocks v4l2-dv-timings -v4l2-event v4l2-flash-led-class v4l2-mc v4l2-mediabus v4l2-mem2mem v4l2-of v4l2-rect -v4l2-subdev v4l2-tuner +v4l2-common v4l2-tveeprom -v4l2-videobuf2 -v4l2-videobuf diff --git a/Documentation/media/kapi/v4l2-dev.rst b/Documentation/media/kapi/v4l2-dev.rst index 306306d8a43d..b03f9b33ad93 100644 --- a/Documentation/media/kapi/v4l2-dev.rst +++ b/Documentation/media/kapi/v4l2-dev.rst @@ -1,5 +1,5 @@ -Video device creation -= +Video device' s internal representation +=== The actual device nodes in the ``/dev`` directory are created using the :c:type:`video_device` struct (``v4l2-dev.h``). This struct can either be @@ -309,8 +309,8 @@ it has been initialized: This can be done from the release callback. -video_device helper functions -- +helper functions + There are a few useful helper functions: @@ -357,7 +357,7 @@ The name is used as a hint by userspace tools such as udev. The function should be used where possible instead of accessing the video_device::num and video_device::minor fields. -video_device kAPI -- +video_device functions and data structures +-- .. kernel-doc:: include/media/v4l2-dev.h diff --git a/Documentation/media/kapi/v4l2-device.rst b/Documentation/media/kapi/v4l2-device.rst index 8e275d0ff0f5..c9115bcd8a9d 100644 --- a/Documentation/media/kapi/v4l2-device.rst +++ b/Documentation/media/kapi/v4l2-device.rst @@ -1,5 +1,5 @@ -V4L2 Device register logic --- +V4L2 device instance + Each device instance is represented by a struct :c:type:`v4l2_device`. Very simple devices can just allocate this struct, but most of the time you @@ -138,7 +138,7 @@ Since the initial refcount is 1 you also need to call or in the ``remove()`` callback (for e.g. PCI devices), otherwise the refcount will never reach 0. -V4L2 device kAPI - +v4l2_device functions and data structures +^ .. kernel-doc:: include
[GIT PULL FOR v4.8] (v4) Various fixes
Hi Mauro, Another bunch of bug fixes for 4.8. The vb2 fix is particularly nasty, the others are all pretty trivial. Regards, Hans New for v4: dropped cleanup patches. Will be a separate pull request for 4.9. New for v3: added patch "cec: fix off-by-one memset" New for v2: added patch "staging: add MEDIA_SUPPORT dependency" The following changes since commit 009a620848218d521f008141c62f56bf19294dd9: [media] cec: always check all_device_types and features (2016-07-19 13:27:46 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.8a for you to fetch changes up to 58ef16e4ff962d4d7903527f3571ff4723ead1b8: cec: fix off-by-one memset (2016-07-22 17:23:29 +0200) Arnd Bergmann (1): staging: add MEDIA_SUPPORT dependency Hans Verkuil (5): adv7511: fix VIC autodetect vim2m: copy the other colorspace-related fields as well vivid: don't handle CEC_MSG_SET_STREAM_PATH airspy: fix compiler warning cec: fix off-by-one memset Steve Longerbeam (1): media: adv7180: Fix broken interrupt register access Vincent Stehlé (1): vb2: Fix allocation size of dma_parms drivers/media/i2c/adv7180.c| 18 +- drivers/media/i2c/adv7511.c| 24 drivers/media/platform/vim2m.c | 15 ++- drivers/media/platform/vivid/vivid-cec.c | 10 -- drivers/media/usb/airspy/airspy.c | 1 - drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +- drivers/staging/media/Kconfig | 2 +- drivers/staging/media/cec/cec-adap.c | 2 +- 8 files changed, 46 insertions(+), 28 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [dvbv5-scan] wait no more than timeout when scanning
some frontends (mentioned on lgdt3306a) wait timeout inside code like: for (i = 20; i > 0; i--) { msleep(50); If there is no-LOCK then dvbv5-scan spent a lot of time (doing 40x calls). This patch introduce timeout which 4 sec * multiply. So we do not wait more than 4 sec (or so) if no-LOCK. Signed-off-by: Abylay Ospan --- utils/dvb/dvbv5-scan.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/utils/dvb/dvbv5-scan.c b/utils/dvb/dvbv5-scan.c index 689bc0b..1fc33d7 100644 --- a/utils/dvb/dvbv5-scan.c +++ b/utils/dvb/dvbv5-scan.c @@ -182,12 +182,23 @@ static int print_frontend_stats(struct arguments *args, return 0; } +/* return timestamp in msec */ +uint64_t get_timestamp() +{ + struct timeval now; + gettimeofday(&now, 0); + return now.tv_sec * 1000 + now.tv_usec/1000; +} + static int check_frontend(void *__args, struct dvb_v5_fe_parms *parms) { struct arguments *args = __args; int rc, i; fe_status_t status; + uint64_t start = get_timestamp(); + /* msec timeout by default 4 sec * multiply */ + uint64_t timeout = args->timeout_multiply * 4 * 1000; args->n_status_lines = 0; for (i = 0; i < args->timeout_multiply * 40; i++) { @@ -203,6 +214,10 @@ static int check_frontend(void *__args, print_frontend_stats(args, parms); if (status & FE_HAS_LOCK) break; + + if ((get_timestamp() - start) > timeout) + break; + usleep(10); }; -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] [media] Documentation: Fix V4L2_CTRL_FLAG_VOLATILE
V4L2_CTRL_FLAG_VOLATILE behaviour when V4L2_CTRL_FLAG_EXECUTE_ON_WRITE is set was not properly explained. Also set some hyperlink to ease the Documentation browsing. Reported-by: Dimitrios Katsaros Credit-to: Hans Verkuil Signed-off-by: Ricardo Ribalda Delgado --- v2: By Hans Verkuil -Fix some syntax errors By Mauro Carvalho Chehab -Add hyperlinks Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst index 8d6e61a7284d..22475f484cb3 100644 --- a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst +++ b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst @@ -728,10 +728,12 @@ See also the examples in :ref:`control`. case the hardware calculates the gain value based on the lighting conditions which can change over time. - .. note:: Setting a new value for a volatile control will have no -effect and no ``V4L2_EVENT_CTRL_CH_VALUE`` will be sent, unless -the ``V4L2_CTRL_FLAG_EXECUTE_ON_WRITE`` flag (see below) is -also set. Otherwise the new value will just be ignored. + .. note:: Setting a new value for a volatile control will be ignored + unless + :ref:`V4L2_CTRL_FLAG_EXECUTE_ON_WRITE ` + is also set. + Setting a new value for a volatile control will *never* trigger a + :ref:`V4L2_EVENT_CTRL_CH_VALUE ` event. - .. row 9 @@ -747,6 +749,7 @@ See also the examples in :ref:`control`. payload of the control. - .. row 10 + .. _FLAG_EXECUTE_ON_WRITE: - ``V4L2_CTRL_FLAG_EXECUTE_ON_WRITE`` -- 2.8.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] [dvbv5-scan] wait no more than timeout when scanning
Hi Abylay, Em Fri, 22 Jul 2016 13:54:37 -0400 Abylay Ospan escreveu: > some frontends (mentioned on lgdt3306a) wait timeout inside code like: > for (i = 20; i > 0; i--) { > msleep(50); > > If there is no-LOCK then dvbv5-scan spent a lot of time (doing 40x calls). > This patch introduce timeout which 4 sec * multiply. So we do not wait more > than 4 sec (or so) if no-LOCK. > > Signed-off-by: Abylay Ospan > --- > utils/dvb/dvbv5-scan.c | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/utils/dvb/dvbv5-scan.c b/utils/dvb/dvbv5-scan.c > index 689bc0b..1fc33d7 100644 > --- a/utils/dvb/dvbv5-scan.c > +++ b/utils/dvb/dvbv5-scan.c > @@ -182,12 +182,23 @@ static int print_frontend_stats(struct arguments *args, > return 0; > } > > +/* return timestamp in msec */ > +uint64_t get_timestamp() > +{ > + struct timeval now; > + gettimeofday(&now, 0); > + return now.tv_sec * 1000 + now.tv_usec/1000; This is not good, as gettimeofday() is not monotonic, and may be affected by clock adjustments. IMHO, the best would be to adjust the do_timeout() to handle args->timeout_multiply. Regards, Mauro > +} > + > static int check_frontend(void *__args, > struct dvb_v5_fe_parms *parms) > { > struct arguments *args = __args; > int rc, i; > fe_status_t status; > + uint64_t start = get_timestamp(); > + /* msec timeout by default 4 sec * multiply */ > + uint64_t timeout = args->timeout_multiply * 4 * 1000; > > args->n_status_lines = 0; > for (i = 0; i < args->timeout_multiply * 40; i++) { > @@ -203,6 +214,10 @@ static int check_frontend(void *__args, > print_frontend_stats(args, parms); > if (status & FE_HAS_LOCK) > break; > + > + if ((get_timestamp() - start) > timeout) > + break; > + > usleep(10); It would also make sense to remove the usleep here and use something else that would be checking timeout_flag, like: for (i = 1; i < 100; i++) { if (timeout_flag) break; usleep(1000); } -- Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/4] media: adv7604: automatic "default-input" selection
On 07/22/2016 12:09 PM, Ulrich Hecht wrote: Fall back to input 0 if "default-input" property is not present. Additionally, documentation in commit bf9c82278c34 ("[media] media: adv7604: ability to read default input port from DT") states that the "default-input" property should reside directly in the node for adv7612. Hence, also adjust the parsing to make the implementation consistent with this. Based on patch by William Towle . Signed-off-by: Ulrich Hecht --- drivers/media/i2c/adv7604.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index 4003831..055c9df 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -3077,10 +3077,13 @@ static int adv76xx_parse_dt(struct adv76xx_state *state) if (!of_property_read_u32(endpoint, "default-input", &v)) state->pdata.default_input = v; else - state->pdata.default_input = -1; + state->pdata.default_input = 0; of_node_put(endpoint); + if (!of_property_read_u32(np, "default-input", &v)) + state->pdata.default_input = v; of_property_read_u32(np, "default-input", &state->pdata.default_input)); should be equivalent... MBR, Sergei -- 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] vb2: move dma-buf unmap from __vb2_dqbuf() to vb2_buffer_done()
On 20/07/16 19:22, Javier Martinez Canillas wrote: > Currently the dma-buf is unmapped when the buffer is dequeued by userspace > but it's not used anymore after the driver finished processing the buffer. > > So instead of doing the dma-buf unmapping in __vb2_dqbuf(), it can be made > in vb2_buffer_done() after the driver notified that buf processing is done. > > Decoupling the buffer dequeue from the dma-buf unmapping has also the side > effect of making possible to add dma-buf fence support in the future since > the buffer could be dequeued even before the driver has finished using it. > > Signed-off-by: Javier Martinez Canillas > > --- > Hello, > > I've tested this patch doing DMA buffer sharing between a > vivid input and output device with both v4l2-ctl and gst: > > $ v4l2-ctl -d0 -e1 --stream-dmabuf --stream-out-mmap > $ v4l2-ctl -d0 -e1 --stream-mmap --stream-out-dmabuf > $ gst-launch-1.0 v4l2src device=/dev/video0 io-mode=dmabuf ! v4l2sink > device=/dev/video1 io-mode=dmabuf-import > > And I didn't find any issues but more testing will be appreciated. > > Best regards, > Javier > Hello all, Tested this using the same GStreamer pipeline as Javier mentions above. It works nicely. Thanks, Luis Tested-by: Luis de Bethencourt -- 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: Sony imx219 driver?
Hi Hans. On 22/07/16 10:46, Hans Verkuil wrote: On 07/21/2016 08:19 PM, Dave Stevenson wrote: Hi All. Just a quick query to avoid duplicating effort. Has anyone worked on a Sony IMX219 (or other Sony sensor) subdevice driver as yet? Not that I am aware of. OK, glad to hear I won't be duplicating effort. With the new Raspberry Pi camera being IMX219, and as Broadcom have released an soc_camera based driver for the sensor already (https://android.googlesource.com/kernel/bcm/+/android-bcm-tetra-3.10-lollipop-wear-release/drivers/media/video/imx219.c) #@!@$! Why do they never ever ask us what would be a good example driver to use. The soc-camera framework is deprecated and will likely be gone by the end of the year. Yes, a touch grim. I'm aware of the project it was done for from my time at Broadcom but wasn't directly involved. Partly in their defence: (a) It was almost 3 years ago. (b) It's on top of a 3.10 kernel, so lots of the nicer features that are now present just weren't there. (c) However they did bastardise even soc_camera to extract extra info from the sensor driver for some of their upper layers. Not so nice. I was going to investigate converting that to a subdevice. I just wanted to check this wasn't already in someone else's work queue. A further Google shows that there's also an soc_camera IMX219 driver in ChromiumOS, copyright Andrew Chew @ Nvidia, but author Guennadi Liakhovetski who I know posts on here. https://chromium.googlesource.com/chromiumos/third_party/kernel/+/factory-ryu-6486.14.B-chromeos-3.14/drivers/media/i2c/soc_camera/imx219.c. At least for the tegra there is a proper non-soc-camera driver in the works. non-soc-camera driver for imx219, or for the tegra hardware blocks? I'm assuming the latter based on you saying you're not aware of an imx219 driver being in progress. As I have mentioned before, the other half of my playing is a subdevice driver for the CSI2 receiver on Pi. That bcm android kernel tree also released all the info needed for that block into the public domain, so I'm not even breaching NDAs in doing so :-) I hope to test my imx219 driver against that. The Broadcom one supports 8MPix and 1080P, the Chromium one only 8MP. Perhaps a hybrid of the feature set? They usually only implement what they need, so I'd say for chromium they only needed 8MP support. Throw in https://github.com/ZenfoneArea/android_kernel_asus_zenfone5/blob/master/linux/modules/camera/drivers/media/i2c/imx219/imx219.h as well, and we have register sets for numerous readout modes, plus there are the ones in the Pi firmware which can be extracted if necessary. With all that code it shouldn't be hard to write a proper subdev driver. Indeed. I'll try to put something together and submit it to the list. I don't know what my timescales will end up being on it though. On a related note, if putting together a system with IMX219 or similar producing Bayer raw 10, the data on the CSI2 bus is one of the V4L2_PIX_FMT_SRGGB10P formats. What's the correct way to reflect that from the sensor subdevice in an MEDIA_BUS_FMT_ enum? The closest is MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_BE (or LE), but the data isn't padded (the Pi CSI2 receiver can do the unpacking and padding, but that just takes up more memory). Or is it MEDIA_BUS_FMT_SBGGR10_1X10 to describe the data on the bus correctly as 10bpp Bayer, and the odd packing is ignored. Or do we need new enums? Just add new enums to media-bus-format.h. It should be clear from comments and/or the naming of the enum what the exact format it, so you'll need to think about that carefully. Otherwise it's no big deal to add new formats there. OK, will do. I wasn't clear from reading the docs how accurately MEDIA_BUS_FMT_ was describing the pixel layout as it mentions NOT having a 1:1 mapping with V4L2_PIX_FMT_ enums. Having the clarification is great. Thanks for the advice. Dave -- 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] doc-rst: kernel-doc: fix handling of address_space tags
On Fri, 22 Jul 2016 11:46:36 -0300 Mauro Carvalho Chehab wrote: > The RST cpp:function handler is very pedantic: it doesn't allow any > macros like __user on it: > [...] > So, we have to remove it from the function prototype. Sigh, this is the kind of thing where somehow there's always more moles to whack. I feel like there must be a better fix, but I don't know what it is, so I've applied this, thanks. I'm trying to get my act together so that the pull request can go in right away once the merge window opens. If there's anything else you think really needs to be there, please do let me know. jon -- 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 v8 0/10] Output raw touch data via V4L2
I'm not Nick, but I'm testing his patches. ;-) Here's what I'm getting from v4l2-compliance with his patches: root@RDU2:/mnt/disk ./v4l2-compliance -a -f -d /dev/v4l-touch0 Driver Info: Driver name : rmi4_f54 Card type : Synaptics RMI4 Touch Sensor Bus info : rmi4:rmi4-00.fn54 Driver version: 4.7.0 Capabilities : 0x9521 Video Capture Touch Capture Read/Write Streaming Extended Pix Format Device Capabilities Device Caps : 0x1521 Video Capture Touch Capture Read/Write Streaming Extended Pix Format Compliance test for device /dev/v4l-touch0 (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 test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 5 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) Test input 0: Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported) test VIDIOC_QUERYCTRL: OK (Not Supported) test VIDIOC_G/S_CTRL: OK (Not Supported) test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK Test input 1: Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported) test VIDIOC_QUERYCTRL: OK (Not Supported) test VIDIOC_G/S_CTRL: OK (Not Supported) test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK Test input 2: Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported) test VIDIOC_QUERYCTRL: OK (Not Supported) test VIDIOC_G/S_CTRL: OK (Not Supported) test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK Test input 3: Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported) test VIDIOC_QUERYCTRL: OK (Not Supported) test VIDIOC_G/S_CTRL: OK (Not Supported) test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK t
Re: [PATCH] doc-rst: kernel-doc: fix handling of address_space tags
Em Fri, 22 Jul 2016 15:37:16 -0600 Jonathan Corbet escreveu: > On Fri, 22 Jul 2016 11:46:36 -0300 > Mauro Carvalho Chehab wrote: > > > The RST cpp:function handler is very pedantic: it doesn't allow any > > macros like __user on it: > > [...] > > So, we have to remove it from the function prototype. > > Sigh, this is the kind of thing where somehow there's always more moles > to whack. Agreed. > I feel like there must be a better fix, Well, we might create a "kernel-c" domain, I guess. I suspect we'll need something like that anyway, in order to handle things like per-subsystem declarations of the syscalls (specially ioctl), but I've no idea how difficult would be to do so. For now, I guess that's the easiest fix. > but I don't know what > it is, so I've applied this, thanks. Thank you! > I'm trying to get my act together so that the pull request can go in > right away once the merge window opens. If there's anything else you > think really needs to be there, please do let me know. I suspect that that's it. There are a few trivial conflicts between my tree and Daniel's one, as we both are adding new books at Documentation/index.rst, but this is something that Stephen already handled, and should be easy for Linus to handle as well. Yet, if you prefer, you could pull from my docs-next branch, but there are also lots of subsystem's patch on that, merged from my master (stable) branch. So, if you pull from it and send to Linus before me, you'll also be sending patches from the media subsystem. Not really an issue, as, if Linus pull from my tree later, he'll get only the few remains that aren't merged at my docs-next branch. Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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: Sat Jul 23 04:00:17 CEST 2016 git branch: test git hash: 009a620848218d521f008141c62f56bf19294dd9 gcc version:i686-linux-gcc (GCC) 5.3.0 sparse version: v0.5.0-56-g7647c77 smatch version: v0.5.0-3428-gdfe27cf host hardware: x86_64 host os:4.6.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-blackfin-bf561: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: WARNINGS linux-3.12.23-i686: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0-i686: WARNINGS linux-4.1.1-i686: WARNINGS linux-4.2-i686: WARNINGS linux-4.3-i686: WARNINGS linux-4.4-i686: WARNINGS linux-4.5-i686: WARNINGS linux-4.6-i686: WARNINGS linux-4.7-rc1-i686: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: WARNINGS linux-3.12.23-x86_64: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0-x86_64: WARNINGS linux-4.1.1-x86_64: WARNINGS linux-4.2-x86_64: WARNINGS linux-4.3-x86_64: WARNINGS linux-4.4-x86_64: WARNINGS linux-4.5-x86_64: WARNINGS linux-4.6-x86_64: WARNINGS linux-4.7-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse: WARNINGS smatch: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] [media] v4l2-ctrls.h: fully document the header file
There are lots of undocumented stuff on this header. Document them. Signed-off-by: Mauro Carvalho Chehab --- include/media/v4l2-ctrls.h | 365 ++--- 1 file changed, 279 insertions(+), 86 deletions(-) diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h index d6f63406b885..178a88d45aea 100644 --- a/include/media/v4l2-ctrls.h +++ b/include/media/v4l2-ctrls.h @@ -1,21 +1,17 @@ /* -V4L2 controls support header. - -Copyright (C) 2010 Hans Verkuil - -This program is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2 of the License, or -(at your option) any later version. - -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. - -You should have received a copy of the GNU General Public License -along with this program; if not, write to the Free Software -Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * V4L2 controls support header. + * + * Copyright (C) 2010 Hans Verkuil + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * 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. */ #ifndef _V4L2_CTRLS_H @@ -58,6 +54,7 @@ union v4l2_ctrl_ptr { /** * struct v4l2_ctrl_ops - The control operations that the driver has to provide. + * * @g_volatile_ctrl: Get a new value for this control. Generally only relevant * for volatile (and usually read-only) controls such as a control * that returns the current signal strength which changes @@ -77,12 +74,13 @@ struct v4l2_ctrl_ops { /** * struct v4l2_ctrl_type_ops - The control type operations that the driver - *has to provide. + *has to provide. * * @equal: return true if both values are equal. * @init: initialize the value. * @log: log the value. - * @validate: validate the value. Return 0 on success and a negative value otherwise. + * @validate: validate the value. Return 0 on success and a negative value + * otherwise. */ struct v4l2_ctrl_type_ops { bool (*equal)(const struct v4l2_ctrl *ctrl, u32 idx, @@ -99,6 +97,7 @@ typedef void (*v4l2_ctrl_notify_fnc)(struct v4l2_ctrl *ctrl, void *priv); /** * struct v4l2_ctrl - The control structure. + * * @node: The list node. * @ev_subs: The list of control event subscriptions. * @handler: The handler that owns the control. @@ -106,7 +105,7 @@ typedef void (*v4l2_ctrl_notify_fnc)(struct v4l2_ctrl *ctrl, void *priv); * @ncontrols: Number of controls in cluster array. * @done: Internal flag: set for each processed control. * @is_new:Set when the user specified a new value for this control. It - * is also set when called from v4l2_ctrl_handler_setup. Drivers + * is also set when called from v4l2_ctrl_handler_setup(). Drivers * should never set this flag. * @has_changed: Set when the current value differs from the new value. Drivers * should never use this flag. @@ -119,9 +118,10 @@ typedef void (*v4l2_ctrl_notify_fnc)(struct v4l2_ctrl *ctrl, void *priv); * set this flag directly. * @is_int:If set, then this control has a simple integer value (i.e. it * uses ctrl->val). - * @is_string: If set, then this control has type V4L2_CTRL_TYPE_STRING. - * @is_ptr:If set, then this control is an array and/or has type >= V4L2_CTRL_COMPOUND_TYPES - * and/or has type V4L2_CTRL_TYPE_STRING. In other words, struct + * @is_string: If set, then this control has type %V4L2_CTRL_TYPE_STRING. + * @is_ptr:If set, then this control is an array and/or has type >= + * %V4L2_CTRL_COMPOUND_TYPES + * and/or has type %V4L2_CTRL_TYPE_STRING. In other words, &struct * v4l2_ext_control uses field p to point to the data. * @is_array: If set, then this control contains an N-dimensional array. * @has_volatiles: If set, then one or more members of the cluster are volatile. @@ -177,7 +177,8 @@ struct v4l2_ctrl { struct list_head ev_subs; struct v4l2_ctrl_handler *handler; struct v4l2_ctrl **cluster; - unsigned ncontrols; + unsigned int ncontrols; + unsigned int done:1;
[PATCH 2/3] [media] dvb_ringbuffer.h: some documentation improvements
Better document a note on this header. While here, better format dvb_ringbuffer_pkt_read_user() to adjust it to CodingStyle. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/dvb-core/dvb_ringbuffer.h | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/media/dvb-core/dvb_ringbuffer.h b/drivers/media/dvb-core/dvb_ringbuffer.h index 3ebc2d34b4a2..8af642399f1e 100644 --- a/drivers/media/dvb-core/dvb_ringbuffer.h +++ b/drivers/media/dvb-core/dvb_ringbuffer.h @@ -150,9 +150,6 @@ extern ssize_t dvb_ringbuffer_pkt_write(struct dvb_ringbuffer *rbuf, u8* buf, /** * dvb_ringbuffer_pkt_read_user - Read from a packet in the ringbuffer. - * Note: unlike dvb_ringbuffer_read(), this does NOT update the read pointer - * in the ringbuffer. You must use dvb_ringbuffer_pkt_dispose() to mark a - * packet as no longer required. * * @rbuf: Ringbuffer concerned. * @idx: Packet index as returned by dvb_ringbuffer_pkt_next(). @@ -161,9 +158,17 @@ extern ssize_t dvb_ringbuffer_pkt_write(struct dvb_ringbuffer *rbuf, u8* buf, * @len: Size of destination buffer. * * returns Number of bytes read, or -EFAULT. + * + * .. note:: + * + *unlike dvb_ringbuffer_read(), this does **NOT** update the read pointer + *in the ringbuffer. You must use dvb_ringbuffer_pkt_dispose() to mark a + *packet as no longer required. */ -extern ssize_t dvb_ringbuffer_pkt_read_user(struct dvb_ringbuffer *rbuf, size_t idx, - int offset, u8 __user *buf, size_t len); +extern ssize_t dvb_ringbuffer_pkt_read_user(struct dvb_ringbuffer *rbuf, + size_t idx, + int offset, u8 __user *buf, + size_t len); /** * dvb_ringbuffer_pkt_read - Read from a packet in the ringbuffer. -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] [media] v4l2-ioctl.h add debug info for struct v4l2_ioctl_ops
This struct is mentioned at the kAPI docbook. So, let's document it. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/v4l2-common.rst | 2 + include/media/v4l2-ioctl.h | 266 +++ 2 files changed, 268 insertions(+) diff --git a/Documentation/media/kapi/v4l2-common.rst b/Documentation/media/kapi/v4l2-common.rst index d1ea1c9e35a0..525d804871ff 100644 --- a/Documentation/media/kapi/v4l2-common.rst +++ b/Documentation/media/kapi/v4l2-common.rst @@ -2,3 +2,5 @@ V4L2 common functions and data structures ^ .. kernel-doc:: include/media/v4l2-common.h + +.. kernel-doc:: include/media/v4l2-ioctl.h diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h index 017ffb2220c7..8b1d19bc9b0e 100644 --- a/include/media/v4l2-ioctl.h +++ b/include/media/v4l2-ioctl.h @@ -17,6 +17,272 @@ struct v4l2_fh; +/** + * struct v4l2_ioctl_ops - describe operations for each V4L2 ioctl + * + * @vidioc_querycap: pointer to the function that implements + * :ref:`VIDIOC_QUERYCAP ` ioctl + * @vidioc_enum_fmt_vid_cap: pointer to the function that implements + * :ref:`VIDIOC_ENUM_FMT ` ioctl logic + * for video capture in single plane mode + * @vidioc_enum_fmt_vid_overlay: pointer to the function that implements + * :ref:`VIDIOC_ENUM_FMT ` ioctl logic + * for video overlay + * @vidioc_enum_fmt_vid_out: pointer to the function that implements + * :ref:`VIDIOC_ENUM_FMT ` ioctl logic + * for video output in single plane mode + * @vidioc_enum_fmt_vid_cap_mplane: pointer to the function that implements + * :ref:`VIDIOC_ENUM_FMT ` ioctl logic + * for video capture in multiplane mode + * @vidioc_enum_fmt_vid_out_mplane: pointer to the function that implements + * :ref:`VIDIOC_ENUM_FMT ` ioctl logic + * for video output in multiplane mode + * @vidioc_enum_fmt_sdr_cap: pointer to the function that implements + * :ref:`VIDIOC_ENUM_FMT ` ioctl logic + * for Software Defined Radio capture + * @vidioc_enum_fmt_sdr_out: pointer to the function that implements + * :ref:`VIDIOC_ENUM_FMT ` ioctl logic + * for Software Defined Radio output + * @vidioc_g_fmt_vid_cap: pointer to the function that implements + * :ref:`VIDIOC_G_FMT ` ioctl logic for video capture + * in single plane mode + * @vidioc_g_fmt_vid_overlay: pointer to the function that implements + * :ref:`VIDIOC_G_FMT ` ioctl logic for video overlay + * @vidioc_g_fmt_vid_out: pointer to the function that implements + * :ref:`VIDIOC_G_FMT ` ioctl logic for video out + * in single plane mode + * @vidioc_g_fmt_vid_out_overlay: pointer to the function that implements + * :ref:`VIDIOC_G_FMT ` ioctl logic for video overlay output + * @vidioc_g_fmt_vbi_cap: pointer to the function that implements + * :ref:`VIDIOC_G_FMT ` ioctl logic for raw VBI capture + * @vidioc_g_fmt_vbi_out: pointer to the function that implements + * :ref:`VIDIOC_G_FMT ` ioctl logic for raw VBI output + * @vidioc_g_fmt_sliced_vbi_cap: pointer to the function that implements + * :ref:`VIDIOC_G_FMT ` ioctl logic for sliced VBI capture + * @vidioc_g_fmt_sliced_vbi_out: pointer to the function that implements + * :ref:`VIDIOC_G_FMT ` ioctl logic for sliced VBI output + * @vidioc_g_fmt_vid_cap_mplane: pointer to the function that implements + * :ref:`VIDIOC_G_FMT ` ioctl logic for video capture + * in multiple plane mode + * @vidioc_g_fmt_vid_out_mplane: pointer to the function that implements + * :ref:`VIDIOC_G_FMT ` ioctl logic for video out + * in multiplane plane mode + * @vidioc_g_fmt_sdr_cap: pointer to the function that implements + * :ref:`VIDIOC_G_FMT ` ioctl logic for Software Defined + * Radio capture + * @vidioc_g_fmt_sdr_out: pointer to the function that implements + * :ref:`VIDIOC_G_FMT ` ioctl logic for Software Defined + * Radio output + * @vidioc_s_fmt_vid_cap: pointer to the function that implements + * :ref:`VIDIOC_S_FMT ` ioctl logic for video capture + * in single plane mode + * @vidioc_s_fmt_vid_overlay: pointer to the function that implements + * :ref:`VIDIOC_S_FMT ` ioctl logic for video overlay + * @vidioc_s_fmt_vid_out: pointer to the function that implements + * :ref:`VIDIOC_S_FMT ` ioctl logic for video out + * in single plane mode + * @vidioc_s_fmt_vid_out_overlay: pointer to the function that implements + * :ref:`VIDIOC_S_FMT ` ioctl logic for video overlay output + * @vidioc_s_fmt_vbi_cap: pointer to the function that implements + * :ref:`VIDIOC_S_FMT ` ioctl logic for raw VBI capture + * @vidioc_s_fmt_vbi_out: pointer to the function that implements + * :ref:`VIDIOC_S_FMT ` ioctl logic for raw VBI output + * @vidioc_s_fmt_sliced_vbi_cap: pointer to the function that implements + * :ref:`VIDIOC_S_FMT ` ioctl logic for sliced VBI capture + * @vidioc_s_fmt_sliced_vbi_out: pointer to the function that implements + * :ref:`