Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1650065 > unrolled thread
| Started by | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| First post | 2017-05-25 02:40 +0200 |
| Last post | 2017-06-02 02:50 +0200 |
| Articles | 20 on this page of 57 — 7 participants |
Back to article view | Back to linux.kernel
[PATCH v7 00/34] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 05/34] ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 21/34] media: imx: Add Capture Device Interface Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 25/34] media: imx: Add MIPI CSI-2 Receiver subdev driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 13/34] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 31/34] media: imx: csi: add frame size/interval enumeration Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 14/34] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 27/34] media: imx: csi: add support for bayer formats Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 08/34] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 28/34] media: imx: csi: increase burst size for YUV formats Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 30/34] media: imx: csi: add sink selection rectangles Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 09/34] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 19/34] media: Add userspace header file for i.MX Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 12/34] ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 06/34] ARM: dts: imx6qdl: Add video multiplexers, mipi_csi, and their connections Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 15/34] add mux and video interface bridge entity functions Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
Re: [PATCH v7 15/34] add mux and video interface bridge entity functions Hans Verkuil <hverkuil@xs4all.nl> - 2017-05-29 15:40 +0200
Re: [PATCH v7 15/34] add mux and video interface bridge entity functions Hans Verkuil <hverkuil@xs4all.nl> - 2017-05-29 16:00 +0200
Re: [PATCH v7 15/34] add mux and video interface bridge entity functions Philipp Zabel <p.zabel@pengutronix.de> - 2017-05-29 16:00 +0200
[PATCH v7 29/34] media: imx: csi: add frame skipping support Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 04/34] ARM: dts: imx6qdl: add multiplexer controls Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 26/34] ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 01/34] dt-bindings: Add bindings for video-multiplexer device Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 23/34] media: imx: Add VDIC subdev driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 18/34] platform: video-mux: include temporary mmio-mux support Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
Re: [PATCH v7 18/34] platform: video-mux: include temporary mmio-mux support kbuild test robot <lkp@intel.com> - 2017-05-25 10:00 +0200
[PATCH] platform: video-mux: fix ptr_ret.cocci warnings kbuild test robot <lkp@intel.com> - 2017-05-25 10:00 +0200
[PATCH v7 17/34] platform: add video-multiplexer subdevice driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 34/34] media: imx: Drop warning upon multiple S_STREAM disable calls Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:40 +0200
[PATCH v7 02/34] [media] dt-bindings: Add bindings for i.MX media driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:50 +0200
[PATCH v7 10/34] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-25 02:50 +0200
Re: [PATCH v7 00/34] i.MX Media Driver Hans Verkuil <hverkuil@xs4all.nl> - 2017-05-29 15:50 +0200
Re: [PATCH v7 00/34] i.MX Media Driver Philipp Zabel <p.zabel@pengutronix.de> - 2017-05-29 16:20 +0200
Re: [PATCH v7 00/34] i.MX Media Driver Hans Verkuil <hverkuil@xs4all.nl> - 2017-05-29 16:30 +0200
Re: [PATCH v7 00/34] i.MX Media Driver Hans Verkuil <hverkuil@xs4all.nl> - 2017-05-29 17:30 +0200
Re: [PATCH v7 00/34] i.MX Media Driver Sakari Ailus <sakari.ailus@iki.fi> - 2017-05-29 17:40 +0200
Re: [PATCH v7 00/34] i.MX Media Driver Hans Verkuil <hverkuil@xs4all.nl> - 2017-05-29 18:30 +0200
Re: [PATCH v7 00/34] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-29 20:20 +0200
Re: [PATCH v7 00/34] i.MX Media Driver Pavel Machek <pavel@ucw.cz> - 2017-05-31 22:20 +0200
Re: [PATCH v7 00/34] i.MX Media Driver Hans Verkuil <hverkuil@xs4all.nl> - 2017-05-29 19:30 +0200
Re: [PATCH v7 00/34] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-29 19:30 +0200
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-05-30 00:00 +0200
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver Sakari Ailus <sakari.ailus@iki.fi> - 2017-05-30 09:00 +0200
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-06-03 20:10 +0200
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-06-04 20:10 +0200
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver Sakari Ailus <sakari.ailus@iki.fi> - 2017-06-07 14:40 +0200
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver Pavel Machek <pavel@ucw.cz> - 2017-05-31 22:00 +0200
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver Sakari Ailus <sakari.ailus@iki.fi> - 2017-06-01 10:30 +0200
exposure vs. exposure_absolute was Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver Pavel Machek <pavel@ucw.cz> - 2017-06-01 10:50 +0200
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-06-03 21:40 +0200
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver Pavel Machek <pavel@ucw.cz> - 2017-06-03 22:00 +0200
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver Sakari Ailus <sakari.ailus@iki.fi> - 2017-06-04 00:00 +0200
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver Pavel Machek <pavel@ucw.cz> - 2017-06-04 00:20 +0200
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-06-04 06:50 +0200
Re: [PATCH v7 16/34] [media] add Omnivision OV5640 sensor driver Sakari Ailus <sakari.ailus@iki.fi> - 2017-06-07 14:40 +0200
Re: [PATCH v7 00/34] i.MX Media Driver Tim Harvey <tharvey@gateworks.com> - 2017-06-02 02:30 +0200
Re: [PATCH v7 00/34] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-06-02 02:50 +0200
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-05-25 02:40 +0200 |
| Subject | [PATCH v7 04/34] ARM: dts: imx6qdl: add multiplexer controls |
| Message-ID | <tKOYQ-Xd-63@gated-at.bofh.it> |
| In reply to | #1650065 |
From: Philipp Zabel <p.zabel@pengutronix.de>
The IOMUXC General Purpose Register space contains various bitfields
that control video bus multiplexers. Describe them using a mmio-mux
node. The placement of the IPU CSI video mux controls differs between
i.MX6D/Q and i.MX6S/DL.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
arch/arm/boot/dts/imx6dl.dtsi | 10 ++++++++++
arch/arm/boot/dts/imx6q.dtsi | 10 ++++++++++
arch/arm/boot/dts/imx6qdl.dtsi | 7 ++++++-
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 7aa120f..10bc9d1 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -181,6 +181,16 @@
"di0", "di1";
};
+&mux {
+ mux-reg-masks = <0x34 0x00000007>, /* IPU_CSI0_MUX */
+ <0x34 0x00000038>, /* IPU_CSI1_MUX */
+ <0x0c 0x0000000c>, /* HDMI_MUX_CTL */
+ <0x0c 0x000000c0>, /* LVDS0_MUX_CTL */
+ <0x0c 0x00000300>, /* LVDS1_MUX_CTL */
+ <0x28 0x00000003>, /* DCIC1_MUX_CTL */
+ <0x28 0x0000000c>; /* DCIC2_MUX_CTL */
+};
+
&vpu {
compatible = "fsl,imx6dl-vpu", "cnm,coda960";
};
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index e9a5d0b..a6962be 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -332,6 +332,16 @@
};
};
+&mux {
+ mux-reg-masks = <0x04 0x00080000>, /* MIPI_IPU1_MUX */
+ <0x04 0x00100000>, /* MIPI_IPU2_MUX */
+ <0x0c 0x0000000c>, /* HDMI_MUX_CTL */
+ <0x0c 0x000000c0>, /* LVDS0_MUX_CTL */
+ <0x0c 0x00000300>, /* LVDS1_MUX_CTL */
+ <0x28 0x00000003>, /* DCIC1_MUX_CTL */
+ <0x28 0x0000000c>; /* DCIC2_MUX_CTL */
+};
+
&vpu {
compatible = "fsl,imx6q-vpu", "cnm,coda960";
};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index e426faa..50534dd 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -808,8 +808,13 @@
};
gpr: iomuxc-gpr@020e0000 {
- compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
+ compatible = "fsl,imx6q-iomuxc-gpr", "syscon", "simple-mfd";
reg = <0x020e0000 0x38>;
+
+ mux: mux-controller {
+ compatible = "mmio-mux";
+ #mux-control-cells = <1>;
+ };
};
iomuxc: iomuxc@020e0000 {
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-05-25 02:40 +0200 |
| Subject | [PATCH v7 26/34] ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers |
| Message-ID | <tKOYQ-Xd-65@gated-at.bofh.it> |
| In reply to | #1650065 |
Enable i.MX v4l2 media staging driver. For video capture on i.MX, the video multiplexer subdev is required. On the SabreAuto, the ADV7180 video decoder is required along with i2c-mux-gpio. The Sabrelite and SabreSD require the OV5640 and the SabreLite requires PWM clocks for the OV5640. Increase max zoneorder to allow larger video buffer allocations. Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com> --- arch/arm/configs/imx_v6_v7_defconfig | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index bb6fa56..63caf25 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -51,6 +51,7 @@ CONFIG_PREEMPT_VOLUNTARY=y CONFIG_AEABI=y CONFIG_HIGHMEM=y CONFIG_CMA=y +CONFIG_FORCE_MAX_ZONEORDER=14 CONFIG_CMDLINE="noinitrd console=ttymxc0,115200" CONFIG_KEXEC=y CONFIG_CPU_FREQ=y @@ -183,6 +184,7 @@ CONFIG_SERIAL_FSL_LPUART=y CONFIG_SERIAL_FSL_LPUART_CONSOLE=y # CONFIG_I2C_COMPAT is not set CONFIG_I2C_CHARDEV=y +CONFIG_I2C_MUX=y CONFIG_I2C_MUX_GPIO=y # CONFIG_I2C_HELPER_AUTO is not set CONFIG_I2C_ALGOPCF=m @@ -223,14 +225,20 @@ CONFIG_REGULATOR_PFUZE100=y CONFIG_MEDIA_SUPPORT=y CONFIG_MEDIA_CAMERA_SUPPORT=y CONFIG_MEDIA_RC_SUPPORT=y +CONFIG_MEDIA_CONTROLLER=y +CONFIG_VIDEO_V4L2_SUBDEV_API=y CONFIG_RC_DEVICES=y CONFIG_IR_GPIO_CIR=y CONFIG_MEDIA_USB_SUPPORT=y CONFIG_USB_VIDEO_CLASS=m CONFIG_V4L_PLATFORM_DRIVERS=y +CONFIG_VIDEO_MUX=y CONFIG_SOC_CAMERA=y CONFIG_V4L_MEM2MEM_DRIVERS=y CONFIG_VIDEO_CODA=y +# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set +CONFIG_VIDEO_ADV7180=m +CONFIG_VIDEO_OV5640=m CONFIG_SOC_CAMERA_OV2640=y CONFIG_IMX_IPUV3_CORE=y CONFIG_DRM=y @@ -340,6 +348,9 @@ CONFIG_FSL_EDMA=y CONFIG_IMX_SDMA=y CONFIG_MXS_DMA=y CONFIG_STAGING=y +CONFIG_STAGING_MEDIA=y +CONFIG_VIDEO_IMX_MEDIA=y +CONFIG_COMMON_CLK_PWM=y CONFIG_IIO=y CONFIG_VF610_ADC=y CONFIG_MPL3115=y -- 2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-05-25 02:40 +0200 |
| Subject | [PATCH v7 01/34] dt-bindings: Add bindings for video-multiplexer device |
| Message-ID | <tKOYP-Xd-51@gated-at.bofh.it> |
| In reply to | #1650065 |
From: Philipp Zabel <p.zabel@pengutronix.de>
Add bindings documentation for the video multiplexer device.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/media/video-mux.txt | 60 ++++++++++++++++++++++
1 file changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/video-mux.txt
diff --git a/Documentation/devicetree/bindings/media/video-mux.txt b/Documentation/devicetree/bindings/media/video-mux.txt
new file mode 100644
index 0000000..63b9dc9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/video-mux.txt
@@ -0,0 +1,60 @@
+Video Multiplexer
+=================
+
+Video multiplexers allow to select between multiple input ports. Video received
+on the active input port is passed through to the output port. Muxes described
+by this binding are controlled by a multiplexer controller that is described by
+the bindings in Documentation/devicetree/bindings/mux/mux-controller.txt
+
+Required properties:
+- compatible : should be "video-mux"
+- mux-controls : mux controller node to use for operating the mux
+- #address-cells: should be <1>
+- #size-cells: should be <0>
+- port@*: at least three port nodes containing endpoints connecting to the
+ source and sink devices according to of_graph bindings. The last port is
+ the output port, all others are inputs.
+
+Optionally, #address-cells, #size-cells, and port nodes can be grouped under a
+ports node as described in Documentation/devicetree/bindings/graph.txt.
+
+Example:
+
+ mux: mux-controller {
+ compatible = "gpio-mux";
+ #mux-control-cells = <0>;
+
+ mux-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
+ };
+
+ video-mux {
+ compatible = "video-mux";
+ mux-controls = <&mux>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mux_in0: endpoint {
+ remote-endpoint = <&video_source0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mux_in1: endpoint {
+ remote-endpoint = <&video_source1_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ mux_out: endpoint {
+ remote-endpoint = <&capture_interface_in>;
+ };
+ };
+ };
+};
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-05-25 02:40 +0200 |
| Subject | [PATCH v7 23/34] media: imx: Add VDIC subdev driver |
| Message-ID | <tKOYQ-Xd-67@gated-at.bofh.it> |
| In reply to | #1650065 |
This is a media entity subdevice driver for the i.MX Video De-Interlacing
or Combining Block. So far this entity does not implement the Combining
function but only motion compensated deinterlacing. Video frames are
received from the CSI and are routed to the IC PRPVF entity.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
drivers/staging/media/imx/Makefile | 1 +
drivers/staging/media/imx/imx-media-vdic.c | 1004 ++++++++++++++++++++++++++++
2 files changed, 1005 insertions(+)
create mode 100644 drivers/staging/media/imx/imx-media-vdic.c
diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile
index c054490..1f01520 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -4,5 +4,6 @@ imx-media-common-objs := imx-media-utils.o imx-media-fim.o
obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media.o
obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-common.o
obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-capture.o
+obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-vdic.o
obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o
diff --git a/drivers/staging/media/imx/imx-media-vdic.c b/drivers/staging/media/imx/imx-media-vdic.c
new file mode 100644
index 0000000..3dedc47
--- /dev/null
+++ b/drivers/staging/media/imx/imx-media-vdic.c
@@ -0,0 +1,1004 @@
+/*
+ * V4L2 Deinterlacer Subdev for Freescale i.MX5/6 SOC
+ *
+ * Copyright (c) 2017 Mentor Graphics Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/sched.h>
+#include <linux/slab.h>
+#include <linux/timer.h>
+#include <media/v4l2-ctrls.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-ioctl.h>
+#include <media/v4l2-mc.h>
+#include <media/v4l2-subdev.h>
+#include <media/imx.h>
+#include "imx-media.h"
+
+/*
+ * This subdev implements two different video pipelines:
+ *
+ * CSI -> VDIC
+ *
+ * In this pipeline, the CSI sends a single interlaced field F(n-1)
+ * directly to the VDIC (and optionally the following field F(n)
+ * can be sent to memory via IDMAC channel 13). This pipeline only works
+ * in VDIC's high motion mode, which only requires a single field for
+ * processing. The other motion modes (low and medium) require three
+ * fields, so this pipeline does not work in those modes. Also, it is
+ * not clear how this pipeline can deal with the various field orders
+ * (sequential BT/TB, interlaced BT/TB).
+ *
+ * MEM -> CH8,9,10 -> VDIC
+ *
+ * In this pipeline, previous field F(n-1), current field F(n), and next
+ * field F(n+1) are transferred to the VDIC via IDMAC channels 8,9,10.
+ * These memory buffers can come from a video output or mem2mem device.
+ * All motion modes are supported by this pipeline.
+ *
+ * The "direct" CSI->VDIC pipeline requires no DMA, but it can only be
+ * used in high motion mode.
+ */
+
+struct vdic_priv;
+
+struct vdic_pipeline_ops {
+ int (*setup)(struct vdic_priv *priv);
+ void (*start)(struct vdic_priv *priv);
+ void (*stop)(struct vdic_priv *priv);
+ void (*disable)(struct vdic_priv *priv);
+};
+
+/*
+ * Min/Max supported width and heights.
+ */
+#define MIN_W 176
+#define MIN_H 144
+#define MAX_W_VDIC 968
+#define MAX_H_VDIC 2048
+#define W_ALIGN 4 /* multiple of 16 pixels */
+#define H_ALIGN 1 /* multiple of 2 lines */
+#define S_ALIGN 1 /* multiple of 2 */
+
+struct vdic_priv {
+ struct device *dev;
+ struct ipu_soc *ipu;
+ struct imx_media_dev *md;
+ struct v4l2_subdev sd;
+ struct media_pad pad[VDIC_NUM_PADS];
+ int ipu_id;
+
+ /* lock to protect all members below */
+ struct mutex lock;
+
+ /* IPU units we require */
+ struct ipu_vdi *vdi;
+
+ int active_input_pad;
+
+ struct ipuv3_channel *vdi_in_ch_p; /* F(n-1) transfer channel */
+ struct ipuv3_channel *vdi_in_ch; /* F(n) transfer channel */
+ struct ipuv3_channel *vdi_in_ch_n; /* F(n+1) transfer channel */
+
+ /* pipeline operations */
+ struct vdic_pipeline_ops *ops;
+
+ /* current and previous input buffers indirect path */
+ struct imx_media_buffer *curr_in_buf;
+ struct imx_media_buffer *prev_in_buf;
+
+ /*
+ * translated field type, input line stride, and field size
+ * for indirect path
+ */
+ u32 fieldtype;
+ u32 in_stride;
+ u32 field_size;
+
+ /* the source (a video device or subdev) */
+ struct media_entity *src;
+ /* the sink that will receive the progressive out buffers */
+ struct v4l2_subdev *sink_sd;
+
+ struct v4l2_mbus_framefmt format_mbus[VDIC_NUM_PADS];
+ const struct imx_media_pixfmt *cc[VDIC_NUM_PADS];
+ struct v4l2_fract frame_interval[VDIC_NUM_PADS];
+
+ /* the video device at IDMAC input pad */
+ struct imx_media_video_dev *vdev;
+
+ bool csi_direct; /* using direct CSI->VDIC->IC pipeline */
+
+ /* motion select control */
+ struct v4l2_ctrl_handler ctrl_hdlr;
+ enum ipu_motion_sel motion;
+
+ int stream_count;
+};
+
+static void vdic_put_ipu_resources(struct vdic_priv *priv)
+{
+ if (!IS_ERR_OR_NULL(priv->vdi_in_ch_p))
+ ipu_idmac_put(priv->vdi_in_ch_p);
+ priv->vdi_in_ch_p = NULL;
+
+ if (!IS_ERR_OR_NULL(priv->vdi_in_ch))
+ ipu_idmac_put(priv->vdi_in_ch);
+ priv->vdi_in_ch = NULL;
+
+ if (!IS_ERR_OR_NULL(priv->vdi_in_ch_n))
+ ipu_idmac_put(priv->vdi_in_ch_n);
+ priv->vdi_in_ch_n = NULL;
+
+ if (!IS_ERR_OR_NULL(priv->vdi))
+ ipu_vdi_put(priv->vdi);
+ priv->vdi = NULL;
+}
+
+static int vdic_get_ipu_resources(struct vdic_priv *priv)
+{
+ int ret, err_chan;
+
+ priv->ipu = priv->md->ipu[priv->ipu_id];
+
+ priv->vdi = ipu_vdi_get(priv->ipu);
+ if (IS_ERR(priv->vdi)) {
+ v4l2_err(&priv->sd, "failed to get VDIC\n");
+ ret = PTR_ERR(priv->vdi);
+ goto out;
+ }
+
+ if (!priv->csi_direct) {
+ priv->vdi_in_ch_p = ipu_idmac_get(priv->ipu,
+ IPUV3_CHANNEL_MEM_VDI_PREV);
+ if (IS_ERR(priv->vdi_in_ch_p)) {
+ err_chan = IPUV3_CHANNEL_MEM_VDI_PREV;
+ ret = PTR_ERR(priv->vdi_in_ch_p);
+ goto out_err_chan;
+ }
+
+ priv->vdi_in_ch = ipu_idmac_get(priv->ipu,
+ IPUV3_CHANNEL_MEM_VDI_CUR);
+ if (IS_ERR(priv->vdi_in_ch)) {
+ err_chan = IPUV3_CHANNEL_MEM_VDI_CUR;
+ ret = PTR_ERR(priv->vdi_in_ch);
+ goto out_err_chan;
+ }
+
+ priv->vdi_in_ch_n = ipu_idmac_get(priv->ipu,
+ IPUV3_CHANNEL_MEM_VDI_NEXT);
+ if (IS_ERR(priv->vdi_in_ch_n)) {
+ err_chan = IPUV3_CHANNEL_MEM_VDI_NEXT;
+ ret = PTR_ERR(priv->vdi_in_ch_n);
+ goto out_err_chan;
+ }
+ }
+
+ return 0;
+
+out_err_chan:
+ v4l2_err(&priv->sd, "could not get IDMAC channel %u\n", err_chan);
+out:
+ vdic_put_ipu_resources(priv);
+ return ret;
+}
+
+/*
+ * This function is currently unused, but will be called when the
+ * output/mem2mem device at the IDMAC input pad sends us a new
+ * buffer. It kicks off the IDMAC read channels to bring in the
+ * buffer fields from memory and begin the conversions.
+ */
+static void __maybe_unused prepare_vdi_in_buffers(struct vdic_priv *priv,
+ struct imx_media_buffer *curr)
+{
+ dma_addr_t prev_phys, curr_phys, next_phys;
+ struct imx_media_buffer *prev;
+ struct vb2_buffer *curr_vb, *prev_vb;
+ u32 fs = priv->field_size;
+ u32 is = priv->in_stride;
+
+ /* current input buffer is now previous */
+ priv->prev_in_buf = priv->curr_in_buf;
+ priv->curr_in_buf = curr;
+ prev = priv->prev_in_buf ? priv->prev_in_buf : curr;
+
+ prev_vb = &prev->vbuf.vb2_buf;
+ curr_vb = &curr->vbuf.vb2_buf;
+
+ switch (priv->fieldtype) {
+ case V4L2_FIELD_SEQ_TB:
+ prev_phys = vb2_dma_contig_plane_dma_addr(prev_vb, 0);
+ curr_phys = vb2_dma_contig_plane_dma_addr(curr_vb, 0) + fs;
+ next_phys = vb2_dma_contig_plane_dma_addr(curr_vb, 0);
+ break;
+ case V4L2_FIELD_SEQ_BT:
+ prev_phys = vb2_dma_contig_plane_dma_addr(prev_vb, 0) + fs;
+ curr_phys = vb2_dma_contig_plane_dma_addr(curr_vb, 0);
+ next_phys = vb2_dma_contig_plane_dma_addr(curr_vb, 0) + fs;
+ break;
+ case V4L2_FIELD_INTERLACED_BT:
+ prev_phys = vb2_dma_contig_plane_dma_addr(prev_vb, 0) + is;
+ curr_phys = vb2_dma_contig_plane_dma_addr(curr_vb, 0);
+ next_phys = vb2_dma_contig_plane_dma_addr(curr_vb, 0) + is;
+ break;
+ default:
+ /* assume V4L2_FIELD_INTERLACED_TB */
+ prev_phys = vb2_dma_contig_plane_dma_addr(prev_vb, 0);
+ curr_phys = vb2_dma_contig_plane_dma_addr(curr_vb, 0) + is;
+ next_phys = vb2_dma_contig_plane_dma_addr(curr_vb, 0);
+ break;
+ }
+
+ ipu_cpmem_set_buffer(priv->vdi_in_ch_p, 0, prev_phys);
+ ipu_cpmem_set_buffer(priv->vdi_in_ch, 0, curr_phys);
+ ipu_cpmem_set_buffer(priv->vdi_in_ch_n, 0, next_phys);
+
+ ipu_idmac_select_buffer(priv->vdi_in_ch_p, 0);
+ ipu_idmac_select_buffer(priv->vdi_in_ch, 0);
+ ipu_idmac_select_buffer(priv->vdi_in_ch_n, 0);
+}
+
+static int setup_vdi_channel(struct vdic_priv *priv,
+ struct ipuv3_channel *channel,
+ dma_addr_t phys0, dma_addr_t phys1)
+{
+ struct imx_media_video_dev *vdev = priv->vdev;
+ unsigned int burst_size;
+ struct ipu_image image;
+ int ret;
+
+ ipu_cpmem_zero(channel);
+
+ memset(&image, 0, sizeof(image));
+ image.pix = vdev->fmt.fmt.pix;
+ /* one field to VDIC channels */
+ image.pix.height /= 2;
+ image.rect.width = image.pix.width;
+ image.rect.height = image.pix.height;
+ image.phys0 = phys0;
+ image.phys1 = phys1;
+
+ ret = ipu_cpmem_set_image(channel, &image);
+ if (ret)
+ return ret;
+
+ burst_size = (image.pix.width & 0xf) ? 8 : 16;
+ ipu_cpmem_set_burstsize(channel, burst_size);
+
+ ipu_cpmem_set_axi_id(channel, 1);
+
+ ipu_idmac_set_double_buffer(channel, false);
+
+ return 0;
+}
+
+static int vdic_setup_direct(struct vdic_priv *priv)
+{
+ /* set VDIC to receive from CSI for direct path */
+ ipu_fsu_link(priv->ipu, IPUV3_CHANNEL_CSI_DIRECT,
+ IPUV3_CHANNEL_CSI_VDI_PREV);
+
+ return 0;
+}
+
+static void vdic_start_direct(struct vdic_priv *priv)
+{
+}
+
+static void vdic_stop_direct(struct vdic_priv *priv)
+{
+}
+
+static void vdic_disable_direct(struct vdic_priv *priv)
+{
+ ipu_fsu_unlink(priv->ipu, IPUV3_CHANNEL_CSI_DIRECT,
+ IPUV3_CHANNEL_CSI_VDI_PREV);
+}
+
+static int vdic_setup_indirect(struct vdic_priv *priv)
+{
+ struct v4l2_mbus_framefmt *infmt;
+ const struct imx_media_pixfmt *incc;
+ int in_size, ret;
+
+ infmt = &priv->format_mbus[VDIC_SINK_PAD_IDMAC];
+ incc = priv->cc[VDIC_SINK_PAD_IDMAC];
+
+ in_size = (infmt->width * incc->bpp * infmt->height) >> 3;
+
+ /* 1/2 full image size */
+ priv->field_size = in_size / 2;
+ priv->in_stride = incc->planar ?
+ infmt->width : (infmt->width * incc->bpp) >> 3;
+
+ priv->prev_in_buf = NULL;
+ priv->curr_in_buf = NULL;
+
+ priv->fieldtype = infmt->field;
+
+ /* init the vdi-in channels */
+ ret = setup_vdi_channel(priv, priv->vdi_in_ch_p, 0, 0);
+ if (ret)
+ return ret;
+ ret = setup_vdi_channel(priv, priv->vdi_in_ch, 0, 0);
+ if (ret)
+ return ret;
+ return setup_vdi_channel(priv, priv->vdi_in_ch_n, 0, 0);
+}
+
+static void vdic_start_indirect(struct vdic_priv *priv)
+{
+ /* enable the channels */
+ ipu_idmac_enable_channel(priv->vdi_in_ch_p);
+ ipu_idmac_enable_channel(priv->vdi_in_ch);
+ ipu_idmac_enable_channel(priv->vdi_in_ch_n);
+}
+
+static void vdic_stop_indirect(struct vdic_priv *priv)
+{
+ /* disable channels */
+ ipu_idmac_disable_channel(priv->vdi_in_ch_p);
+ ipu_idmac_disable_channel(priv->vdi_in_ch);
+ ipu_idmac_disable_channel(priv->vdi_in_ch_n);
+}
+
+static void vdic_disable_indirect(struct vdic_priv *priv)
+{
+}
+
+static struct vdic_pipeline_ops direct_ops = {
+ .setup = vdic_setup_direct,
+ .start = vdic_start_direct,
+ .stop = vdic_stop_direct,
+ .disable = vdic_disable_direct,
+};
+
+static struct vdic_pipeline_ops indirect_ops = {
+ .setup = vdic_setup_indirect,
+ .start = vdic_start_indirect,
+ .stop = vdic_stop_indirect,
+ .disable = vdic_disable_indirect,
+};
+
+static int vdic_start(struct vdic_priv *priv)
+{
+ struct v4l2_mbus_framefmt *infmt;
+ int ret;
+
+ infmt = &priv->format_mbus[priv->active_input_pad];
+
+ priv->ops = priv->csi_direct ? &direct_ops : &indirect_ops;
+
+ ret = vdic_get_ipu_resources(priv);
+ if (ret)
+ return ret;
+
+ /*
+ * init the VDIC.
+ *
+ * note we don't give infmt->code to ipu_vdi_setup(). The VDIC
+ * only supports 4:2:2 or 4:2:0, and this subdev will only
+ * negotiate 4:2:2 at its sink pads.
+ */
+ ipu_vdi_setup(priv->vdi, MEDIA_BUS_FMT_UYVY8_2X8,
+ infmt->width, infmt->height);
+ ipu_vdi_set_field_order(priv->vdi, V4L2_STD_UNKNOWN, infmt->field);
+ ipu_vdi_set_motion(priv->vdi, priv->motion);
+
+ ret = priv->ops->setup(priv);
+ if (ret)
+ goto out_put_ipu;
+
+ ipu_vdi_enable(priv->vdi);
+
+ priv->ops->start(priv);
+
+ return 0;
+
+out_put_ipu:
+ vdic_put_ipu_resources(priv);
+ return ret;
+}
+
+static void vdic_stop(struct vdic_priv *priv)
+{
+ priv->ops->stop(priv);
+ ipu_vdi_disable(priv->vdi);
+ priv->ops->disable(priv);
+
+ vdic_put_ipu_resources(priv);
+}
+
+/*
+ * V4L2 subdev operations.
+ */
+
+static int vdic_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct vdic_priv *priv = container_of(ctrl->handler,
+ struct vdic_priv, ctrl_hdlr);
+ enum ipu_motion_sel motion;
+ int ret = 0;
+
+ mutex_lock(&priv->lock);
+
+ switch (ctrl->id) {
+ case V4L2_CID_DEINTERLACING_MODE:
+ motion = ctrl->val;
+ if (motion != priv->motion) {
+ /* can't change motion control mid-streaming */
+ if (priv->stream_count > 0) {
+ ret = -EBUSY;
+ goto out;
+ }
+ priv->motion = motion;
+ }
+ break;
+ default:
+ v4l2_err(&priv->sd, "Invalid control\n");
+ ret = -EINVAL;
+ }
+
+out:
+ mutex_unlock(&priv->lock);
+ return ret;
+}
+
+static const struct v4l2_ctrl_ops vdic_ctrl_ops = {
+ .s_ctrl = vdic_s_ctrl,
+};
+
+static const char * const vdic_ctrl_motion_menu[] = {
+ "No Motion Compensation",
+ "Low Motion",
+ "Medium Motion",
+ "High Motion",
+};
+
+static int vdic_init_controls(struct vdic_priv *priv)
+{
+ struct v4l2_ctrl_handler *hdlr = &priv->ctrl_hdlr;
+ int ret;
+
+ v4l2_ctrl_handler_init(hdlr, 1);
+
+ v4l2_ctrl_new_std_menu_items(hdlr, &vdic_ctrl_ops,
+ V4L2_CID_DEINTERLACING_MODE,
+ HIGH_MOTION, 0, HIGH_MOTION,
+ vdic_ctrl_motion_menu);
+
+ priv->sd.ctrl_handler = hdlr;
+
+ if (hdlr->error) {
+ ret = hdlr->error;
+ goto out_free;
+ }
+
+ v4l2_ctrl_handler_setup(hdlr);
+ return 0;
+
+out_free:
+ v4l2_ctrl_handler_free(hdlr);
+ return ret;
+}
+
+static int vdic_s_stream(struct v4l2_subdev *sd, int enable)
+{
+ struct vdic_priv *priv = v4l2_get_subdevdata(sd);
+ struct v4l2_subdev *src_sd = NULL;
+ int ret = 0;
+
+ mutex_lock(&priv->lock);
+
+ if (!priv->src || !priv->sink_sd) {
+ ret = -EPIPE;
+ goto out;
+ }
+
+ if (priv->csi_direct)
+ src_sd = media_entity_to_v4l2_subdev(priv->src);
+
+ /*
+ * enable/disable streaming only if stream_count is
+ * going from 0 to 1 / 1 to 0.
+ */
+ if (priv->stream_count != !enable)
+ goto update_count;
+
+ dev_dbg(priv->dev, "stream %s\n", enable ? "ON" : "OFF");
+
+ if (enable)
+ ret = vdic_start(priv);
+ else
+ vdic_stop(priv);
+ if (ret)
+ goto out;
+
+ if (src_sd) {
+ /* start/stop upstream */
+ ret = v4l2_subdev_call(src_sd, video, s_stream, enable);
+ ret = (ret && ret != -ENOIOCTLCMD) ? ret : 0;
+ if (ret) {
+ if (enable)
+ vdic_stop(priv);
+ goto out;
+ }
+ }
+
+update_count:
+ priv->stream_count += enable ? 1 : -1;
+ WARN_ON(priv->stream_count < 0);
+out:
+ mutex_unlock(&priv->lock);
+ return ret;
+}
+
+static struct v4l2_mbus_framefmt *
+__vdic_get_fmt(struct vdic_priv *priv, struct v4l2_subdev_pad_config *cfg,
+ unsigned int pad, enum v4l2_subdev_format_whence which)
+{
+ if (which == V4L2_SUBDEV_FORMAT_TRY)
+ return v4l2_subdev_get_try_format(&priv->sd, cfg, pad);
+ else
+ return &priv->format_mbus[pad];
+}
+
+static int vdic_enum_mbus_code(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+ if (code->pad >= VDIC_NUM_PADS)
+ return -EINVAL;
+
+ return imx_media_enum_ipu_format(&code->code, code->index, CS_SEL_YUV);
+}
+
+static int vdic_get_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *sdformat)
+{
+ struct vdic_priv *priv = v4l2_get_subdevdata(sd);
+ struct v4l2_mbus_framefmt *fmt;
+ int ret = 0;
+
+ if (sdformat->pad >= VDIC_NUM_PADS)
+ return -EINVAL;
+
+ mutex_lock(&priv->lock);
+
+ fmt = __vdic_get_fmt(priv, cfg, sdformat->pad, sdformat->which);
+ if (!fmt) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ sdformat->format = *fmt;
+out:
+ mutex_unlock(&priv->lock);
+ return ret;
+}
+
+static void vdic_try_fmt(struct vdic_priv *priv,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *sdformat,
+ const struct imx_media_pixfmt **cc)
+{
+ struct v4l2_mbus_framefmt *infmt;
+
+ *cc = imx_media_find_ipu_format(sdformat->format.code, CS_SEL_YUV);
+ if (!*cc) {
+ u32 code;
+
+ imx_media_enum_ipu_format(&code, 0, CS_SEL_YUV);
+ *cc = imx_media_find_ipu_format(code, CS_SEL_YUV);
+ sdformat->format.code = (*cc)->codes[0];
+ }
+
+ switch (sdformat->pad) {
+ case VDIC_SRC_PAD_DIRECT:
+ infmt = __vdic_get_fmt(priv, cfg, priv->active_input_pad,
+ sdformat->which);
+ sdformat->format = *infmt;
+ /* output is always progressive! */
+ sdformat->format.field = V4L2_FIELD_NONE;
+ break;
+ case VDIC_SINK_PAD_DIRECT:
+ case VDIC_SINK_PAD_IDMAC:
+ v4l_bound_align_image(&sdformat->format.width,
+ MIN_W, MAX_W_VDIC, W_ALIGN,
+ &sdformat->format.height,
+ MIN_H, MAX_H_VDIC, H_ALIGN, S_ALIGN);
+
+ /* input must be interlaced! Choose SEQ_TB if not */
+ if (!V4L2_FIELD_HAS_BOTH(sdformat->format.field))
+ sdformat->format.field = V4L2_FIELD_SEQ_TB;
+ break;
+ }
+}
+
+static int vdic_set_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *sdformat)
+{
+ struct vdic_priv *priv = v4l2_get_subdevdata(sd);
+ const struct imx_media_pixfmt *cc;
+ struct v4l2_mbus_framefmt *fmt;
+ int ret = 0;
+
+ if (sdformat->pad >= VDIC_NUM_PADS)
+ return -EINVAL;
+
+ mutex_lock(&priv->lock);
+
+ if (priv->stream_count > 0) {
+ ret = -EBUSY;
+ goto out;
+ }
+
+ vdic_try_fmt(priv, cfg, sdformat, &cc);
+
+ fmt = __vdic_get_fmt(priv, cfg, sdformat->pad, sdformat->which);
+ *fmt = sdformat->format;
+
+ /* propagate format to source pad */
+ if (sdformat->pad == VDIC_SINK_PAD_DIRECT ||
+ sdformat->pad == VDIC_SINK_PAD_IDMAC) {
+ const struct imx_media_pixfmt *outcc;
+ struct v4l2_mbus_framefmt *outfmt;
+ struct v4l2_subdev_format format;
+
+ format.pad = VDIC_SRC_PAD_DIRECT;
+ format.which = sdformat->which;
+ format.format = sdformat->format;
+ vdic_try_fmt(priv, cfg, &format, &outcc);
+
+ outfmt = __vdic_get_fmt(priv, cfg, VDIC_SRC_PAD_DIRECT,
+ sdformat->which);
+ *outfmt = format.format;
+ if (sdformat->which == V4L2_SUBDEV_FORMAT_ACTIVE)
+ priv->cc[VDIC_SRC_PAD_DIRECT] = outcc;
+ }
+
+ if (sdformat->which == V4L2_SUBDEV_FORMAT_ACTIVE)
+ priv->cc[sdformat->pad] = cc;
+out:
+ mutex_unlock(&priv->lock);
+ return ret;
+}
+
+static int vdic_link_setup(struct media_entity *entity,
+ const struct media_pad *local,
+ const struct media_pad *remote, u32 flags)
+{
+ struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
+ struct vdic_priv *priv = v4l2_get_subdevdata(sd);
+ struct v4l2_subdev *remote_sd;
+ int ret = 0;
+
+ dev_dbg(priv->dev, "link setup %s -> %s", remote->entity->name,
+ local->entity->name);
+
+ mutex_lock(&priv->lock);
+
+ if (local->flags & MEDIA_PAD_FL_SOURCE) {
+ if (!is_media_entity_v4l2_subdev(remote->entity)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ remote_sd = media_entity_to_v4l2_subdev(remote->entity);
+
+ if (flags & MEDIA_LNK_FL_ENABLED) {
+ if (priv->sink_sd) {
+ ret = -EBUSY;
+ goto out;
+ }
+ priv->sink_sd = remote_sd;
+ } else {
+ priv->sink_sd = NULL;
+ }
+
+ goto out;
+ }
+
+ /* this is a sink pad */
+
+ if (flags & MEDIA_LNK_FL_ENABLED) {
+ if (priv->src) {
+ ret = -EBUSY;
+ goto out;
+ }
+ } else {
+ priv->src = NULL;
+ goto out;
+ }
+
+ if (local->index == VDIC_SINK_PAD_IDMAC) {
+ struct imx_media_video_dev *vdev = priv->vdev;
+
+ if (!is_media_entity_v4l2_video_device(remote->entity)) {
+ ret = -EINVAL;
+ goto out;
+ }
+ if (!vdev) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ priv->csi_direct = false;
+ } else {
+ if (!is_media_entity_v4l2_subdev(remote->entity)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ remote_sd = media_entity_to_v4l2_subdev(remote->entity);
+
+ /* direct pad must connect to a CSI */
+ if (!(remote_sd->grp_id & IMX_MEDIA_GRP_ID_CSI) ||
+ remote->index != CSI_SRC_PAD_DIRECT) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ priv->csi_direct = true;
+ }
+
+ priv->src = remote->entity;
+ /* record which input pad is now active */
+ priv->active_input_pad = local->index;
+out:
+ mutex_unlock(&priv->lock);
+ return ret;
+}
+
+static int vdic_link_validate(struct v4l2_subdev *sd,
+ struct media_link *link,
+ struct v4l2_subdev_format *source_fmt,
+ struct v4l2_subdev_format *sink_fmt)
+{
+ struct vdic_priv *priv = v4l2_get_subdevdata(sd);
+ int ret;
+
+ ret = v4l2_subdev_link_validate_default(sd, link,
+ source_fmt, sink_fmt);
+ if (ret)
+ return ret;
+
+ mutex_lock(&priv->lock);
+
+ if (priv->csi_direct && priv->motion != HIGH_MOTION) {
+ v4l2_err(&priv->sd,
+ "direct CSI pipeline requires high motion\n");
+ ret = -EINVAL;
+ }
+
+ mutex_unlock(&priv->lock);
+ return ret;
+}
+
+static int vdic_g_frame_interval(struct v4l2_subdev *sd,
+ struct v4l2_subdev_frame_interval *fi)
+{
+ struct vdic_priv *priv = v4l2_get_subdevdata(sd);
+
+ if (fi->pad >= VDIC_NUM_PADS)
+ return -EINVAL;
+
+ mutex_lock(&priv->lock);
+
+ fi->interval = priv->frame_interval[fi->pad];
+
+ mutex_unlock(&priv->lock);
+
+ return 0;
+}
+
+static int vdic_s_frame_interval(struct v4l2_subdev *sd,
+ struct v4l2_subdev_frame_interval *fi)
+{
+ struct vdic_priv *priv = v4l2_get_subdevdata(sd);
+ struct v4l2_fract *input_fi, *output_fi;
+ int ret = 0;
+
+ mutex_lock(&priv->lock);
+
+ input_fi = &priv->frame_interval[priv->active_input_pad];
+ output_fi = &priv->frame_interval[VDIC_SRC_PAD_DIRECT];
+
+ switch (fi->pad) {
+ case VDIC_SINK_PAD_DIRECT:
+ case VDIC_SINK_PAD_IDMAC:
+ /* No limits on input frame interval */
+ /* Reset output interval */
+ *output_fi = fi->interval;
+ if (priv->csi_direct)
+ output_fi->denominator *= 2;
+ break;
+ case VDIC_SRC_PAD_DIRECT:
+ /*
+ * frame rate at output pad is double input
+ * rate when using direct CSI->VDIC pipeline.
+ *
+ * TODO: implement VDIC frame skipping
+ */
+ fi->interval = *input_fi;
+ if (priv->csi_direct)
+ fi->interval.denominator *= 2;
+ break;
+ default:
+ ret = -EINVAL;
+ goto out;
+ }
+
+ priv->frame_interval[fi->pad] = fi->interval;
+out:
+ mutex_unlock(&priv->lock);
+ return ret;
+}
+
+/*
+ * retrieve our pads parsed from the OF graph by the media device
+ */
+static int vdic_registered(struct v4l2_subdev *sd)
+{
+ struct vdic_priv *priv = v4l2_get_subdevdata(sd);
+ int i, ret;
+ u32 code;
+
+ /* get media device */
+ priv->md = dev_get_drvdata(sd->v4l2_dev->dev);
+
+ for (i = 0; i < VDIC_NUM_PADS; i++) {
+ priv->pad[i].flags = (i == VDIC_SRC_PAD_DIRECT) ?
+ MEDIA_PAD_FL_SOURCE : MEDIA_PAD_FL_SINK;
+
+ code = 0;
+ if (i != VDIC_SINK_PAD_IDMAC)
+ imx_media_enum_ipu_format(&code, 0, CS_SEL_YUV);
+
+ /* set a default mbus format */
+ ret = imx_media_init_mbus_fmt(&priv->format_mbus[i],
+ 640, 480, code, V4L2_FIELD_NONE,
+ &priv->cc[i]);
+ if (ret)
+ return ret;
+
+ /* init default frame interval */
+ priv->frame_interval[i].numerator = 1;
+ priv->frame_interval[i].denominator = 30;
+ if (i == VDIC_SRC_PAD_DIRECT)
+ priv->frame_interval[i].denominator *= 2;
+ }
+
+ priv->active_input_pad = VDIC_SINK_PAD_DIRECT;
+
+ ret = vdic_init_controls(priv);
+ if (ret)
+ return ret;
+
+ ret = media_entity_pads_init(&sd->entity, VDIC_NUM_PADS, priv->pad);
+ if (ret)
+ v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
+
+ return ret;
+}
+
+static void vdic_unregistered(struct v4l2_subdev *sd)
+{
+ struct vdic_priv *priv = v4l2_get_subdevdata(sd);
+
+ v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
+}
+
+static const struct v4l2_subdev_pad_ops vdic_pad_ops = {
+ .enum_mbus_code = vdic_enum_mbus_code,
+ .get_fmt = vdic_get_fmt,
+ .set_fmt = vdic_set_fmt,
+ .link_validate = vdic_link_validate,
+};
+
+static const struct v4l2_subdev_video_ops vdic_video_ops = {
+ .g_frame_interval = vdic_g_frame_interval,
+ .s_frame_interval = vdic_s_frame_interval,
+ .s_stream = vdic_s_stream,
+};
+
+static const struct media_entity_operations vdic_entity_ops = {
+ .link_setup = vdic_link_setup,
+ .link_validate = v4l2_subdev_link_validate,
+};
+
+static const struct v4l2_subdev_ops vdic_subdev_ops = {
+ .video = &vdic_video_ops,
+ .pad = &vdic_pad_ops,
+};
+
+static const struct v4l2_subdev_internal_ops vdic_internal_ops = {
+ .registered = vdic_registered,
+ .unregistered = vdic_unregistered,
+};
+
+static int imx_vdic_probe(struct platform_device *pdev)
+{
+ struct imx_media_internal_sd_platformdata *pdata;
+ struct vdic_priv *priv;
+ int ret;
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, &priv->sd);
+ priv->dev = &pdev->dev;
+
+ pdata = priv->dev->platform_data;
+ priv->ipu_id = pdata->ipu_id;
+
+ v4l2_subdev_init(&priv->sd, &vdic_subdev_ops);
+ v4l2_set_subdevdata(&priv->sd, priv);
+ priv->sd.internal_ops = &vdic_internal_ops;
+ priv->sd.entity.ops = &vdic_entity_ops;
+ priv->sd.entity.function = MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER;
+ priv->sd.dev = &pdev->dev;
+ priv->sd.owner = THIS_MODULE;
+ priv->sd.flags = V4L2_SUBDEV_FL_HAS_DEVNODE;
+ /* get our group id */
+ priv->sd.grp_id = pdata->grp_id;
+ strncpy(priv->sd.name, pdata->sd_name, sizeof(priv->sd.name));
+
+ mutex_init(&priv->lock);
+
+ ret = v4l2_async_register_subdev(&priv->sd);
+ if (ret)
+ goto free;
+
+ return 0;
+free:
+ mutex_destroy(&priv->lock);
+ return ret;
+}
+
+static int imx_vdic_remove(struct platform_device *pdev)
+{
+ struct v4l2_subdev *sd = platform_get_drvdata(pdev);
+ struct vdic_priv *priv = v4l2_get_subdevdata(sd);
+
+ v4l2_info(sd, "Removing\n");
+
+ v4l2_async_unregister_subdev(sd);
+ mutex_destroy(&priv->lock);
+ media_entity_cleanup(&sd->entity);
+
+ return 0;
+}
+
+static const struct platform_device_id imx_vdic_ids[] = {
+ { .name = "imx-ipuv3-vdic" },
+ { },
+};
+MODULE_DEVICE_TABLE(platform, imx_vdic_ids);
+
+static struct platform_driver imx_vdic_driver = {
+ .probe = imx_vdic_probe,
+ .remove = imx_vdic_remove,
+ .id_table = imx_vdic_ids,
+ .driver = {
+ .name = "imx-ipuv3-vdic",
+ },
+};
+module_platform_driver(imx_vdic_driver);
+
+MODULE_DESCRIPTION("i.MX VDIC subdev driver");
+MODULE_AUTHOR("Steve Longerbeam <steve_longerbeam@mentor.com>");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:imx-ipuv3-vdic");
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-05-25 02:40 +0200 |
| Subject | [PATCH v7 18/34] platform: video-mux: include temporary mmio-mux support |
| Message-ID | <tKOYQ-Xd-71@gated-at.bofh.it> |
| In reply to | #1650065 |
From: Philipp Zabel <p.zabel@pengutronix.de>
As long as the mux framework is not merged, add temporary mmio-mux
support to the video-mux driver itself. This patch is to be reverted
once the "mux: minimal mux subsystem" and "mux: mmio-based syscon mux
controller" patches are merged.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
drivers/media/platform/Kconfig | 1 -
drivers/media/platform/video-mux.c | 62 ++++++++++++++++++++++++++++++++++++++
2 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index b98f755..fea1dc0 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -77,7 +77,6 @@ config VIDEO_M32R_AR_M64278
config VIDEO_MUX
tristate "Video Multiplexer"
depends on OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER
- depends on MULTIPLEXER
help
This driver provides support for N:1 video bus multiplexers.
diff --git a/drivers/media/platform/video-mux.c b/drivers/media/platform/video-mux.c
index 5ce2bd3..630dd9a 100644
--- a/drivers/media/platform/video-mux.c
+++ b/drivers/media/platform/video-mux.c
@@ -17,7 +17,12 @@
#include <linux/err.h>
#include <linux/module.h>
#include <linux/mutex.h>
+#ifdef CONFIG_MULTIPLEXER
#include <linux/mux/consumer.h>
+#else
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+#endif
#include <linux/of.h>
#include <linux/of_graph.h>
#include <linux/platform_device.h>
@@ -29,7 +34,11 @@ struct video_mux {
struct v4l2_subdev subdev;
struct media_pad *pads;
struct v4l2_mbus_framefmt *format_mbus;
+#ifdef CONFIG_MULTIPLEXER
struct mux_control *mux;
+#else
+ struct regmap_field *field;
+#endif
struct mutex lock;
int active;
};
@@ -70,7 +79,11 @@ static int video_mux_link_setup(struct media_entity *entity,
}
dev_dbg(sd->dev, "setting %d active\n", local->index);
+#ifdef CONFIG_MULTIPLEXER
ret = mux_control_try_select(vmux->mux, local->index);
+#else
+ ret = regmap_field_write(vmux->field, local->index);
+#endif
if (ret < 0)
goto out;
vmux->active = local->index;
@@ -79,7 +92,9 @@ static int video_mux_link_setup(struct media_entity *entity,
goto out;
dev_dbg(sd->dev, "going inactive\n");
+#ifdef CONFIG_MULTIPLEXER
mux_control_deselect(vmux->mux);
+#endif
vmux->active = -1;
}
@@ -193,6 +208,48 @@ static const struct v4l2_subdev_ops video_mux_subdev_ops = {
.video = &video_mux_subdev_video_ops,
};
+#ifndef CONFIG_MULTIPLEXER
+static int video_mux_probe_mmio_mux(struct video_mux *vmux)
+{
+ struct device *dev = vmux->subdev.dev;
+ struct of_phandle_args args;
+ struct reg_field field;
+ struct regmap *regmap;
+ u32 reg, mask;
+ int ret;
+
+ ret = of_parse_phandle_with_args(dev->of_node, "mux-controls",
+ "#mux-control-cells", 0, &args);
+ if (ret)
+ return ret;
+
+ if (!of_device_is_compatible(args.np, "mmio-mux"))
+ return -EINVAL;
+
+ regmap = syscon_node_to_regmap(args.np->parent);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ ret = of_property_read_u32_index(args.np, "mux-reg-masks",
+ 2 * args.args[0], ®);
+ if (!ret)
+ ret = of_property_read_u32_index(args.np, "mux-reg-masks",
+ 2 * args.args[0] + 1, &mask);
+ if (ret < 0)
+ return ret;
+
+ field.reg = reg;
+ field.msb = fls(mask) - 1;
+ field.lsb = ffs(mask) - 1;
+
+ vmux->field = devm_regmap_field_alloc(dev, regmap, field);
+ if (IS_ERR(vmux->field))
+ return PTR_ERR(vmux->field);
+
+ return 0;
+}
+#endif
+
static int video_mux_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
@@ -230,9 +287,14 @@ static int video_mux_probe(struct platform_device *pdev)
return -EINVAL;
}
+#ifdef CONFIG_MULTIPLEXER
vmux->mux = devm_mux_control_get(dev, NULL);
if (IS_ERR(vmux->mux)) {
ret = PTR_ERR(vmux->mux);
+#else
+ ret = video_mux_probe_mmio_mux(vmux);
+ if (ret) {
+#endif
if (ret != -EPROBE_DEFER)
dev_err(dev, "Failed to get mux: %d\n", ret);
return ret;
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | kbuild test robot <lkp@intel.com> |
|---|---|
| Date | 2017-05-25 10:00 +0200 |
| Subject | Re: [PATCH v7 18/34] platform: video-mux: include temporary mmio-mux support |
| Message-ID | <tKVQB-5n9-9@gated-at.bofh.it> |
| In reply to | #1650087 |
Hi Philipp, [auto build test WARNING on linuxtv-media/master] [also build test WARNING on v4.12-rc2 next-20170525] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Steve-Longerbeam/i-MX-Media-Driver/20170525-135051 base: git://linuxtv.org/media_tree.git master coccinelle warnings: (new ones prefixed by >>) >> drivers/media/platform/video-mux.c:246:1-3: WARNING: PTR_ERR_OR_ZERO can be used Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
[toc] | [prev] | [next] | [standalone]
| From | kbuild test robot <lkp@intel.com> |
|---|---|
| Date | 2017-05-25 10:00 +0200 |
| Subject | [PATCH] platform: video-mux: fix ptr_ret.cocci warnings |
| Message-ID | <tKVQB-5n9-7@gated-at.bofh.it> |
| In reply to | #1650087 |
drivers/media/platform/video-mux.c:246:1-3: WARNING: PTR_ERR_OR_ZERO can be used Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR Generated by: scripts/coccinelle/api/ptr_ret.cocci CC: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> --- video-mux.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) --- a/drivers/media/platform/video-mux.c +++ b/drivers/media/platform/video-mux.c @@ -243,10 +243,7 @@ static int video_mux_probe_mmio_mux(stru field.lsb = ffs(mask) - 1; vmux->field = devm_regmap_field_alloc(dev, regmap, field); - if (IS_ERR(vmux->field)) - return PTR_ERR(vmux->field); - - return 0; + return PTR_ERR_OR_ZERO(vmux->field); } #endif
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-05-25 02:40 +0200 |
| Subject | [PATCH v7 17/34] platform: add video-multiplexer subdevice driver |
| Message-ID | <tKOYP-Xd-53@gated-at.bofh.it> |
| In reply to | #1650065 |
From: Philipp Zabel <p.zabel@pengutronix.de>
This driver can handle SoC internal and external video bus multiplexers,
controlled by mux controllers provided by the mux controller framework,
such as MMIO register bitfields or GPIOs. The subdevice passes through
the mbus configuration of the active input to the output side.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
---
drivers/media/platform/Kconfig | 7 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/video-mux.c | 295 +++++++++++++++++++++++++++++++++++++
3 files changed, 304 insertions(+)
create mode 100644 drivers/media/platform/video-mux.c
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ac026ee..b98f755 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -74,6 +74,13 @@ config VIDEO_M32R_AR_M64278
To compile this driver as a module, choose M here: the
module will be called arv.
+config VIDEO_MUX
+ tristate "Video Multiplexer"
+ depends on OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER
+ depends on MULTIPLEXER
+ help
+ This driver provides support for N:1 video bus multiplexers.
+
config VIDEO_OMAP3
tristate "OMAP 3 Camera support"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 63303d6..a636302 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -28,6 +28,8 @@ obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o
obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE) += m2m-deinterlace.o
+obj-$(CONFIG_VIDEO_MUX) += video-mux.o
+
obj-$(CONFIG_VIDEO_S3C_CAMIF) += s3c-camif/
obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
diff --git a/drivers/media/platform/video-mux.c b/drivers/media/platform/video-mux.c
new file mode 100644
index 0000000..5ce2bd3
--- /dev/null
+++ b/drivers/media/platform/video-mux.c
@@ -0,0 +1,295 @@
+/*
+ * video stream multiplexer controlled via mux control
+ *
+ * Copyright (C) 2013 Pengutronix, Sascha Hauer <kernel@pengutronix.de>
+ * Copyright (C) 2016-2017 Pengutronix, Philipp Zabel <kernel@pengutronix.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/mux/consumer.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/platform_device.h>
+#include <media/v4l2-async.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-subdev.h>
+
+struct video_mux {
+ struct v4l2_subdev subdev;
+ struct media_pad *pads;
+ struct v4l2_mbus_framefmt *format_mbus;
+ struct mux_control *mux;
+ struct mutex lock;
+ int active;
+};
+
+static inline struct video_mux *v4l2_subdev_to_video_mux(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct video_mux, subdev);
+}
+
+static int video_mux_link_setup(struct media_entity *entity,
+ const struct media_pad *local,
+ const struct media_pad *remote, u32 flags)
+{
+ struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
+ struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
+ int ret = 0;
+
+ /*
+ * The mux state is determined by the enabled sink pad link.
+ * Enabling or disabling the source pad link has no effect.
+ */
+ if (local->flags & MEDIA_PAD_FL_SOURCE)
+ return 0;
+
+ dev_dbg(sd->dev, "link setup '%s':%d->'%s':%d[%d]",
+ remote->entity->name, remote->index, local->entity->name,
+ local->index, flags & MEDIA_LNK_FL_ENABLED);
+
+ mutex_lock(&vmux->lock);
+
+ if (flags & MEDIA_LNK_FL_ENABLED) {
+ if (vmux->active == local->index)
+ goto out;
+
+ if (vmux->active >= 0) {
+ ret = -EBUSY;
+ goto out;
+ }
+
+ dev_dbg(sd->dev, "setting %d active\n", local->index);
+ ret = mux_control_try_select(vmux->mux, local->index);
+ if (ret < 0)
+ goto out;
+ vmux->active = local->index;
+ } else {
+ if (vmux->active != local->index)
+ goto out;
+
+ dev_dbg(sd->dev, "going inactive\n");
+ mux_control_deselect(vmux->mux);
+ vmux->active = -1;
+ }
+
+out:
+ mutex_unlock(&vmux->lock);
+ return ret;
+}
+
+static const struct media_entity_operations video_mux_ops = {
+ .link_setup = video_mux_link_setup,
+ .link_validate = v4l2_subdev_link_validate,
+};
+
+static int video_mux_s_stream(struct v4l2_subdev *sd, int enable)
+{
+ struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
+ struct v4l2_subdev *upstream_sd;
+ struct media_pad *pad;
+
+ if (vmux->active == -1) {
+ dev_err(sd->dev, "Can not start streaming on inactive mux\n");
+ return -EINVAL;
+ }
+
+ pad = media_entity_remote_pad(&sd->entity.pads[vmux->active]);
+ if (!pad) {
+ dev_err(sd->dev, "Failed to find remote source pad\n");
+ return -ENOLINK;
+ }
+
+ if (!is_media_entity_v4l2_subdev(pad->entity)) {
+ dev_err(sd->dev, "Upstream entity is not a v4l2 subdev\n");
+ return -ENODEV;
+ }
+
+ upstream_sd = media_entity_to_v4l2_subdev(pad->entity);
+
+ return v4l2_subdev_call(upstream_sd, video, s_stream, enable);
+}
+
+static const struct v4l2_subdev_video_ops video_mux_subdev_video_ops = {
+ .s_stream = video_mux_s_stream,
+};
+
+static struct v4l2_mbus_framefmt *
+__video_mux_get_pad_format(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ unsigned int pad, u32 which)
+{
+ struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
+
+ switch (which) {
+ case V4L2_SUBDEV_FORMAT_TRY:
+ return v4l2_subdev_get_try_format(sd, cfg, pad);
+ case V4L2_SUBDEV_FORMAT_ACTIVE:
+ return &vmux->format_mbus[pad];
+ default:
+ return NULL;
+ }
+}
+
+static int video_mux_get_format(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *sdformat)
+{
+ struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
+
+ mutex_lock(&vmux->lock);
+
+ sdformat->format = *__video_mux_get_pad_format(sd, cfg, sdformat->pad,
+ sdformat->which);
+
+ mutex_unlock(&vmux->lock);
+
+ return 0;
+}
+
+static int video_mux_set_format(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *sdformat)
+{
+ struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
+ struct v4l2_mbus_framefmt *mbusformat;
+ struct media_pad *pad = &vmux->pads[sdformat->pad];
+
+ mbusformat = __video_mux_get_pad_format(sd, cfg, sdformat->pad,
+ sdformat->which);
+ if (!mbusformat)
+ return -EINVAL;
+
+ mutex_lock(&vmux->lock);
+
+ /* Source pad mirrors active sink pad, no limitations on sink pads */
+ if ((pad->flags & MEDIA_PAD_FL_SOURCE) && vmux->active >= 0)
+ sdformat->format = vmux->format_mbus[vmux->active];
+
+ *mbusformat = sdformat->format;
+
+ mutex_unlock(&vmux->lock);
+
+ return 0;
+}
+
+static const struct v4l2_subdev_pad_ops video_mux_pad_ops = {
+ .get_fmt = video_mux_get_format,
+ .set_fmt = video_mux_set_format,
+};
+
+static const struct v4l2_subdev_ops video_mux_subdev_ops = {
+ .pad = &video_mux_pad_ops,
+ .video = &video_mux_subdev_video_ops,
+};
+
+static int video_mux_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ struct device_node *ep;
+ struct video_mux *vmux;
+ unsigned int num_pads = 0;
+ int ret;
+ int i;
+
+ vmux = devm_kzalloc(dev, sizeof(*vmux), GFP_KERNEL);
+ if (!vmux)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, vmux);
+
+ v4l2_subdev_init(&vmux->subdev, &video_mux_subdev_ops);
+ snprintf(vmux->subdev.name, sizeof(vmux->subdev.name), "%s", np->name);
+ vmux->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+ vmux->subdev.dev = dev;
+
+ /*
+ * The largest numbered port is the output port. It determines
+ * total number of pads.
+ */
+ for_each_endpoint_of_node(np, ep) {
+ struct of_endpoint endpoint;
+
+ of_graph_parse_endpoint(ep, &endpoint);
+ num_pads = max(num_pads, endpoint.port + 1);
+ }
+
+ if (num_pads < 2) {
+ dev_err(dev, "Not enough ports %d\n", num_pads);
+ return -EINVAL;
+ }
+
+ vmux->mux = devm_mux_control_get(dev, NULL);
+ if (IS_ERR(vmux->mux)) {
+ ret = PTR_ERR(vmux->mux);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get mux: %d\n", ret);
+ return ret;
+ }
+
+ mutex_init(&vmux->lock);
+ vmux->active = -1;
+ vmux->pads = devm_kcalloc(dev, num_pads, sizeof(*vmux->pads),
+ GFP_KERNEL);
+ vmux->format_mbus = devm_kcalloc(dev, num_pads,
+ sizeof(*vmux->format_mbus),
+ GFP_KERNEL);
+
+ for (i = 0; i < num_pads - 1; i++)
+ vmux->pads[i].flags = MEDIA_PAD_FL_SINK;
+ vmux->pads[num_pads - 1].flags = MEDIA_PAD_FL_SOURCE;
+
+ vmux->subdev.entity.function = MEDIA_ENT_F_VID_MUX;
+ ret = media_entity_pads_init(&vmux->subdev.entity, num_pads,
+ vmux->pads);
+ if (ret < 0)
+ return ret;
+
+ vmux->subdev.entity.ops = &video_mux_ops;
+
+ return v4l2_async_register_subdev(&vmux->subdev);
+}
+
+static int video_mux_remove(struct platform_device *pdev)
+{
+ struct video_mux *vmux = platform_get_drvdata(pdev);
+ struct v4l2_subdev *sd = &vmux->subdev;
+
+ v4l2_async_unregister_subdev(sd);
+ media_entity_cleanup(&sd->entity);
+
+ return 0;
+}
+
+static const struct of_device_id video_mux_dt_ids[] = {
+ { .compatible = "video-mux", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, video_mux_dt_ids);
+
+static struct platform_driver video_mux_driver = {
+ .probe = video_mux_probe,
+ .remove = video_mux_remove,
+ .driver = {
+ .of_match_table = video_mux_dt_ids,
+ .name = "video-mux",
+ },
+};
+
+module_platform_driver(video_mux_driver);
+
+MODULE_DESCRIPTION("video stream multiplexer");
+MODULE_AUTHOR("Sascha Hauer, Pengutronix");
+MODULE_AUTHOR("Philipp Zabel, Pengutronix");
+MODULE_LICENSE("GPL");
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-05-25 02:40 +0200 |
| Subject | [PATCH v7 34/34] media: imx: Drop warning upon multiple S_STREAM disable calls |
| Message-ID | <tKOYQ-Xd-73@gated-at.bofh.it> |
| In reply to | #1650065 |
From: Marek Vasut <marex@denx.de> Calling S_STREAM OFF multiple times on a video device is valid, although dubious, practice. Instead of warning about it and setting stream count lower than zero, just ignore the subsequent S_STREAM calls and correct the stream count to zero. Signed-off-by: Marek Vasut <marex@denx.de> --- drivers/staging/media/imx/imx-ic-prp.c | 3 ++- drivers/staging/media/imx/imx-ic-prpencvf.c | 3 ++- drivers/staging/media/imx/imx-media-csi.c | 3 ++- drivers/staging/media/imx/imx-media-vdic.c | 3 ++- drivers/staging/media/imx/imx6-mipi-csi2.c | 3 ++- 5 files changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/staging/media/imx/imx-ic-prp.c b/drivers/staging/media/imx/imx-ic-prp.c index 7bc293a..c34367e 100644 --- a/drivers/staging/media/imx/imx-ic-prp.c +++ b/drivers/staging/media/imx/imx-ic-prp.c @@ -387,7 +387,8 @@ static int prp_s_stream(struct v4l2_subdev *sd, int enable) update_count: priv->stream_count += enable ? 1 : -1; - WARN_ON(priv->stream_count < 0); + if (priv->stream_count < 0) + priv->stream_count = 0; out: mutex_unlock(&priv->lock); return ret; diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c b/drivers/staging/media/imx/imx-ic-prpencvf.c index 5e9c817..ed363fe 100644 --- a/drivers/staging/media/imx/imx-ic-prpencvf.c +++ b/drivers/staging/media/imx/imx-ic-prpencvf.c @@ -1140,7 +1140,8 @@ static int prp_s_stream(struct v4l2_subdev *sd, int enable) update_count: priv->stream_count += enable ? 1 : -1; - WARN_ON(priv->stream_count < 0); + if (priv->stream_count < 0) + priv->stream_count = 0; out: mutex_unlock(&priv->lock); return ret; diff --git a/drivers/staging/media/imx/imx-media-csi.c b/drivers/staging/media/imx/imx-media-csi.c index 4ab401d..0ec3176 100644 --- a/drivers/staging/media/imx/imx-media-csi.c +++ b/drivers/staging/media/imx/imx-media-csi.c @@ -861,7 +861,8 @@ static int csi_s_stream(struct v4l2_subdev *sd, int enable) update_count: priv->stream_count += enable ? 1 : -1; - WARN_ON(priv->stream_count < 0); + if (priv->stream_count < 0) + priv->stream_count = 0; out: mutex_unlock(&priv->lock); return ret; diff --git a/drivers/staging/media/imx/imx-media-vdic.c b/drivers/staging/media/imx/imx-media-vdic.c index c0b6d7f..7eabdc4 100644 --- a/drivers/staging/media/imx/imx-media-vdic.c +++ b/drivers/staging/media/imx/imx-media-vdic.c @@ -536,7 +536,8 @@ static int vdic_s_stream(struct v4l2_subdev *sd, int enable) update_count: priv->stream_count += enable ? 1 : -1; - WARN_ON(priv->stream_count < 0); + if (priv->stream_count < 0) + priv->stream_count = 0; out: mutex_unlock(&priv->lock); return ret; diff --git a/drivers/staging/media/imx/imx6-mipi-csi2.c b/drivers/staging/media/imx/imx6-mipi-csi2.c index 49bc2c2..cfaf34a 100644 --- a/drivers/staging/media/imx/imx6-mipi-csi2.c +++ b/drivers/staging/media/imx/imx6-mipi-csi2.c @@ -396,7 +396,8 @@ static int csi2_s_stream(struct v4l2_subdev *sd, int enable) update_count: csi2->stream_count += enable ? 1 : -1; - WARN_ON(csi2->stream_count < 0); + if (csi2->stream_count < 0) + csi2->stream_count = 0; out: mutex_unlock(&csi2->lock); return ret; -- 2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-05-25 02:50 +0200 |
| Subject | [PATCH v7 02/34] [media] dt-bindings: Add bindings for i.MX media driver |
| Message-ID | <tKP8t-11Y-1@gated-at.bofh.it> |
| In reply to | #1650065 |
Add bindings documentation for the i.MX media driver.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
Documentation/devicetree/bindings/media/imx.txt | 74 +++++++++++++++++++++++++
1 file changed, 74 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/imx.txt
diff --git a/Documentation/devicetree/bindings/media/imx.txt b/Documentation/devicetree/bindings/media/imx.txt
new file mode 100644
index 0000000..3059c06
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/imx.txt
@@ -0,0 +1,74 @@
+Freescale i.MX Media Video Device
+=================================
+
+Video Media Controller node
+---------------------------
+
+This is the media controller node for video capture support. It is a
+virtual device that lists the camera serial interface nodes that the
+media device will control.
+
+Required properties:
+- compatible : "fsl,imx-capture-subsystem";
+- ports : Should contain a list of phandles pointing to camera
+ sensor interface ports of IPU devices
+
+example:
+
+capture-subsystem {
+ compatible = "fsl,imx-capture-subsystem";
+ ports = <&ipu1_csi0>, <&ipu1_csi1>;
+};
+
+fim child node
+--------------
+
+This is an optional child node of the ipu_csi port nodes. If present and
+available, it enables the Frame Interval Monitor. Its properties can be
+used to modify the method in which the FIM measures frame intervals.
+Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
+Frame Interval Monitor.
+
+Optional properties:
+- fsl,input-capture-channel: an input capture channel and channel flags,
+ specified as <chan flags>. The channel number
+ must be 0 or 1. The flags can be
+ IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, or
+ IRQ_TYPE_EDGE_BOTH, and specify which input
+ capture signal edge will trigger the input
+ capture event. If an input capture channel is
+ specified, the FIM will use this method to
+ measure frame intervals instead of via the EOF
+ interrupt. The input capture method is much
+ preferred over EOF as it is not subject to
+ interrupt latency errors. However it requires
+ routing the VSYNC or FIELD output signals of
+ the camera sensor to one of the i.MX input
+ capture pads (SD1_DAT0, SD1_DAT1), which also
+ gives up support for SD1.
+
+
+mipi_csi2 node
+--------------
+
+This is the device node for the MIPI CSI-2 Receiver, required for MIPI
+CSI-2 sensors.
+
+Required properties:
+- compatible : "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2";
+- reg : physical base address and length of the register set;
+- clocks : the MIPI CSI-2 receiver requires three clocks: hsi_tx
+ (the D-PHY clock), video_27m (D-PHY PLL reference
+ clock), and eim_podf;
+- clock-names : must contain "dphy", "ref", "pix";
+- port@* : five port nodes must exist, containing endpoints
+ connecting to the source and sink devices according to
+ of_graph bindings. The first port is an input port,
+ connecting with a MIPI CSI-2 source, and ports 1
+ through 4 are output ports connecting with parallel
+ bus sink endpoint nodes and correspond to the four
+ MIPI CSI-2 virtual channel outputs.
+
+Optional properties:
+- interrupts : must contain two level-triggered interrupts,
+ in order: 100 and 101;
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-05-25 02:50 +0200 |
| Subject | [PATCH v7 10/34] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors |
| Message-ID | <tKP8t-11Y-11@gated-at.bofh.it> |
| In reply to | #1650065 |
Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.
The OV5640 connects to the input port on the MIPI CSI-2 receiver on
mipi_csi.
Until the OV5652 sensor module compatible with the SabreSD becomes
available for testing, the ov5642 node is currently disabled.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
arch/arm/boot/dts/imx6dl-sabresd.dts | 5 ++
arch/arm/boot/dts/imx6q-sabresd.dts | 5 ++
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 114 ++++++++++++++++++++++++++++++++-
3 files changed, 123 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6dl-sabresd.dts b/arch/arm/boot/dts/imx6dl-sabresd.dts
index 1e45f2f..9607afe 100644
--- a/arch/arm/boot/dts/imx6dl-sabresd.dts
+++ b/arch/arm/boot/dts/imx6dl-sabresd.dts
@@ -15,3 +15,8 @@
model = "Freescale i.MX6 DualLite SABRE Smart Device Board";
compatible = "fsl,imx6dl-sabresd", "fsl,imx6dl";
};
+
+&ipu1_csi1_from_ipu1_csi1_mux {
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+};
diff --git a/arch/arm/boot/dts/imx6q-sabresd.dts b/arch/arm/boot/dts/imx6q-sabresd.dts
index 9cbdfe7..527772b 100644
--- a/arch/arm/boot/dts/imx6q-sabresd.dts
+++ b/arch/arm/boot/dts/imx6q-sabresd.dts
@@ -23,3 +23,8 @@
&sata {
status = "okay";
};
+
+&ipu1_csi1_from_mipi_vc1 {
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 58055ce..342550d 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -10,6 +10,7 @@
* http://www.gnu.org/copyleft/gpl.html
*/
+#include <dt-bindings/clock/imx6qdl-clock.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
@@ -146,6 +147,36 @@
};
};
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <8>;
+ data-shift = <12>; /* Lines 19:12 used */
+ hsync-active = <1>;
+ vsync-active = <1>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&ov5642_to_ipu1_csi0_mux>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
+};
+
+&mipi_csi {
+ status = "okay";
+
+ port@0 {
+ reg = <0>;
+
+ mipi_csi2_in: endpoint {
+ remote-endpoint = <&ov5640_to_mipi_csi2>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+};
+
&audmux {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_audmux>;
@@ -213,7 +244,32 @@
0x8014 /* 4:FN_DMICCDAT */
0x0000 /* 5:Default */
>;
- };
+ };
+
+ ov5642: camera@3c {
+ compatible = "ovti,ov5642";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ov5642>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ clock-names = "xclk";
+ reg = <0x3c>;
+ DOVDD-supply = <&vgen4_reg>; /* 1.8v */
+ AVDD-supply = <&vgen3_reg>; /* 2.8v, rev C board is VGEN3
+ rev B board is VGEN5 */
+ DVDD-supply = <&vgen2_reg>; /* 1.5v*/
+ powerdown-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
+ status = "disabled";
+
+ port {
+ ov5642_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <8>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+ };
};
&i2c2 {
@@ -222,6 +278,32 @@
pinctrl-0 = <&pinctrl_i2c2>;
status = "okay";
+ ov5640: camera@3c {
+ compatible = "ovti,ov5640";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ov5640>;
+ reg = <0x3c>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ clock-names = "xclk";
+ DOVDD-supply = <&vgen4_reg>; /* 1.8v */
+ AVDD-supply = <&vgen3_reg>; /* 2.8v, rev C board is VGEN3
+ rev B board is VGEN5 */
+ DVDD-supply = <&vgen2_reg>; /* 1.5v*/
+ powerdown-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov5640_to_mipi_csi2: endpoint {
+ remote-endpoint = <&mipi_csi2_in>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+
pmic: pfuze100@08 {
compatible = "fsl,pfuze100";
reg = <0x08>;
@@ -425,6 +507,36 @@
>;
};
+ pinctrl_ipu1_csi0: ipu1csi0grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19 0x1b0b0
+ MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x1b0b0
+ MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC 0x1b0b0
+ MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC 0x1b0b0
+ >;
+ };
+
+ pinctrl_ov5640: ov5640grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT2__GPIO1_IO19 0x1b0b0
+ MX6QDL_PAD_SD1_CLK__GPIO1_IO20 0x1b0b0
+ >;
+ };
+
+ pinctrl_ov5642: ov5642grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT0__GPIO1_IO16 0x1b0b0
+ MX6QDL_PAD_SD1_DAT1__GPIO1_IO17 0x1b0b0
+ >;
+ };
+
pinctrl_pcie: pciegrp {
fsl,pins = <
MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Hans Verkuil <hverkuil@xs4all.nl> |
|---|---|
| Date | 2017-05-29 15:50 +0200 |
| Message-ID | <tMtdv-A4-5@gated-at.bofh.it> |
| In reply to | #1650065 |
Hi Steve, On 05/25/2017 02:29 AM, Steve Longerbeam wrote: > In version 7: > > - video-mux: switched to Philipp's latest video-mux driver and updated > bindings docs, that makes use of the mmio-mux framework. > > - mmio-mux: includes Philipp's temporary patch that adds mmio-mux support > to video-mux driver, until mux framework is merged. > > - mmio-mux: updates to device tree from Philipp that define the i.MX6 mux > devices and modifies the video-mux device to become a consumer of the > video mmio-mux. > > - minor updates to Documentation/media/v4l-drivers/imx.rst. > > - ov5640: do nothing if entity stream count is greater than 1 in > ov5640_s_stream(). > > - Previous versions of this driver had not tested the ability to enable > multiple independent streams, for instance enabling multiple output > pads from the imx6-mipi-csi2 subdevice, or enabling both prpenc and > prpvf outputs. Marek Vasut tested this support and reported issues > with it. > > v4l2_pipeline_inherit_controls() used the media graph walk APIs, but > that walks both sink and source pads, so if there are multiple paths > enabled to video capture devices, controls would be added to the wrong > video capture device, and no controls added to the other enabled > capture devices. > > These issues have been fixed. Control inheritance works correctly now > even with multiple enabled capture paths, and (for example) > simultaneous capture from prpenc and prpvf works also, and each with > independent scaling, CSC, and controls. For example prpenc can be > capturing with a 90 degree rotation, while prpvf is capturing with > vertical flip. > > So the v4l2_pipeline_inherit_controls() patch has been dropped. The > new version of control inheritance could be made generically available, > but it would be more involved to incorporate it into v4l2-core. > > - A new function imx_media_fill_default_mbus_fields() is added to setup > colorimetry at sink pads, and these are propagated to source pads. > > - Ensure that the current sink and source rectangles meet alignment > restrictions before applying a new rotation control setting in > prp-enc/vf subdevices. > > - Chain the s_stream() subdev calls instead of implementing a custom > stream on/off function that attempts to call a fixed set of subdevices > in a pipeline in the correct order. This also simplifies imx6-mipi-csi2 > subdevice, since the correct MIPI CSI-2 startup sequence can be > enforced completely in s_stream(), and s_power() is no longer > required. This also paves the way for more arbitrary OF graphs > external to the i.MX6. > > - Converted the v4l2_subdev and media_entity ops structures to const. What is the status as of v7? From what I can tell patch 2/34 needs an Ack from Rob Herring, patches 4-14 are out of scope for the media subsystem, patches 20-25 and 27-34 are all staging (so fine to be merged from my point of view). I'm not sure if patch 26 (defconfig) should be applied while the imx driver is in staging. I would suggest that this patch is moved to the end of the series. That leaves patches 15-19. I replied to patch 15 with a comment, patches 16-18 look good to me, although patches 17 and 18 should be combined to one patch since patch 17 won't compile otherwise. Any idea when the multiplexer is expected to be merged? (just curious) I would really like to get this merged for 4.13, so did I miss anything? From what I can tell it is really just an Ack for patch 2/34. Regards, Hans > > > Marek Vasut (1): > media: imx: Drop warning upon multiple S_STREAM disable calls > > Philipp Zabel (9): > dt-bindings: Add bindings for video-multiplexer device > ARM: dts: imx6qdl: add multiplexer controls > ARM: dts: imx6qdl: Add video multiplexers, mipi_csi, and their > connections > add mux and video interface bridge entity functions > platform: add video-multiplexer subdevice driver > platform: video-mux: include temporary mmio-mux support > media: imx: csi: increase burst size for YUV formats > media: imx: csi: add frame skipping support > media: imx: csi: add sink selection rectangles > > Russell King (3): > media: imx: csi: add support for bayer formats > media: imx: csi: add frame size/interval enumeration > media: imx: capture: add frame sizes/interval enumeration > > Steve Longerbeam (21): > [media] dt-bindings: Add bindings for i.MX media driver > [media] dt/bindings: Add bindings for OV5640 > ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node > ARM: dts: imx6qdl: add capture-subsystem device > ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround > ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors > ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors > ARM: dts: imx6-sabreauto: create i2cmux for i2c3 > ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b > ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture > ARM: dts: imx6-sabreauto: add the ADV7180 video decoder > [media] add Omnivision OV5640 sensor driver > media: Add userspace header file for i.MX > media: Add i.MX media core driver > media: imx: Add Capture Device Interface > media: imx: Add CSI subdev driver > media: imx: Add VDIC subdev driver > media: imx: Add IC subdev drivers > media: imx: Add MIPI CSI-2 Receiver subdev driver > ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers > media: imx: set and propagate default field, colorimetry > > .../devicetree/bindings/media/i2c/ov5640.txt | 45 + > Documentation/devicetree/bindings/media/imx.txt | 74 + > .../devicetree/bindings/media/video-mux.txt | 60 + > Documentation/media/uapi/mediactl/media-types.rst | 22 + > Documentation/media/v4l-drivers/imx.rst | 590 ++++++ > arch/arm/boot/dts/imx6dl-sabrelite.dts | 5 + > arch/arm/boot/dts/imx6dl-sabresd.dts | 5 + > arch/arm/boot/dts/imx6dl.dtsi | 189 ++ > arch/arm/boot/dts/imx6q-sabrelite.dts | 5 + > arch/arm/boot/dts/imx6q-sabresd.dts | 5 + > arch/arm/boot/dts/imx6q.dtsi | 125 ++ > arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 144 +- > arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 152 +- > arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 114 +- > arch/arm/boot/dts/imx6qdl.dtsi | 20 +- > arch/arm/configs/imx_v6_v7_defconfig | 11 + > drivers/media/i2c/Kconfig | 9 + > drivers/media/i2c/Makefile | 1 + > drivers/media/i2c/ov5640.c | 2224 ++++++++++++++++++++ > drivers/media/platform/Kconfig | 6 + > drivers/media/platform/Makefile | 2 + > drivers/media/platform/video-mux.c | 357 ++++ > drivers/staging/media/Kconfig | 2 + > drivers/staging/media/Makefile | 1 + > drivers/staging/media/imx/Kconfig | 20 + > drivers/staging/media/imx/Makefile | 12 + > drivers/staging/media/imx/TODO | 15 + > drivers/staging/media/imx/imx-ic-common.c | 113 + > drivers/staging/media/imx/imx-ic-prp.c | 514 +++++ > drivers/staging/media/imx/imx-ic-prpencvf.c | 1309 ++++++++++++ > drivers/staging/media/imx/imx-ic.h | 38 + > drivers/staging/media/imx/imx-media-capture.c | 775 +++++++ > drivers/staging/media/imx/imx-media-csi.c | 1842 ++++++++++++++++ > drivers/staging/media/imx/imx-media-dev.c | 665 ++++++ > drivers/staging/media/imx/imx-media-fim.c | 463 ++++ > drivers/staging/media/imx/imx-media-internal-sd.c | 349 +++ > drivers/staging/media/imx/imx-media-of.c | 268 +++ > drivers/staging/media/imx/imx-media-utils.c | 896 ++++++++ > drivers/staging/media/imx/imx-media-vdic.c | 1009 +++++++++ > drivers/staging/media/imx/imx-media.h | 326 +++ > drivers/staging/media/imx/imx6-mipi-csi2.c | 697 ++++++ > include/linux/imx-media.h | 27 + > include/media/imx.h | 15 + > include/uapi/linux/media.h | 6 + > include/uapi/linux/v4l2-controls.h | 4 + > 45 files changed, 13504 insertions(+), 27 deletions(-) > create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt > create mode 100644 Documentation/devicetree/bindings/media/imx.txt > create mode 100644 Documentation/devicetree/bindings/media/video-mux.txt > create mode 100644 Documentation/media/v4l-drivers/imx.rst > create mode 100644 drivers/media/i2c/ov5640.c > create mode 100644 drivers/media/platform/video-mux.c > create mode 100644 drivers/staging/media/imx/Kconfig > create mode 100644 drivers/staging/media/imx/Makefile > create mode 100644 drivers/staging/media/imx/TODO > create mode 100644 drivers/staging/media/imx/imx-ic-common.c > create mode 100644 drivers/staging/media/imx/imx-ic-prp.c > create mode 100644 drivers/staging/media/imx/imx-ic-prpencvf.c > create mode 100644 drivers/staging/media/imx/imx-ic.h > create mode 100644 drivers/staging/media/imx/imx-media-capture.c > create mode 100644 drivers/staging/media/imx/imx-media-csi.c > create mode 100644 drivers/staging/media/imx/imx-media-dev.c > create mode 100644 drivers/staging/media/imx/imx-media-fim.c > create mode 100644 drivers/staging/media/imx/imx-media-internal-sd.c > create mode 100644 drivers/staging/media/imx/imx-media-of.c > create mode 100644 drivers/staging/media/imx/imx-media-utils.c > create mode 100644 drivers/staging/media/imx/imx-media-vdic.c > create mode 100644 drivers/staging/media/imx/imx-media.h > create mode 100644 drivers/staging/media/imx/imx6-mipi-csi2.c > create mode 100644 include/linux/imx-media.h > create mode 100644 include/media/imx.h >
[toc] | [prev] | [next] | [standalone]
| From | Philipp Zabel <p.zabel@pengutronix.de> |
|---|---|
| Date | 2017-05-29 16:20 +0200 |
| Message-ID | <tMtGx-13B-1@gated-at.bofh.it> |
| In reply to | #1652535 |
On Mon, 2017-05-29 at 15:46 +0200, Hans Verkuil wrote: > Hi Steve, > > On 05/25/2017 02:29 AM, Steve Longerbeam wrote: > > In version 7: > > > > - video-mux: switched to Philipp's latest video-mux driver and updated > > bindings docs, that makes use of the mmio-mux framework. > > > > - mmio-mux: includes Philipp's temporary patch that adds mmio-mux support > > to video-mux driver, until mux framework is merged. > > > > - mmio-mux: updates to device tree from Philipp that define the i.MX6 mux > > devices and modifies the video-mux device to become a consumer of the > > video mmio-mux. > > > > - minor updates to Documentation/media/v4l-drivers/imx.rst. > > > > - ov5640: do nothing if entity stream count is greater than 1 in > > ov5640_s_stream(). > > > > - Previous versions of this driver had not tested the ability to enable > > multiple independent streams, for instance enabling multiple output > > pads from the imx6-mipi-csi2 subdevice, or enabling both prpenc and > > prpvf outputs. Marek Vasut tested this support and reported issues > > with it. > > > > v4l2_pipeline_inherit_controls() used the media graph walk APIs, but > > that walks both sink and source pads, so if there are multiple paths > > enabled to video capture devices, controls would be added to the wrong > > video capture device, and no controls added to the other enabled > > capture devices. > > > > These issues have been fixed. Control inheritance works correctly now > > even with multiple enabled capture paths, and (for example) > > simultaneous capture from prpenc and prpvf works also, and each with > > independent scaling, CSC, and controls. For example prpenc can be > > capturing with a 90 degree rotation, while prpvf is capturing with > > vertical flip. > > > > So the v4l2_pipeline_inherit_controls() patch has been dropped. The > > new version of control inheritance could be made generically available, > > but it would be more involved to incorporate it into v4l2-core. > > > > - A new function imx_media_fill_default_mbus_fields() is added to setup > > colorimetry at sink pads, and these are propagated to source pads. > > > > - Ensure that the current sink and source rectangles meet alignment > > restrictions before applying a new rotation control setting in > > prp-enc/vf subdevices. > > > > - Chain the s_stream() subdev calls instead of implementing a custom > > stream on/off function that attempts to call a fixed set of subdevices > > in a pipeline in the correct order. This also simplifies imx6-mipi-csi2 > > subdevice, since the correct MIPI CSI-2 startup sequence can be > > enforced completely in s_stream(), and s_power() is no longer > > required. This also paves the way for more arbitrary OF graphs > > external to the i.MX6. > > > > - Converted the v4l2_subdev and media_entity ops structures to const. > > What is the status as of v7? > > From what I can tell patch 2/34 needs an Ack from Rob Herring, patches > 4-14 are out of scope for the media subsystem, patches 20-25 and 27-34 > are all staging (so fine to be merged from my point of view). > > I'm not sure if patch 26 (defconfig) should be applied while the imx > driver is in staging. I would suggest that this patch is moved to the end > of the series. > > That leaves patches 15-19. I replied to patch 15 with a comment, patches > 16-18 look good to me, although patches 17 and 18 should be combined to one > patch since patch 17 won't compile otherwise. Is this a problem? It won't break any builds as patch 17 depends on CONFIG_MULTIPLEXER, which doesn't exist yet. I'm fine with merging the two patches, though. > Any idea when the multiplexer is expected to be merged? (just curious) I have no idea. v15 of the multiplexer framework patchset was posted on 2017-05-14, is still waiting for comments. > I would really like to get this merged for 4.13, so did I miss anything? Seconded, and not that I can tell. > From what I can tell it is really just an Ack for patch 2/34. regards Philipp
[toc] | [prev] | [next] | [standalone]
| From | Hans Verkuil <hverkuil@xs4all.nl> |
|---|---|
| Date | 2017-05-29 16:30 +0200 |
| Message-ID | <tMtQe-17n-11@gated-at.bofh.it> |
| In reply to | #1652549 |
On 05/29/2017 04:15 PM, Philipp Zabel wrote: > On Mon, 2017-05-29 at 15:46 +0200, Hans Verkuil wrote: >> Hi Steve, >> >> On 05/25/2017 02:29 AM, Steve Longerbeam wrote: >>> In version 7: >>> >>> - video-mux: switched to Philipp's latest video-mux driver and updated >>> bindings docs, that makes use of the mmio-mux framework. >>> >>> - mmio-mux: includes Philipp's temporary patch that adds mmio-mux support >>> to video-mux driver, until mux framework is merged. >>> >>> - mmio-mux: updates to device tree from Philipp that define the i.MX6 mux >>> devices and modifies the video-mux device to become a consumer of the >>> video mmio-mux. >>> >>> - minor updates to Documentation/media/v4l-drivers/imx.rst. >>> >>> - ov5640: do nothing if entity stream count is greater than 1 in >>> ov5640_s_stream(). >>> >>> - Previous versions of this driver had not tested the ability to enable >>> multiple independent streams, for instance enabling multiple output >>> pads from the imx6-mipi-csi2 subdevice, or enabling both prpenc and >>> prpvf outputs. Marek Vasut tested this support and reported issues >>> with it. >>> >>> v4l2_pipeline_inherit_controls() used the media graph walk APIs, but >>> that walks both sink and source pads, so if there are multiple paths >>> enabled to video capture devices, controls would be added to the wrong >>> video capture device, and no controls added to the other enabled >>> capture devices. >>> >>> These issues have been fixed. Control inheritance works correctly now >>> even with multiple enabled capture paths, and (for example) >>> simultaneous capture from prpenc and prpvf works also, and each with >>> independent scaling, CSC, and controls. For example prpenc can be >>> capturing with a 90 degree rotation, while prpvf is capturing with >>> vertical flip. >>> >>> So the v4l2_pipeline_inherit_controls() patch has been dropped. The >>> new version of control inheritance could be made generically available, >>> but it would be more involved to incorporate it into v4l2-core. >>> >>> - A new function imx_media_fill_default_mbus_fields() is added to setup >>> colorimetry at sink pads, and these are propagated to source pads. >>> >>> - Ensure that the current sink and source rectangles meet alignment >>> restrictions before applying a new rotation control setting in >>> prp-enc/vf subdevices. >>> >>> - Chain the s_stream() subdev calls instead of implementing a custom >>> stream on/off function that attempts to call a fixed set of subdevices >>> in a pipeline in the correct order. This also simplifies imx6-mipi-csi2 >>> subdevice, since the correct MIPI CSI-2 startup sequence can be >>> enforced completely in s_stream(), and s_power() is no longer >>> required. This also paves the way for more arbitrary OF graphs >>> external to the i.MX6. >>> >>> - Converted the v4l2_subdev and media_entity ops structures to const. >> >> What is the status as of v7? >> >> From what I can tell patch 2/34 needs an Ack from Rob Herring, patches >> 4-14 are out of scope for the media subsystem, patches 20-25 and 27-34 >> are all staging (so fine to be merged from my point of view). >> >> I'm not sure if patch 26 (defconfig) should be applied while the imx >> driver is in staging. I would suggest that this patch is moved to the end >> of the series. >> >> That leaves patches 15-19. I replied to patch 15 with a comment, patches >> 16-18 look good to me, although patches 17 and 18 should be combined to one >> patch since patch 17 won't compile otherwise. > > Is this a problem? It won't break any builds as patch 17 depends on > CONFIG_MULTIPLEXER, which doesn't exist yet. I'm fine with merging the > two patches, though. You are right, but it is weird. I think I would prefer to have these two merged and the #ifdef CONFIG_MULTIPLEXER bits removed. Just a note in the commit log that this should be converted to the multiplexer when that gets merged would be enough. Dead code in drivers/media should be avoided because that's what this driver currently has. Regards, Hans > >> Any idea when the multiplexer is expected to be merged? (just curious) > > I have no idea. v15 of the multiplexer framework patchset was posted on > 2017-05-14, is still waiting for comments. > >> I would really like to get this merged for 4.13, so did I miss anything? > > Seconded, and not that I can tell. > >> From what I can tell it is really just an Ack for patch 2/34. > > regards > Philipp >
[toc] | [prev] | [next] | [standalone]
| From | Hans Verkuil <hverkuil@xs4all.nl> |
|---|---|
| Date | 2017-05-29 17:30 +0200 |
| Message-ID | <tMuMi-1KX-23@gated-at.bofh.it> |
| In reply to | #1652554 |
On 05/29/2017 04:21 PM, Hans Verkuil wrote: > On 05/29/2017 04:15 PM, Philipp Zabel wrote: >> On Mon, 2017-05-29 at 15:46 +0200, Hans Verkuil wrote: >>> Hi Steve, >>> >>> On 05/25/2017 02:29 AM, Steve Longerbeam wrote: >>>> In version 7: >>>> >>>> - video-mux: switched to Philipp's latest video-mux driver and updated >>>> bindings docs, that makes use of the mmio-mux framework. >>>> >>>> - mmio-mux: includes Philipp's temporary patch that adds mmio-mux support >>>> to video-mux driver, until mux framework is merged. >>>> >>>> - mmio-mux: updates to device tree from Philipp that define the i.MX6 mux >>>> devices and modifies the video-mux device to become a consumer of the >>>> video mmio-mux. >>>> >>>> - minor updates to Documentation/media/v4l-drivers/imx.rst. >>>> >>>> - ov5640: do nothing if entity stream count is greater than 1 in >>>> ov5640_s_stream(). >>>> >>>> - Previous versions of this driver had not tested the ability to enable >>>> multiple independent streams, for instance enabling multiple output >>>> pads from the imx6-mipi-csi2 subdevice, or enabling both prpenc and >>>> prpvf outputs. Marek Vasut tested this support and reported issues >>>> with it. >>>> >>>> v4l2_pipeline_inherit_controls() used the media graph walk APIs, but >>>> that walks both sink and source pads, so if there are multiple paths >>>> enabled to video capture devices, controls would be added to the wrong >>>> video capture device, and no controls added to the other enabled >>>> capture devices. >>>> >>>> These issues have been fixed. Control inheritance works correctly now >>>> even with multiple enabled capture paths, and (for example) >>>> simultaneous capture from prpenc and prpvf works also, and each with >>>> independent scaling, CSC, and controls. For example prpenc can be >>>> capturing with a 90 degree rotation, while prpvf is capturing with >>>> vertical flip. >>>> >>>> So the v4l2_pipeline_inherit_controls() patch has been dropped. The >>>> new version of control inheritance could be made generically available, >>>> but it would be more involved to incorporate it into v4l2-core. >>>> >>>> - A new function imx_media_fill_default_mbus_fields() is added to setup >>>> colorimetry at sink pads, and these are propagated to source pads. >>>> >>>> - Ensure that the current sink and source rectangles meet alignment >>>> restrictions before applying a new rotation control setting in >>>> prp-enc/vf subdevices. >>>> >>>> - Chain the s_stream() subdev calls instead of implementing a custom >>>> stream on/off function that attempts to call a fixed set of subdevices >>>> in a pipeline in the correct order. This also simplifies imx6-mipi-csi2 >>>> subdevice, since the correct MIPI CSI-2 startup sequence can be >>>> enforced completely in s_stream(), and s_power() is no longer >>>> required. This also paves the way for more arbitrary OF graphs >>>> external to the i.MX6. >>>> >>>> - Converted the v4l2_subdev and media_entity ops structures to const. >>> >>> What is the status as of v7? >>> >>> From what I can tell patch 2/34 needs an Ack from Rob Herring, patches >>> 4-14 are out of scope for the media subsystem, patches 20-25 and 27-34 >>> are all staging (so fine to be merged from my point of view). >>> >>> I'm not sure if patch 26 (defconfig) should be applied while the imx >>> driver is in staging. I would suggest that this patch is moved to the end >>> of the series. >>> >>> That leaves patches 15-19. I replied to patch 15 with a comment, patches >>> 16-18 look good to me, although patches 17 and 18 should be combined to one >>> patch since patch 17 won't compile otherwise. >> >> Is this a problem? It won't break any builds as patch 17 depends on >> CONFIG_MULTIPLEXER, which doesn't exist yet. I'm fine with merging the >> two patches, though. > > You are right, but it is weird. I think I would prefer to have these two > merged and the #ifdef CONFIG_MULTIPLEXER bits removed. Just a note in the > commit log that this should be converted to the multiplexer when that gets > merged would be enough. > > Dead code in drivers/media should be avoided because that's what this > driver currently has. Thanks for those updates! That really leaves just an Ack for patch 2/34. Sooo close! Regards, Hans
[toc] | [prev] | [next] | [standalone]
| From | Sakari Ailus <sakari.ailus@iki.fi> |
|---|---|
| Date | 2017-05-29 17:40 +0200 |
| Message-ID | <tMuVY-1P8-45@gated-at.bofh.it> |
| In reply to | #1652535 |
Hi Hans, On Mon, May 29, 2017 at 03:46:08PM +0200, Hans Verkuil wrote: > Hi Steve, > > On 05/25/2017 02:29 AM, Steve Longerbeam wrote: > >In version 7: > > > >- video-mux: switched to Philipp's latest video-mux driver and updated > > bindings docs, that makes use of the mmio-mux framework. > > > >- mmio-mux: includes Philipp's temporary patch that adds mmio-mux support > > to video-mux driver, until mux framework is merged. > > > >- mmio-mux: updates to device tree from Philipp that define the i.MX6 mux > > devices and modifies the video-mux device to become a consumer of the > > video mmio-mux. > > > >- minor updates to Documentation/media/v4l-drivers/imx.rst. > > > >- ov5640: do nothing if entity stream count is greater than 1 in > > ov5640_s_stream(). > > > >- Previous versions of this driver had not tested the ability to enable > > multiple independent streams, for instance enabling multiple output > > pads from the imx6-mipi-csi2 subdevice, or enabling both prpenc and > > prpvf outputs. Marek Vasut tested this support and reported issues > > with it. > > > > v4l2_pipeline_inherit_controls() used the media graph walk APIs, but > > that walks both sink and source pads, so if there are multiple paths > > enabled to video capture devices, controls would be added to the wrong > > video capture device, and no controls added to the other enabled > > capture devices. > > > > These issues have been fixed. Control inheritance works correctly now > > even with multiple enabled capture paths, and (for example) > > simultaneous capture from prpenc and prpvf works also, and each with > > independent scaling, CSC, and controls. For example prpenc can be > > capturing with a 90 degree rotation, while prpvf is capturing with > > vertical flip. > > > > So the v4l2_pipeline_inherit_controls() patch has been dropped. The > > new version of control inheritance could be made generically available, > > but it would be more involved to incorporate it into v4l2-core. > > > >- A new function imx_media_fill_default_mbus_fields() is added to setup > > colorimetry at sink pads, and these are propagated to source pads. > > > >- Ensure that the current sink and source rectangles meet alignment > > restrictions before applying a new rotation control setting in > > prp-enc/vf subdevices. > > > >- Chain the s_stream() subdev calls instead of implementing a custom > > stream on/off function that attempts to call a fixed set of subdevices > > in a pipeline in the correct order. This also simplifies imx6-mipi-csi2 > > subdevice, since the correct MIPI CSI-2 startup sequence can be > > enforced completely in s_stream(), and s_power() is no longer > > required. This also paves the way for more arbitrary OF graphs > > external to the i.MX6. > > > >- Converted the v4l2_subdev and media_entity ops structures to const. > > What is the status as of v7? > > From what I can tell patch 2/34 needs an Ack from Rob Herring, patches > 4-14 are out of scope for the media subsystem, patches 20-25 and 27-34 > are all staging (so fine to be merged from my point of view). > > I'm not sure if patch 26 (defconfig) should be applied while the imx > driver is in staging. I would suggest that this patch is moved to the end > of the series. > > That leaves patches 15-19. I replied to patch 15 with a comment, patches > 16-18 look good to me, although patches 17 and 18 should be combined to one > patch since patch 17 won't compile otherwise. Any idea when the multiplexer is > expected to be merged? (just curious) > > I would really like to get this merged for 4.13, so did I miss anything? > From what I can tell it is really just an Ack for patch 2/34. The patchset re-initialises the control handler in the video node in its media device link_setup callback, among other things. I don't think that this as such should prevent including the driver in staging, but at the same time my concern is what kind of guarantees can we give in terms of V4L2 framework support on things like this using the current API. I'd say "none". If there's a need for this (there should not be, as the controls are exposed to the user space through the sub-device nodes as the other drivers do), the framework APIs need to be extended. I think it'd be good to add a TODO file (such as the one in OMAP4ISS) as part of the patchset that would include a list of things left to do so they're not forgotten. -- Regards, Sakari Ailus e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk
[toc] | [prev] | [next] | [standalone]
| From | Hans Verkuil <hverkuil@xs4all.nl> |
|---|---|
| Date | 2017-05-29 18:30 +0200 |
| Message-ID | <tMvIm-2qR-11@gated-at.bofh.it> |
| In reply to | #1652603 |
On 05/29/2017 05:36 PM, Sakari Ailus wrote: > Hi Hans, > > On Mon, May 29, 2017 at 03:46:08PM +0200, Hans Verkuil wrote: >> Hi Steve, >> >> On 05/25/2017 02:29 AM, Steve Longerbeam wrote: >>> In version 7: >>> >>> - video-mux: switched to Philipp's latest video-mux driver and updated >>> bindings docs, that makes use of the mmio-mux framework. >>> >>> - mmio-mux: includes Philipp's temporary patch that adds mmio-mux support >>> to video-mux driver, until mux framework is merged. >>> >>> - mmio-mux: updates to device tree from Philipp that define the i.MX6 mux >>> devices and modifies the video-mux device to become a consumer of the >>> video mmio-mux. >>> >>> - minor updates to Documentation/media/v4l-drivers/imx.rst. >>> >>> - ov5640: do nothing if entity stream count is greater than 1 in >>> ov5640_s_stream(). >>> >>> - Previous versions of this driver had not tested the ability to enable >>> multiple independent streams, for instance enabling multiple output >>> pads from the imx6-mipi-csi2 subdevice, or enabling both prpenc and >>> prpvf outputs. Marek Vasut tested this support and reported issues >>> with it. >>> >>> v4l2_pipeline_inherit_controls() used the media graph walk APIs, but >>> that walks both sink and source pads, so if there are multiple paths >>> enabled to video capture devices, controls would be added to the wrong >>> video capture device, and no controls added to the other enabled >>> capture devices. >>> >>> These issues have been fixed. Control inheritance works correctly now >>> even with multiple enabled capture paths, and (for example) >>> simultaneous capture from prpenc and prpvf works also, and each with >>> independent scaling, CSC, and controls. For example prpenc can be >>> capturing with a 90 degree rotation, while prpvf is capturing with >>> vertical flip. >>> >>> So the v4l2_pipeline_inherit_controls() patch has been dropped. The >>> new version of control inheritance could be made generically available, >>> but it would be more involved to incorporate it into v4l2-core. >>> >>> - A new function imx_media_fill_default_mbus_fields() is added to setup >>> colorimetry at sink pads, and these are propagated to source pads. >>> >>> - Ensure that the current sink and source rectangles meet alignment >>> restrictions before applying a new rotation control setting in >>> prp-enc/vf subdevices. >>> >>> - Chain the s_stream() subdev calls instead of implementing a custom >>> stream on/off function that attempts to call a fixed set of subdevices >>> in a pipeline in the correct order. This also simplifies imx6-mipi-csi2 >>> subdevice, since the correct MIPI CSI-2 startup sequence can be >>> enforced completely in s_stream(), and s_power() is no longer >>> required. This also paves the way for more arbitrary OF graphs >>> external to the i.MX6. >>> >>> - Converted the v4l2_subdev and media_entity ops structures to const. >> >> What is the status as of v7? >> >> From what I can tell patch 2/34 needs an Ack from Rob Herring, patches >> 4-14 are out of scope for the media subsystem, patches 20-25 and 27-34 >> are all staging (so fine to be merged from my point of view). >> >> I'm not sure if patch 26 (defconfig) should be applied while the imx >> driver is in staging. I would suggest that this patch is moved to the end >> of the series. >> >> That leaves patches 15-19. I replied to patch 15 with a comment, patches >> 16-18 look good to me, although patches 17 and 18 should be combined to one >> patch since patch 17 won't compile otherwise. Any idea when the multiplexer is >> expected to be merged? (just curious) >> >> I would really like to get this merged for 4.13, so did I miss anything? >> From what I can tell it is really just an Ack for patch 2/34. > > The patchset re-initialises the control handler in the video node in its > media device link_setup callback, among other things. I don't think that > this as such should prevent including the driver in staging, but at the same > time my concern is what kind of guarantees can we give in terms of V4L2 > framework support on things like this using the current API. I'd say "none". > > If there's a need for this (there should not be, as the controls are exposed > to the user space through the sub-device nodes as the other drivers do), the > framework APIs need to be extended. > > I think it'd be good to add a TODO file (such as the one in OMAP4ISS) as > part of the patchset that would include a list of things left to do so > they're not forgotten. > A TODO file, that's a very good point. Yes, we need that. Regards, Hans
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-05-29 20:20 +0200 |
| Message-ID | <tMxqN-3H0-3@gated-at.bofh.it> |
| In reply to | #1652603 |
Hi Sakari, On 05/29/2017 08:36 AM, Sakari Ailus wrote: > Hi Hans, > > On Mon, May 29, 2017 at 03:46:08PM +0200, Hans Verkuil wrote: >> Hi Steve, >> >> On 05/25/2017 02:29 AM, Steve Longerbeam wrote: >>> In version 7: >>> >>> - video-mux: switched to Philipp's latest video-mux driver and updated >>> bindings docs, that makes use of the mmio-mux framework. >>> >>> - mmio-mux: includes Philipp's temporary patch that adds mmio-mux support >>> to video-mux driver, until mux framework is merged. >>> >>> - mmio-mux: updates to device tree from Philipp that define the i.MX6 mux >>> devices and modifies the video-mux device to become a consumer of the >>> video mmio-mux. >>> >>> - minor updates to Documentation/media/v4l-drivers/imx.rst. >>> >>> - ov5640: do nothing if entity stream count is greater than 1 in >>> ov5640_s_stream(). >>> >>> - Previous versions of this driver had not tested the ability to enable >>> multiple independent streams, for instance enabling multiple output >>> pads from the imx6-mipi-csi2 subdevice, or enabling both prpenc and >>> prpvf outputs. Marek Vasut tested this support and reported issues >>> with it. >>> >>> v4l2_pipeline_inherit_controls() used the media graph walk APIs, but >>> that walks both sink and source pads, so if there are multiple paths >>> enabled to video capture devices, controls would be added to the wrong >>> video capture device, and no controls added to the other enabled >>> capture devices. >>> >>> These issues have been fixed. Control inheritance works correctly now >>> even with multiple enabled capture paths, and (for example) >>> simultaneous capture from prpenc and prpvf works also, and each with >>> independent scaling, CSC, and controls. For example prpenc can be >>> capturing with a 90 degree rotation, while prpvf is capturing with >>> vertical flip. >>> >>> So the v4l2_pipeline_inherit_controls() patch has been dropped. The >>> new version of control inheritance could be made generically available, >>> but it would be more involved to incorporate it into v4l2-core. >>> >>> - A new function imx_media_fill_default_mbus_fields() is added to setup >>> colorimetry at sink pads, and these are propagated to source pads. >>> >>> - Ensure that the current sink and source rectangles meet alignment >>> restrictions before applying a new rotation control setting in >>> prp-enc/vf subdevices. >>> >>> - Chain the s_stream() subdev calls instead of implementing a custom >>> stream on/off function that attempts to call a fixed set of subdevices >>> in a pipeline in the correct order. This also simplifies imx6-mipi-csi2 >>> subdevice, since the correct MIPI CSI-2 startup sequence can be >>> enforced completely in s_stream(), and s_power() is no longer >>> required. This also paves the way for more arbitrary OF graphs >>> external to the i.MX6. >>> >>> - Converted the v4l2_subdev and media_entity ops structures to const. >> What is the status as of v7? >> >> From what I can tell patch 2/34 needs an Ack from Rob Herring, patches >> 4-14 are out of scope for the media subsystem, patches 20-25 and 27-34 >> are all staging (so fine to be merged from my point of view). >> >> I'm not sure if patch 26 (defconfig) should be applied while the imx >> driver is in staging. I would suggest that this patch is moved to the end >> of the series. >> >> That leaves patches 15-19. I replied to patch 15 with a comment, patches >> 16-18 look good to me, although patches 17 and 18 should be combined to one >> patch since patch 17 won't compile otherwise. Any idea when the multiplexer is >> expected to be merged? (just curious) >> >> I would really like to get this merged for 4.13, so did I miss anything? >> From what I can tell it is really just an Ack for patch 2/34. > The patchset re-initialises the control handler in the video node in its > media device link_setup callback, among other things. I don't think that > this as such should prevent including the driver in staging, but at the same > time my concern is what kind of guarantees can we give in terms of V4L2 > framework support on things like this using the current API. I'd say "none". Re-initializing a control handler in itself works fine (maybe we should add a v4l2_ctrl_handler_reinit() ?). I agree that calling free/init/add at this time (in link_setup and link_notify) is a new way to use those APIs. The effect is that a video node's controls can change post driver load. There's nothing in Documentation/kapi/v4l2-controls.rst that states that a video node's control list can't change at runtime. But as I said free/init/add works just fine and can be called any time after a subdevice or video device is registered. > > If there's a need for this (there should not be, as the controls are exposed > to the user space through the sub-device nodes as the other drivers do), the > framework APIs need to be extended. Right, this gets back to the media framework usability arguments. At least myself, Philipp, and Russell feel that automatic inheritance of a configured pipeline's controls to a video device adds to the usability. > > I think it'd be good to add a TODO file (such as the one in OMAP4ISS) as > part of the patchset that would include a list of things left to do so > they're not forgotten. Right, there is a TODO, but I will add an item that mentions this included feature and whether it should eventually become part of the framework or dropped. Steve
[toc] | [prev] | [next] | [standalone]
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2017-05-31 22:20 +0200 |
| Message-ID | <tNig2-13n-11@gated-at.bofh.it> |
| In reply to | #1652682 |
[Multipart message — attachments visible in raw view] — view raw
Hi! > >If there's a need for this (there should not be, as the controls are exposed > >to the user space through the sub-device nodes as the other drivers do), the > >framework APIs need to be extended. > > Right, this gets back to the media framework usability arguments. At least > myself, Philipp, and Russell feel that automatic inheritance of a configured > pipeline's controls to a video device adds to the usability. For the record, usability can be pretty much fixed in v4l-utils... I have patches that try ioctls on a list of fd's. Now we need a way to find out which /dev/video* files belong to single camera. I believe kernel already has required APIs, we just need to apply v4l-utils patch to use them... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[toc] | [prev] | [next] | [standalone]
| From | Hans Verkuil <hverkuil@xs4all.nl> |
|---|---|
| Date | 2017-05-29 19:30 +0200 |
| Message-ID | <tMwEp-37j-3@gated-at.bofh.it> |
| In reply to | #1652535 |
On 05/29/2017 07:23 PM, Steve Longerbeam wrote: > Hi Hans, thanks for the reply... > > > On 05/29/2017 06:46 AM, Hans Verkuil wrote: >> Hi Steve, >> >> On 05/25/2017 02:29 AM, Steve Longerbeam wrote: >>> In version 7: >>> >>> >> >> What is the status as of v7? >> >> From what I can tell patch 2/34 needs an Ack from Rob Herring, > > > Yes still missing that Ack. I think the issue is likely the Synopsys DW > mipi csi-2 bindings. Someone earlier noted that there is another driver > under devel for this Synopsys core, with another set of bindings. > But it was determined that in fact this is a different device with a > different register set. > > From what I remember of dealing with Synopsys cores in the past, > these cores are highly configurable using their coreBuilder tools. So > while the other device might stem from the same initial core from > Synopsys, it was probably built with different design parameters > compared to the core that exists in the i.MX6. So in essence it is a > different device. > > >> patches >> 4-14 are out of scope for the media subsystem, > > Ok. I did submit patches 4-14 to the right set of folks. Should I just > drop this set in the next submission if they have not changed? No, please keep them. Just make a note in the cover letter that they go through a different tree. I like seeing the whole set :-) >> patches 20-25 and 27-34 >> are all staging (so fine to be merged from my point of view). >> >> I'm not sure if patch 26 (defconfig) should be applied while the imx >> driver is in staging. I would suggest that this patch is moved to the end >> of the series. > > Ok. > >> >> That leaves patches 15-19. I replied to patch 15 with a comment, patches >> 16-18 look good to me, although patches 17 and 18 should be combined >> to one >> patch since patch 17 won't compile otherwise. Any idea when the >> multiplexer is >> expected to be merged? (just curious) > > Philipp replied separately. > >> >> I would really like to get this merged for 4.13, so did I miss anything? >> From what I can tell it is really just an Ack for patch 2/34. > > Agreed. Can you split off the TODO file in its own patch? It was buried in the big patch and I missed it because of that. Take a look at Sakari's comment from today about another TODO item that probably should be in the TODO file. Regards, Hans Regards, Hans
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | linux.kernel
csiph-web