diff options
Diffstat (limited to '')
| -rw-r--r-- | Documentation/admin-guide/media/imx.rst (renamed from Documentation/media/v4l-drivers/imx.rst) | 227 |
1 files changed, 118 insertions, 109 deletions
diff --git a/Documentation/media/v4l-drivers/imx.rst b/Documentation/admin-guide/media/imx.rst index 1246573c1019..b8fa70f854fd 100644 --- a/Documentation/media/v4l-drivers/imx.rst +++ b/Documentation/admin-guide/media/imx.rst @@ -102,6 +102,35 @@ Some of the features of this driver include: problems with the ADV718x video decoders. +Topology +-------- + +The following shows the media topologies for the i.MX6Q SabreSD and +i.MX6Q SabreAuto. Refer to these diagrams in the entity descriptions +in the next section. + +The i.MX5/6 topologies can differ upstream from the IPUv3 CSI video +multiplexers, but the internal IPUv3 topology downstream from there +is common to all i.MX5/6 platforms. For example, the SabreSD, with the +MIPI CSI-2 OV5640 sensor, requires the i.MX6 MIPI CSI-2 receiver. But +the SabreAuto has only the ADV7180 decoder on a parallel bt.656 bus, and +therefore does not require the MIPI CSI-2 receiver, so it is missing in +its graph. + +.. _imx6q_topology_graph: + +.. kernel-figure:: imx6q-sabresd.dot + :alt: Diagram of the i.MX6Q SabreSD media pipeline topology + :align: center + + Media pipeline graph on i.MX6Q SabreSD + +.. kernel-figure:: imx6q-sabreauto.dot + :alt: Diagram of the i.MX6Q SabreAuto media pipeline topology + :align: center + + Media pipeline graph on i.MX6Q SabreAuto + Entities -------- @@ -191,14 +220,7 @@ or unqualified interlaced). The capture interface will enforce the same field order as the source pad field order (interlaced-bt if source pad is seq-bt, interlaced-tb if source pad is seq-tb). -This subdev can generate the following event when enabling the second -IDMAC source pad: - -- V4L2_EVENT_IMX_FRAME_INTERVAL_ERROR - -The user application can subscribe to this event from the ipuX_csiY -subdev node. This event is generated by the Frame Interval Monitor -(see below for more on the FIM). +For events produced by ipuX_csiY, see ref:`imx_api_ipuX_csiY`. Cropping in ipuX_csiY --------------------- @@ -247,84 +269,7 @@ rate by half at the IDMAC output source pad: Frame Interval Monitor in ipuX_csiY ----------------------------------- -The adv718x decoders can occasionally send corrupt fields during -NTSC/PAL signal re-sync (too little or too many video lines). When -this happens, the IPU triggers a mechanism to re-establish vertical -sync by adding 1 dummy line every frame, which causes a rolling effect -from image to image, and can last a long time before a stable image is -recovered. Or sometimes the mechanism doesn't work at all, causing a -permanent split image (one frame contains lines from two consecutive -captured images). - -From experiment it was found that during image rolling, the frame -intervals (elapsed time between two EOF's) drop below the nominal -value for the current standard, by about one frame time (60 usec), -and remain at that value until rolling stops. - -While the reason for this observation isn't known (the IPU dummy -line mechanism should show an increase in the intervals by 1 line -time every frame, not a fixed value), we can use it to detect the -corrupt fields using a frame interval monitor. If the FIM detects a -bad frame interval, the ipuX_csiY subdev will send the event -V4L2_EVENT_IMX_FRAME_INTERVAL_ERROR. Userland can register with -the FIM event notification on the ipuX_csiY subdev device node. -Userland can issue a streaming restart when this event is received -to correct the rolling/split image. - -The ipuX_csiY subdev includes custom controls to tweak some dials for -FIM. If one of these controls is changed during streaming, the FIM will -be reset and will continue at the new settings. - -- V4L2_CID_IMX_FIM_ENABLE - -Enable/disable the FIM. - -- V4L2_CID_IMX_FIM_NUM - -How many frame interval measurements to average before comparing against -the nominal frame interval reported by the sensor. This can reduce noise -caused by interrupt latency. - -- V4L2_CID_IMX_FIM_TOLERANCE_MIN - -If the averaged intervals fall outside nominal by this amount, in -microseconds, the V4L2_EVENT_IMX_FRAME_INTERVAL_ERROR event is sent. - -- V4L2_CID_IMX_FIM_TOLERANCE_MAX - -If any intervals are higher than this value, those samples are -discarded and do not enter into the average. This can be used to -discard really high interval errors that might be due to interrupt -latency from high system load. - -- V4L2_CID_IMX_FIM_NUM_SKIP - -How many frames to skip after a FIM reset or stream restart before -FIM begins to average intervals. - -- V4L2_CID_IMX_FIM_ICAP_CHANNEL -- V4L2_CID_IMX_FIM_ICAP_EDGE - -These controls will configure an input capture channel as the method -for measuring frame intervals. This is superior to the default method -of measuring frame intervals via EOF interrupt, since it is not subject -to uncertainty errors introduced by interrupt latency. - -Input capture requires hardware support. A VSYNC signal must be routed -to one of the i.MX6 input capture channel pads. - -V4L2_CID_IMX_FIM_ICAP_CHANNEL configures which i.MX6 input capture -channel to use. This must be 0 or 1. - -V4L2_CID_IMX_FIM_ICAP_EDGE configures which signal edge will trigger -input capture events. By default the input capture method is disabled -with a value of IRQ_TYPE_NONE. Set this control to IRQ_TYPE_EDGE_RISING, -IRQ_TYPE_EDGE_FALLING, or IRQ_TYPE_EDGE_BOTH to enable input capture, -triggered on the given signal edge(s). - -When input capture is disabled, frame intervals will be measured via -EOF interrupt. - +See ref:`imx_api_FIM`. ipuX_vdic --------- @@ -461,8 +406,8 @@ The following are specific usage notes for the Sabre* reference boards: -SabreLite with OV5642 and OV5640 --------------------------------- +i.MX6Q SabreLite with OV5642 and OV5640 +--------------------------------------- This platform requires the OmniVision OV5642 module with a parallel camera interface, and the OV5640 module with a MIPI CSI-2 @@ -631,44 +576,108 @@ used to select any supported YUV pixelformat on /dev/video2. This platform accepts Composite Video analog inputs to the ADV7180 on Ain1 (connector J42). -SabreSD with MIPI CSI-2 OV5640 ------------------------------- +i.MX6Q SabreSD with MIPI CSI-2 OV5640 +------------------------------------- -Similarly to SabreLite, the SabreSD supports a parallel interface -OV5642 module on IPU1 CSI0, and a MIPI CSI-2 OV5640 module. The OV5642 -connects to i2c bus 1 and the OV5640 to i2c bus 2. +Similarly to i.MX6Q SabreLite, the i.MX6Q SabreSD supports a parallel +interface OV5642 module on IPU1 CSI0, and a MIPI CSI-2 OV5640 +module. The OV5642 connects to i2c bus 1 and the OV5640 to i2c bus 2. The device tree for SabreSD includes OF graphs for both the parallel OV5642 and the MIPI CSI-2 OV5640, but as of this writing only the MIPI CSI-2 OV5640 has been tested, so the OV5642 node is currently disabled. -The OV5640 module connects to MIPI connector J5 (sorry I don't have the -compatible module part number or URL). +The OV5640 module connects to MIPI connector J5. The NXP part number +for the OV5640 module that connects to the SabreSD board is H120729. + +The following example configures unprocessed video capture pipeline to +capture from the OV5640, transmitting on MIPI CSI-2 virtual channel 0: + +.. code-block:: none + + # Setup links + media-ctl -l "'ov5640 1-003c':0 -> 'imx6-mipi-csi2':0[1]" + media-ctl -l "'imx6-mipi-csi2':1 -> 'ipu1_csi0_mux':0[1]" + media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" + media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]" + # Configure pads + media-ctl -V "'ov5640 1-003c':0 [fmt:UYVY2X8/640x480]" + media-ctl -V "'imx6-mipi-csi2':1 [fmt:UYVY2X8/640x480]" + media-ctl -V "'ipu1_csi0_mux':0 [fmt:UYVY2X8/640x480]" + media-ctl -V "'ipu1_csi0':0 [fmt:AYUV32/640x480]" + +Streaming can then begin on "ipu1_csi0 capture" node. The v4l2-ctl +tool can be used to select any supported pixelformat on the capture +device node. + +To determine what is the /dev/video node correspondent to +"ipu1_csi0 capture": + +.. code-block:: none + + media-ctl -e "ipu1_csi0 capture" + /dev/video0 + +/dev/video0 is the streaming element in this case. + +Starting the streaming via v4l2-ctl: + +.. code-block:: none + + v4l2-ctl --stream-mmap -d /dev/video0 + +Starting the streaming via Gstreamer and sending the content to the display: + +.. code-block:: none + + gst-launch-1.0 v4l2src device=/dev/video0 ! kmssink The following example configures a direct conversion pipeline to capture -from the OV5640, transmitting on MIPI CSI-2 virtual channel 1. $sensorfmt -can be any format supported by the OV5640. $sensordim is the frame -dimension part of $sensorfmt (minus the mbus pixel code). $outputfmt can -be any format supported by the ipu1_ic_prpenc entity at its output pad: +from the OV5640, transmitting on MIPI CSI-2 virtual channel 0. It also +shows colorspace conversion and scaling at IC output. .. code-block:: none # Setup links media-ctl -l "'ov5640 1-003c':0 -> 'imx6-mipi-csi2':0[1]" - media-ctl -l "'imx6-mipi-csi2':2 -> 'ipu1_csi1':0[1]" - media-ctl -l "'ipu1_csi1':1 -> 'ipu1_ic_prp':0[1]" + media-ctl -l "'imx6-mipi-csi2':1 -> 'ipu1_csi0_mux':0[1]" + media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" + media-ctl -l "'ipu1_csi0':1 -> 'ipu1_ic_prp':0[1]" media-ctl -l "'ipu1_ic_prp':1 -> 'ipu1_ic_prpenc':0[1]" media-ctl -l "'ipu1_ic_prpenc':1 -> 'ipu1_ic_prpenc capture':0[1]" # Configure pads - media-ctl -V "'ov5640 1-003c':0 [fmt:$sensorfmt field:none]" - media-ctl -V "'imx6-mipi-csi2':2 [fmt:$sensorfmt field:none]" - media-ctl -V "'ipu1_csi1':1 [fmt:AYUV32/$sensordim field:none]" - media-ctl -V "'ipu1_ic_prp':1 [fmt:AYUV32/$sensordim field:none]" - media-ctl -V "'ipu1_ic_prpenc':1 [fmt:$outputfmt field:none]" + media-ctl -V "'ov5640 1-003c':0 [fmt:UYVY2X8/640x480]" + media-ctl -V "'imx6-mipi-csi2':1 [fmt:UYVY2X8/640x480]" + media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/640x480]" + media-ctl -V "'ipu1_csi0':1 [fmt:AYUV32/640x480]" + media-ctl -V "'ipu1_ic_prp':1 [fmt:AYUV32/640x480]" + media-ctl -V "'ipu1_ic_prpenc':1 [fmt:ARGB8888_1X32/800x600]" + # Set a format at the capture interface + v4l2-ctl -d /dev/video1 --set-fmt-video=pixelformat=RGB3 + +Streaming can then begin on "ipu1_ic_prpenc capture" node. + +To determine what is the /dev/video node correspondent to +"ipu1_ic_prpenc capture": + +.. code-block:: none + + media-ctl -e "ipu1_ic_prpenc capture" + /dev/video1 -Streaming can then begin on "ipu1_ic_prpenc capture" node. The v4l2-ctl -tool can be used to select any supported YUV or RGB pixelformat on the -capture device node. +/dev/video1 is the streaming element in this case. + +Starting the streaming via v4l2-ctl: + +.. code-block:: none + + v4l2-ctl --stream-mmap -d /dev/video1 + +Starting the streaming via Gstreamer and sending the content to the display: + +.. code-block:: none + + gst-launch-1.0 v4l2src device=/dev/video1 ! kmssink Known Issues ------------ |