date:20160722



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"

2016-07-22 Thread Krzysztof Hałasa

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

2016-07-22 Thread Markus Heiser


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

2016-07-22 Thread Sakari Ailus


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

2016-07-22 Thread Ricardo Ribalda Delgado

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

2016-07-22 Thread Abylay Ospan

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

2016-07-22 Thread Ricardo Ribalda Delgado

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

2016-07-22 Thread Sergei Shtylyov


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()

2016-07-22 Thread Luis de Bethencourt

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?

2016-07-22 Thread Dave Stevenson

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

2016-07-22 Thread Jonathan Corbet

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

2016-07-22 Thread Chris Healy

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