cron job: media_tree daily build: OK
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 Aug 11 05:00:09 CEST 2018 media-tree git hash:da2048b7348a0be92f706ac019e022139e29495e media_build git hash: baf45935ffad914f33faf751ad9f4d0dd276c021 v4l-utils git hash: 90905c2e4b17d7595256f3824e2d30d19b0df1a1 edid-decode git hash: ab18befbcacd6cd4dff63faa82e32700369d6f25 gcc version:i686-linux-gcc (GCC) 8.1.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.16.0-1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-2.6.36.4-i686: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-i686: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-i686: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-i686: OK linux-2.6.39.4-x86_64: OK linux-3.0.101-i686: OK linux-3.0.101-x86_64: OK linux-3.1.10-i686: OK linux-3.1.10-x86_64: OK linux-3.2.102-i686: OK linux-3.2.102-x86_64: OK linux-3.3.8-i686: OK linux-3.3.8-x86_64: OK linux-3.4.113-i686: OK linux-3.4.113-x86_64: OK linux-3.5.7-i686: OK linux-3.5.7-x86_64: OK linux-3.6.11-i686: OK linux-3.6.11-x86_64: OK linux-3.7.10-i686: OK linux-3.7.10-x86_64: OK linux-3.8.13-i686: OK linux-3.8.13-x86_64: OK linux-3.9.11-i686: OK linux-3.9.11-x86_64: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.57-i686: OK linux-3.16.57-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.115-i686: OK linux-3.18.115-x86_64: OK linux-3.19.8-i686: OK linux-3.19.8-x86_64: OK linux-4.0.9-i686: OK linux-4.0.9-x86_64: OK linux-4.1.52-i686: OK linux-4.1.52-x86_64: OK linux-4.2.8-i686: OK linux-4.2.8-x86_64: OK linux-4.3.6-i686: OK linux-4.3.6-x86_64: OK linux-4.4.140-i686: OK linux-4.4.140-x86_64: OK linux-4.5.7-i686: OK linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: OK linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.112-i686: OK linux-4.9.112-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.55-i686: OK linux-4.14.55-x86_64: OK linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.6-i686: OK linux-4.17.6-x86_64: OK linux-4.18-rc4-i686: OK linux-4.18-rc4-x86_64: OK apps: OK spec-git: OK sparse: 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/index.html
RE: [PATCH v1 2/2] v4l: Document Intel IPU3 meta data uAPI
Hi Mauro, Hans, > -Original Message- > From: Tomasz Figa [mailto:tf...@chromium.org] > Sent: Wednesday, July 18, 2018 7:53 AM > To: Hans Verkuil ; Mauro Carvalho Chehab > > Cc: Zhi, Yong ; Sakari Ailus > ; Linux Media Mailing List me...@vger.kernel.org>; Laurent Pinchart > ; Mani, Rajmohan > ; Zheng, Jian Xu ; Hu, > Jerry W ; Li, Chao C ; Qiu, Tian > Shu > Subject: Re: [PATCH v1 2/2] v4l: Document Intel IPU3 meta data uAPI > > Hi Mauro, Hans, > > On Fri, Jun 15, 2018 at 12:30 PM Yong Zhi wrote: > > > > These meta formats are used on Intel IPU3 ImgU video queues to carry > > 3A statistics and ISP pipeline parameters. > > > > V4L2_META_FMT_IPU3_3A > > V4L2_META_FMT_IPU3_PARAMS > > > > Signed-off-by: Yong Zhi > > Signed-off-by: Chao C Li > > Signed-off-by: Rajmohan Mani > > --- > > Documentation/media/uapi/v4l/meta-formats.rst |1 + > > .../media/uapi/v4l/pixfmt-meta-intel-ipu3.rst | 174 ++ > > include/uapi/linux/intel-ipu3.h| 2816 > > > > The documentation seems to be quite extensive in current version. Do you > think it's more acceptable now? Would you be able to take a look? Hope you had a chance to look into this current version of IPU3 documentation. Please share your thoughts. Thanks Raj > > We obviously need to keep working on the user space framework (and we're in > process of figuring out how we can proceed further), but having the driver > bit- > rotting downstream might not be a very encouraging factor. ;) > > Best regards, > Tomasz
we the editing
Your photos need editing. We can do it for you. We do editing for e-commerce photos, jewelries images and portrait photos etc. This will include cutout and clipping path etc , also retouching if needed. Let;s know if you want to send photos for working. We can do test on your photos. Thanks, Kelly
this here for you
Your photos need editing. We can do it for you. We do editing for e-commerce photos, jewelries images and portrait photos etc. This will include cutout and clipping path etc , also retouching if needed. Let;s know if you want to send photos for working. We can do test on your photos. Thanks, Kelly
Re: [PATCH 3/3] media: imx-pxp: add i.MX Pixel Pipeline driver
On Fri, 2018-08-10 at 17:18 +0200, Philipp Zabel wrote: > Add a V4L2 mem-to-mem scaler/CSC driver for the Pixel Pipeline (PXP) > version found on i.MX6ULL SoCs. A similar variant is used on i.MX7D. > > Since this driver only uses the legacy pipeline, it should be reasonably > easy to extend it to work with the older PXP versions found on i.MX6UL, > i.MX6SX, i.MX6SL, i.MX28, and i.MX23. > > The driver supports scaling and colorspace conversion. There is > currently no support for rotation, alpha-blending, and the LUTs. > > Signed-off-by: Philipp Zabel FWIW for mem2mem devices, here is the output of v4l2-compliance, built from v4l-utils-1.14.0-249-g70b13df426d3: --8<-- v4l2-compliance SHA: not available, 32 bits Compliance test for device /dev/video0: Driver Info: Driver name : pxp Card type: pxp Bus info : platform:pxp Driver version : 4.18.0 Capabilities : 0x84208000 Video Memory-to-Memory Streaming Extended Pix Format Device Capabilities Device Caps : 0x04208000 Video Memory-to-Memory Streaming Extended Pix Format Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second /dev/video0 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 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: 4 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 (Not Supported) test Composing: OK (Not Supported) test Scaling: OK 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 Total: 43, Succeeded: 43, Failed: 0, Warnings: 0 -->8-- regards Philipp
[PATCH 0/3] i.MX PXP scaler/CSC driver
The Pixel Pipeline (PXP) is a memory-to-memory graphics processing engine that supports scaling, colorspace conversion, alpha blending, rotation, and pixel conversion via lookup table. Different versions are present on various i.MX SoCs from i.MX23 to i.MX7. The latest versions on i.MX6ULL and i.MX7D have grown an additional pipeline for dithering and e-ink update processing that is ignored by this driver. This series adds a V4L2 mem-to-mem scaler/CSC driver for the PXP version found on i.MX6ULL SoCs which is a size reduced variant of the i.MX7 PXP. The driver uses only the legacy pipeline, so it should be reasonably easy to extend it to work with the older PXP versions found on i.MX6UL, i.MX6SX, i.MX6SL, i.MX28, and i.MX23. The driver supports scaling and colorspace conversion. There is currently no support for rotation, alpha-blending, and the LUTs. regards Philipp Philipp Zabel (3): dt-bindings: media: Add i.MX Pixel Pipeline binding ARM: dts: imx6ull: add pxp support media: imx-pxp: add i.MX Pixel Pipeline driver .../devicetree/bindings/media/fsl-pxp.txt | 26 + arch/arm/boot/dts/imx6ul.dtsi |8 + arch/arm/boot/dts/imx6ull.dtsi|6 + drivers/media/platform/Kconfig|9 + drivers/media/platform/Makefile |2 + drivers/media/platform/imx-pxp.c | 1455 ++ drivers/media/platform/imx-pxp.h | 1685 + 7 files changed, 3191 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/fsl-pxp.txt create mode 100644 drivers/media/platform/imx-pxp.c create mode 100644 drivers/media/platform/imx-pxp.h -- 2.18.0
[PATCH 1/3] dt-bindings: media: Add i.MX Pixel Pipeline binding
Add DT binding documentation for the Pixel Pipeline (PXP) found on
various NXP i.MX SoCs.
Signed-off-by: Philipp Zabel
---
.../devicetree/bindings/media/fsl-pxp.txt | 26 +++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/fsl-pxp.txt
diff --git a/Documentation/devicetree/bindings/media/fsl-pxp.txt
b/Documentation/devicetree/bindings/media/fsl-pxp.txt
new file mode 100644
index ..2477e7f87381
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/fsl-pxp.txt
@@ -0,0 +1,26 @@
+Freescale Pixel Pipeline
+
+
+The Pixel Pipeline (PXP) is a memory-to-memory graphics processing engine
+that supports scaling, colorspace conversion, alpha blending, rotation, and
+pixel conversion via lookup table. Different versions are present on various
+i.MX SoCs from i.MX23 to i.MX7.
+
+Required properties:
+- compatible: should be "fsl,-pxp", where SoC can be one of imx23, imx28,
+ imx6dl, imx6sl, imx6ul, imx6sx, imx6ull, or imx7d.
+- reg: the register base and size for the device registers
+- interrupts: the PXP interrupt, two interrupts for imx6ull and imx7d.
+- clock-names: should be "axi"
+- clocks: the PXP AXI clock
+
+Example:
+
+pxp@21cc000 {
+ compatible = "fsl,imx6ull-pxp";
+ reg = <0x021cc000 0x4000>;
+ interrupts = ,
+;
+ clock-names = "axi";
+ clocks = < IMX6UL_CLK_PXP>;
+};
--
2.18.0
[PATCH 3/3] media: imx-pxp: add i.MX Pixel Pipeline driver
Add a V4L2 mem-to-mem scaler/CSC driver for the Pixel Pipeline (PXP)
version found on i.MX6ULL SoCs. A similar variant is used on i.MX7D.
Since this driver only uses the legacy pipeline, it should be reasonably
easy to extend it to work with the older PXP versions found on i.MX6UL,
i.MX6SX, i.MX6SL, i.MX28, and i.MX23.
The driver supports scaling and colorspace conversion. There is
currently no support for rotation, alpha-blending, and the LUTs.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/Kconfig |9 +
drivers/media/platform/Makefile |2 +
drivers/media/platform/imx-pxp.c | 1455 ++
drivers/media/platform/imx-pxp.h | 1685 ++
4 files changed, 3151 insertions(+)
create mode 100644 drivers/media/platform/imx-pxp.c
create mode 100644 drivers/media/platform/imx-pxp.h
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index b25c8d3c1c31..ae1c025c14de 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -181,6 +181,15 @@ config VIDEO_CODA
config VIDEO_IMX_VDOA
def_tristate VIDEO_CODA if SOC_IMX6Q || COMPILE_TEST
+config VIDEO_IMX_PXP
+ tristate "i.MX Pixel Pipeline (PXP)"
+ depends on VIDEO_DEV && VIDEO_V4L2 && (ARCH_MXC || COMPILE_TEST)
+ select VIDEOBUF2_DMA_CONTIG
+ select V4L2_MEM2MEM_DEV
+ help
+ The i.MX Pixel Pipeline is a memory-to-memory engine for scaling,
+ color space conversion, and rotation.
+
config VIDEO_MEDIATEK_JPEG
tristate "Mediatek JPEG Codec driver"
depends on MTK_IOMMU_V1 || COMPILE_TEST
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 08640ba87fc2..0c2714c2bb05 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -25,6 +25,8 @@ obj-$(CONFIG_VIDEO_TI_CAL)+= ti-vpe/
obj-$(CONFIG_VIDEO_MX2_EMMAPRP)+= mx2_emmaprp.o
obj-$(CONFIG_VIDEO_CODA) += coda/
+obj-$(CONFIG_VIDEO_IMX_PXP)+= imx-pxp.o
+
obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o
obj-$(CONFIG_CEC_GPIO) += cec-gpio/
diff --git a/drivers/media/platform/imx-pxp.c b/drivers/media/platform/imx-pxp.c
new file mode 100644
index ..c9e3ef0f92b4
--- /dev/null
+++ b/drivers/media/platform/imx-pxp.c
@@ -0,0 +1,1455 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * i.MX Pixel Pipeline (PXP) mem-to-mem scaler/CSC/rotator driver
+ *
+ * Copyright (c) 2018 Pengutronix, Philipp Zabel
+ *
+ * based on vim2m
+ *
+ * Copyright (c) 2009-2010 Samsung Electronics Co., Ltd.
+ * Pawel Osciak,
+ * Marek Szyprowski,
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "imx-pxp.h"
+
+static unsigned int debug;
+module_param(debug, uint, 0644);
+MODULE_PARM_DESC(debug, "activates debug info");
+
+#define MIN_W 8
+#define MIN_H 8
+#define MAX_W 4096
+#define MAX_H 4096
+#define ALIGN_W 3 /* 8x8 pixel blocks */
+#define ALIGN_H 3
+
+/* Flags that indicate a format can be used for capture/output */
+#define MEM2MEM_CAPTURE(1 << 0)
+#define MEM2MEM_OUTPUT (1 << 1)
+
+#define MEM2MEM_NAME "pxp"
+
+/* Per queue */
+#define MEM2MEM_DEF_NUM_BUFS VIDEO_MAX_FRAME
+/* In bytes, per queue */
+#define MEM2MEM_VID_MEM_LIMIT (16 * 1024 * 1024)
+
+/* Flags that indicate processing mode */
+#define MEM2MEM_HFLIP (1 << 0)
+#define MEM2MEM_VFLIP (1 << 1)
+
+#define dprintk(dev, fmt, arg...) \
+ v4l2_dbg(1, debug, >v4l2_dev, "%s: " fmt, __func__, ## arg)
+
+struct pxp_fmt {
+ u32 fourcc;
+ int depth;
+ /* Types the format can be used for */
+ u32 types;
+};
+
+static struct pxp_fmt formats[] = {
+ {
+ .fourcc = V4L2_PIX_FMT_XBGR32,
+ .depth = 32,
+ /* Both capture and output format */
+ .types = MEM2MEM_CAPTURE | MEM2MEM_OUTPUT,
+ }, {
+ .fourcc = V4L2_PIX_FMT_ABGR32,
+ .depth = 32,
+ /* Capture-only format */
+ .types = MEM2MEM_CAPTURE,
+ }, {
+ .fourcc = V4L2_PIX_FMT_BGR24,
+ .depth = 24,
+ .types = MEM2MEM_CAPTURE,
+ }, {
+ .fourcc = V4L2_PIX_FMT_RGB565,
+ .depth = 16,
+ .types = MEM2MEM_CAPTURE | MEM2MEM_OUTPUT,
+ }, {
+ .fourcc = V4L2_PIX_FMT_RGB555,
+ .depth = 16,
+ .types = MEM2MEM_CAPTURE | MEM2MEM_OUTPUT,
+ }, {
+ .fourcc = V4L2_PIX_FMT_RGB444,
+ .depth = 16,
+ .types = MEM2MEM_CAPTURE | MEM2MEM_OUTPUT,
+ }, {
+ .fourcc = V4L2_PIX_FMT_YUV32,
+ .depth = 16,
+ .types = MEM2MEM_CAPTURE | MEM2MEM_OUTPUT,
+ }, {
+
[PATCH 2/3] ARM: dts: imx6ull: add pxp support
Add the device node for the i.MX6ULL Pixel Pipeline (PXP).
Signed-off-by: Philipp Zabel
---
arch/arm/boot/dts/imx6ul.dtsi | 8
arch/arm/boot/dts/imx6ull.dtsi | 6 ++
2 files changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 47a3453a4211..e80a660c14f2 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -928,6 +928,14 @@
};
};
+ pxp: pxp@21cc000 {
+ compatible = "fsl,imx6ul-pxp";
+ reg = <0x021cc000 0x4000>;
+ interrupts = ;
+ clock-names = "axi";
+ clocks = < IMX6UL_CLK_PXP>;
+ };
+
lcdif: lcdif@21c8000 {
compatible = "fsl,imx6ul-lcdif",
"fsl,imx28-lcdif";
reg = <0x021c8000 0x4000>;
diff --git a/arch/arm/boot/dts/imx6ull.dtsi b/arch/arm/boot/dts/imx6ull.dtsi
index ebc25c98e5e1..91d2b6dd9b1b 100644
--- a/arch/arm/boot/dts/imx6ull.dtsi
+++ b/arch/arm/boot/dts/imx6ull.dtsi
@@ -75,3 +75,9 @@
};
};
};
+
+ {
+ compatible = "fsl,imx6ull-pxp";
+ interrupts = ,
+;
+};
--
2.18.0
[PATCH v7 12/12] media: video-mux: add bayer formats
Add non vendor bayer formats to the allowed format array. Signed-off-by: Rui Miguel Silva --- drivers/media/platform/video-mux.c | 20 1 file changed, 20 insertions(+) diff --git a/drivers/media/platform/video-mux.c b/drivers/media/platform/video-mux.c index d8a6fa20879a..af74eb384b78 100644 --- a/drivers/media/platform/video-mux.c +++ b/drivers/media/platform/video-mux.c @@ -263,6 +263,26 @@ static int video_mux_set_format(struct v4l2_subdev *sd, case MEDIA_BUS_FMT_UYYVYY16_0_5X48: case MEDIA_BUS_FMT_JPEG_1X8: case MEDIA_BUS_FMT_AHSV_1X32: + case MEDIA_BUS_FMT_SBGGR8_1X8: + case MEDIA_BUS_FMT_SGBRG8_1X8: + case MEDIA_BUS_FMT_SGRBG8_1X8: + case MEDIA_BUS_FMT_SRGGB8_1X8: + case MEDIA_BUS_FMT_SBGGR10_1X10: + case MEDIA_BUS_FMT_SGBRG10_1X10: + case MEDIA_BUS_FMT_SGRBG10_1X10: + case MEDIA_BUS_FMT_SRGGB10_1X10: + case MEDIA_BUS_FMT_SBGGR12_1X12: + case MEDIA_BUS_FMT_SGBRG12_1X12: + case MEDIA_BUS_FMT_SGRBG12_1X12: + case MEDIA_BUS_FMT_SRGGB12_1X12: + case MEDIA_BUS_FMT_SBGGR14_1X14: + case MEDIA_BUS_FMT_SGBRG14_1X14: + case MEDIA_BUS_FMT_SGRBG14_1X14: + case MEDIA_BUS_FMT_SRGGB14_1X14: + case MEDIA_BUS_FMT_SBGGR16_1X16: + case MEDIA_BUS_FMT_SGBRG16_1X16: + case MEDIA_BUS_FMT_SGRBG16_1X16: + case MEDIA_BUS_FMT_SRGGB16_1X16: break; default: sdformat->format.code = MEDIA_BUS_FMT_Y8_1X8; -- 2.18.0
[PATCH v7 00/12] media: staging/imx7: add i.MX7 media driver
Hi, This series introduces the Media driver to work with the i.MX7 SoC. it uses the already existing imx media core drivers but since the i.MX7, contrary to i.MX5/6, do not have an IPU and because of that some changes in the imx media core are made along this series to make it support that case. This patches adds CSI and MIPI-CSI2 drivers for i.MX7, along with several configurations changes for this to work as a capture subsystem. Some bugs are also fixed along the line. And necessary documentation. For a more detailed view of the capture paths, pads links in the i.MX7 please take a look at the documentation in PATCH 14. The system used to test and develop this was the Warp7 board with an OV2680 sensor, which output format is 10-bit bayer. So, only MIPI interface was tested, a scenario with an parallel input would nice to have. Bellow goes an example of the output of the pads and links and the output of v4l2-compliance testing. The v4l-utils version used is: v4l2-compliance SHA : 90905c2e4b17d7595256f3824e2d30d19b0df1a1 from Aug 6th The Media Driver fail some tests but this failures are coming from code out of scope of this series (imx-capture), and some from the sensor OV2680 but that I think not related with the sensor driver but with the testing and core. The csi and mipi-csi entities pass all compliance tests. Cheers, Rui v6->v7: Myself: - Clock patches removed from this version since they were already merged - Rebuild and test with the latest v4l2-compliance - Add patch to video-mux regarding bayer formats - remove reference to dependent patch serie (was already merged) Sakari Ailus: - add port and endpoint explanantions - fix some wording should -> shall v5->v6: Rob Herring: - rename power-domain node name from: pgc-power-domain to power-domain - change mux-control-cells to 0 - remove bus-width from mipi bindings and dts - remove err... regarding clock names line - remove clk-settle from example - split mipi-csi2 and csi bindings per file - add OF graph description to CSI Philipp Zabel: - rework group IDs and rename them with an _IPU_ prefix, this allowed to remove the ipu_present flag need. v4->v5: Sakari Ailus: - fix remove of the capture entries in dts bindings in the right patch Stephen Boyd: - Send all series to clk list v3->v4: Philipp Zabel: - refactor initialization code from media device probe to be possible to used from other modules - Remove index of csi from all accurrencs (dts, code, documentation) - Remove need for capture node for imx7 - fix pinctrl for ov2680 - add reviewed tag to add multiplexer controls patch Fabio Estevam: - remove always on from new regulator Randy Dunlap: - several text editing fixes in documentation Myself: - rebase on top of v4 of Steve series - change CSI probe to initialize imx media device - remove csi mux parallel endpoint from mux to avoid warning message v2->v3: Philipp Zabel: - use of_match_device in imx-media-dev instead of of_device_match - fix number of data lanes from 4 to 2 - change the clock definitions and use of mipi - move hs-settle from endpoint Rob Herring: - fix phy-supply description - add vendor properties - fix examples indentations Stephen Boyd: patch 3/14 - fix double sign-off - add fixes tag Dong Aisheng: patch 3/14 - fix double sign-off - add Acked-by tag Shawn Guo: patch 4/14 - remove line breakage in parent redifiniton - added Acked-by tag - dropped CMA area increase and add more verbose information in case of dma allocation failure patch 9/14 - remove extra line between cells and reg masks Myself: - rework on frame end in csi - add rxcount in csi driver - add power supplies to ov2680 node and fix gpio polarity v1->v2: Dan Carpenter: - fix return paths and codes; - fix clk_frequency validation and return code; - handle the csi remove (release resources that was missing) - revert the logic arround the ipu_present flag Philipp Zabel: - drop patch that changed the rgb formats and address the pixel/bus format in mipi_csis code. MySelf: - add patch that add ov2680 node to the warp7 dts, so the all data path is complete. - add linux-clk mailing list to the clock patches cc: v4l2-compliance SHA: 90905c2e4b17d7595256f3824e2d30d19b0df1a1, 32 bits Compliance test for device /dev/media0: Media Driver Info: Driver name : imx7-csi Model: imx-media Serial : Bus info : Media version: 4.18.0 Hardware revision: 0x (0) Driver version : 4.18.0 Required ioctls: test MEDIA_IOC_DEVICE_INFO: OK Allow for multiple opens: test second /dev/media0 open: OK test MEDIA_IOC_DEVICE_INFO: OK test for unlimited opens: OK Media Controller ioctls: Entity: 0x0001 (Name: 'csi', Function: Video Interface Bridge) Entity: 0x0004 (Name: 'csi capture', Function: V4L2 I/O)
[PATCH v7 06/12] ARM: dts: imx7s: add mipi phy power domain
Add power domain index 0 related with mipi-phy to imx7s.
While at it rename pcie power-domain node to remove pgc prefix.
Signed-off-by: Rui Miguel Silva
---
arch/arm/boot/dts/imx7s.dtsi | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 9ced589bfa96..df4a29365468 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -610,7 +610,13 @@
#address-cells = <1>;
#size-cells = <0>;
- pgc_pcie_phy: pgc-power-domain@1 {
+ pgc_mipi_phy: power-domain@0 {
+ #power-domain-cells = <0>;
+ reg = <0>;
+ power-supply = <_1p0d>;
+ };
+
+ pgc_pcie_phy: power-domain@1 {
#power-domain-cells = <0>;
reg = <1>;
power-supply = <_1p0d>;
--
2.18.0
[PATCH v7 07/12] ARM: dts: imx7s: add multiplexer controls
The IOMUXC General Purpose Register has bitfield to control video bus
multiplexer to control the CSI input between the MIPI-CSI2 and parallel
interface. Add that register and mask.
Signed-off-by: Rui Miguel Silva
Reviewed-by: Philipp Zabel
---
arch/arm/boot/dts/imx7s.dtsi | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index df4a29365468..f6c7afa51dc1 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -493,8 +493,14 @@
gpr: iomuxc-gpr@3034 {
compatible = "fsl,imx7d-iomuxc-gpr",
- "fsl,imx6q-iomuxc-gpr", "syscon";
+ "fsl,imx6q-iomuxc-gpr", "syscon",
"simple-mfd";
reg = <0x3034 0x1>;
+
+ mux: mux-controller {
+ compatible = "mmio-mux";
+ #mux-control-cells = <0>;
+ mux-reg-masks = <0x14 0x0010>;
+ };
};
ocotp: ocotp-ctrl@3035 {
--
2.18.0
[PATCH v7 04/12] media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7
Adds MIPI CSI-2 subdev for i.MX7 to connect with sensors with a MIPI CSI-2 interface. Signed-off-by: Rui Miguel Silva --- drivers/staging/media/imx/Makefile |1 + drivers/staging/media/imx/imx7-mipi-csis.c | 1134 2 files changed, 1135 insertions(+) create mode 100644 drivers/staging/media/imx/imx7-mipi-csis.c diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile index 074f016d3519..d2d909a36239 100644 --- a/drivers/staging/media/imx/Makefile +++ b/drivers/staging/media/imx/Makefile @@ -14,3 +14,4 @@ obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-mipi-csi2.o obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-media-csi.o +obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-mipi-csis.o diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c new file mode 100644 index ..79cc413b4bbe --- /dev/null +++ b/drivers/staging/media/imx/imx7-mipi-csis.c @@ -0,0 +1,1134 @@ +// SPDX-License-Identifier: GPL +/* + * Freescale i.MX7 SoC series MIPI-CSI V3.3 receiver driver + * + * Copyright (C) 2018 Linaro Ltd + * Copyright (C) 2015-2016 Freescale Semiconductor, Inc. All Rights Reserved. + * Copyright (C) 2011 - 2013 Samsung Electronics Co., Ltd. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include "imx-media.h" + +static int debug; +module_param(debug, int, 0644); +MODULE_PARM_DESC(debug, "Debug level (0-2)"); + +#define CSIS_DRIVER_NAME "imx7-mipi-csis" +#define CSIS_SUBDEV_NAME CSIS_DRIVER_NAME + +#define CSIS_PAD_SINK 0 +#define CSIS_PAD_SOURCE1 +#define CSIS_PADS_NUM 2 + +#define MIPI_CSIS_DEF_PIX_WIDTH640 +#define MIPI_CSIS_DEF_PIX_HEIGHT 480 + +/* Register map definition */ + +/* CSIS common control */ +#define MIPI_CSIS_CMN_CTRL 0x04 +#define MIPI_CSIS_CMN_CTRL_UPDATE_SHADOW BIT(16) +#define MIPI_CSIS_CMN_CTRL_INTER_MODE BIT(10) +#define MIPI_CSIS_CMN_CTRL_UPDATE_SHADOW_CTRL BIT(2) +#define MIPI_CSIS_CMN_CTRL_RESET BIT(1) +#define MIPI_CSIS_CMN_CTRL_ENABLE BIT(0) + +#define MIPI_CSIS_CMN_CTRL_LANE_NR_OFFSET 8 +#define MIPI_CSIS_CMN_CTRL_LANE_NR_MASK(3 << 8) + +/* CSIS clock control */ +#define MIPI_CSIS_CLK_CTRL 0x08 +#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH3(x)(x << 28) +#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH2(x)(x << 24) +#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH1(x)(x << 20) +#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH0(x)(x << 16) +#define MIPI_CSIS_CLK_CTRL_CLKGATE_EN_MSK (0xf << 4) +#define MIPI_CSIS_CLK_CTRL_WCLK_SRCBIT(0) + +/* CSIS Interrupt mask */ +#define MIPI_CSIS_INTMSK 0x10 +#define MIPI_CSIS_INTMSK_EVEN_BEFORE BIT(31) +#define MIPI_CSIS_INTMSK_EVEN_AFTERBIT(30) +#define MIPI_CSIS_INTMSK_ODD_BEFOREBIT(29) +#define MIPI_CSIS_INTMSK_ODD_AFTER BIT(28) +#define MIPI_CSIS_INTMSK_FRAME_START BIT(24) +#define MIPI_CSIS_INTMSK_FRAME_END BIT(20) +#define MIPI_CSIS_INTMSK_ERR_SOT_HSBIT(16) +#define MIPI_CSIS_INTMSK_ERR_LOST_FS BIT(12) +#define MIPI_CSIS_INTMSK_ERR_LOST_FE BIT(8) +#define MIPI_CSIS_INTMSK_ERR_OVER BIT(4) +#define MIPI_CSIS_INTMSK_ERR_WRONG_CFG BIT(3) +#define MIPI_CSIS_INTMSK_ERR_ECC BIT(2) +#define MIPI_CSIS_INTMSK_ERR_CRC BIT(1) +#define MIPI_CSIS_INTMSK_ERR_UNKNOWN BIT(0) + +/* CSIS Interrupt source */ +#define MIPI_CSIS_INTSRC 0x14 +#define MIPI_CSIS_INTSRC_EVEN_BEFORE BIT(31) +#define MIPI_CSIS_INTSRC_EVEN_AFTERBIT(30) +#define MIPI_CSIS_INTSRC_EVEN BIT(30) +#define MIPI_CSIS_INTSRC_ODD_BEFOREBIT(29) +#define MIPI_CSIS_INTSRC_ODD_AFTER BIT(28) +#define MIPI_CSIS_INTSRC_ODD (0x3 << 28) +#define MIPI_CSIS_INTSRC_NON_IMAGE_DATA(0xf << 28) +#define MIPI_CSIS_INTSRC_FRAME_START BIT(24) +#define MIPI_CSIS_INTSRC_FRAME_END BIT(20) +#define MIPI_CSIS_INTSRC_ERR_SOT_HSBIT(16) +#define MIPI_CSIS_INTSRC_ERR_LOST_FS BIT(12) +#define MIPI_CSIS_INTSRC_ERR_LOST_FE BIT(8) +#define MIPI_CSIS_INTSRC_ERR_OVER BIT(4) +#define MIPI_CSIS_INTSRC_ERR_WRONG_CFG BIT(3) +#define MIPI_CSIS_INTSRC_ERR_ECC BIT(2) +#define MIPI_CSIS_INTSRC_ERR_CRC BIT(1) +#define MIPI_CSIS_INTSRC_ERR_UNKNOWN BIT(0) +#define MIPI_CSIS_INTSRC_ERRORS0xf + +/* D-PHY status control */ +#define MIPI_CSIS_DPHYSTATUS 0x20 +#define MIPI_CSIS_DPHYSTATUS_ULPS_DAT BIT(8) +#define MIPI_CSIS_DPHYSTATUS_STOPSTATE_DAT BIT(4) +#define MIPI_CSIS_DPHYSTATUS_ULPS_CLK BIT(1) +#define MIPI_CSIS_DPHYSTATUS_STOPSTATE_CLK BIT(0) + +/* D-PHY common control */ +#define MIPI_CSIS_DPHYCTRL 0x24 +#define
[PATCH v7 05/12] media: dt-bindings: add bindings for i.MX7 media driver
Add bindings documentation for i.MX7 media drivers.
The imx7 MIPI CSI2 and imx7 CMOS Sensor Interface.
Reviewed-by: Rob Herring
Signed-off-by: Rui Miguel Silva
---
.../devicetree/bindings/media/imx7-csi.txt| 45 ++
.../bindings/media/imx7-mipi-csi2.txt | 90 +++
2 files changed, 135 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/imx7-csi.txt
create mode 100644 Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
diff --git a/Documentation/devicetree/bindings/media/imx7-csi.txt
b/Documentation/devicetree/bindings/media/imx7-csi.txt
new file mode 100644
index ..171b089ee91f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/imx7-csi.txt
@@ -0,0 +1,45 @@
+Freescale i.MX7 CMOS Sensor Interface
+=
+
+csi node
+
+
+This is device node for the CMOS Sensor Interface (CSI) which enables the chip
+to connect directly to external CMOS image sensors.
+
+Required properties:
+
+- compatible: "fsl,imx7-csi";
+- reg : base address and length of the register set for the device;
+- interrupts: should contain CSI interrupt;
+- clocks: list of clock specifiers, see
+Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
+- clock-names : must contain "axi", "mclk" and "dcic" entries, matching
+ entries in the clock property;
+
+The device node shall contain one 'port' child node with one child 'endpoint'
+node, according to the bindings defined in:
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+In the following example a remote endpoint is a video multiplexer.
+
+example:
+
+csi: csi@3071 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+compatible = "fsl,imx7-csi";
+reg = <0x3071 0x1>;
+interrupts = ;
+clocks = < IMX7D_CLK_DUMMY>,
+< IMX7D_CSI_MCLK_ROOT_CLK>,
+< IMX7D_CLK_DUMMY>;
+clock-names = "axi", "mclk", "dcic";
+
+port {
+csi_from_csi_mux: endpoint {
+remote-endpoint = <_mux_to_csi>;
+};
+};
+};
diff --git a/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
b/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
new file mode 100644
index ..71fd74ed3ec8
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
@@ -0,0 +1,90 @@
+Freescale i.MX7 Mipi CSI2
+=
+
+mipi_csi2 node
+--
+
+This is the device node for the MIPI CSI-2 receiver core in i.MX7 SoC. It is
+compatible with previous version of Samsung D-phy.
+
+Required properties:
+
+- compatible: "fsl,imx7-mipi-csi2";
+- reg : base address and length of the register set for the device;
+- interrupts: should contain MIPI CSIS interrupt;
+- clocks: list of clock specifiers, see
+Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
+- clock-names : must contain "pclk", "wrap" and "phy" entries, matching
+ entries in the clock property;
+- power-domains : a phandle to the power domain, see
+ Documentation/devicetree/bindings/power/power_domain.txt for details.
+- reset-names : should include following entry "mrst";
+- resets: a list of phandle, should contain reset entry of
+ reset-names;
+- phy-supply: from the generic phy bindings, a phandle to a regulator that
+ provides power to MIPI CSIS core;
+
+Optional properties:
+
+- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
+ value when this property is not specified is 166 MHz;
+- fsl,csis-hs-settle : differential receiver (HS-RX) settle time;
+
+The device node should contain two 'port' child nodes with one child 'endpoint'
+node, according to the bindings defined in:
+ Documentation/devicetree/bindings/ media/video-interfaces.txt.
+ The following are properties specific to those nodes.
+
+port node
+-
+
+- reg: (required) can take the values 0 or 1, where 0 shall be
+ related to the sink port and port 1 shall be the source
+ one;
+
+endpoint node
+-
+
+- data-lanes: (required) an array specifying active physical MIPI-CSI2
+ data input lanes and their mapping to logical lanes; this
+shall only be applied to port 0 (sink port), the array's
+content is unused only its length is meaningful,
+in this case the maximum length supported is 2;
+
+example:
+
+
[PATCH v7 10/12] media: imx7.rst: add documentation for i.MX7 media driver
Add rst document to describe the i.MX7 media driver and also a working example from the Warp7 board usage with a OV2680 sensor. Signed-off-by: Rui Miguel Silva --- Documentation/media/v4l-drivers/imx7.rst | 157 ++ Documentation/media/v4l-drivers/index.rst | 1 + 2 files changed, 158 insertions(+) create mode 100644 Documentation/media/v4l-drivers/imx7.rst diff --git a/Documentation/media/v4l-drivers/imx7.rst b/Documentation/media/v4l-drivers/imx7.rst new file mode 100644 index ..cd1195d391c5 --- /dev/null +++ b/Documentation/media/v4l-drivers/imx7.rst @@ -0,0 +1,157 @@ +i.MX7 Video Capture Driver +== + +Introduction + + +The i.MX7 contrary to the i.MX5/6 family does not contain an Image Processing +Unit (IPU); because of that the capabilities to perform operations or +manipulation of the capture frames are less feature rich. + +For image capture the i.MX7 has three units: +- CMOS Sensor Interface (CSI) +- Video Multiplexer +- MIPI CSI-2 Receiver + +:: + |\ + MIPI Camera Input ---> MIPI CSI-2 --- > | \ + | \ + | M | + | U | --> CSI ---> Capture + | X | + | / + Parallel Camera Input > | / + |/ + +For additional information, please refer to the latest versions of the i.MX7 +reference manual [#f1]_. + +Entities + + +imx7-mipi-csi2 +-- + +This is the MIPI CSI-2 receiver entity. It has one sink pad to receive the pixel +data from MIPI CSI-2 camera sensor. It has one source pad, corresponding to the +virtual channel 0. This module is compliant to previous version of Samsung +D-phy, and supports two D-PHY Rx Data lanes. + +csi_mux +--- + +This is the video multiplexer. It has two sink pads to select from either camera +sensor with a parallel interface or from MIPI CSI-2 virtual channel 0. It has +a single source pad that routes to the CSI. + +csi +--- + +The CSI enables the chip to connect directly to external CMOS image sensor. CSI +can interface directly with Parallel and MIPI CSI-2 buses. It has 256 x 64 FIFO +to store received image pixel data and embedded DMA controllers to transfer data +from the FIFO through AHB bus. + +This entity has one sink pad that receives from the csi_mux entity and a single +source pad that routes video frames directly to memory buffers. This pad is +routed to a capture device node. + +Usage Notes +--- + +To aid in configuration and for backward compatibility with V4L2 applications +that access controls only from video device nodes, the capture device interfaces +inherit controls from the active entities in the current pipeline, so controls +can be accessed either directly from the subdev or from the active capture +device interface. For example, the sensor controls are available either from the +sensor subdevs or from the active capture device. + +Warp7 with OV2680 +- + +On this platform an OV2680 MIPI CSI-2 module is connected to the internal MIPI +CSI-2 receiver. The following example configures a video capture pipeline with +an output of 800x600, and BGGR 10 bit bayer format: + +.. code-block:: none + # Setup links + media-ctl -l "'ov2680 1-0036':0 -> 'imx7-mipi-csis.0':0[1]" + media-ctl -l "'imx7-mipi-csis.0':1 -> 'csi_mux':1[1]" + media-ctl -l "'csi_mux':2 -> 'csi':0[1]" + media-ctl -l "'csi':1 -> 'csi capture':0[1]" + + # Configure pads for pipeline + media-ctl -V "'ov2680 1-0036':0 [fmt:SBGGR10_1X10/800x600 field:none]" + media-ctl -V "'csi_mux':1 [fmt:SBGGR10_1X10/800x600 field:none]" + media-ctl -V "'csi_mux':2 [fmt:SBGGR10_1X10/800x600 field:none]" + media-ctl -V "'imx7-mipi-csis.0':0 [fmt:SBGGR10_1X10/800x600 field:none]" + media-ctl -V "'csi':0 [fmt:SBGGR10_1X10/800x600 field:none]" + +After this streaming can start. The v4l2-ctl tool can be used to select any of +the resolutions supported by the sensor. + +.. code-block:: none +root@imx7s-warp:~# media-ctl -p +Media controller API version 4.17.0 + +Media device information + +driver imx-media +model imx-media +serial +bus info +hw revision 0x0 +driver version 4.17.0 + +Device topology +- entity 1: csi (2 pads, 2 links) + type V4L2 subdev subtype Unknown flags 0 + device node name /dev/v4l-subdev0 + pad0: Sink + [fmt:SBGGR10_1X10/800x600 field:none] + <- "csi_mux":2 [ENABLED] + pad1: Source + [fmt:SBGGR10_1X10/800x600 field:none] + -> "csi capture":0 [ENABLED] + +- entity 4: csi capture (1 pad, 1 link) + type Node subtype
[PATCH v7 11/12] media: staging/imx: add i.MX7 entries to TODO file
Add some i.MX7 related entries to TODO file. Signed-off-by: Rui Miguel Silva --- drivers/staging/media/imx/TODO | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/staging/media/imx/TODO b/drivers/staging/media/imx/TODO index aeeb15494a49..6f29b5ca5324 100644 --- a/drivers/staging/media/imx/TODO +++ b/drivers/staging/media/imx/TODO @@ -45,3 +45,12 @@ Which means a port must not contain mixed-use endpoints, they must all refer to media links between V4L2 subdevices. + +- i.MX7: all of the above, since it uses the imx media core + +- i.MX7: use Frame Interval Monitor + +- i.MX7: runtime testing with parallel sensor, links setup and streaming + +- i.MX7: runtime testing with different formats, for the time only 10-bit bayer + is tested -- 2.18.0
[PATCH v7 08/12] ARM: dts: imx7: Add video mux, csi and mipi_csi and connections
This patch adds the device tree nodes for csi, video multiplexer and mipi-csi
besides the graph connecting the necessary endpoints to make the media capture
entities to work in imx7 Warp board.
Signed-off-by: Rui Miguel Silva
---
arch/arm/boot/dts/imx7s-warp.dts | 51
arch/arm/boot/dts/imx7s.dtsi | 27 +
2 files changed, 78 insertions(+)
diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts
index fa390da636de..8e098b90c525 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -306,6 +306,57 @@
status = "okay";
};
+ {
+ csi_mux {
+ compatible = "video-mux";
+ mux-controls = < 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ csi_mux_from_mipi_vc0: endpoint {
+ remote-endpoint = <_vc0_to_csi_mux>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ csi_mux_to_csi: endpoint {
+ remote-endpoint = <_from_csi_mux>;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ port {
+ csi_from_csi_mux: endpoint {
+ remote-endpoint = <_mux_to_csi>;
+ };
+ };
+};
+
+_csi {
+ clock-frequency = <16600>;
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ fsl,csis-hs-settle = <3>;
+
+ port@1 {
+ reg = <1>;
+
+ mipi_vc0_to_csi_mux: endpoint {
+ remote-endpoint = <_mux_from_mipi_vc0>;
+ };
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_wdog>;
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index f6c7afa51dc1..432c69f50a05 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include "imx7d-pinfunc.h"
/ {
@@ -712,6 +713,17 @@
status = "disabled";
};
+ csi: csi@3071 {
+ compatible = "fsl,imx7-csi";
+ reg = <0x3071 0x1>;
+ interrupts = ;
+ clocks = < IMX7D_CLK_DUMMY>,
+ < IMX7D_CSI_MCLK_ROOT_CLK>,
+ < IMX7D_CLK_DUMMY>;
+ clock-names = "axi", "mclk", "dcic";
+ status = "disabled";
+ };
+
lcdif: lcdif@3073 {
compatible = "fsl,imx7d-lcdif",
"fsl,imx28-lcdif";
reg = <0x3073 0x1>;
@@ -721,6 +733,21 @@
clock-names = "pix", "axi";
status = "disabled";
};
+
+ mipi_csi: mipi-csi@3075 {
+ compatible = "fsl,imx7-mipi-csi2";
+ reg = <0x3075 0x1>;
+ interrupts = ;
+ clocks = < IMX7D_IPG_ROOT_CLK>,
+ < IMX7D_MIPI_CSI_ROOT_CLK>,
+ <
IMX7D_MIPI_DPHY_ROOT_CLK>;
+ clock-names = "pclk", "wrap", "phy";
+ power-domains = <_mipi_phy>;
+ phy-supply = <_1p0d>;
+ resets = < IMX7_RESET_MIPI_PHY_MRST>;
+ reset-names = "mrst";
+ status = "disabled";
+ };
};
aips3: aips-bus@3080 {
--
2.18.0
[PATCH v7 09/12] ARM: dts: imx7s-warp: add ov2680 sensor node
Warp7 comes with a Omnivision OV2680 sensor, add the node here to make complete
the camera data path for this system. Add the needed regulator to the analog
voltage supply, the port and endpoints in mipi_csi node and the pinctrl for the
reset gpio.
Signed-off-by: Rui Miguel Silva
---
arch/arm/boot/dts/imx7s-warp.dts | 44
1 file changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts
index 8e098b90c525..b1c5d8f8a2ba 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -91,6 +91,14 @@
regulator-always-on;
};
+ reg_peri_3p15v: regulator-peri-3p15v {
+ compatible = "regulator-fixed";
+ regulator-name = "peri_3p15v_reg";
+ regulator-min-microvolt = <315>;
+ regulator-max-microvolt = <315>;
+ regulator-always-on;
+ };
+
sound {
compatible = "simple-audio-card";
simple-audio-card,name = "imx7-sgtl5000";
@@ -214,6 +222,27 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c2>;
status = "okay";
+
+ ov2680: camera@36 {
+ compatible = "ovti,ov2680";
+ pinctrl-names = "default";
+ pinctrl-0 = <_ov2680>;
+ reg = <0x36>;
+ clocks = <>;
+ clock-names = "xvclk";
+ reset-gpios = < 3 GPIO_ACTIVE_LOW>;
+ DOVDD-supply = <_reg>;
+ DVDD-supply = <_reg>;
+ AVDD-supply = <_peri_3p15v>;
+
+ port {
+ ov2680_to_mipi: endpoint {
+ remote-endpoint = <_from_sensor>;
+ clock-lanes = <0>;
+ data-lanes = <1>;
+ };
+ };
+ };
};
{
@@ -348,6 +377,15 @@
#size-cells = <0>;
fsl,csis-hs-settle = <3>;
+ port@0 {
+ reg = <0>;
+
+ mipi_from_sensor: endpoint {
+ remote-endpoint = <_to_mipi>;
+ data-lanes = <1>;
+ };
+ };
+
port@1 {
reg = <1>;
@@ -404,6 +442,12 @@
>;
};
+ pinctrl_ov2680: ov2660grp {
+ fsl,pins = <
+ MX7D_PAD_LPSR_GPIO1_IO03__GPIO1_IO3 0x14
+ >;
+ };
+
pinctrl_sai1: sai1grp {
fsl,pins = <
MX7D_PAD_SAI1_RX_DATA__SAI1_RX_DATA00x1f
--
2.18.0
[PATCH v7 03/12] media: staging/imx7: add imx7 CSI subdev driver
This add the media entity subdevice and control driver for the i.MX7 CMOS Sensor Interface. Signed-off-by: Rui Miguel Silva --- drivers/staging/media/imx/Kconfig |9 +- drivers/staging/media/imx/Makefile |2 + drivers/staging/media/imx/imx7-media-csi.c | 1352 3 files changed, 1362 insertions(+), 1 deletion(-) create mode 100644 drivers/staging/media/imx/imx7-media-csi.c diff --git a/drivers/staging/media/imx/Kconfig b/drivers/staging/media/imx/Kconfig index bfc17de56b17..40a11f988fc6 100644 --- a/drivers/staging/media/imx/Kconfig +++ b/drivers/staging/media/imx/Kconfig @@ -11,7 +11,7 @@ config VIDEO_IMX_MEDIA driver for the i.MX5/6 SOC. if VIDEO_IMX_MEDIA -menu "i.MX5/6 Media Sub devices" +menu "i.MX5/6/7 Media Sub devices" config VIDEO_IMX_CSI tristate "i.MX5/6 Camera Sensor Interface driver" @@ -20,5 +20,12 @@ config VIDEO_IMX_CSI ---help--- A video4linux camera sensor interface driver for i.MX5/6. +config VIDEO_IMX7_CSI + tristate "i.MX7 Camera Sensor Interface driver" + depends on VIDEO_IMX_MEDIA && VIDEO_DEV && I2C + default y + ---help--- + A video4linux camera sensor interface driver for i.MX7. + endmenu endif diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile index a30b3033f9a3..074f016d3519 100644 --- a/drivers/staging/media/imx/Makefile +++ b/drivers/staging/media/imx/Makefile @@ -12,3 +12,5 @@ obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-ic.o obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-mipi-csi2.o + +obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-media-csi.o diff --git a/drivers/staging/media/imx/imx7-media-csi.c b/drivers/staging/media/imx/imx7-media-csi.c new file mode 100644 index ..7facb7fcbc67 --- /dev/null +++ b/drivers/staging/media/imx/imx7-media-csi.c @@ -0,0 +1,1352 @@ +// SPDX-License-Identifier: GPL +/* + * V4L2 Capture CSI Subdev for Freescale i.MX7 SOC + * + * Copyright (c) 2018 Linaro Ltd + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include +#include "imx-media.h" + +#define IMX7_CSI_PAD_SINK 0 +#define IMX7_CSI_PAD_SRC 1 +#define IMX7_CSI_PADS_NUM 2 + +/* reset values */ +#define CSICR1_RESET_VAL 0x4800 +#define CSICR2_RESET_VAL 0x0 +#define CSICR3_RESET_VAL 0x0 + +/* csi control reg 1 */ +#define BIT_SWAP16_EN BIT(31) +#define BIT_EXT_VSYNC BIT(30) +#define BIT_EOF_INT_EN BIT(29) +#define BIT_PRP_IF_EN BIT(28) +#define BIT_CCIR_MODE BIT(27) +#define BIT_COF_INT_EN BIT(26) +#define BIT_SF_OR_INTENBIT(25) +#define BIT_RF_OR_INTENBIT(24) +#define BIT_SFF_DMA_DONE_INTEN BIT(22) +#define BIT_STATFF_INTEN BIT(21) +#define BIT_FB2_DMA_DONE_INTEN BIT(20) +#define BIT_FB1_DMA_DONE_INTEN BIT(19) +#define BIT_RXFF_INTEN BIT(18) +#define BIT_SOF_POLBIT(17) +#define BIT_SOF_INTEN BIT(16) +#define BIT_MCLKDIV(0xF << 12) +#define BIT_HSYNC_POL BIT(11) +#define BIT_CCIR_ENBIT(10) +#define BIT_MCLKEN BIT(9) +#define BIT_FCCBIT(8) +#define BIT_PACK_DIR BIT(7) +#define BIT_CLR_STATFIFO BIT(6) +#define BIT_CLR_RXFIFO BIT(5) +#define BIT_GCLK_MODE BIT(4) +#define BIT_INV_DATA BIT(3) +#define BIT_INV_PCLK BIT(2) +#define BIT_REDGE BIT(1) +#define BIT_PIXEL_BIT BIT(0) + +#define SHIFT_MCLKDIV 12 + +/* control reg 3 */ +#define BIT_FRMCNT (0x << 16) +#define BIT_FRMCNT_RST BIT(15) +#define BIT_DMA_REFLASH_RFFBIT(14) +#define BIT_DMA_REFLASH_SFFBIT(13) +#define BIT_DMA_REQ_EN_RFF BIT(12) +#define BIT_DMA_REQ_EN_SFF BIT(11) +#define BIT_STATFF_LEVEL (0x7 << 8) +#define BIT_HRESP_ERR_EN BIT(7) +#define BIT_RXFF_LEVEL (0x7 << 4) +#define BIT_TWO_8BIT_SENSORBIT(3) +#define BIT_ZERO_PACK_EN BIT(2) +#define BIT_ECC_INT_EN BIT(1) +#define BIT_ECC_AUTO_ENBIT(0) + +#define SHIFT_FRMCNT 16 +#define SHIFT_RXFIFO_LEVEL 4 + +/* csi status reg */ +#define BIT_ADDR_CH_ERR_INTBIT(28) +#define BIT_FIELD0_INT BIT(27) +#define BIT_FIELD1_INT BIT(26) +#define BIT_SFF_OR_INT BIT(25) +#define BIT_RFF_OR_INT BIT(24) +#define BIT_DMA_TSF_DONE_SFF BIT(22) +#define BIT_STATFF_INT BIT(21) +#define BIT_DMA_TSF_DONE_FB2 BIT(20) +#define BIT_DMA_TSF_DONE_FB1 BIT(19) +#define BIT_RXFF_INT BIT(18) +#define BIT_EOF_INTBIT(17) +#define BIT_SOF_INTBIT(16) +#define BIT_F2_INT BIT(15) +#define BIT_F1_INT BIT(14) +#define BIT_COF_INT
[PATCH v7 02/12] media: staging/imx: rearrange group id to take in account IPU
Some imx system do not have IPU, so prepare the imx media drivers to support
this kind of devices. Rename the group ids to include an _IPU_ prefix, add a new
group id to support systems with only a CSI without IPU, and also
rename the create internal links to make it clear that only systems with IPU
have internal subdevices.
Signed-off-by: Rui Miguel Silva
---
drivers/staging/media/imx/imx-ic-common.c | 6 ++---
drivers/staging/media/imx/imx-ic-prp.c| 14 +--
drivers/staging/media/imx/imx-media-csi.c | 6 ++---
drivers/staging/media/imx/imx-media-dev.c | 22 ++
.../staging/media/imx/imx-media-internal-sd.c | 20
drivers/staging/media/imx/imx-media-utils.c | 12 +-
drivers/staging/media/imx/imx-media.h | 23 ++-
7 files changed, 54 insertions(+), 49 deletions(-)
diff --git a/drivers/staging/media/imx/imx-ic-common.c
b/drivers/staging/media/imx/imx-ic-common.c
index cfdd4900a3be..765919487a73 100644
--- a/drivers/staging/media/imx/imx-ic-common.c
+++ b/drivers/staging/media/imx/imx-ic-common.c
@@ -41,13 +41,13 @@ static int imx_ic_probe(struct platform_device *pdev)
pdata = priv->dev->platform_data;
priv->ipu_id = pdata->ipu_id;
switch (pdata->grp_id) {
- case IMX_MEDIA_GRP_ID_IC_PRP:
+ case IMX_MEDIA_GRP_ID_IPU_IC_PRP:
priv->task_id = IC_TASK_PRP;
break;
- case IMX_MEDIA_GRP_ID_IC_PRPENC:
+ case IMX_MEDIA_GRP_ID_IPU_IC_PRPENC:
priv->task_id = IC_TASK_ENCODER;
break;
- case IMX_MEDIA_GRP_ID_IC_PRPVF:
+ case IMX_MEDIA_GRP_ID_IPU_IC_PRPVF:
priv->task_id = IC_TASK_VIEWFINDER;
break;
default:
diff --git a/drivers/staging/media/imx/imx-ic-prp.c
b/drivers/staging/media/imx/imx-ic-prp.c
index 98923fc844ce..795ca61f7cea 100644
--- a/drivers/staging/media/imx/imx-ic-prp.c
+++ b/drivers/staging/media/imx/imx-ic-prp.c
@@ -77,7 +77,7 @@ static int prp_start(struct prp_priv *priv)
priv->ipu = priv->md->ipu[ic_priv->ipu_id];
/* set IC to receive from CSI or VDI depending on source */
- src_is_vdic = !!(priv->src_sd->grp_id & IMX_MEDIA_GRP_ID_VDIC);
+ src_is_vdic = !!(priv->src_sd->grp_id & IMX_MEDIA_GRP_ID_IPU_VDIC);
ipu_set_ic_src_mux(priv->ipu, priv->csi_id, src_is_vdic);
@@ -238,7 +238,7 @@ static int prp_link_setup(struct media_entity *entity,
goto out;
}
if (priv->sink_sd_prpenc && (remote_sd->grp_id &
-IMX_MEDIA_GRP_ID_VDIC)) {
+
IMX_MEDIA_GRP_ID_IPU_VDIC)) {
ret = -EINVAL;
goto out;
}
@@ -259,7 +259,7 @@ static int prp_link_setup(struct media_entity *entity,
goto out;
}
if (priv->src_sd && (priv->src_sd->grp_id &
-IMX_MEDIA_GRP_ID_VDIC)) {
+IMX_MEDIA_GRP_ID_IPU_VDIC)) {
ret = -EINVAL;
goto out;
}
@@ -309,13 +309,13 @@ static int prp_link_validate(struct v4l2_subdev *sd,
return ret;
csi = imx_media_find_upstream_subdev(priv->md, _priv->sd.entity,
-IMX_MEDIA_GRP_ID_CSI);
+IMX_MEDIA_GRP_ID_IPU_CSI);
if (IS_ERR(csi))
csi = NULL;
mutex_lock(>lock);
- if (priv->src_sd->grp_id & IMX_MEDIA_GRP_ID_VDIC) {
+ if (priv->src_sd->grp_id & IMX_MEDIA_GRP_ID_IPU_VDIC) {
/*
* the ->PRPENC link cannot be enabled if the source
* is the VDIC
@@ -334,10 +334,10 @@ static int prp_link_validate(struct v4l2_subdev *sd,
if (csi) {
switch (csi->grp_id) {
- case IMX_MEDIA_GRP_ID_CSI0:
+ case IMX_MEDIA_GRP_ID_IPU_CSI0:
priv->csi_id = 0;
break;
- case IMX_MEDIA_GRP_ID_CSI1:
+ case IMX_MEDIA_GRP_ID_IPU_CSI1:
priv->csi_id = 1;
break;
default:
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/staging/media/imx/imx-media-csi.c
index 19ef3771b7b1..52d7fded7e40 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1026,10 +1026,10 @@ static int csi_link_setup(struct media_entity *entity,
remote_sd = media_entity_to_v4l2_subdev(remote->entity);
switch (remote_sd->grp_id) {
- case IMX_MEDIA_GRP_ID_VDIC:
+
[PATCH v7 01/12] media: staging/imx: refactor imx media device probe
Refactor and move media device initialization code to a new common module, so it
can be used by other devices, this will allow for example a near to introduce
imx7 CSI driver, to use this media device.
Signed-off-by: Rui Miguel Silva
---
drivers/staging/media/imx/Makefile| 1 +
drivers/staging/media/imx/imx-media-dev.c | 88 ++-
drivers/staging/media/imx/imx-media-of.c | 6 +-
drivers/staging/media/imx/imx-media.h | 15
4 files changed, 40 insertions(+), 70 deletions(-)
diff --git a/drivers/staging/media/imx/Makefile
b/drivers/staging/media/imx/Makefile
index 698a4210316e..a30b3033f9a3 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
imx-media-objs := imx-media-dev.o imx-media-internal-sd.o imx-media-of.o
+imx-media-objs += imx-media-dev-common.o
imx-media-common-objs := imx-media-utils.o imx-media-fim.o
imx-media-ic-objs := imx-ic-common.o imx-ic-prp.o imx-ic-prpencvf.o
diff --git a/drivers/staging/media/imx/imx-media-dev.c
b/drivers/staging/media/imx/imx-media-dev.c
index 659420ec4b2e..b06c300d12e0 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -107,9 +107,9 @@ static int imx_media_get_ipu(struct imx_media_dev *imxmd,
}
/* async subdev bound notifier */
-static int imx_media_subdev_bound(struct v4l2_async_notifier *notifier,
- struct v4l2_subdev *sd,
- struct v4l2_async_subdev *asd)
+int imx_media_subdev_bound(struct v4l2_async_notifier *notifier,
+ struct v4l2_subdev *sd,
+ struct v4l2_async_subdev *asd)
{
struct imx_media_dev *imxmd = notifier2dev(notifier);
int ret = 0;
@@ -293,7 +293,7 @@ static int imx_media_create_pad_vdev_lists(struct
imx_media_dev *imxmd)
}
/* async subdev complete notifier */
-static int imx_media_probe_complete(struct v4l2_async_notifier *notifier)
+int imx_media_probe_complete(struct v4l2_async_notifier *notifier)
{
struct imx_media_dev *imxmd = notifier2dev(notifier);
int ret;
@@ -317,11 +317,6 @@ static int imx_media_probe_complete(struct
v4l2_async_notifier *notifier)
return media_device_register(>md);
}
-static const struct v4l2_async_notifier_operations imx_media_subdev_ops = {
- .bound = imx_media_subdev_bound,
- .complete = imx_media_probe_complete,
-};
-
/*
* adds controls to a video device from an entity subdevice.
* Continues upstream from the entity's sink pads.
@@ -365,8 +360,8 @@ static int imx_media_inherit_controls(struct imx_media_dev
*imxmd,
return ret;
}
-static int imx_media_link_notify(struct media_link *link, u32 flags,
-unsigned int notification)
+int imx_media_link_notify(struct media_link *link, u32 flags,
+ unsigned int notification)
{
struct media_entity *source = link->source->entity;
struct imx_media_pad_vdev *pad_vdev;
@@ -429,10 +424,6 @@ static int imx_media_link_notify(struct media_link *link,
u32 flags,
return ret;
}
-static const struct media_device_ops imx_media_md_ops = {
- .link_notify = imx_media_link_notify,
-};
-
static int imx_media_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -440,76 +431,38 @@ static int imx_media_probe(struct platform_device *pdev)
struct imx_media_dev *imxmd;
int ret;
- imxmd = devm_kzalloc(dev, sizeof(*imxmd), GFP_KERNEL);
- if (!imxmd)
- return -ENOMEM;
-
- dev_set_drvdata(dev, imxmd);
- strlcpy(imxmd->md.model, "imx-media", sizeof(imxmd->md.model));
- imxmd->md.ops = _media_md_ops;
- imxmd->md.dev = dev;
- mutex_init(>mutex);
-
- imxmd->v4l2_dev.mdev = >md;
- strlcpy(imxmd->v4l2_dev.name, "imx-media",
- sizeof(imxmd->v4l2_dev.name));
-
- media_device_init(>md);
-
- ret = v4l2_device_register(dev, >v4l2_dev);
- if (ret < 0) {
- v4l2_err(>v4l2_dev,
-"Failed to register v4l2_device: %d\n", ret);
- goto cleanup;
- }
-
- dev_set_drvdata(imxmd->v4l2_dev.dev, imxmd);
-
- INIT_LIST_HEAD(>vdev_list);
-
- v4l2_async_notifier_init(>notifier);
+ imxmd = imx_media_dev_init(dev);
+ if (IS_ERR(imxmd))
+ return PTR_ERR(imxmd);
ret = imx_media_add_of_subdevs(imxmd, node);
if (ret) {
v4l2_err(>v4l2_dev,
"add_of_subdevs failed with %d\n", ret);
- goto notifier_cleanup;
+ goto dev_cleanup;
}
ret = imx_media_add_internal_subdevs(imxmd);
if (ret) {
v4l2_err(>v4l2_dev,
"add_internal_subdevs failed with %d\n", ret);
- goto
support editing
Your photos need editing. We can do it for you. We do editing for e-commerce photos, jewelries images and portrait photos etc. This will include cutout and clipping path etc , also retouching if needed. Let;s know if you want to send photos for working. We can do test on your photos. Thanks, Kelly
support editing
Your photos need editing. We can do it for you. We do editing for e-commerce photos, jewelries images and portrait photos etc. This will include cutout and clipping path etc , also retouching if needed. Let;s know if you want to send photos for working. We can do test on your photos. Thanks, Kelly
[PATCH] v4l2-ctrls: add v4l2_ctrl_del_handler()
If a sub-device is unbound, then it should also remove its controls from
other control handlers that it was added to using v4l2_ctrl_add_handler().
So create a v4l2_ctrl_del_handler() function that removes the controls that
were earlier added with v4l2_ctrl_add_handler().
Signed-off-by: Hans Verkuil
---
I'm not sure if this should be merged. It is necessary to safely unbind
subdevs, but since we don't do that yet anyway it is debatable if this
should be merged without anyone using it. But at least it will be archived
in patchwork so it isn't lost.
This function is used in our out-of-tree driver when we unconfigure an
FPGA where we do exactly this type of unbinding.
Regards,
Hans
---
drivers/media/v4l2-core/v4l2-ctrls.c | 39
include/media/v4l2-ctrls.h | 12 +
2 files changed, 51 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 599c1cbff3b9..b40cea8ec436 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2421,6 +2421,45 @@ int v4l2_ctrl_add_handler(struct v4l2_ctrl_handler *hdl,
}
EXPORT_SYMBOL(v4l2_ctrl_add_handler);
+void v4l2_ctrl_del_handler(struct v4l2_ctrl_handler *hdl,
+ struct v4l2_ctrl_handler *del)
+{
+ struct v4l2_ctrl_ref *ref, *ref_safe;
+
+ /* Do nothing if either handler is NULL or if they are the same */
+ if (!hdl || !del || hdl == del)
+ return;
+
+ mutex_lock(hdl->lock);
+ list_for_each_entry_safe(ref, ref_safe, >ctrl_refs, node) {
+ struct v4l2_ctrl *ctrl = ref->ctrl;
+ struct v4l2_ctrl_ref *bucket_ref;
+ int bucket;
+
+ if (ctrl->handler != del)
+ continue;
+
+ bucket = ctrl->id % hdl->nr_of_buckets; /* which bucket to use
*/
+ bucket_ref = hdl->buckets[bucket];
+
+ list_del(>node);
+ if (bucket_ref == ref)
+ hdl->buckets[bucket] = ref->next;
+ else {
+ while (bucket_ref->next && bucket_ref->next != ref)
+ bucket_ref = bucket_ref->next;
+ if (bucket_ref)
+ bucket_ref->next = ref->next;
+ else
+ pr_err("could not find ctrl '%s'\n",
ctrl->name);
+ }
+ kfree(ref);
+ }
+ hdl->cached = NULL;
+ mutex_unlock(hdl->lock);
+}
+EXPORT_SYMBOL(v4l2_ctrl_del_handler);
+
bool v4l2_ctrl_radio_filter(const struct v4l2_ctrl *ctrl)
{
if (V4L2_CTRL_ID2WHICH(ctrl->id) == V4L2_CTRL_CLASS_FM_TX)
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index f615ba1b29dd..c32d3500db54 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -644,6 +644,18 @@ int v4l2_ctrl_add_handler(struct v4l2_ctrl_handler *hdl,
struct v4l2_ctrl_handler *add,
v4l2_ctrl_filter filter);
+/**
+ * v4l2_ctrl_del_handler() - Remove all controls in handler @del from
+ * handler @hdl.
+ * @hdl: The control handler.
+ * @del: The control handler whose controls you want to delete from
+ * the @hdl control handler.
+ *
+ * Does nothing if either of the two handlers is a NULL pointer.
+ */
+void v4l2_ctrl_del_handler(struct v4l2_ctrl_handler *hdl,
+ struct v4l2_ctrl_handler *del);
+
/**
* v4l2_ctrl_radio_filter() - Standard filter for radio controls.
*
--
2.18.0
Re: [PATCHv16 01/34] Documentation: v4l: document request API
On 08/10/18 12:46, Pavel Machek wrote: > Hi! >> From: Alexandre Courbot >> >> Document the request API for V4L2 devices, and amend the documentation >> of system calls influenced by it. >> >> Signed-off-by: Alexandre Courbot >> Signed-off-by: Hans Verkuil > >> --- a/Documentation/media/uapi/v4l/buffer.rst >> +++ b/Documentation/media/uapi/v4l/buffer.rst >> @@ -306,10 +306,15 @@ struct v4l2_buffer >>- A place holder for future extensions. Drivers and applications >> must set this to 0. >> * - __u32 >> - - ``reserved`` >> + - ``request_fd`` >>- >> - - A place holder for future extensions. Drivers and applications >> -must set this to 0. >> + - The file descriptor of the request to queue the buffer to. If >> specified >> +and flag ``V4L2_BUF_FLAG_REQUEST_FD`` is set, then the buffer will >> be > > Delete "specified and" -- 0 is valid fd? Good catch! > >> +queued to that request. This is set by the user when calling >> +:ref:`ioctl VIDIOC_QBUF ` and ignored by other ioctls. >> +If the device does not support requests, then ``EPERM`` will be >> returned. >> +If requests are supported but an invalid request FD is given, then >> +``ENOENT`` will be returned. > > Should this still specify that this should be 0 if > V4L2_BUF_FLAG_REQUEST_FD is not set? I don't think so. But I can mentioned with request_fd that it is ignored if V4L2_BUF_FLAG_REQUEST_FD is not set. Regards, Hans > > Pavel >
Re: [PATCHv16 01/34] Documentation: v4l: document request API
Hi! > From: Alexandre Courbot > > Document the request API for V4L2 devices, and amend the documentation > of system calls influenced by it. > > Signed-off-by: Alexandre Courbot > Signed-off-by: Hans Verkuil > --- a/Documentation/media/uapi/v4l/buffer.rst > +++ b/Documentation/media/uapi/v4l/buffer.rst > @@ -306,10 +306,15 @@ struct v4l2_buffer >- A place holder for future extensions. Drivers and applications > must set this to 0. > * - __u32 > - - ``reserved`` > + - ``request_fd`` >- > - - A place holder for future extensions. Drivers and applications > - must set this to 0. > + - The file descriptor of the request to queue the buffer to. If > specified > +and flag ``V4L2_BUF_FLAG_REQUEST_FD`` is set, then the buffer will be Delete "specified and" -- 0 is valid fd? > + queued to that request. This is set by the user when calling > + :ref:`ioctl VIDIOC_QBUF ` and ignored by other ioctls. > + If the device does not support requests, then ``EPERM`` will be > returned. > + If requests are supported but an invalid request FD is given, then > + ``ENOENT`` will be returned. Should this still specify that this should be 0 if V4L2_BUF_FLAG_REQUEST_FD is not set? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 00/21] V4L2 fwnode rework; support for default configuration
Hi Sakari, thanks for this nice rework On Mon, Jul 23, 2018 at 04:46:45PM +0300, Sakari Ailus wrote: > Hello everyone, > > I've long thought the V4L2 fwnode framework requires some work (it's buggy > and it does not adequately serve common needs). This set should address in > particular these matters: > > - Most devices support a particular media bus type but the V4L2 fwnode > framework was not able to use such information, but instead tried to > guess the bus type with varying levels of success while drivers > generally ignored the results. This patchset makes that possible --- > setting a bus type enables parsing configuration for only that bus. > Failing that check results in returning -ENXIO to be returned. > > - Support specifying default configuration. If the endpoint has no > configuration, the defaults set by the driver (as documented in DT > bindings) will prevail. Any available configuration will still be read > from the endpoint as one could expect. A common use case for this is > e.g. the number of CSI-2 lanes. Few devices support lane mapping, and > default 1:1 mapping is provided in absence of a valid default or > configuration read OF. > > - Debugging information is greatly improved. > > - Recognition of the differences between CSI-2 D-PHY and C-PHY. All > currently supported hardware (or at least drivers) is D-PHY only, so > this change is still easy. > > The smiapp driver is converted to use the new functionality. This patchset > does not address remaining issues such as supporting setting defaults for > e.g. bridge drivers with multiple ports, but with Steve Longerbeam's > patchset we're much closer with that goal. I've rebased this set on top of > Steve's. Albeit the two deal with the same files, there were only a few > trivial conflicts. > > Note that I've only tested parsing endpoints for the CSI-2 bus (no > parallel IF hardware). Testing in general would be beneficial: the code > flows are rather convoluted and different hardware tends to excercise > different flows while the use of the use of defaults has a similar > effect. > I have tested on a parallel device, and so far it's all good. I would like to test default settings next, and see how they behave. > Comments are welcome. > In the meantine, looking at your (anticipated) v2, and in particular to this commit https://git.linuxtv.org/sailus/media_tree.git/commit/?h=v4l2-fwnode-next=077d73a3e1b66f9fbb1227245b1332cc1c7871d4 I'm wondering if introducing an API to query the bus type from the firmware wouldn't be beneficial for bridge drivers (and possibly for sensor drivers too). I see in that commit most drivers will set the bus type to 0 and rely on autoguessing, which is fine, but I'm thinking at peripheral that can support two different media busses (eg. Parallel and BT.656) or sensor that can work with parallel or CSI-2 interface, and in that case would you consider something like: static int bridge_driver_parse_of(struct device_node *np): struct v4l2_fwnode_endpoint bus_cfg ; bus_type = v4l2_fwnode_get_bus_type(fwnode_handle(np); if (bus_type != V4L2_MBUS_PARALLEL && bus_type != V4L2_MBUS_BT656) return -ENXIO; bus_cfg.bus_type = bus_type; v4l2_fwnode_endpoint_parse(of_fwnode_handle(np), _cfg); Adding a function to retrieve the bus type specified in firmware would make easier for drivers to check if the configuration is acceptable (as this is a device specific decision) and use this information later to provide to v4l2_fwnode_endpoint_parse() a v4l2_fwnode_endpoint with the bus_type initialized, so it does not need to rely on autoguessing. Otherwise, if I got this right, the only way not to go with autoguessing is to restrict the supported media bus type to a single one, which for some devices is a limitation. Does this makes sense to you? Thanks j > I've pushed the patches (including Steve's) here: > > https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-fwnode> > > Sakari Ailus (21): > v4l: fwnode: Add debug prints for V4L2 endpoint property parsing > v4l: fwnode: Use fwnode_graph_for_each_endpoint > v4l: fwnode: Detect bus type correctly > v4l: fwnode: The CSI-2 clock is continuous if it's not non-continuous > dt-bindings: media: Specify bus type for MIPI D-PHY, others, > explicitly > v4l: fwnode: Add definitions for CSI-2 D-PHY, parallel and Bt.656 > busses > v4l: mediabus: Recognise CSI-2 D-PHY and C-PHY > v4l: fwnode: Make use of newly specified bus types > v4l: fwnode: Read lane inversion information despite lane numbering > v4l: fwnode: Only assign configuration if there is no error > v4l: fwnode: Support driver-defined lane mapping defaults > v4l: fwnode: Support default CSI-2 lane mapping for drivers > v4l: fwnode: Parse the graph endpoint as last > v4l: fwnode: Use default parallel flags > v4l: fwnode: Allow setting default parameters > v4l: fwnode: Use media bus
qcom: update firmware file for Venus on SDM845
hi, This pull request updates firmware files for Venus h/w codec found on the Qualcomm SDM845 chipset. The following changes since commit 7b5835fd37630d18ac0c755329172f6a17c1af29: linux-firmware: add firmware for mt76x2u (2018-07-30 07:20:31 -0400) are available in the git repository at: https://github.com/vgarodia/venus_firmware_23 master for you to fetch changes up to 6ae7a5bf57f035aecc7613943528e52ada7e1e03: qcom: update venus firmware files for v5.2 (2018-08-10 12:57:47 +0530) Vikash Garodia (1): qcom: update venus firmware files for v5.2 WHENCE | 2 +- qcom/venus-5.2/venus.b00 | Bin 212 -> 212 bytes qcom/venus-5.2/venus.b01 | Bin 6600 -> 6600 bytes qcom/venus-5.2/venus.b02 | Bin 819552 -> 837304 bytes qcom/venus-5.2/venus.b03 | Bin 33536 -> 33640 bytes qcom/venus-5.2/venus.mbn | Bin 865408 -> 883264 bytes qcom/venus-5.2/venus.mdt | Bin 6812 -> 6812 bytes 7 files changed, 1 insertion(+), 1 deletion(-)
Re: [PATCH v1 4/5] [media] i2c: drop soc_camera code from ov9640 and switch to v4l2_async
Hi Petr,
On Thu, Aug 09, 2018 at 03:39:48AM +0200, petrcve...@gmail.com wrote:
> From: Petr Cvek
>
> This patch removes the dependency on an obsoleted soc_camera from ov9640
> driver and changes the code to be a standalone v4l2 async subdevice.
> It also adds GPIO allocations for power and reset signals (as they are not
> handled by soc_camera now).
>
> The patch should make ov9640 again compatible with the pxa_camera driver.
Are there board files using this driverin mainline ? (git grep says so)
Care to port them to use the new driver if necessary? You can have a
look at the SH4 Migo-R board, which recently underwent the same
process (arch/sh/boards/mach-migor/setup.c)
I also suggest to adjust the build system in a single patch with this
changes, but that's not a big deal...
>
> Signed-off-by: Petr Cvek
> ---
> drivers/media/i2c/ov9640.c | 76 ++
> drivers/media/i2c/ov9640.h | 2 +
> 2 files changed, 55 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/media/i2c/ov9640.c b/drivers/media/i2c/ov9640.c
> index c63948989688..44129c60c524 100644
> --- a/drivers/media/i2c/ov9640.c
> +++ b/drivers/media/i2c/ov9640.c
> @@ -9,6 +9,7 @@
> * Kuninori Morimoto
> *
> * Based on ov7670 and soc_camera_platform driver,
> + * transition from soc_camera to pxa_camera based on mt9m111
> *
> * Copyright 2006-7 Jonathan Corbet
> * Copyright (C) 2008 Magnus Damm
While at there, drop the license text and add SPDX identifier please
> @@ -27,10 +28,14 @@
> #include
> #include
>
> -#include
> +#include
> #include
> #include
> #include
> +#include
> +#include
> +
> +#include
>
> #include "ov9640.h"
>
> @@ -323,11 +328,23 @@ static int ov9640_set_register(struct v4l2_subdev *sd,
>
> static int ov9640_s_power(struct v4l2_subdev *sd, int on)
> {
> - struct i2c_client *client = v4l2_get_subdevdata(sd);
> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> struct ov9640_priv *priv = to_ov9640_sensor(sd);
> -
> - return soc_camera_set_power(>dev, ssdd, priv->clk, on);
> + int ret = 0;
> +
> + if (on) {
> + gpiod_set_value(priv->gpio_power, 1);
> + mdelay(1);
mdelay() is backed by a busy-waiting loop, according to
timers-howto.txt and for milliseconds-long sleeps is not suggested.
Please try to quantify the required delay and use msleep_range().
> + ret = v4l2_clk_enable(priv->clk);
Is this required by the pxa camera driver using v4l2_clk_ APIs?
Otherwise you should use the clk API directly.
> + mdelay(1);
> + gpiod_set_value(priv->gpio_reset, 0);
> + } else {
> + gpiod_set_value(priv->gpio_reset, 1);
> + mdelay(1);
> + v4l2_clk_disable(priv->clk);
> + mdelay(1);
> + gpiod_set_value(priv->gpio_power, 0);
> + }
> + return ret;
> }
>
> /* select nearest higher resolution for capture */
> @@ -631,14 +648,10 @@ static const struct v4l2_subdev_core_ops
> ov9640_core_ops = {
> static int ov9640_g_mbus_config(struct v4l2_subdev *sd,
> struct v4l2_mbus_config *cfg)
g_mbus/s_mbus are deprecated. Unless the pxa camera driver wants them
all format negotiation should go through s_fmt/g_fmt pad operations
> {
> - struct i2c_client *client = v4l2_get_subdevdata(sd);
> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> -
> cfg->flags = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |
> V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_HIGH |
> V4L2_MBUS_DATA_ACTIVE_HIGH;
> cfg->type = V4L2_MBUS_PARALLEL;
> - cfg->flags = soc_camera_apply_board_flags(ssdd, cfg);
>
> return 0;
> }
> @@ -667,18 +680,27 @@ static int ov9640_probe(struct i2c_client *client,
> const struct i2c_device_id *did)
> {
> struct ov9640_priv *priv;
> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> int ret;
>
> - if (!ssdd) {
> - dev_err(>dev, "Missing platform_data for driver\n");
> - return -EINVAL;
> - }
> -
> - priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> + priv = devm_kzalloc(>dev, sizeof(*priv),
> + GFP_KERNEL);
> if (!priv)
> return -ENOMEM;
>
> + priv->gpio_power = devm_gpiod_get(>dev, "Camera power",
> + GPIOD_OUT_LOW);
> + if (IS_ERR_OR_NULL(priv->gpio_power)) {
> + ret = PTR_ERR(priv->gpio_power);
> + return ret;
> + }
> +
> + priv->gpio_reset = devm_gpiod_get(>dev, "Camera reset",
> + GPIOD_OUT_HIGH);
> + if (IS_ERR_OR_NULL(priv->gpio_reset)) {
> + ret = PTR_ERR(priv->gpio_reset);
> + return ret;
> + }
> +
> v4l2_i2c_subdev_init(>subdev, client, _subdev_ops);
>
>
Re: [PATCHv17 12/34] v4l2-ctrls: alloc memory for p_req
On 08/09/2018 10:19 PM, Mauro Carvalho Chehab wrote:
> Em Sat, 4 Aug 2018 14:45:04 +0200
> Hans Verkuil escreveu:
>
>> From: Hans Verkuil
>>
>> To store request data the handler_new_ref() allocates memory
>> for it if needed.
>>
>> Signed-off-by: Hans Verkuil
>> ---
>> drivers/media/v4l2-core/v4l2-ctrls.c | 20
>> 1 file changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
>> b/drivers/media/v4l2-core/v4l2-ctrls.c
>> index b33a8bee82b0..171ab389afdd 100644
>> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
>> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
>> @@ -2018,13 +2018,18 @@ EXPORT_SYMBOL(v4l2_ctrl_find);
>> /* Allocate a new v4l2_ctrl_ref and hook it into the handler. */
>> static int handler_new_ref(struct v4l2_ctrl_handler *hdl,
>> struct v4l2_ctrl *ctrl,
>> - bool from_other_dev)
>> + struct v4l2_ctrl_ref **ctrl_ref,
>> + bool from_other_dev, bool allocate_req)
>> {
>> struct v4l2_ctrl_ref *ref;
>> struct v4l2_ctrl_ref *new_ref;
>> u32 id = ctrl->id;
>> u32 class_ctrl = V4L2_CTRL_ID2WHICH(id) | 1;
>> int bucket = id % hdl->nr_of_buckets; /* which bucket to use */
>> +unsigned int sz_extra = 0;
>
> Nitpick: I would name it size_extra_req, to make clear its usage.
OK, makes sense.
Regards,
Hans
> Once renamed:
>
> Reviewed-by: Mauro Carvalho Chehab
>
>> +
>> +if (ctrl_ref)
>> +*ctrl_ref = NULL;
>>
>> /*
>> * Automatically add the control class if it is not yet present and
>> @@ -2038,11 +2043,16 @@ static int handler_new_ref(struct v4l2_ctrl_handler
>> *hdl,
>> if (hdl->error)
>> return hdl->error;
>>
>> -new_ref = kzalloc(sizeof(*new_ref), GFP_KERNEL);
>> +if (allocate_req)
>> +sz_extra = ctrl->elems * ctrl->elem_size;
>> +new_ref = kzalloc(sizeof(*new_ref) + sz_extra, GFP_KERNEL);
>> if (!new_ref)
>> return handler_set_err(hdl, -ENOMEM);
>> new_ref->ctrl = ctrl;
>> new_ref->from_other_dev = from_other_dev;
>> +if (sz_extra)
>> +new_ref->p_req.p = _ref[1];
>> +
>> if (ctrl->handler == hdl) {
>> /* By default each control starts in a cluster of its own.
>> new_ref->ctrl is basically a cluster array with one
>> @@ -2082,6 +2092,8 @@ static int handler_new_ref(struct v4l2_ctrl_handler
>> *hdl,
>> /* Insert the control node in the hash */
>> new_ref->next = hdl->buckets[bucket];
>> hdl->buckets[bucket] = new_ref;
>> +if (ctrl_ref)
>> +*ctrl_ref = new_ref;
>>
>> unlock:
>> mutex_unlock(hdl->lock);
>> @@ -2223,7 +2235,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
>> v4l2_ctrl_handler *hdl,
>> ctrl->type_ops->init(ctrl, idx, ctrl->p_new);
>> }
>>
>> -if (handler_new_ref(hdl, ctrl, false)) {
>> +if (handler_new_ref(hdl, ctrl, NULL, false, false)) {
>> kvfree(ctrl);
>> return NULL;
>> }
>> @@ -2416,7 +2428,7 @@ int v4l2_ctrl_add_handler(struct v4l2_ctrl_handler
>> *hdl,
>> /* Filter any unwanted controls */
>> if (filter && !filter(ctrl))
>> continue;
>> -ret = handler_new_ref(hdl, ctrl, from_other_dev);
>> +ret = handler_new_ref(hdl, ctrl, NULL, from_other_dev, false);
>> if (ret)
>> break;
>> }
>
>
>
> Thanks,
> Mauro
>
Re: [PATCHv17 11/34] v4l2-ctrls: prepare internal structs for request API
On 08/09/2018 10:16 PM, Mauro Carvalho Chehab wrote:
> Em Sat, 4 Aug 2018 14:45:03 +0200
> Hans Verkuil escreveu:
>
>> From: Hans Verkuil
>>
>> Embed and initialize a media_request_object in struct v4l2_ctrl_handler.
>>
>> Add a p_req field to struct v4l2_ctrl_ref that will store the
>> request value.
>>
>> Signed-off-by: Hans Verkuil
>> Signed-off-by: Alexandre Courbot
>
> Reviewed-by: Mauro Carvalho Chehab
>
>> ---
>> drivers/media/v4l2-core/v4l2-ctrls.c | 1 +
>> include/media/v4l2-ctrls.h | 10 ++
>> 2 files changed, 11 insertions(+)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
>> b/drivers/media/v4l2-core/v4l2-ctrls.c
>> index 404291f00715..b33a8bee82b0 100644
>> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
>> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
>> @@ -1901,6 +1901,7 @@ int v4l2_ctrl_handler_init_class(struct
>> v4l2_ctrl_handler *hdl,
>>sizeof(hdl->buckets[0]),
>>GFP_KERNEL | __GFP_ZERO);
>> hdl->error = hdl->buckets ? 0 : -ENOMEM;
>> +media_request_object_init(>req_obj);
>
> I don't like very much the idea of initializing it even when the
> request API won't work, e. g. :
>
> if (!mdev->ops || !mdev->ops->req_validate || !mdev->ops->req_queue)
>
> but I guess it would be too early to check it here, right?
Correct.
Regards,
Hans
>
>> return hdl->error;
>> }
>> EXPORT_SYMBOL(v4l2_ctrl_handler_init_class);
>> diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
>> index 192e31c21faf..3f4e062d4e3d 100644
>> --- a/include/media/v4l2-ctrls.h
>> +++ b/include/media/v4l2-ctrls.h
>> @@ -20,6 +20,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> /* forward references */
>> struct file;
>> @@ -249,6 +250,11 @@ struct v4l2_ctrl {
>> * ``prepare_ext_ctrls`` function at ``v4l2-ctrl.c``.
>> * @from_other_dev: If true, then @ctrl was defined in another
>> * device than the v4l2_ctrl_handler.
>> + * @p_req: If the control handler containing this control reference
>> + * is bound to a media request, then this points to the
>> + * value of the control that should be applied when the request
>> + * is executed, or to the value of the control at the time
>> + * that the request was completed.
>> *
>> * Each control handler has a list of these refs. The list_head is used to
>> * keep a sorted-by-control-ID list of all controls, while the next pointer
>> @@ -260,6 +266,7 @@ struct v4l2_ctrl_ref {
>> struct v4l2_ctrl *ctrl;
>> struct v4l2_ctrl_helper *helper;
>> bool from_other_dev;
>> +union v4l2_ctrl_ptr p_req;
>> };
>>
>> /**
>> @@ -283,6 +290,8 @@ struct v4l2_ctrl_ref {
>> * @notify_priv: Passed as argument to the v4l2_ctrl notify callback.
>> * @nr_of_buckets: Total number of buckets in the array.
>> * @error: The error code of the first failed control addition.
>> + * @req_obj:The media_request_object, used to link into a
>> + * media_request. This request object has a refcount.
>> */
>> struct v4l2_ctrl_handler {
>> struct mutex _lock;
>> @@ -295,6 +304,7 @@ struct v4l2_ctrl_handler {
>> void *notify_priv;
>> u16 nr_of_buckets;
>> int error;
>> +struct media_request_object req_obj;
>> };
>>
>> /**
>
>
>
> Thanks,
> Mauro
>
Re: [PATCHv17 08/34] v4l2-dev: lock req_queue_mutex
On 08/09/2018 10:03 PM, Mauro Carvalho Chehab wrote:
> Em Sat, 4 Aug 2018 14:45:00 +0200
> Hans Verkuil escreveu:
>
>> From: Hans Verkuil
>>
>> We need to serialize streamon/off with queueing new requests.
>> These ioctls may trigger the cancellation of a streaming
>> operation, and that should not be mixed with queuing a new
>> request at the same time.
>>
>> Finally close() needs this lock since that too can trigger the
>> cancellation of a streaming operation.
>>
>> We take the req_queue_mutex here before any other locks since
>> it is a very high-level lock.
>>
>> Signed-off-by: Hans Verkuil
>> Signed-off-by: Sakari Ailus
>> ---
>> drivers/media/v4l2-core/v4l2-dev.c | 13 +
>> drivers/media/v4l2-core/v4l2-ioctl.c | 22 +-
>> 2 files changed, 34 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-dev.c
>> b/drivers/media/v4l2-core/v4l2-dev.c
>> index 69e775930fc4..53018e4a4c78 100644
>> --- a/drivers/media/v4l2-core/v4l2-dev.c
>> +++ b/drivers/media/v4l2-core/v4l2-dev.c
>> @@ -444,8 +444,21 @@ static int v4l2_release(struct inode *inode, struct
>> file *filp)
>> struct video_device *vdev = video_devdata(filp);
>> int ret = 0;
>>
>> +/*
>> + * We need to serialize the release() with queueing new requests.
>> + * The release() may trigger the cancellation of a streaming
>> + * operation, and that should not be mixed with queueing a new
>> + * request at the same time.
>> + */
>> +if (v4l2_device_supports_requests(vdev->v4l2_dev))
>> +mutex_lock(>v4l2_dev->mdev->req_queue_mutex);
>> +
>> if (vdev->fops->release)
>> ret = vdev->fops->release(filp);
>> +
>> +if (v4l2_device_supports_requests(vdev->v4l2_dev))
>> +mutex_unlock(>v4l2_dev->mdev->req_queue_mutex);
>> +
>
> This will very likely generate sparse warnings. See my discussions
> with that regards with Linus.
>
> The only way to avoid it would be to do something like:
>
> if (v4l2_device_supports_requests(vdev->v4l2_dev)) {
> mutex_lock(>v4l2_dev->mdev->req_queue_mutex);
> if (vdev->fops->release)
> ret = vdev->fops->release(filp);
> mutex_unlock(>v4l2_dev->mdev->req_queue_mutex);
> } else {
> if (vdev->fops->release)
> ret = vdev->fops->release(filp);
> }
I'll check what sparse says and make this change if needed (I hate
working around sparse warnings).
>
>> if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
>> dprintk("%s: release\n",
>> video_device_node_name(vdev));
>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
>> b/drivers/media/v4l2-core/v4l2-ioctl.c
>> index 54afc9c7ee6e..ea475d833dd6 100644
>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>> @@ -2780,6 +2780,7 @@ static long __video_do_ioctl(struct file *file,
>> unsigned int cmd, void *arg)
>> {
>> struct video_device *vfd = video_devdata(file);
>> +struct mutex *req_queue_lock = NULL;
>> struct mutex *lock; /* ioctl serialization mutex */
>> const struct v4l2_ioctl_ops *ops = vfd->ioctl_ops;
>> bool write_only = false;
>> @@ -2799,10 +2800,27 @@ static long __video_do_ioctl(struct file *file,
>> if (test_bit(V4L2_FL_USES_V4L2_FH, >flags))
>> vfh = file->private_data;
>>
>> +/*
>> + * We need to serialize streamon/off with queueing new requests.
>> + * These ioctls may trigger the cancellation of a streaming
>> + * operation, and that should not be mixed with queueing a new
>> + * request at the same time.
>> + */
>> +if (v4l2_device_supports_requests(vfd->v4l2_dev) &&
>> +(cmd == VIDIOC_STREAMON || cmd == VIDIOC_STREAMOFF)) {
>> +req_queue_lock = >v4l2_dev->mdev->req_queue_mutex;
>> +
>> +if (mutex_lock_interruptible(req_queue_lock))
>> +return -ERESTARTSYS;
>> +}
>> +
>> lock = v4l2_ioctl_get_lock(vfd, vfh, cmd, arg);
>>
>> -if (lock && mutex_lock_interruptible(lock))
>> +if (lock && mutex_lock_interruptible(lock)) {
>> +if (req_queue_lock)
>> +mutex_unlock(req_queue_lock);
>> return -ERESTARTSYS;
>> +}
>
> Same applies here.
I'm not sure there is much that can be done here without making the
code hard to read. I'll see.
>
>>
>> if (!video_is_registered(vfd)) {
>> ret = -ENODEV;
>> @@ -2861,6 +2879,8 @@ static long __video_do_ioctl(struct file *file,
>> unlock:
>> if (lock)
>> mutex_unlock(lock);
>> +if (req_queue_lock)
>> +mutex_unlock(req_queue_lock);
>
> This code looks really weird! are you locking in order to get a
> lock pointer?
>
> That seems broken by design.
I've no idea what you mean. Both 'lock' and 'req_queue_lock' are pointers to
a struct mutex. If NULL, don't
Re: [PATCH v1 1/5] [media] soc_camera: ov9640: move ov9640 out of soc_camera
Hi Petr,
thanks for the patches,
On Thu, Aug 09, 2018 at 03:39:45AM +0200, petrcve...@gmail.com wrote:
> From: Petr Cvek
>
> Initial part of ov9640 transition from soc_camera subsystem to a standalone
> v4l2 subdevice.
>
> Signed-off-by: Petr Cvek
> ---
> drivers/media/i2c/{soc_camera => }/ov9640.c | 0
> drivers/media/i2c/{soc_camera => }/ov9640.h | 0
> 2 files changed, 0 insertions(+), 0 deletions(-)
> rename drivers/media/i2c/{soc_camera => }/ov9640.c (100%)
> rename drivers/media/i2c/{soc_camera => }/ov9640.h (100%)
>
> diff --git a/drivers/media/i2c/soc_camera/ov9640.c
> b/drivers/media/i2c/ov9640.c
> similarity index 100%
> rename from drivers/media/i2c/soc_camera/ov9640.c
> rename to drivers/media/i2c/ov9640.c
> diff --git a/drivers/media/i2c/soc_camera/ov9640.h
> b/drivers/media/i2c/ov9640.h
> similarity index 100%
> rename from drivers/media/i2c/soc_camera/ov9640.h
> rename to drivers/media/i2c/ov9640.h
When I've been recently doing the same for ov772x and other sensor
driver I've been suggested to first copy the driver into
drivers/media/i2c/ and leave the original soc_camera one there, so
they can be bulk removed or moved to staging. I'll let Hans confirm
this, as he's about to take care of this process.
Thanks
j
> --
> 2.18.0
>
signature.asc
Description: PGP signature
Re: [PATCHv17 05/34] media-request: add media_request_get_by_fd
On 08/09/2018 09:55 PM, Mauro Carvalho Chehab wrote:
> Em Sat, 4 Aug 2018 14:44:57 +0200
> Hans Verkuil escreveu:
>
>> From: Hans Verkuil
>>
>> Add media_request_get_by_fd() to find a request based on the file
>> descriptor.
>>
>> The caller has to call media_request_put() for the returned
>> request since this function increments the refcount.
>>
>> Signed-off-by: Hans Verkuil
>> Acked-by: Sakari Ailus
>> ---
>> drivers/media/media-request.c | 40 +++
>> include/media/media-request.h | 24 +
>> 2 files changed, 64 insertions(+)
>>
>> diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
>> index 253068f51a1f..4b523f3a03a3 100644
>> --- a/drivers/media/media-request.c
>> +++ b/drivers/media/media-request.c
>> @@ -231,6 +231,46 @@ static const struct file_operations request_fops = {
>> .release = media_request_close,
>> };
>>
>> +struct media_request *
>> +media_request_get_by_fd(struct media_device *mdev, int request_fd)
>> +{
>> +struct file *filp;
>> +struct media_request *req;
>> +
>> +if (!mdev || !mdev->ops ||
>> +!mdev->ops->req_validate || !mdev->ops->req_queue)
>> +return ERR_PTR(-EPERM);
>
> EPERM? I guess ENOTTY would be better.
>
> Any reason why using EPERM?
This is called by e.g. VIDIOC_QBUF or VIDIOC_S/G/TRY_EXT_CTRLS where someone
sets request_fd. Then this function is called to obtain the corresponding
media_request struct. If requests are not supported, then EPERM is returned.
Returning ENOTTY would be wrong, since VIDIOC_QBUF etc. are definitely
implemented,
instead they just do not permit the use of requests.
Let me know if I can add your Reviewed-by after this explanation.
Regards,
Hans
Re: [PATCHv17 03/34] media-request: implement media requests
On 08/09/2018 08:37 PM, Mauro Carvalho Chehab wrote: >> +get_task_comm(comm, current); >> +snprintf(req->debug_str, sizeof(req->debug_str), "%s:%d", >> + comm, fd); > > I'm pretty sure we've discussed about get_task_comm(). I don't think > we should use it, as the task with queues can be different than > the one with dequeues. Instead, just give an unique ID for each > request. That will allow tracking it in a better way, no matter how > the userspace app is encoded. The original discussion went back-and-forth a bit, but I'll just replace it with a unique ID. > Also, for dynamic debugs, the task ID can easily be obtained by > passing a parameter to it, with +t: > > echo "file media_request.c +t" > /sys/kernel/debug/dynamic_debug/control > > or, at the boot time with: > dyndbg="file media_request.c +t" > > So, Kernel shouldn't be bothered by having such hacks hardcoded > at the code. Regards, Hans
Re: [PATCHv17 02/34] uapi/linux/media.h: add request API
On 08/09/2018 07:53 PM, Mauro Carvalho Chehab wrote:
> Em Sat, 4 Aug 2018 14:44:54 +0200
> Hans Verkuil escreveu:
>
>> From: Hans Verkuil
>>
>> Define the public request API.
>>
>> This adds the new MEDIA_IOC_REQUEST_ALLOC ioctl to allocate a request
>> and two ioctls that operate on a request in order to queue the
>> contents of the request to the driver and to re-initialize the
>> request.
>>
>> Signed-off-by: Hans Verkuil
>> Acked-by: Sakari Ailus
>> Reviewed-by: Laurent Pinchart
>> ---
>> include/uapi/linux/media.h | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
>> index 36f76e777ef9..cf77f00a0f2d 100644
>> --- a/include/uapi/linux/media.h
>> +++ b/include/uapi/linux/media.h
>> @@ -364,11 +364,23 @@ struct media_v2_topology {
>>
>> /* ioctls */
>>
>> +struct __attribute__ ((packed)) media_request_alloc {
>> +__s32 fd;
>> +};
>> +
>> #define MEDIA_IOC_DEVICE_INFO _IOWR('|', 0x00, struct
>> media_device_info)
>> #define MEDIA_IOC_ENUM_ENTITIES _IOWR('|', 0x01, struct
>> media_entity_desc)
>> #define MEDIA_IOC_ENUM_LINKS_IOWR('|', 0x02, struct
>> media_links_enum)
>> #define MEDIA_IOC_SETUP_LINK_IOWR('|', 0x03, struct media_link_desc)
>> #define MEDIA_IOC_G_TOPOLOGY_IOWR('|', 0x04, struct
>> media_v2_topology)
>> +#define MEDIA_IOC_REQUEST_ALLOC _IOWR('|', 0x05, struct
>> media_request_alloc)
>
> Same comment as in patch 1: keep it simpler: just pass a s32 * as the
> argument for this ioctl.
Same comment as in patch 1: I have no strong opinion, but I want the input from
others
as well.
Regards,
Hans
>
>> +
>> +/*
>> + * These ioctls are called on the request file descriptor as returned
>> + * by MEDIA_IOC_REQUEST_ALLOC.
>> + */
>> +#define MEDIA_REQUEST_IOC_QUEUE _IO('|', 0x80)
>> +#define MEDIA_REQUEST_IOC_REINIT_IO('|', 0x81)
>>
>> #ifndef __KERNEL__
>>
>
>
>
> Thanks,
> Mauro
>
Re: [PATCHv17 01/34] Documentation: v4l: document request API
On 08/09/2018 07:43 PM, Mauro Carvalho Chehab wrote:
> Em Sat, 4 Aug 2018 14:44:53 +0200
> Hans Verkuil escreveu:
>
>> From: Alexandre Courbot
>>
>> Document the request API for V4L2 devices, and amend the documentation
>> of system calls influenced by it.
>
> It follows some comments. Most are nitpicks. There are just two ones
> that aren't:
> - a problem at the tables changes on Documentation/
> - a question with regards to MEDIA_IOC_REQUEST_ALLOC ioctl.
I'll fix all the smaller comments and in this reply only address these
two topics.
>
> I'll keep reviewing this patch series.
>
> PS.: I lost entirely my first review to this doc... I hope I didn't
> forget anything when re-typing my comments.
>
>>
>> Signed-off-by: Alexandre Courbot
>> Signed-off-by: Hans Verkuil
>> ---
>> .../media/uapi/mediactl/media-controller.rst | 1 +
>> .../media/uapi/mediactl/media-funcs.rst | 6 +
>> .../uapi/mediactl/media-ioc-request-alloc.rst | 78 ++
>> .../uapi/mediactl/media-request-ioc-queue.rst | 82 ++
>> .../mediactl/media-request-ioc-reinit.rst | 51
>> .../media/uapi/mediactl/request-api.rst | 247 ++
>> .../uapi/mediactl/request-func-close.rst | 49
>> .../uapi/mediactl/request-func-ioctl.rst | 68 +
>> .../media/uapi/mediactl/request-func-poll.rst | 77 ++
>> Documentation/media/uapi/v4l/buffer.rst | 21 +-
>> .../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 94 ---
>> Documentation/media/uapi/v4l/vidioc-qbuf.rst | 32 ++-
>> .../media/videodev2.h.rst.exceptions | 1 +
>> 13 files changed, 771 insertions(+), 36 deletions(-)
>> create mode 100644
>> Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
>> create mode 100644
>> Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
>> create mode 100644
>> Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
>> create mode 100644 Documentation/media/uapi/mediactl/request-api.rst
>> create mode 100644 Documentation/media/uapi/mediactl/request-func-close.rst
>> create mode 100644 Documentation/media/uapi/mediactl/request-func-ioctl.rst
>> create mode 100644 Documentation/media/uapi/mediactl/request-func-poll.rst
>>
>> +.. c:type:: media_request_alloc
>> +
>> +.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
>> +
>> +.. flat-table:: struct media_request_alloc
>> +:header-rows: 0
>> +:stub-columns: 0
>> +:widths: 1 1 2
>> +
>> +* - __s32
>> + - ``fd``
>> + - The file descriptor of the request.
>
> It should be mentioned that the struct should be zeroed before calling
> the Kernel, but I is overkill to have a struct to pass just one value.
>
> I mean, if this has just one value inside the struct, it is a way better
> to declare it as:
>
> .. c:function:: int ioctl( int fd, MEDIA_IOC_REQUEST_ALLOC, s32 )
>
> Even if we later need more stuff, the size of a new MEDIA_IOC_REQUEST_ALLOC
> will be bigger, and then (and only then) we can add extra stuff.
>
> Or are you foreseen any new fields there in short term?
The first version just had a s32 argument, not a struct. The main reason for
going back to a struct was indeed to make it easier to add new fields in the
future. I don't foresee any, but then, you never do.
I don't have a particularly strong opinion on this one way or another, but
if we change it back to a s32 argument, then I want the opinion of others as
well.
>> @@ -110,15 +130,13 @@ still cause this situation.
>> .. flat-table:: struct v4l2_ext_control
>> :header-rows: 0
>> :stub-columns: 0
>> -:widths: 1 1 1 2
>> +:widths: 1 1 3
>
> This is wrong: you can't change widths without changing the preceeding
> .. tabularcolumns tag.
>
> You probably didn't test PDF generation for this table.
>
> Also, the change is this table doesn't belong to this patch. It is
> a (doubtful) optimization at the table, not related to requests API.
>
>>
>> * - __u32
>>- ``id``
>> - -
>>- Identifies the control, set by the application.
>> * - __u32
>>- ``size``
>> - -
>>- The total size in bytes of the payload of this control. This is
>> normally 0, but for pointer controls this should be set to the
>> size of the memory containing the payload, or that will receive
>> @@ -135,51 +153,43 @@ still cause this situation.
>> *length* of the string may well be much smaller.
>> * - __u32
>>- ``reserved2``\ [1]
>> - -
>>- Reserved for future extensions. Drivers and applications must set
>> the array to zero.
>> -* - union
>> +* - union {
>
> Adding { and } at the end sounds ok...
>
>>- (anonymous)
>> -* -
>> - - __s32
>> +* - __s32
>>- ``value``
>>- New value or current value. Valid if this control is not of type
>> ``V4L2_CTRL_TYPE_INTEGER64`` and ``V4L2_CTRL_FLAG_HAS_PAYLOAD`` is
>> not
